[StructuralMechanicsApplication] Only check constitutive laws when an element is active

[rfaasse]

📝 Description
During testing with the structural elements, we found that inactive elements lead to issues in the workflow. The reason is that all on all elements, the Check function is called (see the check in ModelPart), while only the active elements are initialized (see the EntitiesUtilities). Since the constitutive law vector is only created when an element is Initialized (meaning, when it's active), the check on the constitutive law should only been done when the element is active.

This PR adds that check, including unit tests to describe + test this behavior.

[matekelemen]

How often does Element::Check get invoked?

As far as I see, the call stack traces back all the way to AnalysisStage::Initialize and is never invoked during later stages of the analysis. This means that skipping the checks on initially inactive Elements that get activated later on remain unchecked throughout the run.

Though I don't think this is a big issue, I'd try to properly initialize Elements before the solution loop, even if they're inactive in the beginning. Unless of course the algorithm you're implementing makes this impossible.

[loumalouomega]

How often does Element::Check get invoked?

As far as I see, the call stack traces back all the way to AnalysisStage::Initialize and is never invoked during later stages of the analysis. This means that skipping the checks on initially inactive Elements that get activated later on remain unchecked throughout the run.

Though I don't think this is a big issue, I'd try to properly initialize Elements before the solution loop, even if they're inactive in the beginning. Unless of course the algorithm you're implementing makes this impossible.

I don't know. Bu IMHO all elements should be initialized despite being active/inactive. Opinion @KratosMultiphysics/technical-committee ¿?

[rfaasse]

How often does Element::Check get invoked?
As far as I see, the call stack traces back all the way to AnalysisStage::Initialize and is never invoked during later stages of the analysis. This means that skipping the checks on initially inactive Elements that get activated later on remain unchecked throughout the run.
Though I don't think this is a big issue, I'd try to properly initialize Elements before the solution loop, even if they're inactive in the beginning. Unless of course the algorithm you're implementing makes this impossible.

I don't know. Bu IMHO all elements should be initialized despite being active/inactive. Opinion @KratosMultiphysics/technical-committee ¿?

In my understanding, Element::Check is indeed called once, at the start of a stage/calculation. I see two solutions:

• Either the core part is kept as is (i.e. only initialize inactive elements, but check all), we take it into account in our check functions and leave it up to processes which would re-activate elements to initialize and check them. This is the route we take here, since it has the least amount of impact on the rest of the code base.
• The InitializeEntities function is adjusted, such that also inactive entities are initialized. Here, I don't oversee all consequences, but maybe indeed the @KratosMultiphysics/technical-committee can help.

There is one more possibility (only check and initialize active elements in core), but the consequences are similar to that of the first bullet point.

FYI @KratosMultiphysics/geomechanics

[matekelemen]

I'd go with the second option to make inits/checks consistent, but I see what you mean. EntitiesUtilities::InitializeEntities is called from Scheme::InitializeElements and Scheme::InitializeConditions, which in turn is called from a bunch of places.

Still, I think it's worth giving it a try in the CI.

[rubenzorrilla]

My two cents in here

I don't know. Bu IMHO all elements should be initialized despite being active/inactive. Opinion @KratosMultiphysics/technical-committee ¿?

About @loumalouomega 's point, I agree. A very simple rationale is that some elements / conditions can be activated or deactivated on the fly depending on the numerical technique you're using.

As far as I see, the call stack traces back all the way to AnalysisStage::Initialize and is never invoked during later stages of the analysis. This means that skipping the checks on initially inactive Elements that get activated later on remain unchecked throughout the run.

Yes. Initialize is (and must be) called once except in those cases involving remeshing.

Though I don't think this is a big issue, I'd try to properly initialize Elements before the solution loop, even if they're inactive in the beginning. Unless of course the algorithm you're implementing makes this impossible.

I think this is the safe way to go. Initialize and check everything and then deactivate.

I'd go with the second option to make inits/checks consistent, but I see what you mean. EntitiesUtilities::InitializeEntities is called from Scheme::InitializeElements and Scheme::InitializeConditions, which in turn is called from a bunch of places.

We are currently on the process of redesigning the strategies and schemes. Taking this into account, I'd "survive" with current design but take into account these observations for the future one.

[rfaasse]

Thanks for all of your inputs! I created a (draft) PR to make the initialization unconditional (see #13119) to see what the pipelines will do. This would make the initialization consistent with the calling of Check on entities, as well as with other functions (in the EntitiesUtilities, you'll see that e.g. InitializeSolutionStep etc is also done unconditionally)