Documentation of parameters to change for each supported solver

[MakisH]

Originating from the review of the restructuring the perpendicular flap FSI tutorial cases: precice/tutorials#146 (comment)

Such a hint would be useful for users that want to compare cases, and it would also helpful for us to navigate in each solver's configuration, without having to first read their documentation (as we are typically not users of the solvers).

Such parameters could include density, viscosity, heat conductivity, etc. Each maintainer should document as much as they think is useful (and to the extent of their understanding).

• OpenFOAM @MakisH
• CalculiX (edit to assign yourself)
• deal.II (edit to assign yourself)
• FEniCS @BenjaminRodenberg
• SU2 @BenjaminRodenberg
• code_aster @MakisH

See a related discussion in precice/tutorials#150.

This issue can be closed when each of the above items is checked. Each item can be checked when a contributor says it is covered good enough.

[BenjaminRodenberg]

I think defining the parameters clearly and providing them on the website will help us a lot in the future! I am just not 100% what to do. Therefore, I try to give an example:

We want one piece of documentation per solver and case. Example: I document where in the code (line ... in perp_flap-py) one can set which parameters (Young's modulus E, ...) on the FEniCS side for the FSI case and what the default values are (known working parameter set is E = 123 and ...).

Do you already have some place in mind where we want to put this information? For the FSI example from above, we could add another level Solid: FEniCS below Tutorials > Perpendicular flap where all the information is provided.

[BenjaminRodenberg]

Another thing that might be useful: Sometimes there exist well-know formulas to convert one set of parameters to another one. OpenFOAM, for example, uses the Prandtl number Pr to define flow with heat transport, while it uses Diffusivity + Conductivity for heat transport in a solid. That's what I understand from the transportProperties and the preciceDict.

Conversion from one system to the other is sometimes important when debugging and it might be useful to collect this knowledge for future changes in the parameters of the tutorials. Any opinions on this "feature"? We can also put this into an independent issue, if you prefer.

[MakisH]

I don't mean documenting the parameters of each tutorial: that would be difficult to maintain.

What I mean is a sentence such as "In case.inp you can set the Young's Modulus using the parameter E" (or whatever). No values, only future-proof hints.

Your comment about the inconsistency OpenFOAM adapter is mainly an issue with the current implementation and I don't want to discuss it in this issue. For application-specific knowledge, we can always write on Discourse and link from the documentation. If something is crucial, we move it to the docs.

[MakisH]

I don't really see how we can act on this issue at the moment. Now all cases are using the same parameters, and those that don't are clearly stated, explaining how they differ.

One can usually guess by looking at the numbers where each parameter is set, while the adapter documentation pages could already hint towards common parameters.

We have taken a decision to keep our tutorial pages slim and not go too deep in details. Unless we decide to offer more details, I don't think we can do anything else here.