Add a fluid-fake for easier debugging

[BenjaminRodenberg]

See #176 for motivation. Here is a small drawing:

[MakisH]

I am struggling to decide if we should pursue this direction or not.

On the one hand:

• it is clear that it was useful for you
• this is what we were sometimes suggesting users to try out first
• it does not seem to harm merging it
• it sounds like the right tutorial to add such a fake solver, since most of our users probably start from this tutorial. But let's not add fake solvers to more tutorials.

I also understand that the motivation was mainly to have uni-directional coupling instead of bi-directional, to not have to feed back data while developing the FEniCS adapter.

On the other hand, this is why we developed the ASTE replay mode. Instead of creating fake solvers, we could instead (in the long-term) generate replay data and store them next to the reference-results we now have.

Clearly, the situation is "I developed a quick solution before the long-term solution was available, do we now also want to make the quick solution available, or not?". Given that ASTE is currently not super easy to install, and this is probably more intuitive for users, I would say "why not". But let's add a note in the README that ASTE replay mode would be the more powerful approach.

[BenjaminRodenberg]

Since I stumbled across this PR and I think we should merge it rather sooner than later:

But let's add a note in the README that ASTE replay mode would be the more powerful approach.

I can link to https://precice.org/tooling-aste.html.

However, I do not fully agree that both are addressing the same thing: The replay mode has a different use case.

With the fake fluid you replace the real fluid with a simplified fake version. This eliminates possible sources of error (other solver and other adapter) and allows us to focus on only one party in the overall simulation (this solver and this adapter). I think this is useful, if you do not want to bother with the other solver or you do not trust or cannot assess the output. This is particularly useful for development when the other side is not yet available.

The replay mode only bypasses the computation of one solver and simplifies the feedback loop somehow. This reduces computation time and provides an environment that is close to reality. But you should be quite sure that the original setup that you used for creating the recording is correct. This is useful for detecting regressions.

Note: I'm planning to write something about this whole topic in my thesis. This should serve as a proper documentation as soon as published. Until then I would rather not spend time coming up with more documentation pages here.

[uekerman]

The replay mode only bypasses the computation of one solver and simplifies the feedback loop somehow. This reduces computation time and provides an environment that is close to reality. But you should be quite sure that the original setup that you used for creating the recording is correct. This is useful for detecting regressions.

With ASTE, you could also write artificial data. Then, you have exactly the same functionality as the fake-fluid here.

[uekerman]

Let's add this.

Could be good to also add a requirements.txt and a venv here. Similar to the Nutils cases.

[BenjaminRodenberg]

Ready to merge. @MakisH I'll wait for your ok or you can also push the button, if you want. Don't want to interfere with your release with something that is not critical.

[MakisH]

I think that the current state is nice and sustainable. There is a clear description in the README, there is a clear hint to ASTE (while it is also implied that ASTE would be more complicated to use), and the case follows the guidelines.

I also tested the following combinations, and they completed, resulting into a reasonably moving flap:

• fake-deal.II
• fake-OpenFOAM
• fake-Nutils

Let's merge this already, there is no reason to wait, and I can add the watchpoint next to the rest.