Kratos: Migration two fluids to free surface application

[antonialarese]

@KratosMultiphysics/technical-committee
It should be decided whether to unify or not all the free surface (mature) applications (twofluid and edgebased-one fluid) into an external free surface application (derived from Fluid Dynamic application) or not.

It was discussed among @RiccardoRossi @antonialarese @ipouplana @rubenzorrilla @GuillermoCasas who are in favor (the majority) of using a free surface application bor both twofluid and edgebased algorithms.

[RiccardoRossi]

@antonialarese @ipouplana @rubenzorrilla @GuillermoCasas

we discussed this at lenght in the @KratosMultiphysics/technical-committee and the prevailing opinion is to make an attempt to limit the number of core applications. For this reason we would prefer to have the TwoFluid solver as a part of the FluidDynamicsApplication and eventually to also port there the EdgeBasedLevelset once it is modernized to use json input and processes.

[pooyan-dadvand]

@rubenzorrilla as you are not conform with this decision, would you please give us your opinion here? Consider that most of us were not there when you had discussed it in the team.

[rubenzorrilla]

@pooyan-dadvand IMO (and I think that I can speak on behalf of @jcotela ) the FluidDynamicsApplication is becoming larger and larger (e.g. right now there are more than forty files only in the custom_elements folder, more than fifty in the python_scripts one, ...) and what it actually needs is a major clean up.

We put a lot of effort on migrating the "old" elements to a new standards as well as on the enhancement of the fluid testing suites. We always considered this as a first step to reduce the complexity of the application. Having this in mind, I'm not particularly on including all the free surface and two fluids formulations inside the FluidDynamicsApplication, but of course I will assume any consensus reached by the @KratosMultiphysics/technical-committee.

[maceligueta]

Actually, @jcotela stated this point very clearly during the meeting. The necessary workforce to maintain the Fluid Dynamics application is increasing. However, from the technical point of view, we found best to have the fluids in the Fluid application.
The increasing workload is something to be discussed as well, though.

[pooyan-dadvand]

@rubenzorrilla thanks for the explanation. I see your point and also understand the @jcotela concern about this issue.

But I see it from other point of view. Merging those application means that @antonialarese and her group and others who have their code there (like @ddiezrod and @inigolcanalejo when we merge his application) should also put effort in maintaining the FluidDynamicApplication as you are doing. It is clear that your maintenance effort would be more than before but at least I hope having more developers in the team should improve the situation.

[philbucher]

I just saw this issue and I share the opinion of @rubenzorrilla
I am not sure if having one big app that can do everything is better than several small ones

The maintenance is already taking a lot of time, and it wont get less (speaking from my experiences with StructuralMechanics)
I spend quite some time on this, mostly in my free time, and unfortunately (but understandable, I am not blaming anyone) there are not many others like this
Kratos is growing very fast at the moment and it is hard to keep up with the maintenance sometimes

Another option would be the following:
Having a few well consolidated, stable, tested and not changing much apps, that many ppl would use (and rely on!)
Then we could derive other apps from those, which wouldn’t affect the parent-apps but still could use all their functionalities

Please keep this in mind when making a decision @KratosMultiphysics/technical-committee

[antonialarese]

My opinion is already known since I was the one arising the problem, Nevertheless, I would stress that personally I support @rubenzorrilla and @philbucher. Concerning @pooyan-dadvand commnet I guess that the group of maintainers will increase in any case, but responsibility will be shared among different people if the applications are kept divided, while responsibility will fall inevitably more on @jcotela and @rubenzorrilla if we merge everything on one single application (please, consider that this is worse for me!). Modularity, in my opinion, helps keeping things simpler to be used/modified and especially understood by new users or developers at initial stages who can concentrate more on the specific features of the application without facing a giant like the Fluid Dynamics App.

Said that, I am not an expert of code architecture nor a good developer, so I will accept any decision of the @KratosMultiphysics/technical-committee

[pooyan-dadvand]

I appreciate all of your opinions and understand the heavy load of application maintenance in the major ones..... Meanwhile I want to give a better description of technical drawbacks in going in separate applications:

• Making more difficult for python developers to figure out which apps they need (another import, copy of parameters, similar but different solvers, processes, etc.)
• The argue of increasing the modularity is rather weak because having them in separate applications is not reducing the dependency between them. They will be dependent applications in different directories and dependencies to upstream/downstream is a source of many issues all the time....
• The maintenance problem is a serious problem... Nevertheless, I don't see how this would help. In fact I see the small applications more subjected to become old, incompatible or going into a life time branch...
• I, personally, hate duplicated codes and this kind of dependent applications are source of copy pasted files with a lot of duplicated codes with the argument that I don't want changes in upstream affect me.... One may argue that this can be avoided by clean coding but I in practice ...
• I understand the separation between stable applications and sand box one as @philbucher is mentioning but I don't consider the two fluid a sandbox formulation. I agree that experimental ones should go to a separate application. (Assuming the merge overhead afterwards...)

Apart from my technical opinion, I admit all your concerns from management point of view but I think we should try to find a solution for our management problem separately. To be honest I don't know how but I am very open to suggestions in this line.

By the way, I think we have enough votes against this decision to consider passing it back to the @KratosMultiphysics/technical-committee

[jcotela]

@pooyan-dadvand for me the main concern is code quality. We just do not have the resources to keep the current FluidDynamics to the best practice standards we try to follow in the core and in new implementations. Both @rubenzorrilla and myself agree that, if anything, several features in the current code base should be dropped due to lack of maintenance, rather than trying to grandfather in more old code. Adding more features without the manpower to support them only decreases overall code quality.

[pooyan-dadvand]

This is a justifiable point of view... It is sad to see an important application which many people are taking advantage leaves with lack of resource... But I insist that we should improve our management also...

This is also a self critic as @KratosMultiphysics/altair ...

[pooyan-dadvand]

Can we close this? The solution for the dependencies is under development

[philbucher]

@pooyan-dadvand what is the solution for the dependencies?

[pooyan-dadvand]

@roigcarlo would you please describe your solution?

[jcotela]

In the @KratosMultiphysics/technical-committee we consider this issue as closed, since a technical solution was reached. We understand that @KratosMultiphysics/altair will remove the old two_fluid element implementation from the FluidDynamicsApplication once it is no longer required.