KratosMultiphysics / Kratos

Kratos Multiphysics (A.K.A Kratos) is a framework for building parallel multi-disciplinary simulation software. Modularity, extensibility and HPC are the main objectives. Kratos has BSD license and is written in C++ with extensive Python interface.
https://kratosmultiphysics.github.io/Kratos/
Other
991 stars 244 forks source link

Moving Research Applications to a new folder in Kratos #5270

Open pooyan-dadvand opened 5 years ago

pooyan-dadvand commented 5 years ago

@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:

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

antonialarese commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

maceligueta commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

ParticleMechanicsApplication

DEMApplication

FluidDynamicsApplication

StructuralMechanicsApplication

ContactStructuralMechanicsApplication:

TrilinosApplication

MetisApplication

CompressiblePotentialFlowApplication

MeshingApplication

MeshMovingApplication

maceligueta commented 4 years ago

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

loumalouomega commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

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.