Handling of coordinate conversions outside LCFS in eq.map_coordinates

[amicitas]

I am trying to use desc to help me convert real-space coordinates to flux-space coordinates for a synthetic diagnostic implementation. For points that fall within the last closed flux surface (LCFS) desc seems to work quite well using eq.map_coordinates. However, since I am starting from real-space, I need to sample points from a much wider area and currently desc is both inefficient and unpredictable for points outside the LCFS (see attached figure for W7-X).

Are there any known solutions to improve handling of eq.map_coordinates for handling of inverse coordinate transforms outside the LCFS? What I would like is a fast calculation of NaN or a mask for requests outside of the LCFS, rather than the slow and unpredictable result from the solver.

Sam Lazerson and I were able to implement such a filter within the LIBSTELL library (stelltools.f90/mirtools.f90), but I don't know if that approach works within desc.

-- Novimir

[YigitElma]

eq.map_coordinates does a small optimization to find $\rho, \theta, \phi$ flux coordinates that minimize the error between the evaluated and desired $R, \phi, Z$ points. Since this doesn't have an actual minimum for the points outside of the LCFS, the poor performance is expected.

I don't think we currently have a mask for this purpose, but I think you can create one using the distance to the magnetic axis. At points $\phi$ coordinate, evaluate $\sqrt{(R-R0)^2 + (Z-Z0)^2}$ and if it is bigger than some threshold, it can be masked. This is kind of tricky to do exactly, because in general DESC's native coordinate $\theta$ doesn't correspond to the polar angle with the Z=0 plane, so a threshold can only remove most of the points outside of the LCFS but not all without special care.

Given that, you can use maxiter and the output of the map_coordinates to have some idea whether point is inside or outside. For example, here we use similar approach to deduce if the point is in or out. Usually, points that are inside converges quite fast, so by capping the maxiter, long compute time can be reduced.

[dpanici]

Can you share a sample of the code you tried that lead to this? We then can help more with the implementation of the solution