non-dimensional velocity input

[Junting Chen]

Hello Dr.Witherden,

Since our discuss was nothing related to OpenMP or cuda, I think it would be better to open another thread.

So today instead of "u = 20", I used "u = 0.0583090", normalized by the speed of sound. 

I have tried cases such as:

    - 2nd order and 4th order (to see result quicker, I chose 2nd order)

    - ac-char-riem-inv for both inlet and outlet

    - ac-in-fv for inlet and ac-out-fp for outlet

    - initial condition of "u = 0.0583090"

    - initial condition of "u = 0" with the expectation of seeing movement of incoming flow profile approaching the bluff body

I have not made it run properly yet. The central plane (y=0) looks like after 40s - 200s in the cases above:

Seems there is something preventing the incoming flow entering the fluid domain from the left.

In the case where initial condition of the fluid domain was set the same as the inlet, the flow is not developing at all.

Would you mind to take a brief look of my ini file and give me some hints? What is the difference between using ac-char-riem-inv for both inlet and outlet, and using ac-in-fv for inlet and ac-out-fp for outlet?

I also noticed that in the example case couette_flow_2d, in the "ini" file it stated that "Uw"=70 and "p=100000". Apparently these values are not normalized. Please let me know in what situations the inlet velocity needs to be normalized.

Also, in the 3d_cylinder case (along with the publication), the initial condition was set like: u    = 0.2366431913+0.001*z*yv    = 0+0.001*z+0.01*cos(x)*cos(y)*cos(z)w    = 0+0.001*z+0.01*cos(x)*cos(y)*cos(z)Is there any meaning behind them or they were just optimized to push convergence? In the case, seems like not only "u", "v", and "w", "x", "y", and "z" are normalized values as well. Thanks a lot!Best regards,Junting Chen

[Giorgio Giangaspero]

Hi Junting

keep in mind that the boundary conditions starting with 'ac' refer to the artificial comprehensibility method, which is what the incompressible solver is based upon. If the flow is incompressible then by definition the speed of sound goes to infinity and the Mach number is zero. Thus normailsing with respect to the speed of sound may not be the best option.

For the incompressible solver, I typically set in pyfr u=1,p=1 and then change the viscosity to obtained the desired Reynolds number (see the incompressible cylinder in the examples). With this choice the artificial compressibility variable zeta, ac-zeta=3 or 2.5, usually works fine. Also the boundary condition ac-char-riem-inv typically works well for the incompressible solver.

The choice of normalisation is up to you. In principle PyFR can be run with all dimensional values. However, for the incompressible solver I would suggest the numbers above.

Yes the initial condition for the cylinder was chosen to minimise the initial transients. Again the combination of variables (u,v,w,rho,p) and domain size (x,y,z) is such that you obtain the desired Reynolds and Mach number.

Best

Giorgio

[Junting Chen]

Great! Thanks for clearing things out!

Junting

[Junting Chen]

Hello Giorgio,

Sorry to bother you again, since we had some had some discussion on ac-zeta selection.

So, I am currently running a bluff body case on 2nd order first, then switching to 4th order. It keeps breaking. Sometimes I found that dropping ac-zeta can prevent it from breaking, sometimes I found that reducing pseudo-dt can prevent it from breaking, or ultimately reducing dt can prevent it from breaking (which is not something I want to do..).

For the case I am running now, Inlet velocity I set as 1, max velocity in the domain is around 2,3. Smallest cell in the mesh is 0.01. In the 2nd order run I set dt = 0.0005, pseudo-dt = 0.0001 which makes the Courant number significantly smaller than 1. I understand that dt should drop as we go for higher order. I am thinking if there is a way to keep it from diverging by using some specific ac-zeta? what is the physical significance of ac-zeta? What kinds of difference will it make if I set ac-zeta = 9 versus ac-zeta =1.1? I have seen that suggested value of ac-zeta is between 1 and 10 times the max velocity. What I feel now is smaller ac-zeta somehow reduces the chance of diverging, but it only works to certain level.

Currently, seems that I made it run by reducing pseudo-dt. I am also not sure why this happens.. I don't have the result yet, so don't know if it really works... As far as I understand pseudo-time step acts like inner iterations. So is there any guideline on choosing the right pseudo-dt? 

Best regards,

Junting Chen

On Monday, June 24, 2019 at 12:11:55 PM UTC-4, Giorgio Giangaspero wrote:

[Loppi, Niki A]

Hi Junting,

Let me try to give you few tips.

1. As the pseudo-stepper is always explicit, your pseudo-dt is limited by CFL.

    - Selection of pseudo-dt requires a bit of experimentation because CFL is dependent on the mesh, polynomial order and ac-zeta.

    - Keep the rest of the parameters in their default values and try few different pseudo-dt values to ensure that you are in the right ball park.

2. Physical stepper is always implicit. Use large dt/pseudo-dt ratios in the range of 20-50x

    - Requires more pseudo-time steps within a time step but does not make the simulation slower as you take larger physical time-steps. This helps to  converge the pressure (more divergence free).

    - I always set dt very large, try a couple of different pseudo-dt values to find largest stable one, and finish by adjusting dt to approx 30x larger than the pseudo-time step size.

3. Use local-pi pseudo-controller to enable locally adaptive-pseudo time stepping and always use P-multigrid that goes down to p=0

    - These can speed-up the simulation by over 10x

4. "I have seen that suggested value of ac-zeta is between 1 and 10 times the max velocity.” 

     - This sounds good. I tend to use 3x max velocity always. 

     - ac-zeta sets the pseudo speed of sound so if you increase it you need to decrease pseudo-dt.

5. Use ac-char-riem-inv boundary condition in the far-field.

6. Use pseudo stats plugin to monitor the convergence.

My suggestion is to use the following as a starting point. There is a lot of parameters to experiment with, but usually the default values work the best.

ac-zeta = 4 

dt = <set a large value as it is implicit>

pseudo-dt = <find maximum stable one as it is explicit>

pseudo-controller = local-pi

pseudo-dt-max-mult = 2.5

max-fact= 1.01

min-fact = 0.98

atol = 1e-6

pseudo-niters-max = 20

pseudo-niters-min = 5

pseudo-resid-norm = l2

pseudo-resid-tol = 1e-4

pseudo-resid-tol-p = 1e-3

[solver-dual-time-integrator-multip]

pseudo-dt-fact = 1.6

cycle = [ (2, 1), (1, 1), (0, 3), (1, 1), (2, 5)] # for P2

cycle = [(4, 1), (3, 1), (2, 1), (1, 1), (0, 3), (1, 1), (2, 1), (3, 1), (4, 5)] # for P4

[soln-plugin-pseudostats]

flushsteps = 1

file = pseudostats.csv

header = true

[soln-bcs-outlet]

type = ac-char-riem-inv

ac-zeta = 120

p = 1.0

u = 1.0

v = 0.0

w = 0.0

[soln-bcs-inlet]

type = ac-char-riem-inv

ac-zeta = 120

p = 1.0

u = 1.0

v = 0.0

w = 0.0

Hope this helps.

Niki

-- 
You received this message because you are subscribed to the Google Groups "PyFR Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pyfrmailingli...@googlegroups.com.
To post to this group, send email to pyfrmai...@googlegroups.com.
Visit this group at https://groups.google.com/group/pyfrmailinglist.
To view this discussion on the web, visit https://groups.google.com/d/msgid/pyfrmailinglist/d067b127-9236-4208-a074-c51fb6941a46%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Junting Chen]

Thanks Niki for those hints. They are very helpful to get better understanding of the code.

The result I am getting becomes much better (pretty close to wind tunnel results). The issue now is the run speed. I admit that the only resource I have is a half k80 GPU. With the same setup you provided (using the largest allowable pseudo-dt and the physical dt being 30x of pseudo-dt), the simulation is taking way too long. Even pyfr in 2nd order method takes longer time to run compare with OpenFoam, and 4th order pyfr run takes way too long (nearly 24hr to complete 1 vortex shedding on a grid of 71,000 tet cells).

So here are things I am experimenting right now, please review it and hopefully you can give me some comments:

1. increased the ratio of physical dt to pseudo-dt to 100-200, and increased pseudo-niters-max to 50 to 100? In this case, all p and U can converge better? I feel like 30x still makes the physical-dt somewhat small (about 1000-2000 time steps inside a vortex shedding). I have tried to increase the ratio of physical dt to pseudo-dt without increasing pseudo-niters-max, it resulted in incorrect vortex shedding frequency. I am hoping extra pseudo iteration can help resolve this issue.

2. also gave more steps to 0th order in the p multi-grid cycle and less 4th order steps?

3. decrease ac-zeta ---> allowing larger pseudo-dt ---> allowing larger physical dt?

Maybe there is something else I didn't think of at the moment. Really appreciate your help.

Junting

To unsubscribe from this group and stop receiving emails from it, send an email to pyfrmailinglist+unsub...@googlegroups.com.