Problem reproducing published Taylor-Green results

Hi,

I have very recently picked up PyFR. I have been trying to compute the Taylor-Green vortex solutions reported here: On the utility of GPU accelerated high-order methods for unsteady flow simulations: A comparison with industry-standard tools - ScienceDirect

I used the .ini file provided with the MMC1 extras, via the Science Direct link, and ran the p5 case on the 43^3 mesh.
This is what I was expecting:

![pic1|614x484](upload://76JSoTsKib1GaLKhjBvFDl2w6ZR.pn

This is what I got:

pic2

This is the published ini file (to which I have added tend=169.0):

  ;cblas-mt = Enter path to local multi-threaded BLAS library for OpenMP backend
  
  [constants]
  gamma = 1.4
  mu = 7.395099728874521e-05
  Pr = 0.71
  
  M=0.1
  
  [solver]
  system = navier-stokes
  order = 5
  
  [solver-time-integrator]
  scheme = rk45
  controller = pi
  t0 = 0.0
  dt = 0.0001
  atol = 0.000001
  rtol = 0.000001
  safety-fact = 0.9
  min-fact = 0.3
  max-fact = 2.5
  tend = 169.0
  [solver-interfaces]
  riemann-solver = rusanov
  ldg-beta = 0.5
  ldg-tau = 0.1
  
  [solver-interfaces-quad]
  flux-pts = gauss-legendre
  
  [solver-elements-hex]
  soln-pts = gauss-legendre
  
  [soln-output]
  format = pyfrs-dir
  basedir = .
  basename = taylor_green-1-%(t).3f
  times = range(0, 169.03, 1001)
  
  [soln-ics]
  u    = +0.118321595661992*sin(x)*cos(y)*cos(z)
  v    = -0.118321595661992*cos(x)*sin(y)*cos(z)
  w    = 0.0
  p    = 1.0+1.0*0.118321595661992*0.118321595661992/16*(cos(2*x)+cos(2*y))*(cos(2*z)+2)
  rho  = (1.0+1.0*0.118321595661992*0.118321595661992/16*(cos(2*x)+cos(2*y))*(cos(2*z)+2))/1.0

I would be grateful for any advice.

Dave.

Looks like I messed up the upload of the first image. Trying again. Kinetic energy vs time:

pic1

What is the perceived issue here?

If you are worried about the small differences between the plots I wouldn’t. There are been numerous changes to the code since that paper that could lead to these.

For example:

  • The kinetic energy can be significantly effected by the Reimann solver
  • The LDG upwinding is controlled by which interface is tagged as left vs right. Any change to the tagging algorithm will effect this.
  • I see you are using the PI controller, this changes the time step and we have changed the PI controller weights since this paper, so the dt used for each step will no longer match, even thought both used RK45 with the PI controller.

These are just some things I could think of that could cause these differences, there may be more

Hi Will,

Sorry, I have not made myself sufficiently clear, possibly because one of the images did not load properly in the first post. It seems that new users are permitted one embedded media per post.

I am comparing the solutions presented in the first post with the expected result presented in the second post. These are not similar.

Dave.

Well, this is embarrassing, I have been postprocessing the solution incorrectly.

Hi Will,
I also want to reproduce the taylor-green example in this paper recently.
Unfortunately, the ini provided in this paper seems to be an earlier version of pyfr, and I use the latest version of pyfr, that is 1.15.0. What should I pay attention to when I use the ini provided in this paper to calculate on the latest version of pyfr?

It seems that I don’t fully understand your answer above.

What I want to know is, how should I understand the following code?

  [soln-output]
  format = pyfrs-dir
  basedir = .
  basename = taylor_green-1-%(t).3f
  times = range(0, 169.03, 1001)

As far as I know, there is no [soln-output] entry in the latest version of pyfr document. What I don’t understand in particular is the content of times = range(0, 169.03, 1001). Can you explain the meaning of this older writing in detail?

Besides modifying the contents of output, are there any other points that I should pay attention to in order to make the old ini run well on the new version of pyfr?

Can you try the inifile found here: TGV Performance Numbers

The paper “On the utility of GPU accelerated…” is quite old now and PyFR has change quite a bit.

Some things may be too profound for me now, but I will try my best to understand it.
I understand now that the paper may be a little old.

However, when I want to try taylor-green as an example, I think maybe its ini file configuration will enlighten me, won’t it?

I can’t understand the meaning of times = range(0, 169.03, 1001) in its [soln-output] module. Could you explain it, please?

Best regards.

This is an old feature; please check out the documentation for the current features available. For example, the writer plugin is here: User Guide — Documentation

The code can also tell you a lot: https://github.com/PyFR/PyFR/blob/2474e05160ea757ffef2f081c00903ca915f5c47/pyfr/plugins/writer.py

Thank you for your patience.

I really read the official documents carefully, and I really know that the correct way to write output now is

[soln-plugin-writer]
dt-out = 0.01
basedir = .
basename = files-{t:.2f}
post-action = echo "Wrote file {soln} at time {t} for mesh {mesh}."
post-action-mode = blocking
region = box((-5, -5, -5), (5, 5, 5))

But what I want to know is that the three numbers of the range that appeared in the past expressions seem to indicate time. What do they mean?
namely “ times = range(0, 169.03, 1001)”

I’m really confused because there seems to be no relevant content in the latest output expression.

I want to know the meaning of these three numbers in the past expression out of curiosity. I didn’t find the relevant explanations in the official documents, of course, because they are out of date, but I am really curious and look forward to your explanation.

Best wishes.

I don’t know what they mean, but taking an educated guess, I imagine it is asking for outputs to be written at all the times generated by np.linspace(0, 169.03, 1001). But I really wouldn’t get bogged down in this as it’s the API for a version of the code you definitely shouldn’t try to run anymore.

Also the readthedocs page only goes back to 1.12 as that’s the version when I implemented it, further back than that and you’ll have to consult the docs in the git repo.