core icon indicating copy to clipboard operation
core copied to clipboard

EFITEquilibrium SOL region mapping

Open Mateasek opened this issue 6 years ago • 3 comments

EFITEquilibrium functions map2d https://github.com/cherab/core/blob/73125a9fc96a04a209496ecc92e055a9ebf49b06/cherab/tools/equilibrium/efit.pyx#L202 and map3d https://github.com/cherab/core/blob/73125a9fc96a04a209496ecc92e055a9ebf49b06/cherab/tools/equilibrium/efit.pyx#L224 allow selecting a constant value for mapping outside LCFS, for which https://github.com/cherab/core/blob/73125a9fc96a04a209496ecc92e055a9ebf49b06/cherab/tools/equilibrium/efit.pyx#L222 is used.

It would be nice to add a possibility to add a profile for SOL region. When more detailed models are not available, the gap can be filled to some extent by using arbitrary functions of psi e.g. exponential decays.

EFiTEquilibrium has a tool to identify SOL by combining inside_lcfs and inside_limiter. Does the blending has to happen only with using inside_lcfs? Could be also replaceable with inside_limiter or some combination.

what do you think?

Mateasek avatar Feb 15 '19 14:02 Mateasek

In principle I think this is a good idea, and I've been wondering about this kind of thing for a while myself. The reason I've never gone to far with it is that you can quickly end up strange results when the equilibriums depart from simple cases.

In a limiter plasma for example, the model you describe would work quite well. But in a double null or a snow flake divertor for example, the results could be quite strange in the private flux region and areas further away from the core.

Either way this is rather specialist and probably doesn't belong in the core. The right way to do it would be to make your own function for the density outside the LCFS (exponential decay for example) and then use it with the Blend2D class and explore the cases. You could easily build your own helper functions for the trial and if they prove successful they could be merged in. But I think you should test it externally in the COMPASS module first. In general, the SOL has more 2d structure than the core and needs more advanced modelling.

mattngc avatar Feb 19 '19 14:02 mattngc

I just noticed you already have a working example of this in your COMPASS demo files.

https://github.com/cherab/compass/blob/master/demos/efit_plasma_profiles/Plasma_profiles_mapping.ipynb

def exp_decay(r, lamb, max_val):
    return max_val * np.exp(-1*(r-r.min())*lamb)

I think we should include it in the examples and see how much it gets used.

mattngc avatar Feb 19 '19 17:02 mattngc

I see all the problems you named with using this approach to SOL, on the other hand I think users should know limits of their models and boundaries of their application and should not be stopped by the code to apply any model just because somebody thought it could be nasty. In some cases, for example COMPASS or for example for some tests, when you want to test feasibility/idea and you don't have access to a more detailed model or you simply don't think it is worth of calculating it in first step, this could be a good option. I don't think it does not belong into the core tho, in my opinion it falls into the same category as using 1D profiles inside lcfs.

I like what you proposed. I will try to write some functions on top of the EFITEquilibrium delivering what I had in mind and lets see after some testing and usage if it was a good idea!

Mateasek avatar Feb 20 '19 10:02 Mateasek