DC Compensation (remove direct DC pickup from selected coils) has not been implemented because it requires additional specific information about each device.
Similarly, the ability to use a previous fit as a reference has not been implemented as we would need to save fits and in order to do this. This has not been implemented yet, but could be fascinating.
Claude Description of the Issue:
Summary
Two quasi-stationary fit features have been identified but deliberately deferred, since
each depends on data or infrastructure that doesn't exist yet. Tracking them here so
they aren't lost.
1. DC vacuum compensation
What it would do: subtract the DC vacuum-field pickup from selected coils before
fitting, matching OMFIT's dc_comp / dc_comp_coils behavior (remove direct DC pickup
from a regex-selected set of coil channels).
Why it's not implemented yet: this requires a per-device coupling matrix (OMFIT's
reference implementation only applies it when shotdata.coupling contains a
dc_coupling entry). That coupling data is device-specific and isn't currently present
in our data layer for any device — DC compensation can't be computed without it.
Unblocked by: adding per-device DC-coupling data to the geometry/data layer
(likely alongside the existing per-device sensor geometry work).
2. Reference-fit comparison (compare against a previous fit)
What it would do: let a user pull up a previously computed fit as a reference/overlay
when reviewing a new one — e.g. to sanity-check whether today's mode structure matches
a prior shot or a prior run's fit.
Why it's not implemented yet: fits aren't currently persisted anywhere; they're
computed on demand and held only in memory for the current request. Supporting this
would require a way to save and later retrieve fit results (a fit store/cache keyed by
shot + params, or similar).
Unblocked by: deciding on and implementing fit persistence (storage format, cache
key, retention policy).
Notes
These are independent of each other and could be split into two separate issues if
preferred — grouping them here for now since both are "known gap, deferred pending
supporting infrastructure" rather than active bugs.
DC Compensation (remove direct DC pickup from selected coils) has not been implemented because it requires additional specific information about each device.
Similarly, the ability to use a previous fit as a reference has not been implemented as we would need to save fits and in order to do this. This has not been implemented yet, but could be fascinating.
Claude Description of the Issue:
Summary
Two quasi-stationary fit features have been identified but deliberately deferred, since
each depends on data or infrastructure that doesn't exist yet. Tracking them here so
they aren't lost.
1. DC vacuum compensation
What it would do: subtract the DC vacuum-field pickup from selected coils before
fitting, matching OMFIT's
dc_comp/dc_comp_coilsbehavior (remove direct DC pickupfrom a regex-selected set of coil channels).
Why it's not implemented yet: this requires a per-device coupling matrix (OMFIT's
reference implementation only applies it when
shotdata.couplingcontains adc_couplingentry). That coupling data is device-specific and isn't currently presentin our data layer for any device — DC compensation can't be computed without it.
Unblocked by: adding per-device DC-coupling data to the geometry/data layer
(likely alongside the existing per-device sensor geometry work).
2. Reference-fit comparison (compare against a previous fit)
What it would do: let a user pull up a previously computed fit as a reference/overlay
when reviewing a new one — e.g. to sanity-check whether today's mode structure matches
a prior shot or a prior run's fit.
Why it's not implemented yet: fits aren't currently persisted anywhere; they're
computed on demand and held only in memory for the current request. Supporting this
would require a way to save and later retrieve fit results (a fit store/cache keyed by
shot + params, or similar).
Unblocked by: deciding on and implementing fit persistence (storage format, cache
key, retention policy).
Notes
These are independent of each other and could be split into two separate issues if
preferred — grouping them here for now since both are "known gap, deferred pending
supporting infrastructure" rather than active bugs.