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
On 3 Jul 2019, at 21:58, Junting Chen
<chen1...@gmail.com<mailto:chen1...@gmail.com>> wrote:
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:
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
On Wednesday, June 19, 2019 at 10:09:06 PM UTC+1, Junting Chen wrote:
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:
[1.PNG]
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
--
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
pyfrmailinglist+unsubscr...@googlegroups.com<mailto:pyfrmailinglist+unsubscr...@googlegroups.com>.
To post to this group, send email to
pyfrmailinglist@googlegroups.com<mailto:pyfrmailinglist@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<https://groups.google.com/d/msgid/pyfrmailinglist/d067b127-9236-4208-a074-c51fb6941a46%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
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 pyfrmailinglist+unsubscr...@googlegroups.com.
To post to this group, send an email to pyfrmailinglist@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/97F01679-1FF1-455D-85A5-B537CC6ABA9E%40ic.ac.uk.
For more options, visit https://groups.google.com/d/optout.
