Dependencies of the FSI applicaton

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

1.01k stars 244 forks source link

Dependencies of the FSI applicaton #248

Closed jcotela closed 7 years ago

jcotela commented 7 years ago

For some reason, I'm compiling the FSI application but not the SolidMechanics application. The configure script works fine, the compilation works fine, but when I run the tests, they fail, since they try to import the SolidMechanics Application. I would like to clarify this issue. Is the FSI application considered to be dependent on the Solid (and I guess on the Fluid)? If so, we should enforce compilaiton of these applications on the CMake level. If there is no such dependence, then we should be able to run the FSI tests standalone (without requiring other applications) or at least catch the ModuleNotFoundError that python throws and turn them into expected fails (right now, they just kill the test routine) for the tests that do use features from other applications.

@rubenzorrilla could you give us your view on this?

loumalouomega commented 7 years ago

@jcotela, I agree with you, but I think that we should ensure the compilation of the StructuralMechanicsApplication (Fluid-Structure) and at the same time the StructuralMechanicsApplication should ensure the SolidMechanics compilation

rubenzorrilla commented 7 years ago

@jcotela From my point of view the FSIApplication should not have dependencies on other applications. Actually, the recent developments in the FSIApplication are oriented towards the black box FSI partitioning. Thus, having dependencies makes no so much sense to me... (imagine that one day we want to use different fluid dynamics or structural apps). Of course, this will change if we decide to implement monolithic strategies one day... @RiccardoRossi what do you think about?

Regarding the FSI tests, it is strange to test the FSI algorithms without the necessity of importing other apps stuff. I will try to figure out how to modify them, but in any case, I completely agree about using the ModuleNotFoundError to turn these errors to expected test fails.

loumalouomega commented 7 years ago

@rubenzorrilla You can save the residuals you want to minimize and then apply the solvers

RiccardoRossi commented 7 years ago

@jcotela i see you point, that is, i would prefer not to have dependencies on the SM. @rubenzorrilla is it really needed? where? maybe in the python scripts of the strategies?

however at least for the testing it makes sense to have them to depend on the StructuralMechanics. I agree on the other hand it should give an expected failure if it is not compiled

jcotela commented 7 years ago

@RiccardoRossi I don't particularly care if the application depends on the Solid/Fluid or not, but this is a design decision that has to be made. If it does, it should be enforced so that users do not end up compiling something that is useless because it has unmet dependencies.

However, I understand that the idea is to avoid explicit dependencies. In this case, I would try to ensure that (most of) the tests work for the standalone application, which also makes sense because we want each test to check for a specific feature, not run a full simulation.

RiccardoRossi commented 7 years ago

i am not sure of what is the answer to this. The FSI solver does depend on the StructuralMechanics app, and i believe it has to be the case to simplify its usage (structural and fluid solver are constructed in there). Indeed it could be made generic, however we do need to provide some defaults.

@rubenzorrilla what do you think?

rubenzorrilla commented 7 years ago

Regarding the Python solvers, at the moment it does not come to my mind how to set them up without importing the Fluid and Structural App (it would be possible modifying the MainKratos.py file, but this is something that definitively we do not want to do). Thus, I think that:

the FSIApplication should compile independently (this is already achieved)
the FSIApplication tests should not depend on other Apps (this implies to modify the test that @jcotela points out). Of course the validation tests (e.g. Mok, Turek, ...) will always use the mixed solver. However this is not a problem since they are rarely run.

jcotela commented 7 years ago

After thinking a bit more about this issue, I believe that we should allow (but not encourage) that tests use stuff from other applications. The only point is that such tests should be skipped or turned into expected failures if the required applications are not available. I have written a small how-to in the wiki on this topic: https://github.com/KratosMultiphysics/Kratos/wiki/How-to-create-unitary-tests#skipping-tests-with-external-dependencies

maceligueta commented 7 years ago

@rubenzorrilla rised an interesing point. We have at the @KratosMultiphysics/dem team the Swimming DEM Application, which now couples the DEM with the Fluid Dynamics Application. However, very soon a new Main Script (in python) will be using the same components to couple the DEM with the PFEM Fluid Application. Right now we have CmakeLists configured to require the Fluid Dynamics App, but maybe it's not such a good idea if we think in general terms.

jcotela commented 7 years ago

@maceligueta I think that having the CMakeLists configured to require another application makes sense only if there is some dependency on the level of the code (#includes from the other application). If it is just that normal operation of your application will require using the other application (for example the FSI always uses the fluid and structural solvers) I would not force the compilation through CMake, as you could have alternatives (imagine we create a new application for non-Newtonian fluids that is alternative to the standard FluidDynamics)

GuillermoCasas commented 7 years ago

@jcotela Exactly: The DEM-fluid coupling is often viewed as a fluid-structure coupling which is potentially treatable with the black-box strategy that @rubenzorrilla and @maceligueta discussed. I agree. However, such a coupling between applications is not always necessarily of that nature. One may still have many #include-type dependencies with, say FluidDynamicsApplication and still have the capability of interacting with the PFEM Fluid Application in an application-blind way.

Applications may correspond to phases, but this does not need to be always the case. What may be useful is to develop a coupled-problems abstraction/convention that we can all follow, so as to make this sort of problems easily treatable.

pooyan-dadvand commented 7 years ago

Just to add that we should encourage developer to avoid c++ dependency between applications as much as possible and try to postponed the dependency (without code duplication) to python calls.

jcotela commented 7 years ago

I'll go ahead and close this, since it seems like we reached a consensus and the immediate issue of the FSI tests was solved in #341. Just to summarize:

Dependencies at C++ level should be avoided as much as possible.
Dependencies at Python level are OK.
If an application is compiled, its tests should run even if the Python dependencies are not satisfied. For tests that use features from other applications, please ensure that they can be skipped if the other applications are missing.