Add a quickstart rigid flap tutorial

[davidscn]

Resolves #117
Setup as described in #117 . We decided to remove the nearest-projection capability and use a RBF mappings instead.

[davidscn]

I will check if we can remove this block completely since it is an unnecessary complication for newcomer.

[uekerman]

Nice 👍

• Let's also add a export:vtk to the Solid participant and explain in the docs how to visualize the point cloud.
• Could you please format the C++ file with the same clang-format options as used in preCICE?

The IQN convergence is still a bit bad. I'll try whether better settings are possible.

[davidscn]

Could you please format the C++ file with the same clang-format options as used in preCICE?

I used now the main repo .clang-format file and it should be formatted properly. I'm still a bit confused why the comments are not formatted (linebreaks), but I guess this is not configured in preCICE itself.

[uekerman]

Looks good. Let me only still check the IQN performance. I can merge then.

[MakisH]

I quickly went through the code (did not try to run it) and I have a few minor suggestions. Feel free to integrate as many as you want. I can also try running it, if you want.

[davidscn]

Looks good. Let me only still check the IQN performance. I can merge then.

Where should the README go? I guess I should add it before merging this?

[MakisH]

Looks good. Let me only still check the IQN performance. I can merge then.

Where should the README go? I guess I should add it before merging this?

Yes, please. Even if we keep the instructions in a separate place (already now or later), we need a minimal README here as well.

[MakisH]

• I tried running it (serial & parallel) and it works nicely. The Fluid results in ParaView look fine, the watchpoint plot was clear. The motion feels a bit too intense, but good that preCICE converges in such conditions.
• The code looks clean & nice 👍

Two small todos:

• We still need a README, but you have this already in mind.
• We still need to add the script removeObsoleteFolders.sh, similarly to other OpenFOAM tutorials.

[MakisH]

Looks good. Let me only still check the IQN performance. I can merge then.

Here are the convergence and iteration files for the parallel case:

precice-Solid-convergence.log
precice-Solid-iterations.log

It starts converging in 3-4 iterations, goes up to 7 iterations in the given time frame.

[davidscn]

The motion feels a bit too intense

It's indeed near an (even with implicit coupling) unstable configuration. We could reduce the motion by, e.g., modifying the Fluid density.

[MakisH]

We could reduce the motion by, e.g., modifying the Fluid density.

Or maybe reducing the (output) time step. We mainly want to change the visual effect here.

[davidscn]

I added now a README and the tutorial is ready to merge from my side.

Or maybe reducing the (output) time step. We mainly want to change the visual effect here.

I like the visual effect :D

[MakisH]

I added now a README and the tutorial is ready to merge from my side.

Or maybe reducing the (output) time step. We mainly want to change the visual effect here.

I like the visual effect :D

For me it feels that the flap moves too sharply with every plotting step. Usually we have more smooth transitions. But this can indeed be a matter of preference.

[uekerman]

I also think we need a smaller timestep size:

• The displacement jumps are too big and, thus, accuracy is probably weak. Might be a strange "first impression".
• The visual effect.
• Quasi-Newton coupling needs more similarity of the coupled system between the current and the last timestep.

Furthermore, the fluid side is rather unstable. Many inner iterations are needed. Small changes in the parameters can let the case crash (e.g. smaller dt + parallel coupling). We need a setup that is rather insensitive to changes, robustness-wise. I guess users would want to play around with such things.

What worked well for me was sth like:

• density fluid 1000
• nu 0.001
• density solid 10000
• dt = 0.005
• T= 2.5
  ... but then the displacement gets too big. I guess we will need some sort of rotational spring that works against the fluid force.

[davidscn]

I added now an implicit rotational spring. After (too) many test runs, I conclude the following: The spring doesn't change the general problem. We have either stable setups or unstable setups. I guess there is even an analytic solution for some characteristic numbers which could tell us the stability region. If we want to see a visual effect in the results, the setups are (after a certain amount of time) unstable, for stable setups, the effect is 'only' visible in the watchpoint. Therefore, I added now a 'switch' in the middle of the simulation, which stiffens the spring so that the unstable initial setup is stabilized. The advantage would be, that you can really play around with the parameters and the simulation is rather stable. If it is not stable, the reason should be clear enough for the user.
As always, feel free to try it yourself. I just realized that I need to update the given formulas.

[uekerman]

I think the stiffness switch is a good solution. With all that, however, the simulation became a little bit too slow maybe. I'll try more things.

[uekerman]

With a few tweaks, we are now done to 30s compute time for adapter + preCICE in debug mode. 🎉

[davidscn]

With a few tweaks, we are now done to 30s compute time for adapter + preCICE in debug mode. 🎉

Sounds good. I still had some points on my list for the README, in particular the formulas and an explanation for the rigid body model as well as the the explanation of the additional spring. Should this go in a separate PR or are you fine with the current state?

[uekerman]

Feel free to open another PR or directly push to develop if the changes are pure extensions.