Kratos: Strategies do not consistently implement SolveSolutionStep

[philbucher]

when doing #1909 I found out that many Strategies do not implement SolveSolutionStep
@RiccardoRossi says that we should use
~
InitializeSolutionStep
Predict
SolveSolutionStep # only this one can be called several times within one timestep
FinalizeSolutionStep
~
instead of Solve, because if we have to repeat Timesteps (e.g. for the inner coupling loop in FSI) then we should only call SolveSolutionStep

This issue is a reminder, I guess a proper solution would be to properly divide the things done in Solveinto the separate functions.

In addition one could e.g. remove the virtual from the BaseClass

@KratosMultiphysics/technical-committee

[armingeiser]

I think a similar issue also exists for the solvers. In PR #1675 I proposed to at least throw an error in the LinearSolver base class if SolveSolutionStep is not overwritten.

[philbucher]

@armingeiser it is the exact same problem :D
since the number of strategies is not as large as the linear solvers, I think it would be possible to change the structure of them

It does not have to be done, at least for the basic ones I think it would make sense

[RiccardoRossi]

+1 for adding this to the strategies

[philbucher]

I talked to the developers here and they would adapt the Strategies in StructuralMechanics

@RiccardoRossi if you agree I could do the same separation for the LinearStrategy in the Core

[loumalouomega]

I use a modifies NR for contact. What is supposed to be changed?

El vie., 20 abr. 2018 17:35, Philipp Bucher [e-mail]
escribió:

I talked to the developers here and they would adapt the Strategies in
StructuralMechanics

@RiccardoRossi https://github.com/RiccardoRossi if you agree I could do
the same separation for the LinearStrategy in the Core

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/KratosMultiphysics/Kratos/issues/1911#issuecomment-383135107,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ATEMgM5lp-mKLBO0ias3rQpeDP7Ovh66ks5tqgBBgaJpZM4TdL8V
.

[philbucher]

@loumalouomega from what I can see you NR is fine
It seems to correctly implement the functions above

[philbucher]

Hi guys
I did the separation for the Linear Strategy in #1962
The following strategies are remaining in StructuralMechanics, as previously discussed:

• [ ] EigensolverStrategy @msandre
• [ ] HarmonicAnalysisStrategy @qaumann
• [ ] MechanicalExplicitStrategy @KlausBSautter

Please have a look at what I did in #1962 , e.g. replacing the boost timer by the builtin one

I think also the FSStrategy needs some refactoring @jcotela ?

[jcotela]

@philbucher the FSStrategy is currently patched with a quick-and-dirty solution, so it should work (@mpentek can tell you if there are any remaining problems). I have to look into achieving a better fitting to the standard, but the FSStrategy has always been a bit "special" in this regard.

[KlausBSautter]

@philbucher I changed it but I'll wait until #1962 is merged :metal:

[msandre]

For the eigensolver I would wait until #1675 is merged.

[qaumann]

@philbucher I also prepared it and will merge it, when you say so

[mpentek]

@jcotela Your patch works, so - at least with FractionalStep - one can have a separate call of the CalculateReactions() - my local patch in the respective python scripts - after SolveSolutionStep(). This is imperative for FSI. Probably something similar need to be done to the monolithic solver as well.

The question is whether to have the CalculateReactions() in SolveSolutionStep() similarly as currently Solve() has it if compute_reactions flag is true or to be done in a better way.

[philbucher]

this is solved