Enstrophy of Taylor-Green vortex

Hello, I want reproduce the result of the Taylor-Green vortex, and I used the ini file attached below. But the enstrophy is very small,such as 1e-7 magnitude, part of the intergate file shows as follows. I used 0.5int-enst/(6.28 6.28*6.28) to cpmpute the enstrophy. Could someone know why this happened?

t,int-E,int-enst
0.0,61.88686627706847,0.0
0.4078656934018042,61.71802887873954,2.296300887116251e-08
0.8126183908977003,61.66268203880613,2.2212134292246567e-08
1.2169787745012177,61.58912752367325,2.1407088724571597e-08
1.6213517499473626,61.40097967914074,2.335030599623308e-08
2.024735988773325,61.32884987397709,2.340023530064617e-08
2.429111965244726,61.150483719028344,2.6112916912040565e-08
2.8334889495806497,60.97994750963156,2.8637945756793558e-08
3.2378705009449598,60.76012199832907,3.271690050704794e-08
3.6422420383489493,60.414482995681674,4.005853489985599e-08
4.046274631632653,60.08034786662381,5.033455666865129e-08
4.4506458091006325,59.53703404808475,6.748288945787687e-08
4.855020538699844,58.79887780590352,8.443631895397037e-08
5.258836914167074,57.89562220938521,9.719333586798353e-08
5.663215056052942,56.88529038770501,1.0474202893366631e-07
6.0673729685088995,55.788333167493114,1.1838002565398031e-07
6.471739485748487,54.511532291536916,1.310943058129848e-07
6.876105308222941,53.08500329326516,1.3945450301219878e-07
7.27852897903444,51.540097049753726,1.505466677746701e-07
7.682910004531521,49.74735830317027,1.7738844455941727e-07
8.080485954171163,47.732202932666794,2.1336828115703726e-07
8.484847463344611,45.39140036066121,2.2297014408616568e-07
8.888743802772288,42.920517827578934,2.2261182749731495e-07
9.293741641193087,40.55697054723922,2.1696698181250097e-07
9.698161132745843,38.31054255039028,2.180221050457046e-07
10.097959610421743,36.10005644885872,2.2224672633588195e-07
10.50255266267484,33.745063507787684,2.2150203913637967e-07
10.906976795193533,31.39102822601325,2.1523462619471398e-07

This is currently a bug in the develop branch in PyFR relating to the integrator plugin using _vect_upts for the gradients instead of _grad_upts . I believe changing that in:

fixes the problem on CUDA, but I’m not quite sure about other backends or if it might negatively interact with other features like kernel fusion.

Hi @fei can you try this branch (or implement the change in your version): Comparing PyFR:develop...pv101:fusion-fix · PyFR/PyFR · GitHub it should fix this issue as well as the issue with flux antialiasing for Navier Stokes being broken.

Hi @fei if you get a chance could you test this release candidate branch and see if it fixes your issues? GitHub - PyFR/PyFR at release/v2.0.1

Thanks a lot. I used this branch v2.0.1, the enstrophy is normally, but the kinetic energy dissipation rate is very strange.

Thanks.

How did you obtain the plot? Did PyFR output the Ek and then you took the time derivative?

Peter

I first used Ek = 0.5int-E/(6.28 6.28*6.28), then I took time derivative of the Ek.

Does this case use adaptive time stepping?

If so, did you account for the variable time step when taking derivatives?

What does the Ek plot look like?

Peter

It now works. The nsteps of the [soln-plugin-integrate] can’t set too small, or it will occur oscillation.

The oscillations in kinetic energy are due to using a constant density IC instead of an isothermal IC which causes oscillatory energy exchange between kinetic and internal energy at nonzero Mach number. Please use the TGV config file in GitHub - PyFR/PyFR-Test-Cases which has isothermal ICs.

Thanks. I compared the Ek between the original PyFR2.0 and PyFR 2.0.1, and the result of the PyFR2.0 is more consistent with the reference value when t is 12-20. Have you ever encountered this problem?

Could you share plots to show exactly what the issue is?

Peter

The test case is 64^3 elements, and P3 order.

Are these results obtained using identical .ini files for 2.0 and 2.0.1?

Yes, the ini file is same.

What backend are you using and is the .ini file from the examples? My results for the kinetic energy are essentially identical between 2.0 and 2.0.1 for the example case.

The backend is openmp, and the .ini file is from the examples but with double precision. And I didn’t set the [backend-openmp] in the .ini file, I don’t know if that’s the reason.

I’m not running into the issue with the CUDA backend, and I can’t check the OpenMP backend myself. Can you try with

[backend-openmp]
cflags = -O3

and see if that changes anything?

I’d also be interested to know what version of numpy you have installed?

Ok, I am trying with cflags = -O3.

The version of numpy is 1.26.4.