Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
boris-martin opened this issue Nov 16, 2021 · 4 comments
Open

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

boris-martin opened this issue Nov 16, 2021 · 4 comments

Comments

@boris-martin
Copy link
Contributor

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.

u0 = 10 # mean velocity
ampl = 3 # amplitude of varying velocity
frequency = 10 # frequency of variation
t_shift = 0 # temporal shift of variation
p0 = 0 # pressure at outlet
kappa = 100
L = 10 # length of tube/simulation domain
N = 100
dx = L / kappa
# helper function to create constant cross section

(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
Copy link
Member

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
Copy link
Member

MakisH commented Nov 17, 2021

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

@boris-martin
Copy link
Contributor Author

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
Copy link
Member

MakisH commented Nov 17, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants