Support preCICE naively

[kursatyurt]

preCICE is a well-known partitioned multi-physics library with minimal invasive integration to existing codes.

There is an official SU2-preCICE adapter that exists, however, requires modification in the SU2 code base and recompilation.

A recent development by @j-signorelli adapts the python wrappings of SU2 to implement adapters using python scripts see.

The advantage of using a python wrapper is that preCICE headers are not required during the compilation phase of the SU2. Only existing preCICE and python bindings are required if one wants to use preCICE.

In #1949 it has already been achieved that one can modify the existing solution on a marker. Have access to the initial coordinates of the mesh (I am not sure about this).

These futures are enough to reach an explicit coupling scheme. For implicit coupling, one needs to save the current state of the solution to memory (as IO is not efficient for a such task) and should be able to reload this solution.

I would like to get opinions about providing such functions in the official SU2 code.

[pcarruscag]

You save the current state into a numpy array with a couple lines of python. What else is needed?

[kursatyurt]

@pcarruscag for explicit coupling schemes you do not need a restart or move backward in time but for implicit methods you need.

@Nicola-Fonzi I have already working setups with preCICE and adapters, migration to SU2 internal capability would be painful. The final goal is to provide the required interfaces for preCICE naively and sample scripts to users. Just requires a few additional methods and I don't want to patch those methods every time I upgrade SU2, providing them naively would be better.

I am not so familiar with the internal data structures of SU2, the two adapter codes I shared above have different approaches (they support different versions).

[Nicola-Fonzi]

I see, thank you for the explanation

[pcarruscag]

@kursatyurt they are calling driver.Update before the coupling for the current time step is finished, that is why they then need to restore the old state if the coupling is not converged yet.
Instead they should solve the coupling and only update (which pushes old solutions) once the coupling for the current time step is finished.
We have Implicit coupling in SU2 and that's how it works, no need to restore anything.

[kursatyurt]

@pcarruscag great, I will talk with preCICE developers if we can skip saving/reloading states (sounds no problem but to be sure). if it internally works with preCICE saves some time and memory.

Out of context, I found it a bit confusing Postprocess() and Postprocessing() the first one does the post-processing of the solution, and the latter finalizes the driver right?

[pcarruscag]

That's correct, we can rename Postprocessing, I also think it is not very intuitive