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.