Restructure tutorials

[fsimonis]

This PR is a common communication channel for restructuring the tutorials, which should simplify the integration with the website.

[fsimonis]

Can someone with all adapters installed please try to merge this?
There are tons of conflicts due to the diverging history and I cannot verify if the merge is successful or not.

[davidscn]

Not sure about all available merge strategies. I see a lot of conflicts in the FSI cases: we can safely delete all flap_perp* and cylinder_flap cases. Maybe a forced develop update is in the end a better solution (for us, not the user).

[MakisH]

I am a bit concerned that we will probably lose a lot of the history when merging this actually. What is a good way to prevent this?

[BenjaminRodenberg]

I am a bit concerned that we will probably lose a lot of the history when merging this actually. What is a good way to prevent this?

One solution that might help us is splitting this PR into two PRs:

1. Make all relevant changes to prepare the restructuring: change parameters, make all cases consistent, simplify solvers, add new cases, if this is necessary. Here, we should mainly see small, but important changes.
2. Do the actual restructuring: only move files (don't change them!) delete duplicates. Here, it will be difficult to understand all changes in detail, since there will be a lot of code removals and additions, but we are only moving around files. So nothing complicated happens inside the files.

Currently, I see that both points are mixed up in this PR and this will make it very hard to understand what this PR changes from a future perspective. The important changes are hidden in a huge diff.

I think we can still continue using this PR for preparing (and discovering) all the relevant changes for the restructuring. However, if we want to keep a sane history, we need to invest some time into de-spaghettiing this PR at the end. Maybe, by going back to develop and reapplying all changes step-by-step in a manual fashion.

[uekerman]

One solution that might help us is splitting this PR into two PRs:

I am afraid that this will not be possible (or not that easy). Many file changes are directly related to the flattening.

[BenjaminRodenberg]

I took care of resolving the merge conflicts. It's a quite big merge, so might be a good idea to merge this into your respective PRs. Some information on what has changed:

• new case: FSI/rigid_flap/OpenFOAM-RigidBody/runSolid (from Add a quickstart rigid flap tutorial #123, needs restructuring)
• new case: FSI/two_flap_perp_2D/OpenFOAM-deal.II (from two perpendicular flap case #110, needs restructuring)
• major changes: partitioned-heat-conduction/fenics-fenics/heat.py (Modify FEniCS tutorials to enable parallel runs #120 and Fix ill-posed problem by providing additional data. #144)
• new case: perpendicular-flap/OpenFOAM-FEniCS (quite a lot was missing here, but now it looks ok, I tested this case, adds changes from Move 2D FEniCS cases #141 and Ensuring consistency in FEniCS scripts for FSI tutorial cases  #142)
• new case: perpendicular-flap/SU2-FEniCS (needs to be added to Restructure flap_perp FSI case #146)
• new case: turek-hron-fsi3/solid-fenics (needs to be tested, since turek-hron-fsi3/fluid-openfoam is broken, I tried with the merged version and 9f36045)

I added the tick-boxes to indicate open todos that I see from the merge. The things that have to be done are marked in bold.

[davidscn]

@BenjaminRodenberg the rigid body restructuring is covered in #145, the two flap case is covered in #151 and the Su2-Fenics perpendicular flap is already included in #146. Please don't ask me why, but solid-fenics is not part of turek-hron-fsi3 (have a look at the project description). So, you could check all of your open boxes.

[uekerman]

Please don't ask me why, but solid-fenics is not part of turek-hron-fsi3

Because FEniCS only has a linear solid solver and therefore gives too bad results for the FSI3.

[BenjaminRodenberg]

Please don't ask me why, but solid-fenics is not part of turek-hron-fsi3

Because FEniCS only has a linear solid solver and therefore gives too bad results for the FSI3.

I agree that we should not have it in turek-hron-fsi3 anymore, if it does not meet the quality criteria. Completely throwing it away and/or forgetting about it would also be bad, since it took a lot of work to set up this case.

I can take the care of putting it onto a branch and create a (draft) PR. This will avoid that we totally forget about the case and it might be a nice starting point for a thesis or similar. The currently missing steps are 1) to implement a non-linear model and 2) make sure that results agree with the other cases.

Alternatively, we can also create turek-hron-fsi3-linear, but this does not really contribute a meaningful case and looks to me like a dead-end with a lot of unnecessary maintainment.

[BenjaminRodenberg]

Adding the namespaces to the tutorials, documentation etc. (over some time) to slowly teach users a new best practice

from precice/precice#928 (comment) could also fit into this PR, since we are touching all the configs anyway. But it also makes this PR even more gigantic.