DESC
DESC copied to clipboard
PlasmaControl
make DESC routines to plot eps_effective and Gamma_c
I was under the impression that this should work with some sensible defaults for unspecified parameters:
eq = desc.examples.get("SOLOVEV")
grid = Grid.create_meshgrid([np.array([0.5]), np.linspace(0, 2*np.pi, 20), np.linspace(0, 2*np.pi, 20)], coordinates="raz")
eq.compute("effective ripple 3/2", grid=grid)
but I get an error that theta needs to be passed as a kwarg. Can't that be determined automatically from the given grid?
Similarly, plotting it also fails
plot_1d(eq, "effective ripple 3/2")
this errors because the grid can't fft2
or
grid = Grid.create_meshgrid([np.array([0.5]), np.linspace(0, 2*np.pi, 20), np.linspace(0, 2*np.pi, 20)], coordinates="raz")
plot_1d(eq, "effective ripple 3/2", grid=grid)
this errors because the grid poloidal coordinate isn't theta
The same issue occurs for Gamma_c
The quantities you requested to compute are computed in DESC coordinates, but you have given a grid in field line coordinates.
Regarding the theta kwarg, I believe we had chatted about this a long time ago before introducing these quantities to master. If I recall correctly, we decided ir needs to be passed as a kwarg because computing it required a coordinate mapping, and there is no public infrastructure in DESC to compute a coordinate mapping without an equilibrium object.
Regarding the theta kwarg, I believe we had chatted about this a long time ago before introducing these quantities to master. If I recall correctly, we decided ir needs to be passed as a kwarg because computing it required a coordinate mapping, and there is no public infrastructure in DESC to compute a coordinate mapping without an equilibrium object.
I thought the logic in eq.compute should handle that?
If you prepend "old" to those quantity names it will work.
This still doesn't work for plotting with the default grid. (also I don't think the old stuff is documented anywhere, and not sure if it really should be?)
I'd like to figure out what we need to fix so that calling eq.compute with any grid "just works". That should also fix the issues with plotting since all the plot routines under the hood just call eq.compute with some custom grid
I'd like to figure out what we need to fix so that calling eq.compute with any grid "just works". That should also fix the issues with plotting since all the plot routines under the hood just call eq.compute with some custom grid
This will require setting a bunch of defaults that specifying the pitch angle resolution, number of wells to include, Fourier-Chebyshev quadrature required to fit |B| in alpha, zeta space, and quadrature resolution for each bounce integral. These quantities are needed to calculate the bounce integral. Not sure if choosing these defaults is a great idea because there aren't any standard values and hiding this process behind a command like eq.compute may encourage users to use to ignore many of the important details of the calculation and get funny results.
If you prepend "old" to those quantity names it will work.
This still doesn't work for plotting with the default grid. (also I don't think the old stuff is documented anywhere, and not sure if it really should be?)
test_effective_ripple_1D calculates ripple using the old grid so it should with with an "raz" grid and eq.compute. Similarly, look test_Gamma_c_Nemov_1D and test_Gamma_c_Velasco_1D.
For the "old" quantities, you specify a grid in field line coordinates and it will do the coordinate mapping automatically in eq.compute.
Regarding the plotting feature you want, it doesn't work because the DESC plotting routines require/assume a DESC coordinate grid. The existing plotting routines then call eq.compute with that DESC grid. I didn't implement logic to convert this DESC grid into some default field aligned grid in eq.compute for the following reasons.
- There is a lot of resolution settings, and what constitutes a good resolution varies across the particular quantity to compute and the equilibrium.
- The plotting functions in DESC do not support passing parameters into the compute functions. That makes it impossible for the user to choose any of the resolution in 1. It is also a burden for developers as they must create new routines for any quantity whose discretization resolution is determined by anything beyond the DESC grid density.
I think above issues need be resolved in order to implement the feature you want. I am against implementing a temporary solution that picks a default resolution without offering means to change it.
In the meantime, you can call eq.compute and then plt.plot on the data.
Regarding the theta kwarg, I suggest making a PR where the coordinate mapping routines in DESC that does not demand an equilibrium object is made public. Such as the one I added recently to master. Then the theta quantity can just be a dependency, and you avoid polluting eq.compute with additional logic.
In our tutorial we do show doing just plt.plot: https://desc-docs.readthedocs.io/en/latest/notebooks/tutorials/EffectiveRipple.html#Calculating-effective-ripple-for-Precise-QH
if right now this is not a quantity where using desc plotting is supported, we could at least add a "not-supported" list to the plotting.py and throw an error when a requested quantity is in that list (also ideally would say how to plot it but not sure best way to do this for each quantity, and don't love having compute quantities we cannot plot with our own utilities)
As for eq.compute not working with defaults, we do have the tutorial for how to use the bounce integrated stuff. Maybe we need to make it clearer that you have to do it that way since there is lots of resolution parameters that may vary from problem to problem
https://github.com/PlasmaControl/DESC/pull/1915#issuecomment-3331030502
once #1915 and we set default resolutions for everything