Diagnostics: Omega and Omega average appear to disagree, even when appearing to be converged to 2.d.p.

[mrhardman]

Attached is an input file that shows strange behaviour. In the output file "tem-nocols.omega", we see that the frequency omega and the averaged frequency omega_avg appear to converge to different values. For want of being able to fix this myself, I am posting this here in case anyone has ideas, or can connect this to a bug in the code.

test-case.zip

[mrhardman]

For example, the last few lines of the .omega file

   #time          ky          kx      Re[om]      Im[om]   Re[omavg]   Im[omavg]

0.19611937E+03 0.50000000E+00 0.63000000E+00 0.14281919E+00 0.21973374E+00 -0.12987901E+00 0.23262842E-01
0.19712511E+03 0.50000000E+00 0.63000000E+00 0.14290998E+00 0.21878905E+00 -0.12981415E+00 0.23160056E-01
0.19813085E+03 0.50000000E+00 0.63000000E+00 0.14281445E+00 0.21788071E+00 -0.12977341E+00 0.23053565E-01
0.19913659E+03 0.50000000E+00 0.63000000E+00 0.14254883E+00 0.21704023E+00 -0.12975568E+00 0.22947913E-01
0.20014233E+03 0.50000000E+00 0.63000000E+00 0.14213489E+00 0.21629485E+00 -0.12975877E+00 0.22847360E-01
0.20114807E+03 0.50000000E+00 0.63000000E+00 0.14159876E+00 0.21566683E+00 -0.12977967E+00 0.22755633E-01

[mrhardman]

test-case-no-flip-flop.zip
test-case.zip
Following suggestions from Michael B and Denis, we have found 1) setting nwrite = 5 in the initial test case reveals that the instantaneous frequency flip-flops between two values. Running the simulation for nstep = 20000 shows that these values appear to be "converged". (See attached test-case.zip)

Setting the flag flip_flop =.false. In the initial test case allows the mode to converge to a reasonable frequency in both Omega and Omega average. Remarkably, the eigenmode in both cases attached here are very similar.

Conclusion: this is a bug with flip_flop, or the time advance more generally.

[mabarnes]

This appears to be a feature of the flip-flop operator splitting that only affects the diagnostics for the instantaneous growth rate/real frequency. Perhaps worth re-defining instantaneous to mean an average over two time steps to avoid this confusion in future.

[rd1042]

I've noticed similar behaviour, in which both the average and "instantaneous" frequency seems unreasonable (that is, contrary to the frequency one can calculate by looking at phi_vs_t ). From restarting a ~converged simulation with nwrite=1 , an extract from .omega file looks like:
#time ky kx Re[om] Im[om] Re[omavg] Im[omavg]
0.13400963E+03 0.35000000E+00 0.00000000E+00 0.21842644E+00 0.25596022E+00 0.88032963E+00 0.94070941E+00
0.13402292E+03 0.35000000E+00 0.00000000E+00 0.15422324E+01 0.16254584E+01 0.88032961E+00 0.94070940E+00
0.13403622E+03 0.35000000E+00 0.00000000E+00 0.21842644E+00 0.25596023E+00 0.88032961E+00 0.94070940E+00
0.13404952E+03 0.35000000E+00 0.00000000E+00 0.15422324E+01 0.16254584E+01 0.88032960E+00 0.94070939E+00

whereas from looking at |phi|^2 in .out, the growth rate should be ~0.145 .

flip_flop_from_restart.zip

2 possibilities occur to me:

1. omega is calculated from phi and phi_old; possibly phi isn't being updated at the end of advance_explicit, such that the "phi" used to calculate omega isn't the value of phi at the end of the timestep; thus, the instantaneous growth rate on even timesteps is miscalculated.
2. Something more subtle regarding stella's way of calculating omega (a field-line-average of phi rather than e.g. looking at a single point in theta, as GS2 does). Looking at how phi changes from one timestep to another with flip-flopping, it seems that advancing one timestep increases |phi| for some z points and decreases |phi| for others.

[rd1042]

Just to add to point 2. above, attached are some plots showing how |phi|(z) changes in successive steps. Although taking 2 consective steps gives a smooth change in |phi|, each individual step is changing |phi| strangely.