Make EFITequilibrium class variables public

[munechika-koyo]

As mentioned in PR #348, I threw the issue about it.
Why I proposed this issue is that I need to reconstruct some function classes (e.g. MagneticField) and apply them to EFITequilibrium variables to use my own tokamak device and calculated equilibrium information.

[CnlPepper]

Could you expand on what it is you are attempting to do with the EFITEquilibrium class? This class is meant to be immutable as it is representing the state of an EFIT run. If it is being used to pass data around, rather than passing the functions held on its attributes then it is being used incorrectly.

[munechika-koyo]

I actually apply the results of Tokamak Simulation Code (TSC) to EFITequilibrium class to use the useful methods implemented in it like this example. At first, I just instantiated it by adding some arguments but I decided to inherit it because it is needed to apply re-defined classes such as a MagneticField, which is not assumed in terms of using not EFIT results but others.

[munechika-koyo]

I should have defined the original one, but the methods implemented on EFITequilibrium class such as map3d or 2d is so useful that it has allowed me to facilitate to create a plasma object, plot some profiles, etc.

[Mateasek]

Hi @munechika-koyo , I'm sorry but I still don't understand the issue. Could you please help me a bit more? Is it that you would like to be able to define the equilibrium with a different set of parameters?

[munechika-koyo]

Thank you for your reply @Mateasek!
Roughly speaking, yes it is.
However, I could not manage to generate a new equilibrium only with different parameters which are offered in EFITEquilibrium to obtain the magnetic information such as a b_field.
So I needed to implement my own MagneticField class and apply it to b_field variables in EFITEquilibrium.

[Mateasek]

If you have your magnetic field in 3D, you should be able to calculate most of the values the EFITEquilibrium needs to be initialised, shouldn't you?

[munechika-koyo]

Actually, I suppose so.
I defined my own class because b_vacuum_radius and b_vacuum_magnitude values were required to calculate the magnetic field outside LCFS, which were not offered by TSC. It produces the current flux profile (f profile) including outside LCFS, but probably I would be able to prepare b_vacuum_magnitude using an f profile raw data at a certain (r, z) point outside lcfs.

[vsnever]

If the problem is only with b_field, we can make it a property as a hotfix. Indeed, the MagneticField is not very accurate outside LCFS. More general equilibrium classes will still be needed in the future.

[CnlPepper]

The EFITEquilibrium is for EFIT data. Don't break it's abstractions to support another data source. The correct approach would be to pull all the common functionality into a base class (or set of base classes) and derive a new equilibrium object from that, clean base.

If you solve problems by breaking abstractions you will destroy the protections cherab provides to reduce the risk of unexpected behaviours. Do not do it!

[CnlPepper]

Matt and I always intended for the equilibrium tools to be expanded. The EFITEquilibrium was just the first step. The next stages were, as @Mateasek has suggested, to generalise the code. 2D and 3D Equilibrium objects should provide a common interface and subclasses ahould be provided for each data source. The subclasses would likely contain additional attributes/methods to cover the "extra" data specific to each source.

[munechika-koyo]

I agree to the @CnlPepper's opinion.
I also intend to use cherab's classes like EFITEquilibrium to apply to completely 3D magnetic configurations such as stellarators.
So more common base class is preferable for me.

[Mateasek]

For now I would really suggest @munechika-koyo to make function, which calculates all the needed parameters for EFITEquilibrium, from the parameters you have and returns the EFITEquilibrium object, if this is what you need. I did this several times, when there was something missing/defined through different physical quantity.

I'm not an equilibrium expert, so maybe there can be a different path. But I thought the first thing we could do is to define a set of functions, which calculate equilibrium quantities from other equilibrium inputs and other data. This is given by physics and imo is the most general thing. Then, we can start defining equilibrium objects, which would be a sort of a data and function containers, using the defined functions. As far as I know, there are more ways how to get a working equilibrium class, with certain input data. Some may be more numerically accurate than other. This approach may give us and users all the needed building blocks.

[munechika-koyo]

Thank you @Mateasek
I would follow your recommendation firstly.