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
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 pyfrmai...@googlegroups.com <javascript:>.
To post to this group, send email to pyfrmai...@googlegroups.com
<javascript:>.
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 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/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.
--
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/a8bcccdf-32f3-41a6-1bdf-455f0d93f226%40imperial.ac.uk.
For more options, visit https://groups.google.com/d/optout.
