************************************************************************** WD/GWH 9/3/99 intermittent gridgen bug There is an occasional bug somewhere in the guts of gridgen4.f90, which intermittently comes and goes depending on the geometry. gridgen4.f90 does the layout of the theta mesh, with options to optimize the layout for highly shaped cases. This bug causes the theta grid to be missing 2 gridpoints (so omega_d(theta) is no longer exactly symmetric, and the resulting eigenfunctions Phi(theta) are not exactly symmetric or antisymmetric). Below is a message from Dorland describing it. We haven't yet had time to fix this. SHORT TERM work around: do "wc run.fields" to find the number of lines in the *.fields file. This should be [(2*nperiod-1)*ntheta + 2]*naky*ntheta0 (the extra 2 lines are for the +N*pi grid point, and for a blank line). If its not, there is a bug. Rerun the code with ntheta changed by +2 or -2, and things should work okay. ************************************************************************** Date: Fri, 3 Sep 1999 00:35:40 -0400 From: Bill Dorland To: Hammett@pppl.gov Subject: Re: test cases illustrating a symmetry bug? (GWH: Includes typo fix in the next email.) The problem begins in gridgen. The debug file (gridgen.200) shows that miller32_0 generates a 31 point theta grid, rather than a 33 point theta grid. This cascades to cause other problems. Within gridgen4.f90, the problem seems to be with slight mismatches in the value of pi, or something like that. I see that Peter has a comment about stupid problems near -pi, which is what this looks like. While I figure this out (and it may take a while), note that you can use ntheta = 34 and gridgen behaves. In general, ntheta needs to be even, but is not required to be powers of two. I think I can quickly put in a diagnostic that will warn the user that the run is probably corrupted when this occurs, because I know a simple condition that can be tested. However, fixing the actual problem will take longer, possibly until Peter is around. The fact that fails on a T3E but works on a DEC alpha is probably consistent with a pi mismatch. Peter has a value of pi hardwired in gridgen4. --Bill ************************************************************************** GWH 9/3/99 eiktest triangularity When running eiktest using a local equilibrium, the value of tri reported in eik2.out appears to be about a factor of 2 too low. This is a diagnostic only, and not used to calculate anything, but should be checked eventually. ************************************************************************** GWH 8/29/99 improve frequency measurement There is a trick to be able to calculate omega in the dt=0 limit even though the code is running with finite time step dt. I should implement this in gs2_diagnostics.f90 (and include a species avg of implicit parameter delta and a warning if delta aren't the same?). To further make it more robust, could make the code automatically select the theta at which the frequency is to be measured, by looking for the point of maximum phi? Update/streamline discussion of frequency in algorithms.txt. ************************************************************************** GWH 8/27/99 minor diagnostic issue? In the *.out file, the value of phi(0) plotted on the final time step, after the line "*** omega converged" is printed, doesn't seem right. Before that, |phi(0)|**2 is growing proportional phtot as it should approximately be, but something seems off on the final time step?