Hi Zach,
The backward Euler, bdf2, and bdf3 are backward difference schemes,
which are iterated explicitly in pseudo time. This is because fully
implicit approaches in high-order are unattractive for GPUs due to their
memory limitations. Therefore, the CFL is limited by the stability of
the explicit RK4. You have specified the pseudo time step larger than
the real time step, which is why the simulation is almost guaranteed
blow-up.
The source terms are not the issue. They are just used to prevent the
reflection of the initial pseudo wave to make the initial transient
phase faster and cleaner. You should be able to run the case without
them, but then in the transient phase you are left with bouncing
pressure waves. The coordinates +/-5 and +/-25 are from the origin,
which is in the middle of the cylinder.
Yes, the paper says that the factor typically ranges from 1 to 4, but
there is much more literature on this. Its appropriate value is
affected by many different aspects, such as length scales in the
simulation and the grid you are using. Moreover, it should have
different values the viscous and advection dominated areas. Since the
optimal value for beta should be temporally and spatially varying, the
best option for now is just to find a good global value and stable time
steps for each configuration heuristically. The value ac-zeta = 6 seemed
to work fine in my configuration.
I managed to start the simulation with bdf2/rk4, ac-zeta = 4.0, dt =
0.0002, pseudo-dt = 0.0001 and 7th order flux anti-aliasing, but
simulation blows up starting from the boundaries (picture attached).
Just to be sure that the boundary definitions work correctly in the
Pointwise pyfrm writer, could you write your mesh as Gmsh .msh and send
it to me.
Thanks,
Niki
On 17/03/17 18:16, Zach Davis wrote:
Hi Niki,
I’ve modified my 2_d cylinder mesh to use a diameter of 1. I’ve also
brought in the control volume boundaries to align more with what was
covered in the paper reference you provided. I’ve attached the mesh
and configuration files I’m using in the hopes that you might have
some time to help me troubleshoot, so I can better understand the
process involved. The solver is diverging, and i’ve tried increasing
the max number of sub-iterations, decreasing the time step, and so
forth. I suspect it may have to do again with the source terms which
I still don’t quite understand (are your +/-5 and +/-25 from the
cylinder boundary or from the control volume boundaries?).
Also the paper suggests that the artificial compressibility factor
they use is 1.25 and typically ranges from 1 to 4. Could you explain
why you opted for a factor of 6? Lastly, is there a difference in how
one should choose a time step and pseudo time step depending on
whether the backward euler, bdf2, and bdf3 schemes are used? I assume
the former is an explicit scheme; whereas, the latter two are
implicit? Thanks!
Best Regards,
Zach
enc
On Mar 16, 2017, at 12:47 PM, Niki Loppi <[email protected]
<mailto:[email protected]>> wrote:
Zach,
Yes, I saw that in your original .vtu file. However, when I started
the simulation from scratch with your mesh, it did not reproduce the
error. However, I did repartition it into two. Did you try it without
partitioning?
The cylinder diameter is not defined in the .ini file, but my mesh
was generated so that D=1 and domain length -5<x<30 units. According
to Paraview, your D=~285 and domain -2500<x<20000 units. Therefore,
some of the values in the .ini file including the source terms should
be scaled to match the dimensionless quantities. For example, now
your Reynolds number is Re=1*285/0.008 = 35625 and one flow through
would take 22500 time units. In the original file Re = 1*1/0.008=125
and flow through time 35 units.
-Niki
On 16/03/17 16:43, Zach Davis wrote:
Niki,
You aren’t seeing this in Paraview (see attached screenshot)? Also,
where is the cylinder diameter defined within the *.ini file for
this case. Are you referring to your setup of the source terms?
Best Regards,
Pointwise, Inc.
Zach Davis
Pointwise®, Inc.
Sr. Engineer, Sales & Marketing
213 South Jennings Avenue
Fort Worth, TX 76104-1107
*E*: [email protected] <mailto:[email protected]>
*P*: (817) 377-2807 x1202
*F*: (817) 377-2799
enc
<Mail Attachment.png>
On Mar 16, 2017, at 8:22 AM, Niki Loppi <[email protected]
<mailto:[email protected]>> wrote:
Hi Zach,
I tried running your case for couple of outputs and did not
experience the odd behaviour in your .vtu file (attachment).
However, in your mesh the dimensions are scaled differently. For
instance, the cylinder diameter is D=~285, while the values in the
.ini file are specified for D=1 used in my mesh.
Cheers,
Niki
On 15/03/17 20:27, Zach Davis wrote:
Hi Niki,
Thanks for the explanation. I’ll look into this method a bit
further based on the paper reference you provided. Something
seems to be amiss with solution files. I’ve attached the *.pyfrm
*.vtu and *.ini files I have generated for this case; though, the
mesh is one of my own creation. If someone could explain what’s
happening with the *.vtu file based on the *.pyfrm mesh input,
then that would be appreciated.
Best Regards,
Pointwise, Inc.
Zach Davis
Pointwise®, Inc.
Sr. Engineer, Sales & Marketing
213 South Jennings Avenue
Fort Worth, TX 76104-1107
*E*: [email protected] <mailto:[email protected]>
*P*: (817) 377-2807 x1202
*F*: (817) 377-2799
enc
On Mar 15, 2017, at 8:42 AM, Niki Loppi <[email protected]
<mailto:[email protected]>> wrote:
Hi Zach,
AC stands for the method of artificial compressibility. Instead
of relying on a Poisson based projection, the system is driven
towards a divergence free state by introducing artificial
pressure waves through the continuity equation. The formulation
preserves the hyperbolic nature of the system, but destroys the
time accuracy, which is then recovered with dual time stepping.
For the ac formulation you can refer to
http://www.sciencedirect.com/science/article/pii/S0021999116001686
The artificial compressibility factor ac-zeta is the coefficient
of the fluxes in the continuity equation. This results in
characteristics
V + c, V, V - c,
where c = sqrt(V^2 + ac-zeta) is the pseudo speed of sound. Thus,
in the current implementation ac-zeta is the free parameter that
is used to downscale the speed of the pseudo-waves to globally
reduce the pseudo system stiffness. The parameter is something
that one can experiment with, typical values varying from 1.25 -
10 times the freestream velocity. Currently, I am looking into
making ac-zeta and pseudo-dt spatially and temporally varying.
The source terms specify a sponge region near the domain edges
(|y|>5, x<-5, x>25) to damp the initial pressure wave that is
generated when the simulation is started from scratch. Please
note that the sponge turns off at t=5 because of the (1 -
tanh(1.5*(t - 5.0)))*0.5 coefficient. You can see how the sponge
works if you write the solution files before t=5.
The plugin [soln-plugin-pseudostats] is used to output the
residual of the pseudo time problem to monitor the divergence.
The [soln-plugin-residual] on the other hand computes the
"residual" of two consecutive real time steps. The
[soln-plugin-fluidforce] plugin can be used with the ac systems.
Coarsening the mesh and increasing the order is something that
would be beneficial, especially when using a polynomial multigrid
for accelerating the pseudo time problem. P-multigrid should be
added in the next release.
Thanks,
Niki
On 14/03/17 23:37, Zach Davis wrote:
Tuesday, 14 March 2017
Peter & Freddie,
I believe the mesh export issue from Pointwise using the PyFR
exporter has been resolved in PyFR 1.6. I still seem to have
issues running using the OpenCL backend which persistently
complains about an invalid workgroup size. It use to work at
one point, but something has changed in the intervening releases
which is causing problems for me at least. I’ve tried adjusting
the values per Freddie’s guidance to no avail. He also
suggested a tool that might be helpful in determining the
appropriate workgroup size needed for my card. Unfortunately
that tool seems to be NVIDIA card specific requiring
installation of NVIDIA software that won’t run on my machine.
I’m using an AMD card instead, and the tool won’t compile due
to missing dependencies. It’s not a pressing matter, but just
something that I thought you both might want to be aware of.
Nikki,
I’ve looked over your incompressible 2d-cylinder case, and I was
wondering if you could elaborate a bit, or point me to some
reference, about how you came up with the source terms you’re
using in the input file. It also appears that the
[soln-plugin-pseudostats] is used in place of the
[soln-plugin-residual] namelist for incompressible cases—is that
right? Does the [soln-plugin-fluidforce] namelist still work
for the ac-navier-stokes solver? Another question if you don’t
mind—what is this artificial compressibility factor, ac-zeta and
why is value of 6.0 used? Oh, and what does the ac prefix stand
for? Thanks!
I think it would be interesting to see how coarse of a
higher-order mesh could be made for this case while increasing
the polynomial solution basis such that you essentially recover
the linear mesh spacing in each element, and see if you could
capture one or more vortices within a single element with any
noticeable diffusion over time.
Best Regards,
Pointwise, Inc.
Zach Davis
Pointwise®, Inc.
Sr. Engineer, Sales & Marketing
213 South Jennings Avenue
Fort Worth, TX 76104-1107
*E*: [email protected] <mailto:[email protected]>
*P*: (817) 377-2807 x1202
*F*: (817) 377-2799
--
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 post to this group, send email to
[email protected]
<mailto:[email protected]>.
Visit this group at https://groups.google.com/group/pyfrmailinglist.
For more options, visit https://groups.google.com/d/optout.
--
Niki Andreas Loppi MSc
Postgraduate Researcher
Department of Aeronautics
Imperial College London
South Kensington
London
SW7 2AZ
UK
--
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 post to this group, send email to
[email protected]
<mailto:[email protected]>.
Visit this group at https://groups.google.com/group/pyfrmailinglist.
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 [email protected]
<mailto:[email protected]>.
To post to this group, send email to
[email protected]
<mailto:[email protected]>.
Visit this group at https://groups.google.com/group/pyfrmailinglist.
For more options, visit https://groups.google.com/d/optout.
<0.5cylinder.png>
--
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 post to this group, send email to
[email protected]
<mailto:[email protected]>.
Visit this group at https://groups.google.com/group/pyfrmailinglist.
For more options, visit https://groups.google.com/d/optout.
--
Niki Andreas Loppi MSc
Postgraduate Researcher
Department of Aeronautics
Imperial College London
South Kensington
London
SW7 2AZ
UK
--
Niki Andreas Loppi MSc
Postgraduate Researcher
Department of Aeronautics
Imperial College London
South Kensington
London
SW7 2AZ
UK
--
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 an email to [email protected].
Visit this group at https://groups.google.com/group/pyfrmailinglist.
For more options, visit https://groups.google.com/d/optout.
