[Core] Adding deprecation message to CheckSameModelPartUsingSkinDistanceProcess + check dimension

[loumalouomega]

📝 Description

Adding deprecation message to CheckSameModelPartUsingSkinDistanceProcess + check dimension. Also adding pure model part constructor as well.

After comment from #10704

🆕 Changelog

• Adding deprecation message to CheckSameModelPartUsingSkinDistanceProcess + check dimension
• Adding model part constructors
• Expose to python

[rubenzorrilla]

I'd check that the ProcessInfo has the domain size to throw a meaningful error if not provided.

[rubenzorrilla]

Why adding a pure model part constructor? The line of the project is to promote the model-based ones. If the reasoning behind is to use more than one model, in my opinion giving this possibility is not a good idea. Note that the line of the project is to have a unique Model container, also in the multistage case.

[loumalouomega]

(yes, that's the idea, @pooyan-dadvand wants to use it to check it in CoSim and the same model is not guaranteed)

[rubenzorrilla]

Though this is a fair usage, I'm not sure if we want to open this possibility in the entire Kratos core. To be discussed in @KratosMultiphysics/technical-committee.

[rubenzorrilla]

Giving support to "multi-model" simulations is out of the scope of this PR and must be discussed by the @KratosMultiphysics/technical-committee.

[loumalouomega]

Giving support to "multi-model" simulations is out of the scope of this PR and must be discussed by the @KratosMultiphysics/technical-committee.

1. I commented the code
2. There are many processes with modelpart in the constructor instead of Models (specially the old ones)

[rubenzorrilla]

2. There are many processes with modelpart in the constructor instead of Models (specially the old ones)

Exactly, these come from the pre-model era. New ones must use the model. This is why I said "The line of the project is to promote the model-based ones".

[rubenzorrilla]

@KratosMultiphysics/technical-committee has been discussing about the points raised by @rubenzorrilla.

1. About the "multi-model" support. Even though in the context of CoSimulation this might be a fair usage, we would stick to current design guidelines and have a unique Model container. If in the future this becomes in a technical limitation we will reopen the "multi-model" discussion again.

2. About the multiple constructors. The @KratosMultiphysics/technical-committee agrees on promoting Model-parameters ones because this eases a lot code maintenance and allows standarized factories. However, there might be cases in which other constructors might handy or even required (e.g. passing a linear solver). Hence, we wouldn't ban the addition of new constructors provided a technical justification.

[loumalouomega]

@rubenzorrilla I already removed (commented) the two modelpart constructor. In that case, this is ready. Anyway, the problem will be the CoSimulation design itself.

[philbucher]

Anyway, the problem will be the CoSimulation design itself.

for the record, Aditya and I raised those concerns VERY LOUDLY during the implementation of the "single model" strategy

IMO this is a limitation of the "single model" design

[loumalouomega]

Anyway, the problem will be the CoSimulation design itself.

for the record, Aditya and I raised those concerns VERY LOUDLY during the implementation of the "single model" strategy

IMO this is a limitation of the "single model" design

I wasn't in that discussion, I just realized that design limitation as soon as I started with the implementation...

[loumalouomega]

I forgot what this about...

[loumalouomega]

I forgot what this about...

@rubenzorrilla do you remember?

[loumalouomega]

I forgot what this about...

@rubenzorrilla do you remember?

Hellooooooooooooooooooooooo

[loumalouomega]

At last!, I don't even remember what was this PR doing :P