Kratos: define a "way to go" to change settings (for FluidDynamicsApplication and StructuralMechanicsApplication)

[RiccardoRossi]

Hello everyone,
we need to agree on a procedure on how to proceed when someone proposes to change input settings.
My point is that it is very disturbing that a perfectly valid testcase stops working from one day to the next since something changed in the input.

this is so in particular for the FluidDynamics and StructuralMechanics application which are used by many people.

My proposal would be first of all to have a sory of "standardized issue" for this, structured as (let's say):

• PROBLEM TO BE SOLVED
• PROPOSED SOLUTION (with a rationale)
• OLD SETTINGS
• NEW SETTINGS PROPOSAL

my idea is that that if we manage to have it relatively clean, it will also constitute a documentation of the change, which we can refer from the deprecation message we'll put in the code.

My proposal would be also that no changes to the input settings goes in for those 2 application without explicit approbation from at least one member of both the Barcelona team and the TUM team.

...anyway... i am not 100% sure if this is the correct way to go... so opinions and suggestions on this topic are very welcome!

[philbucher]

I agree with this idea
to make the teams aware of this:
@KratosMultiphysics/structural-mechanics @KratosMultiphysics/fluid-dynamics

I would say this also holds if the change is "silent", i.e. if sth becomes deprecated but still works for some time, which is what we do now most of the times

[jcotela]

I agree with the spirit of the proposal, but I believe that the code is not mature enough to lock it in this way. We had to rewrite everything for the analysis stage just a few months ago, and we are still feeling the aftershocks of that change. I am afraid that making the update procedure more rigid will only serve to fossilize the remaining problems in the design and ultimately not solve the backwards compatibility problem, since breaking changes will now be backed by the system (What do you mean my change breaks your code? We approved the change in issue #9824759243, it is your responsibility so stay updated).

If we want to be strict about preserving backwards compatibility, I believe we will eventually need to have "release" and "development" versions of python solvers (probably to match with the developer and release modes of GiD?), so that big interface changes are only "forced" on the users as new versions are released. This could be controlled by the factory, so that the supported release version is used unless the json contains a specific option to enable the "experimental" version of the solver.

[RiccardoRossi]

i agree code is not mature, and that we need to break some stuff, however as of now i simply cannot follow what changes are going in, and i am really afraid of things suddently getting broken.

I really think we need to formalize the discussion and maybe to prefer to make fewer large changes which are fully concertated, than a lot of small changes that break the code every now and then...

note in any case that i am not asking to freeze changes, simply to have the changes agreed

[jcotela]

@RiccardoRossi I agree with you. I don't think we can expect anyone to be always up to date with all changes in the solver (I sure can't always follow it, and I worked pretty closely with @philbucher in the last round of changes). I also agree 100% with you that fewer large changes is better than many small ones. However, I think there is value in being able to play a bit with the things in other to improve them, that is why I was suggesting having some mechanism to "freeze" (a version of) the format while new changes are in progress.

[RiccardoRossi]

ok i am not against the "freezing mechanism" ... however maybe a branch could do it...

no good ideas unfortunately

[philbucher]

can we close this?

[rubenzorrilla]

Is this still alive?

[philbucher]

I would close it for now, we haven't had many problems with this in the last year I would say