Easy confusion on non-dimensionalization

[yangtianyong]

Dear professor:
I'm really sorry to bother you again! In your code ,the range_drag_plot is about from -0.175 to -0.13,and my results are totally in this range with your program.However,the drag coefficient in article is about 2 or 3.And I tried to use equation(2.3) to process data ,still can not get the same results(the range from 2 to 3). It is very kind if you can explain those!
Thank you professor!
sincerely:
best wishes!
A student!

[jerabaul29]

Hi!

This is because of how non-dimensionalization is made. Unfortunately in the code we are using dimensional quantities (because of some legacy reasons), and non-dimensionalization has to be done afterhand.

Namely, if you look in details at how nu, \bar{U} and D are defined, you will see that you need to renormalize the value of the drag coefficient by mutliplying a factor:

coeff_CD = -2.0 / 1.0 / (2 * 1.5 / 3)**2 / 0.1 = -20

This will give you a typical value of the drag coefficient of 2.6 to 3.5 in normalized unit.

The same applies for the time; you will have to apply a factor of 10 (here also, if you look in details in the code) to convert between the time in the simulation and the non-dimensional time.

Can you confirm me that this works for you?

[jerabaul29]

PS: the values obtained after normalization can be checked against the benchmark by Turek; see:

http://www.mathematik.tu-dortmund.de/lsiii/cms/papers/SchaeferTurek1996.pdf

The case b) 2D-2 is the same as ours (just note that they write 4 U_m = 4 * 1.5 = 6 while we write 6 in our paper for the coefficient in front of the inflow condition formula, and that their domain is centered in H/2 while our domain is centered around 0 in the Z direction, hence the difference for the H and H/2 stuff). You can check that they get the same typical value for both the drag coefficient C_D and the Strouhal number St in their table 4; respectively, C_D approx 3.23 and St approx 0.30.

[jerabaul29]

PPS: I added a note about this in the Readme: 68efde7#diff-04c6e90faac2675aa89e2176d2eec7d8 .

Please confirm that this solves your problem.

[jerabaul29]

PPPS: about the St, remember that the signal for the drag coefficient oscillates at twice the vortex shedding frequency due to symmetry of the problem... ;)

[yangtianyong]

yes ,those are really useful to deal with my problem,and now i know how to use my data correctly，thank you ,professor!

[jerabaul29]

I keep opened as this may interest also other people.

Also, I am not a professor and you can as a rule just use 'you' in the tech world / on GitHub when discussing, people will not take offense and it is faster and easier to read ;)

[gonanc13]

Hi Jean,

For the final year project of my Aeronautics degree at Imperial College I'm using your code. I'm turning the body into a rectangular cylinder (for resemblance with road vehicles) to study the adaptivity of RL to variations in the incidence and aspect ratio of the cylinder.

I understand that your code defines the simulation geometry using dimensional quantities and then you non-dimensionalize the results using the relevant quantities. However, the 2D Navier Stokes equation reported in your code is in the non-dimensional form.

1. Are the equations being solved by FEniCS in the code the dimensional or non-dimensional form of 2D Navier Stokes equations?

2. If it is the non-dimensional form that is numerically solved, what would be the issue in just using non-dimensional quantities to define the problem:
   -in the case of the circular cylinder diameter=1, timestep=0.005, cylinder mesh size = 0.1, etc
   instead of dimensional ones:
   -diameter=0.1, timestep=0.0005, cylinder mesh size = 0.01

Sorry if this is a silly question, I don't have that much experience with CFD

Thanks!

[jerabaul29]

Regarding the code, if I remember well we use the same dimensions as in the Turek paper, but with slightly different coordinate origins: see the messages in this thread from 27th May 2019. The paper uses a different, non dimensional form.

If you want to use another geometry, you will need of course to adapt the code. For a short discussion of the kind of things you may need to adapt, please see #16 .