elastic-tube-1d : Unclear / wrong physicial parameters

[boris-martin]

The dimensionless stiffness is supposed to be a function of material properties and inlet velocities. In terms of code, either the stiffness is computed from these, or it is fixed and some properties or the inlet velocities should be deduced. But here, both inlet and stiffness have an independant definition (which could be correct if these are used to compute E or h, but I don't think it's done, at least not explicitly). I'm not confident enough with the code to say if E or h is deduced somewhere , but something definitely wrong for me is the dx = L / kappa instead of dx = L / N. Material properties should not impact the mesh size if the mesh size is another parameter (N). Currently, N and kappa happen to have the same value so it has no impact, but this makes it quite tricky to run the tutorial with different values without creating inconsistencies.

https://github.com/precice/tutorials/blob/8e71370f0700caa25892af04145be79a3f79aff5/elastic-tube-1d/fluid-python/FluidSolver.py#L19-L29

(For reference, paper definition of the quantities can be found around page 142 of B. Gatzhammer's thesis : https://www5.in.tum.de/pub/Gatzhammer2014_preCICE.pdf)

Any insight ?

(Poke @fsimonis , I think you have some experience with this code given the history)

[fsimonis]

I ran into this when looking into both versions of the elastictube-1d.

General problem is that their naming is not consistent in both versions. Furthermore, the naming changes once parameters are passed to the function that does the actual work.

I would advise to unify the naming of the parameters and constants in both solvers for the command-line interface, the main function and the parameter names of the solver functions. I am certain that this alone will reveal bugs we have in these solver.

[MakisH]

This is also a code we very often use for student research projects, so the more consistency and documentation, the better!

[boris-martin]

I could probably improve this when I'm done with other things with higher priority... By the way, I also realize the plotting part could be improved : current script has the number of steps as a constant, so if we want to do different time steps or durations, we have to change this file too.

Any suggestion on the best approach to fix this ? I'd be happy to add something like a YAML file containing everything (so we don't have to update material properties in both solvers, ...) that is read by all solvers AND the plotting script, but that would add an additional dependency (pyyaml and, with C++, libyaml-cpp) and I don't know if you think the compromise between usability and dependencies is good enough .

[MakisH]

I could probably improve this when I'm done with other things with higher priority...

This is not urgent and there will be always issues popping up on the elastic-tube-1d. Don't worry, if you can contribute something at some point, it would be very welcome! :-)

Any suggestion on the best approach to fix this ?

I would indeed prefer to avoid adding additional dependencies. I don't think we need a configuration file, we anyway don't share configuration files between participants in the more complex tutorials. Each solver has its own format and I think this is fine. Hard-coding is enough, given some consistency and documentation.