search

fsciortino / Aurora

Modern toolbox for impurity transport, neutrals and radiation modeling in magnetically-confined plasmas
https://aurora-fusion.readthedocs.io
MIT License
41 stars 24 forks source link

Enabling Aurora on W7-X #65

Closed fsciortino closed 2 years ago

fsciortino commented 2 years ago

Made a few changes to core.py to allow users to pass some key parameters for the grid directly through the namelist. Everything else works fine, except that no use of geqdsk files is possible for W7-X/stellarators, so all Aurora functions/methods invoking geqdsk processing won't work. This does not prevent one from running single Aurora simulations.

Users will need to pass a minor radius and a major radius (and possibly a magnetic field strength for the prompt redeposition model), usually taking these from a VMEC reconstruction. These numbers could also be set arbitrarily. These changes therefore add flexibility to Aurora simulations, permitting them to run again also without a true equilibrium.

This PR enables further development within the OMFIT ImpRad module for W7-X.

Interested parties: @thromba

fsciortino commented 2 years ago

@odstrcilt I'd appreciate a quick review if possible, even though I assume that you don't have access to W7-X data. It would be sufficient if you could check to make sure that these changes are backwards-compatible, as they should be. You can easily test by commenting out some lines of the new w7x_example.py script and giving some reasonable values of rmin and Rmaj.

fsciortino commented 2 years ago

I'm tempted to delete lines 81-93 in core.py, which allow users to automatically fetch a geqdsk from EFIT01. I don't think that we ever use this code (EFIT01 is a bad choice usually, anyway) and maybe users should be discouraged from using this. Eliminating this would also avoid confusion for users that don't want to use a geqdsk at all (e.g. on W7-X). If we delete this, then geqdsk=None could be used to simply indicate that key grid parameters should be searched for in the namelist. @odstrcilt do you see any reason not to do this?

odstrcilt commented 2 years ago

Yes, I have never used it. Why do you think that EFIT01 is a bad choice? If you use the same equilibrium for mapping everywhere and input profiles are provided as function rho toroidal, then equilibrium choice should not matter. EFIT01 usually provides a better estimate of separatrix location than EFIT02.

fsciortino commented 2 years ago

@odstrcilt well, EFIT01 is not MSE-constrained on DIII-D, for example. On C-Mod, EFIT01 is never the right one to do detailed analysis.

Since you've never used it either, I'll eliminate this default geqdsk option.