In addition to my previous email.
Large pressure residuals are normal in the beginning of the simulation.
If you do a fresh start (not restarting from a developed solution),
strong pseudo-waves occur and you have to keep running the simulation
until the waves get dissipated by the boundaries.
Niki
On 22/07/19 15:27, Niki Loppi wrote:
Hi Junting,
I have run an infinitely long SD7003 airfoil case at Re=60,000 where I
used 1e-4 for velocity and 1e-3 for the pressure. I remember that your
mesh was quite coarse for the given Reynolds number. You may want to
try adding flux anti-aliasing (may allow you to use larger pseudo-time
step sizes). Also the using tets instead of hexa in the boundary layer
might impose a stricter pseudo-cfl. Did you curve the surface mesh
using gmsh?
Please send your periodic mesh and I can have a go later tonight.
Niki
On 22/07/19 14:42, Junting Chen wrote:
Hello Niki,
I have implemented periodic condition on those two walls but still
residuals are pretty big. Pressure residual dropped from 0.08 at the
begining of a physical time step to 0.02, and velocity residual
dropped from 0.5 to 1E-3, with multi-grid method implemented.
I seen that you or your colleague has ran simulation of flow past a
infinitely long cylinder. What does the residuals of that case look like?
Junting Chen
On Thursday, July 18, 2019 at 5:40:19 AM UTC-4, Niki Loppi wrote:
Hi Junting,
I tried running the case and it appears to be very difficult
(nearly impossible) to convergence properly. I think the main
reason is that you have specified your front and back back
boundaries (top and bottom) as slip-wall.
[soln-bcs-top]
type = slp-wall
[soln-bcs-bottom]
type = slp-wall
I'm pretty sure that using a periodic z-direction would help
significantly and allow you to drive the pseudo-residuals down
several orders of magnitude. Please see Arvind's response in
https://groups.google.com/forum/#!topic/pyfrmailinglist/JLhiy8TV9xo
<https://groups.google.com/forum/#%21topic/pyfrmailinglist/JLhiy8TV9xo>
In summary, you just need name your top and bottom boundary-fields as
"periodic_0_l" and "periodic_0_r"
in you .msh / cgns file, and PyFR builds the connectivity during
the import step. In the .ini file you don't have to specify anything.
Cheers,
Niki
On 16/07/19 22:21, Junting Chen wrote:
Thanks Niki, good to know! I understand.
We are running a simple case where the geometry is just a bluff
body. Only criteria that we are using to do validation in this
case are Strouhal number (shedding frequency), drag and lift. We
noticed that increasing dt/pseudo-dt to ~100 can still maintain
stability but requiring a bit more niters to let residual drop
to a desirable level (equivalent to having dt/pseudo-dt = 30 and
niter =20). As far as i understand, the consequence of larger
dt/pseudo-dt ratio is more pseudo-steps are required to converge
within a physical step, correct me if I am wrong. Also noticed
that high residual will lead to wrong result (off shedding
frequency).
It would be really nice of you if you can take a look at my
setup. I first found out highest value of pseudo-dt I can use is
2.5E-5. Then I slightly pushed dt to 3E-3 trying to find out the
boundary where the simulation either breaks or spits out wrong
result.
In fact, another feature we are really hoping to see in the next
few release is a portal that allows users to implement a
specific velocity profile at a boundary. By saying that, another
critical test case of ours requires using a time-varying
velocity profile at the inlet (so basically we have a bunch of
velocity profiles to be implemented at each every time step).
Thanks a lot again for the clarification!
Junting Chen
On Tuesday, July 16, 2019 at 1:38:10 PM UTC-4, Niki Loppi wrote:
Hi Junting,
High memory footprint is not the only issue. Construction of
the global linear system for high-order polynomials is very
expensive on modern hardware (high memory requirements with
low arithmetic intensity). Also solving the linear system is
challenging due to global communications.
You can read about implicit time-stepping on GPUs from
http://aero-comlab.stanford.edu/Papers/Dissertation_Jerry_Watkins-augmented.pdf
<http://aero-comlab.stanford.edu/Papers/Dissertation_Jerry_Watkins-augmented.pdf>
We are working on local implicit (pseudo) time stepping
approaches, but I'm afraid they won't be ready for the next
release.
Regarding the dt/pseudo-dt ratio, I suggest keeping it in
the range of 20-50. You can send me your case files if you
want me to try it.
Thanks,
Niki
On 15/07/19 22:30, Junting Chen wrote:
Hello,
Any work ongoing to make the computation in pseudo time
steps implicit?
As Niki mentioned, implicit pseudo time stepper caused
storage issues (in one of the posts). Any chance an
implicit option can be offered in the next release?
Explicit forces pseudo dt being extremely small therefore
physical dt kind of small even though physical time stepper
is implicit. I am working on a bluff body problem. Aiming
to reduce the number of physical time steps within a vortex
shedding cycle to be around than 20, while now it has to be
more than 300 to maintain stability.
Thanks!
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 [email protected].
To post to this group, send email to
[email protected].
Visit this group at
https://groups.google.com/group/pyfrmailinglist
<https://groups.google.com/group/pyfrmailinglist>.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/pyfrmailinglist/a6ba9d83-aba8-4687-8864-ee2202574fbd%40googlegroups.com
<https://groups.google.com/d/msgid/pyfrmailinglist/a6ba9d83-aba8-4687-8864-ee2202574fbd%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout
<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 [email protected].
To post to this group, send email to [email protected].
Visit this group at
https://groups.google.com/group/pyfrmailinglist
<https://groups.google.com/group/pyfrmailinglist>.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/pyfrmailinglist/1d32d32b-3909-40de-94b0-4e1ce8f71bee%40googlegroups.com
<https://groups.google.com/d/msgid/pyfrmailinglist/1d32d32b-3909-40de-94b0-4e1ce8f71bee%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout
<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 [email protected]
<mailto:[email protected]>.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/pyfrmailinglist/a8df5fff-8926-46b4-9625-3fd5b1cda417%40googlegroups.com
<https://groups.google.com/d/msgid/pyfrmailinglist/a8df5fff-8926-46b4-9625-3fd5b1cda417%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
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 [email protected]
<mailto:[email protected]>.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/pyfrmailinglist/24154789-518b-8b02-96fc-cec7f03a251d%40imperial.ac.uk
<https://groups.google.com/d/msgid/pyfrmailinglist/24154789-518b-8b02-96fc-cec7f03a251d%40imperial.ac.uk?utm_medium=email&utm_source=footer>.
--
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 [email protected].
To view this discussion on the web, visit
https://groups.google.com/d/msgid/pyfrmailinglist/b167b37b-372b-2bdc-50bb-db130c9e3f0f%40imperial.ac.uk.
