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
1k stars 243 forks source link

use kratos without python #11423

Open alexbrownsoft opened 1 year ago

alexbrownsoft commented 1 year ago

I noted kratos is excuated through python interface, is that possible to use kratos directly from c++? for example, directly read .json file and carry out analysis.

rubenzorrilla commented 1 year ago

It is technically possible (indeed it is actually being done in the @KratosMultiphysics/geomechanics application). Nevertheless, this is not the way we officially support from the KratosCore.

alexbrownsoft commented 1 year ago

How much efforts do you think is necessary to get the c++ codes directly read json file and excute calculations? i assume it should be right straightforward, is that correct?

RiccardoRossi commented 1 year ago

well, you can take a look at the cpp tests, which do just that, however we have a quite large python lyaer in which we implement Stages, Solvers etc which you would need to replicate manuually

mcgicjn2 commented 1 year ago

I can explain how we achieve this (if you require). Basically we reverse engineer the python controllers. (analysis_stage.py) .... It is quite straight forward when you get the hang of it, and have a template for doing so, but note there is no real performance benefit.

We have software requirements from our stakeholders who prefer to avoid python, thus our need. However we still maintain a python wrapper into our functionality and are persuading our stakeholders to drop their objections. Using Python also allows use to interact better with the other applications within the framework.

Also if you are going to continue using files as input, I recommend that you maintain and use the python layer, as there can be a lot of logic (helper functions) in those layers in the parsing and setting up of the model.

Furthermore as a community member I would expect this layer to be there, and I suspect that functionality would not pass review without it. I am happy to discuss, if you really need to do it.

mcgicjn2 commented 1 year ago

Note, another reason we do this is that our tailored applications have a lot of default parameters, and thus we would like to avoid file inputs and hard code the data structures sent to the solver, rather than read from file..... which inevitably a user will intercept the files and change them beyond our testing.

You should also note that you can compress the python components of your script into an executable if that is your goal.

alexbrownsoft commented 1 year ago

You mentioned there is a template to do this, could you please kindly help to provide more guidance regarding how this can be done.

While python is a greate coding language, it is a bit strange to have a such ”thick“ layer of python. There are so many functions such as i/o are coded in python instead of c++. If the purpose is to provide a interface of python, a quite thin layer could be able to do this.

Using C++, there are quite a lot of tools that can do automatic i/o, such as json schema etc.

RiccardoRossi commented 1 year ago

Well, there are quite a lot of advantages in using the thick python layer you describe, the most important of which that you can script your solution procedure and hook into other frameworks (think into scipy, tensorflow, numpy, etc...) without introducing a compile time dependency (libraries are strictly loaded at runtime)

having said this i guess that this discussion is a bit off topic, so i leave the word to @mcgicjn2 which is surely the person with most expertise on this

mcgicjn2 commented 1 year ago

@RiccardoRossi : Totally agree with the usage with third party libraries such as Tensorflow, and it should also be said with the kratos tools such as cosim, etc.

@alexbrownsoft : If you want to take a look in our repo at GeoMechanicsApplication/custom_workflows you will see our work toward a workflow we have for a product. Currently we are improving this to parse more of the data from the native files. However for us, as previously said one of the advantages is that in many of our applications we want have a lot of default parameters and data, so it is also hard coded here. Please also note that we have also introduced a simple external bindings, as we wanted to call the dll from c#, not build an executable, thus GeoMechanicsApplication/external_bindings.

I hope this helps, if you need clarity let me know and we can discuss in a teams chat.