What we develop in the step-by-step guide is best described as an adapted code, not an adapter. We directly modified the main solver routines. Better alternatives exist. Depending on the solver’s functionalities, you could either consider creating a separate class for the preCICE adapter (as applied e.g. in the SU2 adapter) or using a callback functionality provided by the solver (as applied e.g. in the OpenFOAM adapter).
The diagram below summarizes these three different ways of using preCICE:
The direct modification approach is what the step-by-step guide uses. It consists of directly modifying the solver code lines to couple with preCICE. This, however, is not an ideal approach since it requires changing of the solver source code, and you should try to avoid this to wherever possible to maintain a sustainable software development practice.
To minimize the lines of solver source code changes, you can create a separate class for the adapter. This adapter will be responsible for calling all the preCICE APIs, and from the solver source code you would only call the corresponding adapter class methods. As stated above, this approach is used e.g. for the SU2-adapter and explained in detail in Alexander Rusch’s thesis.
If the solver you are using provides a callback functionality you can separate the adapter even better from the code. You simply call the preCICE API from the callback. As stated above this is realized in the OpenFOAM adapter and is explained in detail in Gerasimos Chourdakis’ thesis.