Simplified representation of magnetics sensors

[MireilleSchneider]

Codes like DINA and NICE need to define their own simplified representation of magnetic sensors because they are too many in ITER to be all be handed by free-boundary equilibrium code. It would be nice to define reference sensors which could be used, to define a subset which could reasonable be used in FBE codes. For example DINA has defined 24 flux loops and 18 probes. NICE has its own way to define a subset of sensors. Each code will have its own way, but we could also possibly define this subset in a clever way for everyone, based on weights, which would imply extending the DD accordingly.

[SimonPinches]

I would suggest a pre-processing step in which a magnetics IDS is prepared in which only the magnetic sensors and flux loops which are to be used are populated and passed to the equilibrium code.

[MireilleSchneider]

This solution is the one we have right now, only that the selection method used in DINA is not the same as the one used in NICE. Do we leave it as it is, or do we try to make it standard?

[SimonPinches]

My suggestion was not to do the selection in DINA or NICE but rather in a separate pre-processing step. The same input with the same selection of magnetics coils and flux loops can then be given to any interpretive equilibrium solver.

[imbeauf]

The equilibrium IDS, in the time_slice/constraints structure, describes which measurements have been used to constrain the equilibrium reconstruction. This is normally used as an output, to document what has been done, but you may also decide to use it as an input to prescribe all quantities that have to be used for the reconstruction, e.g. by filling only time_slice(1)/constraints/flux_loop(i)/source.
It's a bit heavy, but it's a suggestion.

[olivhoenen]

From the description I understand that different codes may have different limitations in how many or even how they've selected their sensors. If it more or less always boils down to code-specifics, then I see no added value to avoid doing this processing locally within the code. This could also be done by a single parametrized code to avoid "duplication". But adding placeholders in IDS structure to pass weights will not simplify things, one would still need to decide (and input manually) what values to put in what weights, and by consequence which sensors to take into account and which ones to drop. IIRC discussions with @paulotex on EFIT++, there it was concluded that these weights are code-specific parameters?

[paulotex]

If it is possible to agree on a simplified set of coils and sensors to be used, we can document this properly and also add this preprocessing step.

However, I think selecting which sensors to use based on a general set of weights is abusing the definition of weights. In particular, weights for efit++ are code specific parameters, and so they can be left out of the machine description IDS. Like @imbeauf says above, equilibrium/time_slice/constraints is filled as output by efit++ to record what was used for the reconstruction.

Extending a bit the notion of default set of coils/sensors, during operations we might need a way to record which magnetic sensors are broken and should not be used, which usually means setting the weight of that sensor to zero at input. This is could be stored in the respective MD IDS (magnetics, pf_active, ...) as a way to share with everyone that a particular sensor should not be used, but it is a restricted usage of the notion of weights, it is more a disable/enable switch than a real weight. Even that is not sure to be useful, since sometimes a sensor is not fully broken: it might produce some valid signal up to certain point of the discharge and then misbehave. So there might be cases where, even when the sensor is broken, some of its data might still be relevant.

Ultimately, the example I have at JET (my only experience so far of a working tokamak) was that the magnetics team would publish regularly the list of probes that should be disabled or were misbehaving and efit++ would use that to update its code specific parameter file (an xml file). This file is pulse dependent (valid for a range of pulses). But it was not automatically created from the report of broken probes of the magnetics team, it was updated manually after each change, to make sure the correct exclusion of probes was being done.

So in conclusion, I am pointing that although do need a general way to know which sensors can be used or not for ranges of pulses or operational dates ranges, this is not really weights. Ultimately weights are code specific parameters that are set be the codes themselves.