Summary
debias() silently applies no correction when the star-catalog is given as an obs80 single-character code (e.g. W, L, q) rather than a catalog name (e.g. Gaia3, 2MASS, UCAC4). Since Obs80DataReader supplies the single-char code, debiasing never fires on obs80 input — including the bulk MPC observation archive.
Root cause
MPC_CATALOGS maps name -> code:
MPC_CATALOGS = {"USNOA1": "a", ..., "UCAC4": "q", ..., "Gaia3": "W"}
and bias_dict (from generate_bias_dict) is keyed by the codes (MPC_CATALOGS.values()). But debias() looks the catalog up as a key:
catalog_key = MPC_CATALOGS.get(catalog) # name -> code
if catalog_key is None or catalog_key not in bias_dict:
return ra, dec
So a name works ("UCAC4" -> "q" -> in bias_dict), but a code ("q") is not a key -> .get returns None -> the guard returns the astrometry unchanged. No debiasing.
Evidence
Fitting the same objects with debias=False vs debias=True gives byte-identical elements, because every obs80 catalog code no-ops:
obj da(deb=0) da(deb=1) changed?
20000 3.829e-04 3.829e-04 no
90377 4.078e-02 4.078e-02 no
944 5.271e-08 5.271e-08 no
The obs80 astCat values (L, N, S, U, W, b, c, d, o, q, r, u, v, w) all match MPC_CATALOGS values, none match its keys.
Impact
The full-catalogue run ingests obs80, so the "faithful to JPL" weighting+debiasing story is incomplete: weighting applies, debiasing does not. (It does not move the headline element agreement much — debias is a sub-arcsec correction and well-observed objects are already tight — but it should actually run, and matters for bias-sensitive objects.)
Proposed fix
Accept a code as well as a name — bias_dict is already code-keyed, so let a code pass through:
catalog_key = MPC_CATALOGS.get(catalog, catalog) # name -> code, or a code passes through
if catalog_key is None or catalog_key not in bias_dict:
return ra, dec
Names still map to their code; obs80 codes now resolve directly; blank/None/unknown still fall through the not in bias_dict guard unchanged (preserving #401). Companion to #401.
Found while enabling debiasing on the MPC full-catalogue fit.
Summary
debias()silently applies no correction when the star-catalog is given as an obs80 single-character code (e.g.W,L,q) rather than a catalog name (e.g.Gaia3,2MASS,UCAC4). SinceObs80DataReadersupplies the single-char code, debiasing never fires on obs80 input — including the bulk MPC observation archive.Root cause
MPC_CATALOGSmaps name -> code:and
bias_dict(fromgenerate_bias_dict) is keyed by the codes (MPC_CATALOGS.values()). Butdebias()looks the catalog up as a key:So a name works (
"UCAC4"->"q"-> inbias_dict), but a code ("q") is not a key ->.getreturnsNone-> the guard returns the astrometry unchanged. No debiasing.Evidence
Fitting the same objects with
debias=Falsevsdebias=Truegives byte-identical elements, because every obs80 catalog code no-ops:The obs80
astCatvalues (L, N, S, U, W, b, c, d, o, q, r, u, v, w) all matchMPC_CATALOGSvalues, none match its keys.Impact
The full-catalogue run ingests obs80, so the "faithful to JPL" weighting+debiasing story is incomplete: weighting applies, debiasing does not. (It does not move the headline element agreement much — debias is a sub-arcsec correction and well-observed objects are already tight — but it should actually run, and matters for bias-sensitive objects.)
Proposed fix
Accept a code as well as a name —
bias_dictis already code-keyed, so let a code pass through:Names still map to their code; obs80 codes now resolve directly; blank/
None/unknown still fall through thenot in bias_dictguard unchanged (preserving #401). Companion to #401.Found while enabling debiasing on the MPC full-catalogue fit.