[Core] Enabling the possibility of adding variables from processes

[ddiezrod]

📝 Description This is more or less the same as https://github.com/KratosMultiphysics/Kratos/pull/9117 but using the registry (so it works in cpp and python)

The idea is to use the registry to obtain the variables that a process needs to be added to a model part at the very beginning before model parts are even imported. This improves a lot the modularity as you will not need to always add this variable in the solver.

I adapted apply_inlet_process from FluidDynApp to use this new capability.

[loumalouomega]

I will wait for test foor final review

[rubenzorrilla]

Great. As it involves changing a few crucial classes I'll add it for the next @KratosMultiphysics/technical-committee discussion. Nevertheless, at first glance everything makes sense for me.

[ddiezrod]

Test added.

[ddiezrod]

@loumalouomega lucky me, there was already a test with exactly same name in ContactStructApp, I have changed the name there because I think it is more clear that way

[pooyan-dadvand]

@KratosMultiphysics/technical-committee had a discussion about this and the main question is if we should go for the static member our virtual one. Here are pros and cons: Static:

• Prototype would be optional
• No need to implement the default constructor in all Processes
• It needs registry for dispatching the method (That can check if is with prototype or direct use of static function)
• Having the common implementation in the base class is not possible (To be done in a template<ClassType, BaseType> utility)
• GetDefaultVariables is virtual and we cannot call it. The idea is to have Specification as static member and GetDefaultVariable uses that as a default implementation

Edit The possibility of using virtual functions has been dismissed because of practical issues, in particular of the last point of the ones listed below.

• More flexible in hierarchy
• No need for registry involvement
• It needs default constructor for all processes (Several processes has reference to the modepart which should be changed to pointer)

[rubenzorrilla]

Note for myself: after (re-)discussing this in the @KratosMultiphysics/technical-committee we decided to basically mimic what is in the GetSpecifications of the element but making it static.

[philbucher]

Note for myself: after (re-)discussing this in the @KratosMultiphysics/technical-committee we decided to basically mimic what is in the GetSpecifications of the element but making it static.

static methods cannot be virtual :/

[rubenzorrilla]

Note for myself: after (re-)discussing this in the @KratosMultiphysics/technical-committee we decided to basically mimic what is in the GetSpecifications of the element but making it static.

static methods cannot be virtual :/

Yes... this is the price we will be paying.

[philbucher]

@rubenzorrilla I dont understand the technical solution What you propose does not work in C++