Concern
AdvancedParams and especially ScanParameters are carrying more than physical scan acquisition settings.
AdvancedParams is effectively an instrument/method defaults object. That is mostly reasonable, but the name is vague and it includes scan-range defaults such as default_ms1_scan_window alongside AGC, max IT, collision energy, analyzer, activation type, etc.
ScanParameters is more overloaded. It is documented as scan instructions for the mass spec, but it also contains controller/task bookkeeping and policy fields, including examples like:
SCAN_IDMETADATAUNIQUENESS_TOKENCURRENT_TOP_N- dynamic-exclusion tolerances (
DYNAMIC_EXCLUSION_MZ_TOL, DYNAMIC_EXCLUSION_RT_TOL)
Some of these are true acquisition parameters, but others are controller policy, scheduler metadata, or simulator/export bookkeeping.
Why this matters
The current design makes it hard to tell whether a value is:
- a real instrument scan parameter
- a simulation-only instruction
- controller policy
- scheduling/export metadata
That ambiguity increases the risk of future changes putting new fields in the wrong object, and it makes behavior harder to reason about when scan params are passed through controllers, the simulator, and mzML export.
Possible direction
Consider a cleanup that first maps current usage and then separates responsibilities, for example:
InstrumentScanDefaults: method-level defaults such as MS1/MS2 ranges, AGC, max IT, analyzer, resolution, activation, collision energyScanRequest: per-scan acquisition request such as MS level, precursor list, isolation width/windows, polarity, first/last mass, scan idControllerPolicy: controller-level settings such as TopN N, dynamic-exclusion tolerances, min intensity, ROI policyScanMetadata: scheduler/export-only metadata and uniqueness tokens
A first step could be documenting which existing ScanParameters keys are consumed by the mass spec simulator, the controllers, and the mzML writer before changing the API.
Concern
AdvancedParamsand especiallyScanParametersare carrying more than physical scan acquisition settings.AdvancedParamsis effectively an instrument/method defaults object. That is mostly reasonable, but the name is vague and it includes scan-range defaults such asdefault_ms1_scan_windowalongside AGC, max IT, collision energy, analyzer, activation type, etc.ScanParametersis more overloaded. It is documented as scan instructions for the mass spec, but it also contains controller/task bookkeeping and policy fields, including examples like:SCAN_IDMETADATAUNIQUENESS_TOKENCURRENT_TOP_NDYNAMIC_EXCLUSION_MZ_TOL,DYNAMIC_EXCLUSION_RT_TOL)Some of these are true acquisition parameters, but others are controller policy, scheduler metadata, or simulator/export bookkeeping.
Why this matters
The current design makes it hard to tell whether a value is:
That ambiguity increases the risk of future changes putting new fields in the wrong object, and it makes behavior harder to reason about when scan params are passed through controllers, the simulator, and mzML export.
Possible direction
Consider a cleanup that first maps current usage and then separates responsibilities, for example:
InstrumentScanDefaults: method-level defaults such as MS1/MS2 ranges, AGC, max IT, analyzer, resolution, activation, collision energyScanRequest: per-scan acquisition request such as MS level, precursor list, isolation width/windows, polarity, first/last mass, scan idControllerPolicy: controller-level settings such as TopNN, dynamic-exclusion tolerances, min intensity, ROI policyScanMetadata: scheduler/export-only metadata and uniqueness tokensA first step could be documenting which existing
ScanParameterskeys are consumed by the mass spec simulator, the controllers, and the mzML writer before changing the API.