Here is my comment again. I deleted it shortly after posting, wasn't sure if the tone was a bit too harsh.

Don't forget the tutorials are tutorials. Their purpose is to show people how to set up simulation cases involving preCICE. They are not a lesson in software engineering or library development. As a new user, I would seriously be turned down by the need to understand a library-like structure of bash or python scripts calling each other, even it is minimizes code duplication.

imho, the tutorials should be self-contained, so that a user can copy the case, start modifying it without the need to keep the other tutorial cases or some additional tutorial library code. For tutorials, I would prefer straight and easy case steering code, even if snippets are copied around.

Just my 2 euro-cents. 🦆

from tutorials.

Same applies to the FSI scenarios.

from tutorials.

That's a tricky one... I am not sure if it is worth automating/centralizing this, as then a change in one tutorial could break another tutorial. On the other hand, this would be a nice way to demonstrate the "exchangeable solvers" concept.

I see two approaches:

1. Have a "main" tutorial (e.g. the OpenFOAM-OpenFOAM heated plate) and point users to it. We could then also provide a symbolic link, but this would easily lead the users to mixing up different configurations.

2. Restructure our tutorials repository in a Single physics/Geometry/Solver way (for example):

• Fluid
  • Channel with heated bottom
    • OpenFOAM
  • Channel with perpendicular flap
    • OpenFOAM
    • SU2
  • Channel with flap attached to a cylinder
    • OpenFOAM
  • Heat exchanger: outer fluid
    • OpenFOAM
  • Heat exchanger: inner fluid
    • OpenFOAM
• Structure
  • Beam
    • CalculiX
  • Perpendicular flap
    • CalculiX
  • Flap attached to cylinder
    • CalculiX
• Heat Transfer
  • Heated plate
    • FEniCS
    • Nutils
    • OpenFOAM
  • Heat exchanger: solid
    • CalculiX

Still, I think we would not really reduce complexity this way, but rather transform it. I would rather stick to what we have already. If a tutorial is exactly the same as another one for one participant, then I would simply write "copy this from there", as @BenjaminRueth did already. Even further, we could simply provide a one-line script to do this.

from tutorials.

I agree with @floli though I cannot see his post any longer. The structure Single physics/Geometry/Solver, I find indeed a bit over-engineered.
Still, I think we need to restructure the tutorials soonish as we are getting more and more, and more and more different types. Which is good, of course!

Two suggestions:

• Let's get rid of the coupling physics layer, FSI, CHT etc. I don't think that users will search by this. The top level could just directly be the testcase, FSI3, Flow over heated plate, Heat exchanger, etc.
• The second layer could directly be the solver, where the user can then choose among different options (if applicable). "Choosing" means solely modifying the preCICE config. Here, I am, however, not sure whether this is feasible and whether it is the best solution.

Option 1 (ideal world)

• FSI3
  • precice-config.xml
  • OpenFOAM
  • dealii
  • CalculiX
  • FEniCS
  • nutils
• Heat exchanger
  • precice-config.xml
  • OpenFOAM1
  • OpenFOAM2
  • CalculiX
• Beam
  • precice-config.xml
  • CalculiX1
  • CalculiX2
  • FEniCS1
  • FEniCS2
• ...

On the testcase level, there could further be an Allrun and an Allclean script, but nothing else! Also not logging output etc.

Option 2 (pragmatic)

• FSI3
  • OpenFOAM-dealii
    • precice-config.xml
    • OpenFOAM
    • dealii
  • OpenFOAM-FEniCS
    • precice-config.xml
    • OpenFOAM
    • FEniCS
• Heat exchanger
  • precice-config.xml
  • OpenFOAM1
  • OpenFOAM2
  • CalculiX
• ...

Option 3 (all flat)

• FSI3-OpenFOAM-dealii
  • precice-config.xml
  • OpenFOAM
  • dealii
• FSI3-OpenFOAM-CalculiX
  • precice-config.xml
  • OpenFOAM
  • CalculiX
• ...

Furthermore, but maybe this does not belong here (let's take some time to discuss this at the next coding days):

• All solvers should be started from the sub-folders, exchange-directory is always "..".
• Participants named after their solver, not after their physics ?? so OpenFOAM, not Fluid (maybe PimpleFOAM)

from tutorials.

@floli:

Don't forget the tutorials are tutorials. Their purpose is too show people how to set up simulation cases involving preCICE. They are not a lesson in software engineering or library development. As a new user, I would seriously be turned down by the need to understand a library-like structure of bash or python scripts calling each other, even it is minimizes code duplication.

That's why I try to include both a fully automatic Allrun script, but also very simple runFluid/runSolid scripts.

imho, the tutorials should be self-contained, so that a user can copy the case, start modifying it without the need to keep the other tutorial cases or some additional tutorial library code.

I completely agree!

For tutorials, I would prefer straight and easy case steering code, even if snippets are copied around.

What do you mean here?

@uekerman:
I understand that, at the moment, having many directories can be a bit annoying, but I don't see why move to a completely flat structure. With omitting the physics from the directory structure I am also not sure, as users may only be interested in FSI, or only in FF etc. But if it is in the naming scheme, I am ok with it.

* All solvers should be started from the sub-folders, `exchange-directory` is always `".."`.

Consistency here is important, indeed.

* Participants named after their solver, not after their physics ?? so `OpenFOAM`, not `Fluid` (maybe `PimpleFOAM`)

Here I disagree: it's not physics, but subdomain and could be many of them using the same solver. But let's discuss it in a separate thread/coding days.

from tutorials.

With omitting the physics from the directory structure I am also not sure, as users may only be interested in FSI, or only in FF etc.

I think that users will first look for the solver (e.g. OpenFOAM), only then for the coupling physics.

But let's discuss this at the coding days. There is certainly no easy solution to all this.

from tutorials.

Just discussed between @MakisH and me. Things that should / could improve (but not urgent):

• The solver (e.g. OpenFOAM) is more important than the coupled physics (Fluid or FSI) for the user because tutorials should be for the adapters (and preCICE), not for the (physical) coupled problem.
• Solvers should be started from subfolders. All solver related files should go there (including all output and e.g. plotDisplacements.sh).
• Hide, but still retain the automation scripts (documentation should not focus on them)
• Prefer editing over automation for precice-config.xml, since the user needs to learn this. Also, see precice/precice#347
• Other problems are still open (such as the config duplication)

from tutorials.

In the end, we could write guidelines in markdown on how a tutorial should be structured and add it to the tutorials repo.

from tutorials.

See also #72. Do we have any updates or new opinions on this issue?

from tutorials.

See also #72. Do we have any updates or new opinions on this issue?

No updates. I think everything above is still valid. We should go for an easy first round of more consistency as described above:

• The solver (e.g. OpenFOAM) is more important than the coupled physics (Fluid or FSI) for the user because tutorials should be for the adapters (and preCICE), not for the (physical) coupled problem.
• Solvers should be started from subfolders. All solver related files should go there (including all output and e.g. plotDisplacements.sh).
• Hide, but still retain the automation scripts (documentation should not focus on them)

from tutorials.

This was the original trigger for the tutorials restructuring project: https://github.com/orgs/precice/projects/5

With this project being closed in the next hours, we consider this closed.

from tutorials.