[smithsp]

Problem

boundary_separatrix.geometric_axis.r, geometric_axis.z, and minor_radius
return values ~100× too small on DIII-D.

Field	Observed	Expected
geometric_axis.r	~0.017 m	~1.7 m
minor_radius	~0.006 m	~0.6 m

Root cause

The _efit.json mappings apply a /100. conversion assuming CGS (cm), but
DIII-D MDSplus stores AEQDSK.RSURF, AEQDSK.ZSURF, and AEQDSK.AMINOR
in metres with units explicitly labelled in the tree.

Verified on shots 163303 :

• AEQDSK.AMINOR ∈ [0.57, 0.63] m (units: metres)
• AEQDSK.RSURF ∈ [1.63, 1.70] m (units: metres)

Fix

Remove the /100. from three TDI expressions in _efit.json.

Related

• The same erroneous /100. appears on AEQDSK.SEPLIM, GAPIN, GAPOUT,
  GAPTOP, and GAPBOT. These have not been verified yet and are left
  for a follow-up issue/PR after confirming tree units.

• Corresponding fix in imas_composer: boundary_separatrix.geometric_axis.r and minor_radius return ~100x wrong values on DIII-D GA-FDP/imas_composer#112

🤖 Generated with Claude Code

[torrinba]

Good catch! I've confirmed that the MDSplus units for these are meters, which differs from the EFIT a-files and is likely the source of the error.

[AreWeDreaming]

@torrinba So there are units stored for this one? I wonder if that could be part of the regression tests.

[torrinba]

@torrinba So there are units stored for this one? I wonder if that could be part of the regression tests.

That's correct. Most of the MDSplus equilibrium entries have units and all the ones I've checked are valid. We could add a test for the order of magnitude of some variables like RSURF and AMINOR, but others like ZSURF wouldn't be so easy (the mean or median could be close to zero).

Are you suggesting this should be an omas or imas_composer regression test? This discussion should probably be continued in #446