Revamp "builder_and_solver_settings" for StructuralMechanicsAnalysis

[matekelemen]

Changes

Choosing and configuring a BuilderAndSolver in a solver is weird and inconsistent with other types of settings such as configuring a SolvingStrategy.

This PR refactors what StructuralMechanicsSolver expects in "builder_and_solver_settings"

...
"builder_and_solver_settings" : {
+   "type" : "block",
-   "use_block_builder" : true,
-   "use_lagrange_BS" : false,
    "advanced_settings" : {}
}
...

Now "type" is the only parameter that decides which BuilderAndSolver to use. Current options are

• "block" refers to ResidualbasedBlockBuilderAndSolver
• "block_lagrange" refers to ResidualbasedBlockBuilderAndSolverWithLagrangeMultiplier
• "elimination" refers to either ResidualBasedEliminationBuilderAndSolver or ResidualBasedEliminationBuilderAndSolverWithConstraints, depending on whether the system has constraints

This makes it much easier and cleaner to integrate more BuilderAndSolver types. The current system is still supported, but will issue a deprecation warning.

Notes

The "block_builder" flag in the solver's settings has been deprecated for 5 years. I tried removing it but saw that most downstream apps, as well as test cases still heavily use this setting, and even add new code using it. Please don't ignore deprecation warnings.

A quick grep shows the following applications using this deprecated setting:

> rg "\"block_builder\"" -l | rg "applications/(\w*)/.*" -or '$1' | sort | uniq
ConvectionDiffusionApplication
CSharpWrapperApplication
DamApplication
FemToDemApplication
FluidTransportApplication
GeoMechanicsApplication
IgaApplication
MPMApplication
PfemFluidDynamicsApplication
PoromechanicsApplication
SolidMechanicsApplication
StructuralMechanicsApplication
TrilinosApplication

@KratosMultiphysics/dem @KratosMultiphysics/geomechanics @KratosMultiphysics/nurbs-breps @KratosMultiphysics/mpm @KratosMultiphysics/pfem @KratosMultiphysics/poromechanics @trilinos

[loumalouomega]

I would agree if the @KratosMultiphysics/technical-committee agrees, specially if @KratosMultiphysics/fluid-dynamics in order to be consistent

[rubenzorrilla]

Honestly I'd avoid this considering that we're getting rid of the B&S soon. Instead, I'd discuss the I/O for the new building settings.

[matekelemen]

Without this PR, however I try to add my B&S from #13276 will be a massive hack. I'd prefer transitioning to the new strategies from a cleaner state rather than an ugly one.

[RiccardoRossi]

my problem with this is that it destroys the backward compatibility.

we need to have a mechanism that if someone has a old file using the old mechanism it still works

on the line of:

if(parameters.Has(block_builder_and_solver) : 
    throw watning 
    type = block
else
    ...

[matekelemen]

we need to have a mechanism that if someone has a old file using the old mechanism it still works

@RiccardoRossi

Kratos/applications/StructuralMechanicsApplication/python_scripts/structural_mechanics_solver.py

Line 566 in a5f7c97

def __ConvertDeprecatedSettings(self, settings: KratosMultiphysics.Parameters) -> None:

JSONs (ProjectParameters.json) can use the old mechanism. I did exactly what has been done with other deprecated settings: support them but throw a deprecation warning.

[matekelemen]

By the way, our approach to deprecation is completely broken.

The deprecated settings you see in StructuralMechanicsSolver are at least 5 years old, and they are impossible to remove because many applications (even the structural mechanics application itself) still use them, so the CI wouldn't pass. At this rate, we won't ever be able to get rid of deprecated features/settings.

Relying on the due diligence of downstream developers to update their code is clearly not working if there is no threat of their code eventually breaking one day.

[loumalouomega]

By the way, our approach to deprecation is completely broken.

The deprecated settings you see in StructuralMechanicsSolver are at least 5 years old, and they are impossible to remove because many applications (even the structural mechanics application itself) still use them, so the CI wouldn't pass. At this rate, we won't ever be able to get rid of deprecated features/settings.

Relying on the due diligence of downstream developers to update their code is clearly not working if there is no threat that their code will break one day.

The other day I removed the mesh_id of the processes. I understand the concerns. Maybe we need something to properly manage consistently the deprecation, I will think about it.

[loumalouomega]

By the way, our approach to deprecation is completely broken.
The deprecated settings you see in StructuralMechanicsSolver are at least 5 years old, and they are impossible to remove because many applications (even the structural mechanics application itself) still use them, so the CI wouldn't pass. At this rate, we won't ever be able to get rid of deprecated features/settings.
Relying on the due diligence of downstream developers to update their code is clearly not working if there is no threat that their code will break one day.

The other day I removed the mesh_id of the processes. I understand the concerns. Maybe we need something to properly manage consistently the deprecation, I will think about it.

For example adding special tags in the parameters and a method to specifically validate parameters including deprecated ones, I need to think about it.

[philbucher]

Having dealt with this particular problem a frustratingly high number of times, my recommendation is to go ahead with this PR and continue to adapt it for future developments when the need arises. Otherwise, as @matekelemen states, this is a big blocker for progress/developments

[matekelemen]

I need a review on this PR @KratosMultiphysics/structural-mechanics.

my problem with this is that it destroys the backward compatibility.

we need to have a mechanism that if someone has a old file using the old mechanism it still works

on the line of:

if(parameters.Has(block_builder_and_solver) : 
    throw watning 
    type = block
else
    ...

@RiccardoRossi I'm not sure whether I got my point across last time: I'm already doing this.

[philbucher]

Makes sense to me, proper cleanup 👍🏻

[philbucher]

I think its time to issue an error. This has been deprecated for years

[RiccardoRossi]

ok, this makes sense also for me.

@KratosMultiphysics/technical-committee has the final decision ... (and also should take a look at the deprecation comment)

[AlejandroCornejo]

ok, this makes sense also for me.

@KratosMultiphysics/technical-committee has the final decision ... (and also should take a look at the deprecation comment)

maybe we also need to update our GiD interface...

[RiccardoRossi]

we should, nevertheless the old version should still work

[RiccardoRossi]

@KratosMultiphysics/technical-committee agrees provided that backward compatibility is guaranteed (which i understand is the case).

I will open a separate issue to decide what to do about "historically deprecated" stuff

[RiccardoRossi]

@matekelemen why you did not merge this finally?