[Core] Level set convection - allowing using a custom element

[ddiezrod]

📝 Description We are very interested in altair in being able to use the level set convection process from kratos core. However, the main problem is that we want to be able to use our own elements, as their formulation cannot be shared openly.

With these minimum changes we will be able to do so. My proposal here is to check if the "element_type" matches the available element types in the process. If it is not there, we throw a messa and try to use this string directly and get the element from Kratos Components.

I think it is not big harm for the rest of the users and will help us a lot.

🆕 Changelog

• Adding option to use custom element in level set convection process.

[rubenzorrilla]

Indeed, now I remember that we designed this in such a way that you can internally override these methods to add your custom elements.

[ddiezrod]

Indeed, now I remember that we designed this in such a way that you can internally override these methods to add your custom elements.

I tried to do that https://github.com/KratosMultiphysics/Kratos/pull/9042 I think this is not such a big change to make everything work. Anyway, I can always copy-paste this into our side and forget about kratos core, although that is not the way I prefer to do things...

[rubenzorrilla]

Indeed, now I remember that we designed this in such a way that you can internally override these methods to add your custom elements.

I tried to do that #9042 I think this is not such a big change to make everything work. Anyway, I can always copy-paste this into our side and forget about kratos core, although that is not the way I prefer to do things...

Not very nice but maybe we can add the custom_ keyword in front of your custom element names. Then, if the element is not found and there is no custom_ keyword in front, we keep the current user-friendly error thrown. If the element is not found but there is the custom_ keyword in front we go to the KratosComponents as you suggest. What you think?

[ddiezrod]

Not very nice but maybe we can add the custom_ keyword in front of your custom element names. Then, if the element is not found and there is no custom_ keyword in front, we keep the current user-friendly error thrown. If the element is not found but there is the custom_ keyword in front we go to the KratosComponents as you suggest. What you think?

If your concern is that user does not get a correct error message, I can check if the element exists with

&KratosComponents<Element>::Has(element_register_name)

and if it is not there throw a error message that explains clearly to the user what happened.

[rubenzorrilla]

Not very nice but maybe we can add the custom_ keyword in front of your custom element names. Then, if the element is not found and there is no custom_ keyword in front, we keep the current user-friendly error thrown. If the element is not found but there is the custom_ keyword in front we go to the KratosComponents as you suggest. What you think?

If your concern is that user does not get a correct error message, I can check if the element exists with

&KratosComponents<Element>::Has(element_register_name)

and if it is not there throw a error message that explains clearly to the user what happened.

My concern is that your proposal doesn't return the list of available elements as the error thrown is managed by the KratosComponents. This is IMO quite important for non-experienced users, specially for those that use the packaged version (with no code access).

I think that we can achieve this with your Has proposal.

[ddiezrod]

@rubenzorrilla I added a test which shows the error as a user will see it, is that ok to you?

[rubenzorrilla]

@rubenzorrilla I added a test which shows the error as a user will see it, is that ok to you?

Yes. This is great, we keep previous usability while adding the possibility to use custom elements. Thanks!

[ddiezrod]

Thanks @rubenzorrilla , merging!