First off, thanks for this community and resource. As someone that is very early in their research in multiphysics analysis, the world of preCICE already seems very promising and exciting.
I am currently working on coupling a solver to preCICE in order to carry out multiphysics simulations on CAD-based geometries with other solver’s already in the preCICE repertoire (e.g., OpenFOAM, CalculiX, etc.). While the solver’s source code is written in C++, it has a very rich Python API that is extensively used by users and developers alike.
Exploring through the preCICE docs, I see that the two methods to build an adapter that is separate from the source code is either via an Adapter Class or through a Function Object. Beyond the fact that the function object leaves the solver’s source code “completely unchanged,” I’d like to know what other factors should be considered when choosing a method.
Additionally, I am mostly familiar with Python programming, and my goal would be to develop an adapter that takes advantage of the preCICE Python bindings and the solver’s Python API to remain fully in Python space. From the preCICE docs, I believe this was done in the development of the SU2 adapter (Alexander Rusch’s thesis; the Adapter Class method), but it is not so clear to me if the Function Object method could also be done completely on the Python side. My assumption is yes, but perhaps this is a quick check one of the experts could help me with.
Thanks again for the awesome work that has been hosted here and I look forward to become involved in the future through more multiphysics developments!
If you are the one (or your team is the one) developing the simulation code, then it makes a lot of sense to directly edit the C++ code. This will save you from any limitations of the Python API and will ensure that the coupling feature will remain maintained naturally with the rest of the code.
If you don’t develop the code yourself, then it makes sense to use the Python API. This will keep the feature less tightly integrated with the rest of the solver, and you can just abandon the project one day (which of course would not be nice, but that’s reality).
In the SU2 adapter, we started with directly editing the C++ code (that’s what Rusch’ thesis was about), but we are not the ones developing SU2. Therefore, this was tricky to maintain. Later, SU2 got a nice Python API, and a preCICE user contributed a completely rewritten adapter, which is now much easier for us to maintain.
While the team I participate in does develop the code for the solving library, many of the library’s functionalities are developed as Python packages. Users import these packages within their Python application scripts, which are virtually the only way that the solving library is used.
After reading through the entire list of official adapters, we found that the FEniCS adapter is most similar to our goal. Like FEniCS, our solver is more of a library than a stand-alone solver, and users utilize Python application scripts to run simulations.
Like in FEniCS-preCICE, our goal would be to create a package “solver-preCICE” that we could import from a user’s Python application script. I believe the paper and repository for FEniCS-preCICE will help us on from here, but please provide any additional insights if you do have any.
In that case, developing a package similar to fenicsprecice makes a lot of sense: The package would provide a class that would encapsulate all the solver-specific code for reading and writing data, storing and reloading checkpoints, etc. So, the user would not interact with the preCICE API directly, but with this package.
