DESC wout and MGRID file incompatibilty

[lazersos]

There have been multiple issues raised over on the STELLOPT Github related to DESC produced wout files and mgrid files. These files are not being written correctly, are missing information, and cannot be read by the STELLOPT family of codes. The source for reading MGRID files can be found here, and should be used as a template for generating the files. While not all values are necessarily needed it is advised that variable name convention be respected:

LIBSTELL/Sources/Modules/mgrid_mod.f

The writing of VMEC wout files should follow the conventions set here:

LIBSTELL/Sources/Modules/read_wout_mod.f90

[rahulgaur104]

Thank you for pointing this out, Sam!

[ddudt]

Thanks Sam. We are aware that many variables are missing from the DESC-generated wout files, and they are documented in the code. The issue is that we are not sure what these variables are supposed to be, since the STELLOPT source code that generates them is poorly documented. Our general practice has been to exclude these outputs until they can be implemented properly, so that we avoid any issues with using incorrect values. If you know what any of these outputs are supposed to be we would appreciate the help in adding them!

[lazersos]

@ddudt The deffinitions in read_wout_mod.f90 are pretty clear. I believe you're missing <1/R> over_r variable. There may be others. I've just push and update so the variable names and meaning are more clear.

One subtle point is that when putting Fourier quantities on the half grid, even and odd modes are treated differently with the odd modes being interpolated in sqrt(s) instead of s (the grid spacing, normalized flux).

For MGRID, I'm not sure what went wrong but the file @rahulgaur104 provided didn't even have the correct variable names. Below you can find a dump of the header information from a work MGRID file. I've made comments where perhaps the meaning of a name is not obvious.

netcdf mgrid_hsx_complete {
dimensions:
	stringsize = 30 ;
	external_coil_groups = 7 ;
	dim_00001 = 1 ;
	external_coils = 7 ;
	rad = 121 ;
	zee = 121 ;
	phi = 50 ;
variables:
	int ir ; Number of radial gridpoints
	int jz ; Number of vertical gridpoints
	int kp ; Number of toroidla gridpoints (last gridpoint does not repeat first)
	int nfp ; Number of field periods
	int nextcur ; Number of field sources
	double rmin ;
	double zmin ;
	double rmax ;
	double zmax ;
	char coil_group(external_coil_groups, stringsize) ; Field source names
	char mgrid_mode(dim_00001) ; 'raw' or 'scaled'
	double raw_coil_cur(external_coils) ; current source currents
	double br_001(phi, zee, rad) ; B_R
	double bp_001(phi, zee, rad) ; B_PHI
	double bz_001(phi, zee, rad) ; B_Z
	double br_002(phi, zee, rad) ;
	double bp_002(phi, zee, rad) ;
	double bz_002(phi, zee, rad) ;
	double br_003(phi, zee, rad) ;
	double bp_003(phi, zee, rad) ;
	double bz_003(phi, zee, rad) ;
	double br_004(phi, zee, rad) ;
	double bp_004(phi, zee, rad) ;
	double bz_004(phi, zee, rad) ;
	double br_005(phi, zee, rad) ;
	double bp_005(phi, zee, rad) ;
	double bz_005(phi, zee, rad) ;
	double br_006(phi, zee, rad) ;
	double bp_006(phi, zee, rad) ;
	double bz_006(phi, zee, rad) ;
	double br_007(phi, zee, rad) ;
	double bp_007(phi, zee, rad) ;
	double bz_007(phi, zee, rad) ;
}

Notes:

• 'raw' implies that coil current in the coil file was used when constructing the MGRID file. 'scaled' implies that unit normal current was used when constructing the coil current. Becasue of this I advise users to use a coils file if at all possible, so they know what they are doing. This not only influences the meaning of the EXTCUR array but can also screw up the field if a the stellarator symmetric coil was constructed so that it has an opposite signed current.
• For each current system a separate set of fields is saved.

[ddudt]

Thanks Sam, those descriptions you updated are helpful! We had been looking at wrout.f where the wout file is written, and the long names are not included for most of the variables in the actual output.

Can you clarify your point about the odd modes on the half grid? DESC is saving the "full grid" quantities on surfaces linearly spaced in $s \in [0, 1]$, and the "half grid" quantities on surfaces linearly spaced in $s \in [0.5/(NS-1), 1 - 0.5/(NS-1)]$. We are treating the even and odd Fourier modes similarly, and that agrees pretty well with VMEC at least for a tokamak benchmark we use for testing. Are you saying that for the "half grid" quantities, the even and odd modes actually represent different flux surfaces?

Also, do you know if there are any noteworthy differences in the wout formats between different versions of VMEC? We are benchmarking against an example from version 9 that was generated several years ago.

[lazersos]

@ddudt First there are an infinte set of flux surfaces in every VMEC equilibria. VMEC has two radial grids, one on the full radial mesh, and one on the half radial mesh. Quantities on the half radial mesh are on that mesh because they arrise from derivatives in the radial direction. These derivatives are first order finite differences in order to create a block tridiagnoal system. Becasue the even and odd poloidal modes have different radial linear dependences VMEC treats them differently. The even modes in m are treated as linear in the radial grid as they go like the toroidal flux. The odd modes are treated in the square root of the radial grid as the are linear in the minor radius.

There haven't been many changes in the main branches of VMEC in the last few years with regard to outputs. I would advise you to contact Mark Cianciosa for VMEC support. The STELLOPT repo periodically aligns with the ORNL repo, but ORNL is the official source of VMEC.