Skip to content

Discussion: NHARMS (PINT) vs NHARM (Tempo2), silent ELL1H harmonic-count mismatch #2030

Open

Description

@vhaasteren

Summary

For the MetaPulsar work I am doing cross-checks of (binary) models between PINT and tempo2. This one stumbled me a bit. PINT and Tempo2 use different par-file spellings for the same ELL1H / T2 Shapiro harmonic-count control:

Package Keyword Default (when omitted on H3+H4 path)
Tempo2 NHARM 4
PINT NHARMS 7 (floored in BinaryELL1H.setup when H4 is set)

There is no alias in either direction today. A shared .par that works in one package can be silently misinterpreted in the other.

Evidence (current trees)

Tempo2 (readParfile.C / initialise.C):

  • Parses NHARM only (strcasecmp(str, "NHARM")).
  • Short label is "NHARM".

PINT (binary_ell1.py):

  • Parameter name is NHARMS, aliases=[].
  • Docs already note: default in PINT is 7, in Tempo2 is 4.
  • A line NHARM 7 produces: Unrecognized parfile line 'NHARM 7' and does not set NHARMS.

Observed residual impact (PINT-idealized TOAs → Tempo2 residuals, otherwise aligned conventions): ELL1H with H3+H4 and only NHARMS 7 in the par left Tempo2 at nharm=4 → ~5–6 ns RMS disagreement. Writing both NHARM 7 and NHARMS 7 brought Tempo2 RMS back under ~1 ns.

Why this is ugly

This is not a “MetaPulsar should dual-write” problem alone. Anyone who:

  1. fits / writes an ELL1H H3+H4 model in PINT (emits NHARMS), then
  2. evaluates or combines with Tempo2,

gets a different delay with no hard error in Tempo2 (unknown keyword → default 4). The reverse (NHARM from Tempo2/EPTA-style pars into PINT) is also ignored unless PINT’s floor happens to match the intended value.

Proposed direction (for discussion)

Prefer non-breaking interchange fixes over a rename:

  1. PINT

    • Accept NHARM as an alias of NHARMS on read.
    • On write: emit NHARM for Tempo2-format pars (canonical Tempo2 spelling); consider emitting NHARM (or both) for interchange / PINT format after a deprecation window.
    • Keep the Python attribute NHARMS for API compatibility (optional later soft rename).
  2. Tempo2 (separate upstream issue/PR)

    • Accept NHARMS as a synonym of NHARM in readParfile.C.

Canonical interchange name should be NHARM (Tempo2 / historical ELL1H spelling). PINT’s plural NHARMS is the outlier.

Alternatives considered

Option Pros Cons
PINT alias + write NHARM Non-breaking; fixes PINT→Tempo2 Tempo2 still ignores pure NHARMS until Tempo2 synonym
Tempo2 synonym only Fixes PINT-written pars under Tempo2 PINT still ignores NHARM
Breaking rename NHARMS→NHARM in PINT Clean long-term Breaks pars and model.NHARMS users for a one-letter typo
Downstream dual-write only Works for one consumer Leaves ecosystem silent mismatch

Ask

Is the preferred path:

  1. PINT alias + Tempo2-format write of NHARM (recommended), and/or
  2. a small Tempo2 synonym for NHARMS, and/or
  3. a documented breaking rename?

Happy to open a PINT PR for (1) if that matches project preference.

Related

  • Local motivation / parity suite: MetaPulsar cross-engine ELL1H round-trips (consistency-pint-tempo2 / alignment work).
  • Related ELL1H Tempo2 parity: ell1h_shapiro="absorbed" (FW10 Eq. 28 vs Eq. 29).

Activity

  1. dlakaplan commented on Jul 31, 2026

    @dlakaplan
    Contributor

    I think your solution looks good. We could change PINT entirely and add the alias as you suggest - I think that would not have too many negative consequences but happy to discuss.

  2. vhaasteren commented on Aug 6, 2026

    @vhaasteren
    MemberAuthor

    I think both packages supporting both aliases would be best. Both already exist in the wild. Perhaps we can all default to NHARMS?

  3. dlakaplan commented on Aug 7, 2026

    @dlakaplan
    Contributor

    I'm OK with that, but I think it needs some discussion with the broader timing group. Perhaps this and #2035 / #2033 could be discussed next week?

  4. vhaasteren commented on Aug 7, 2026

    @vhaasteren
    MemberAuthor

    I'm on a holiday, so no guarantee from me to be there, but I'll see here what you all agree on 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions