REVIEW 2 major objections 4 minor 3 references
Same-named space physics frames disagree by up to 0.3 degrees between providers
Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →
T0 review · deepseek-v4-flash
2026-08-03 11:01 UTC pith:ZYLGOKVK
load-bearing objection Useful audit of coordinate-transform inconsistencies; the software library comparison is the strong result, but the position discrepancies are partly an ephemeris-provenance artifact and need a same-ephemeris test. the 2 major comments →
Coordinate Systems and Transforms in Space Physics: Terms, Definitions, Implementations, and Recommendations for Reproducibility
The pith
A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.
Core claim
The paper argues that a space physics 'coordinate system' acronym such as GEI or GSM is what astronomy calls an ideal reference system: the definition fixes axes and origin but leaves out the constants, models, and algorithms needed to compute the frame. As a result, every implementation is a distinct reference frame. The paper shows this empirically: two public archives' positions for the Geotail spacecraft in a frame both label GCI differ from each other by ~0.3°, with the GCI label matching the other archive's J2000 frame far better than its GEI frame; and seven software libraries, each passing its own tests, disagree on the same frame's Z-axis by 0.001°–0.04°. The proposed remedy is a fo
What carries the argument
The central mechanism is the reference-system/reference-frame distinction, imported from astronomy and geodesy: an ideal reference system names axes and origin; a reference system adds the constants, models, and algorithms; a reference frame is the realized system with measured parameters. The paper's concrete proposal is a standard dataset in which each record is a timestamp plus a transform matrix (or one or two angles) relating a named frame to a base frame, making any transform fully specified by a citation. The comparisons use the angle between frame Z-axes and the angular difference Δθ between position vectors as metrics to expose implementation spread.
Load-bearing premise
The paper's attribution of the 0.3° position differences to coordinate-frame definition and implementation presupposes that the two archives' underlying spacecraft positions come from the same source; the paper itself notes that positions can differ because they originate in different ephemeris data (navigation kernels, orbit-element fits, or flight-dynamics output), which would put the discrepancy before any frame transform.
What would settle it
Take one spacecraft's position from a single authoritative navigation kernel, transform it into a named frame (e.g., GSE) using two different software libraries that both cite the same published definition, and compare. If the outputs agree to numerical precision (angular difference below ~10^-6 degrees), then the large provider-level differences shown in the paper are due to ephemeris provenance rather than frame ambiguity, weakening the central claim. If the outputs differ by 0.01–0.04 degrees, the claim is supported.
If this is right
- If a citable standard dataset of transform matrices is adopted, a publication's transform statement can be fully reproduced by citing the dataset, with no need to name a software version.
- Data providers would document both the raw position source and the transform pipeline, since the paper shows observed differences can arise at either stage.
- At the angular scales of the tightest multi-spacecraft formations (~0.007°), the measured 0.001°–0.04° library differences are no longer negligible for data intercomparison.
- Magnetic-field-dependent frames need two defined variants — one using final, definitive field-model coefficients and one using the preliminary values current at the time — to keep past transforms reproducible.
- A shared reference dataset would expose software bugs that existing unit tests miss; the authors report discovering significant errors in four libraries during the survey.
Where Pith is reading between the lines
- The measured Z-axis spread probably understates the full ambiguity; rotations within the ecliptic plane could be quantified the same way and may show larger disagreement for in-plane vector quantities.
- The same named-frame problem almost certainly extends to planetary and lunar coordinate frames, where fewer cross-checks exist; applying the proposed reference-dataset test there would likely reveal larger implementation drift.
- A practical consequence the paper does not spell out: if reference-field model releases are given DOI-like identifiers, any historical analysis can be re-run exactly, which would also make reprocessing campaigns cheaper.
- A testable next step is to build the standard dataset from the surveyed libraries' common output and check whether inter-library residuals collapse to numerical precision; if they do not, the remaining spread measures true definitional ambiguity.
Editorial analysis
A structured set of objections, weighed in public.
Referee Report
Summary. This manuscript addresses reproducibility of coordinate reference-frame transformations in space physics. It distinguishes ideal reference systems, reference systems, and reference frames, documents terminology ambiguities (mainly around GEI/GCI/J2000), and quantifies discrepancies in two settings: spacecraft positions from different providers (SSCWeb, CDAWeb, JPL Horizons) and transform results from six software packages (Geopack, PySPEDAS, SpacePy, SpiceyPy, SunPy, cxform). Reported position differences reach ~0.3° for Geotail and ~1° for MMS-2 relative to JPL, while software Z-axis differences are 0.001°–0.04°. The paper proposes community standards for acronyms and definitions, a citable reference-frame transform dataset, versioned SPICE kernels, and better versioning and documentation of spacecraft positions. Software and data are released with the paper (Weigel et al., 2025).
Significance. If the main conclusions hold, the paper provides rare, quantitative evidence for a problem that is often discussed anecdotally: nominally equivalent coordinate transforms and data products are not uniquely defined. The comparisons are clearly described, expected precision is computed, and the open release of data and code strengthens reproducibility. The software-library comparison is independent of ephemeris provenance and already supports the reproducibility argument. However, the position-level evidence is partly confounded by trajectory source differences, and the software comparison measures only Z-axis alignment rather than the full rotation, so the quantitative scope of the claimed problem is not yet fully established. The recommendations are actionable and likely to be useful to data providers, software developers, and standards bodies.
major comments (2)
- [§4.1, Figs. 1–2] The position comparisons do not control for ephemeris provenance. SSCWeb and CDAWeb positions are generated from different trajectory inputs (SPICE kernels, mission-computed GEI variables, or TLEs; see §5), and JPL Horizons explicitly states its TLE-based trajectory may depart from the actual trajectory. Thus the 0.3° Geotail discrepancy and ~1° MMS/JPL discrepancy cannot be attributed to coordinate-frame implementation alone. The text acknowledges this in §6.4, but the figures are presented as evidence of the coordinate-system problem in the Key Points and abstract. Please add a same-ephemeris comparison (e.g., the same position vector transformed with different implementations) or explicitly reframe the position comparisons as provider-level differences whose causes are not separated.
- [§4.2, Fig. 3] The software comparison measures only the angle between the Z axes of each frame pair. A rotation about the Z axis would not be detected, so the quoted 0.001°–0.04° range is a lower bound on full rotation-matrix differences, not a complete characterization. The summary statement in §4.2 that 'differences in library implementations of reference frames range from 0.001° to 0.04°' is therefore stronger than the metric supports. Please compute full transformation-matrix or quaternion differences, or clearly limit the claim to the tested Z-axis observable.
minor comments (4)
- [Key Points] Typo: 'as doZ-axis' should read 'as do Z-axis orientations'.
- [Appendix A] Typo: 'Magnetospheric Multiscale Misson' should be 'Mission'.
- [§4.2, bottom paragraph] The list of maximum differences appears to repeat 'GSE/GSM' twice; check whether the second entry should be 'MAG/GSM' or another frame pair.
- [§6.2] The statement that 'we encountered significant errors in four of the libraries, despite these libraries passing their tests' is not documented. Since this claim motivates the recommended standard dataset, please provide details or a reference to the error reports or reproducible test cases.
Circularity Check
No significant circularity: the paper's quantitative findings are external comparisons, and its recommendations are not used to define the measured discrepancies.
full rationale
This is an empirical survey and recommendations paper rather than a derivation. The key claims are supported by direct comparisons of position data from external providers (SSCWeb, CDAWeb, JPL Horizons) and by comparisons among independent transform libraries (Geopack, PySPEDAS, SpacePy, SpiceyPy, SunPy). No parameter is fitted to a subset of the target quantity and then renamed as a prediction, and the recommendations are not used to define the metrics. The only author-associated artifact is the companion hxform package cited in the Open Data section as the location of software/data/calculations; this is a data-availability pointer and is not load-bearing for the conclusions. One author is also associated with SunPy, but SunPy is only one of several independently developed libraries being compared, not the source used to establish the paper's central claims. The closest weakness is the paper's own acknowledgment that position differences can arise from both source ephemeris and transform-implementation differences (§4.2: 'The position vectors can differ for two reasons: differences in the source of the position data and differences in the data providers' software libraries'), and §6.4 likewise acknowledges this provenance confound. That is a validity caveat about how much of the position discrepancy can be attributed to coordinate-frame implementation, not a circular definition or fitted-input-called-prediction step. No equation or constructed quantity reduces to its own inputs, and no load-bearing argument depends on an unverified self-citation chain. The central measurements are therefore self-contained with respect to external benchmarks.
Axiom & Free-Parameter Ledger
axioms (3)
- domain assumption A named space physics coordinate system (e.g., GEI, GSM) should have a single definition such that two independent implementations agree to numerical precision.
- domain assumption The differences observed between data providers/libraries are attributable to transformation implementation choices rather than unmodeled ephemeris source differences.
- domain assumption Standardization models from astronomy (ICRS/ICRF) and geodesy (WGS84) can be transferred to space physics coordinate systems.
read the original abstract
In space physics, acronyms for coordinate systems (e.g., \texttt{GEI}, \texttt{GSM}) are commonly used; however, differences in their definitions and implementations can prevent reproducibility. In this work, we compare definitions in online resources, software packages, and frequently cited journal articles and show that implementation differences can lead to transformations between same-named coordinate systems and position values from different data providers to differ significantly. Based on these comparisons and results, and to enable reproducibility, we recommend that (a) a standard for acronyms and definitions for coordinate systems is developed, similar to equivalents in astronomy or earth sciences; (b) a standards body develops a citable database of reference data needed for these transforms. For software that computes coordinate transforms, we also recommend that their developers provide explicit comparisons of their implementations with the results of (b) and documentation on implementation choices. Additionally, we provide recommendations for scientists and metadata developers to ensure that sufficient information is provided to enable reproducibility. Finally, we document that spacecraft positions from data providers can differ both because of differences in how they implemented transforms and because of differences in the original source of the position data, and provide recommendations to improve the documentation of spacecraft positional datasets.
Figures
Reference graph
Works this paper leans on
-
[1]
Acton, C. H. (1997). NASA’s SPICE System Models the Solar System. InDynamics and Astrometry of Natural and Artificial Celestial Bodies(p. 257–262). Springer Netherlands. doi: 10.1007/978-94-011-5534-2 34 Alken, P., Th´ ebault, E., Beggan, C. D., Amit, H., Aubert, J., Baerenzung, J., . . . Zhou, B. (2021, February). International Geomagnetic Reference Fiel...
arXiv 1997
-
[2]
M., Lim, P
Price-Whelan, A. M., Lim, P. L., Earl, N., Starkman, N., Bradley, L., Shupe, D. L., . . . Zonca, A. (2022, August). The Astropy Project: Sustaining and Growing a Community-oriented Open-source Project and the Latest Major Release (v5.0) of the Core Package.The Astrophysical Journal,935(2),
2022
-
[167]
(1993).Cluster Software Tools Part I - Coordinate Transformations Library
doi: 10.3847/1538-4357/ac7c74 Robert, S. (1993).Cluster Software Tools Part I - Coordinate Transformations Library. https://www.lpp.polytechnique.fr/IMG/pdf/ 1993 robert dtcrpe1231 rocotlib.pdf. Russell, C. (1971). Geophysical coordinate transformations.Cosmic Electrodynamics(2), 184-196. Satellite Situation Center System and Services. (2025a).SSCWeb Coor...
discussion (0)
Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.