[GeoMechanicsApplication] Bug: Initialization in test_helper of staged analysis has side-effects on available variables

[rfaasse]

[GeoMechanicsApplication] Bug: Initialization in test_helper of staged analysis has side-effects on available variables

[rfaasse]

Moving this to the backlog to not lose sight of it, but moving it out of this sprint.

FYI @indigocoral

[WPK4FEM]

Curiously the script applications\GeoMechanicsApplication\MainKratos_multiple_stages_template.py shows the fixed way.

The Kratos_stages.py script that is shared around and the one with stages in separate directories share the "wrong" way.
These are found in applications\GeoMechanicsApplication\python_scripts\ run_multiple_stages.py and run_multiple_separated_stages.py
These should be "fixed".

I think we can safely switch to the proposed way.

[rfaasse]

While implementing the fix, as found in the description, we encountered the following issue (and failing test):
It is not possible, after running a single stage (which initializes the elements and nodes etc in the model) to add new nodal solution step variables:

Therefore we have three options as far as I can see:

1. We use the current way of constructing stages, which will not crash when an earlier stage defines less dofs than a later stage. However, this will result in the described bug: all stages will have all dofs.
2. We change the current way of constructing stages to the proposed way in the description, which means the situation in point 1 will crash, but when stage 1 has more dofs than stage 2, these will not be removed, so the amount of dofs still won't always be consistent with the input files. However, in the 'bug' scenario at least the user would be aware that something is inconsistent.
3. We discuss the possibility of adding functionality to the modelpart to add and remove dofs between stages. This would be changing 'core' functionality, so in my opinion this would be out of scope for a quick fix of this bug.