Kratos: Moving Research Applications to a new folder in Kratos

[pooyan-dadvand]

@KratosMultiphysics/all

@KratosMultiphysics/technical-committee decided to keep only the core applications inside the application folder of Kratos and move the research applications to a separate folder at the same level of applications in Kratos. All the applications are considered to be research applications. Maintainers of any application which fulfills the following conditions can request to the technical committee for considering it as core application.

The requirements for the core applications are:

• Active maintaining team
• Align with global vision of Kratos: (compatibility for multiphysics, synergy in development, etc.)
• Extensive testing
• Documentation: At least updated feature list
• Updated examples in example repository
• Active support and attention to community
• Active maintenance of the applications aligned with changes in the core (fast removal of deprecation warnings, backward incompatible changes, etc.)

You may use this issue to request for initial core applications.

[antonialarese]

Dear @KratosMultiphysics/technical-committee,
On behalf of @bodhinandach @VeronikaSinger @tteschemacher @iiaconeta @peterjwilson and the others contributors, I would like to ask to consider the ParticleMechanicsApplication as a core application since we guess we respect all the requirements listed in @pooyan-dadvand previous message.
Thank you!

[inigolcanalejo]

Dear @KratosMultiphysics/technical-committee
On behalf of @KratosMultiphysics/potential-flow-team I would also like to ask you to consider the CompressiblePotentialFlowApplication as a core application.
Thanks!

[RiccardoRossi]

Well, i think we should formally apply for StructuralMechanicsApplication, FluidDynamicsApplication, TrilinosApplication and MetisApplication to be considered core.

Structural and Fluid are probably the largest application and are the de-facto standard.

Trilinos and Metis are the basis of many of the others.

[loumalouomega]

I think MeshingApplication is an application extensively use by several users and developers, and should be part of the core application

[maceligueta]

Dear @KratosMultiphysics/technical-committee,
On behalf of the @KratosMultiphysics/dem Team, I would like to add the DemApplication to the list of core applications.
We have extensive testing, however it is not added to Travis because they take too long. In Travis we have a small set of them. Please let us know if we have transfer some more tests to Travis or any CI.
Thanks

[philbucher]

I would like to apply for the MeshMovingApplication (formerly called ALEapplication) and the MappingApplication to be part of the Core-Apps
Both Apps are very clean (python-scripts and C++-parts follow the latest standards) and are extensively tested within the testing framework of Kratos
Most of all is that they both are used for many other simulations (FSI, Optimization and coupling in general)
Furthermore the both fully support MPI

I will add some basic description of the capabilities in the next days
Neither application does have examples in the examples-repo, but I think this is ok because usually they are used within other apps. Instead I wrote the tests in a way such that they represent a typical usecase, i.e. one can see how the app is being used directly from the tests

[loumalouomega]

I would like to apply for the ContactStructuralMechanicsApplication to be part of the Core-Apps. The application has 83 C++ tests and 100 python tests, examples, completely up-to-date and it is documented. The support after my leave will be carried by @AlejandroCornejo and I hope to be able to give support in my own on my spare time.

[roigcarlo]

Here are our comments after discussing all the petititons for Core Apllications:

ParticleMechanicsApplication

• Ensure complete compatibility with StructuralMechanicsApplication: To fulfill the no code duplication requirement, the ParticleMechanicsApplication must use the elements and constitutive laws in the StructuralMechanicsApplicaiton before becoming a core application.
• Who are the official maintainers?

DEMApplication

• Migrate to the AnalysisStage and Processes based boundary conditions imposition to ensure compatibility with the rest of Kratos Multiphysics applications.
• Who are the official maintainers?

FluidDynamicsApplication

• Remove old and deprecated code in the application. Clearly state which are the “official” and supported elements and move the rest to the legacy application.
• Remove the FluidDynamicsApplication link in TrilinosApplication.
• Who are the official maintainers?

StructuralMechanicsApplication

• Is accepted.
• Who are the official maintainers?

ContactStructuralMechanicsApplication:

• Stable part is ready to be merge in the core StructuralMechanicsApplication
• Cleanup will be needed to keep compile/linking times under control.

TrilinosApplication

• Trilinos must not have compile time dependencies. However due to its toolbox nature, it will be considered as core application (module).
• Move pure MPI tests from trilinos to core.
• Official maintainers: @KratosMultiphysics/kratos-core-team

MetisApplication

• MetisApplication needs a major clean up
• Drop Metis 4 support before making it core application
• There is no testing
• Official maintainer: @KratosMultiphysics/kratos-core-team

CompressiblePotentialFlowApplication

• Even though the things in this application are in line with Kratos standards, we have the feeling that the app is under very active development and not yet sufficiently mature for being considered as core. This is of course something that could change in the near future.
• We also believe that once reached such stable status, it should be merged to the core FluidDynamicsApplciation. This shouldn’t be a tough migration since it already depends on it.

MeshingApplication

• The @KratosMultiphysics/technical-committee considers that this application should be in the core applications repository. However it needs a major clean up to reach the quality standards.
• Who are the official maintainers?

MeshMovingApplication

• Up to the standards and ready to be core application.

• Who are the official maintainers?
   

  MappingApplication

• Up to the standards and ready to be core application.

• Who are the official maintainers?

[maceligueta]

How much time do we have to apply the requested changes?

[loumalouomega]

@KratosMultiphysics/technical-committee I don't think that is a good idea to merge the ContactStructuralMechanicsApplications into the StructuralMechanicsApplication. The application by its own is quite complex, with many components. Developers as @tteschemacher are already complaining that the compilation of the StructuralMechanicsApplication takes to long because the constitutive laws compilation requires a lot of time, we were even thinking ways to reduce this or even separate the CL in a independent application. Put the ContactStructuralMechanicsApplication will make worse this problem, and additionally will make more difficult to maintain the code.

[roigcarlo]

@maceligueta We will have all applications pending on changes automatically added to the core folder once the change is made.
Applications will remain there for a grace period ending on October the 28th (Monday).
If by that date changes have not been addressed we will move them to the Research Applications folder.

[dbaumgaertner]

@KratosMultiphysics/technical-committee Just wondering if it's also possible to apply for an integration as core app at some point later after this round?

[rubenzorrilla]

@KratosMultiphysics/technical-committee Just wondering if it's also possible to apply for an integration as core app at some point later after this round?

For sure it is! :wink:

[antonialarese]

@KratosMultiphysics/technical-committee concerning the ParticleMechanicsApplication we agreed that code duplication should be reduced to the minimum and we will work for that.

Nevertheless, we would like to address the following points for discussion: the dependency from StructuralMechanicsApplication is seen as a bottleneck for the heaviness of the application especially for the time of compilation which is never-ending. Just to make an example, only to use the most simple linear elastic law we need the whole application.... That is the reason behind some repetition in the constitutive laws.
Some constitutive laws of the MPM application could be used by the StructuralMechanicsApplication, but were not developed as constitutive laws in the StructuralMechanicsApp for the reason above. Just to know (partially out of scope, sorry): is it under discussion the possibility to move the constitutive laws to somewhere else or do somehing? This would solve part of the problems not only for the ParticleMechanicsApplication, I guess.

ParticleMechanicsApplication, as the DEM app, is defining a different kind of element technology, and, for instance, it is designed and thought to have, in the near future, both structural and fluid and geomechanics (multiphase) MPM elements, therefore there are some intrinsic differences with the structural mechanics elements that cannot be easily overcome especially considering the multiphysics planned developments. It is true that the MPM elements are somehow “FEM oriented” and therefore similar to those in the Structural Mech App, but the application is a Particle Mechanics Application, i.e. it is thought for all continuum based particle methods, not only MPM, what if someone will add a SPH element? The use of the elements of the StructuralMechanicsApp is not recommendable...

The mantainers: @antonialarese , @bodhinandach @VeronikaSinger @tteschemacher @peterjwilson

[loumalouomega]

@KratosMultiphysics/technical-committee concerning the ParticleMechanicsApplication we agreed that code duplication should be reduced to the minimum and we will work for that.

Nevertheless, we would like to address the following points for discussion: the dependency from StructuralMechanicsApplication is seen as a bottleneck for the heaviness of the application especially for the time of compilation which is never-ending. Just to make an example, only to use the most simple linear elastic law we need the whole application.... That is the reason behind some repetition in the constitutive laws.
Some constitutive laws of the MPM application could be used by the StructuralMechanicsApplication, but were not developed as constitutive laws in the StructuralMechanicsApp for the reason above. Just to know (partially out of scope, sorry): is it under discussion the possibility to move the constitutive laws to somewhere else or do somehing? This would solve part of the problems not only for the ParticleMechanicsApplication, I guess.

ParticleMechanicsApplication, as the DEM app, is defining a different kind of element technology, and, for instance, it is designed and thought to have, in the near future, both structural and fluid and geomechanics (multiphase) MPM elements, therefore there are some intrinsic differences with the structural mechanics elements that cannot be easily overcome especially considering the multiphysics planned developments. It is true that the MPM elements are somehow “FEM oriented” and therefore similar to those in the Structural Mech App, but the application is a Particle Mechanics Application, i.e. it is thought for all continuum based particle methods, not only MPM, what if someone will add a SPH element? The use of the elements of the StructuralMechanicsApp is not recommendable...

The mantainers: @antonialarese , @bodhinandach @VeronikaSinger @tteschemacher @peterjwilson

Thanks @antonialarese, your arguments reinforces my point to avoid merge ContactStructuralMechanicsApplication in order to avoid even larger compilation times. (Compilations times are not only stressful but a significant productivity bottleneck.)

[RiccardoRossi]

@antonialarese i opened the thread #5331 to discuss the case of the MPM app

@loumalouomega i will also open a similar thread asap about the Contact

[philbucher]

@KratosMultiphysics/technical-committee I propose to also (right away or in a second step) make the ExternalSolversApplication and the EigenSolversApplication a core-app
I would consider those apps to have the same status as Metis & Trilinos
Esp the EigenSolversApp has an interface to the direct solver Intel Pardiso as well as an excellent Eigenvalue solver that is super handy
Both apps are well consolidated / don't change much so I think they meet the requirements

[maceligueta]

DEMApplication

• Migrate to the AnalysisStage and Processes based boundary conditions imposition to ensure compatibility with the rest of Kratos Multiphysics applications.

PR #6007 should fulfil this condition.