Developing adapter as Adapter Class vs. Function Object using Python

Hi @juanvalderrama,

continuing the discussion from Thesis/paper for SU2 adapter / Adapter Class method - #4 by Makis (you asked that later, but I saw the two threads in reverse order), here are some comments:

  1. 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.
  2. The function object approach is kind-a specific to OpenFOAM. I would call it plug-in approach. See also OpenFOAM-preCICE: Coupling OpenFOAM with External Solvers for Multi-Physics Simulations | OpenFOAM® Journal, where we explain these approaches.
  3. 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.