Skip to content

dPIE: make Lenstool-native parameterization the default profile #506

Description

@Jammy2211

Overview

Make the Lenstool-native parameterization the default dPIE mass profile, so al.mp.dPIEMass / dPIEMassSph expose exactly the parameters readers of Lenstool cluster papers expect (ellipticity, angle_pos, sigma = fiducial v_disp, r_core, r_cut), with the internal ra/rs/b0 parameterization demoted to a clearly-non-standard variant. Re-verify every convention against the Lenstool source/papers, then sweep the downstream workspace (cluster/group examples and the SLaM pipelines, absorbing the deferred lenstool-scaling-slam PR3 from autolens_workspace#265) so the whole stack presents one consistent, standard prescription. End goal: our dPIE perfectly matches the standard Lenstool prescription, so readers of those papers know exactly what our model is doing.

Motivated by the referee comment on the scaling-relation parameterization (Eq. 5) and the follow-up Slack discussion (2026-07): the community convention is reference-anchored Faber–Jackson (σ ∝ L^¼, r_cut ∝ L^½, exponents fixed; normalization the only free parameter), and the dPIE with Lenstool-native parameters is the profile family those papers use.

Plan

  • Verify the parameterization conventions against Limousin et al. 2005, Elíasdóttir et al. 2007 (App. A), Bergamini et al. 2019 (Eq. 5) and the Lenstool C source; record the audit in the PR.
  • Swap the class hierarchy in PyAutoGalaxy: dPIEMass/dPIEMassSph take the Lenstool-native constructor; internal ra/rs/b0 variant becomes dPIEMassB0/dPIEMassB0Sph plus a dPIEMass.from_b0(...) classmethod.
  • Update priors config, exports, unit tests, docstrings.
  • Workspace sweep: cluster suite, group scaling_relation, guides, weak a2744 onto the new default with the reference-anchored scaling convention; apply the same convention consistently through the group/cluster SLaM pipelines (absorbs the deferred lenstool-scaling-slam task).
  • Re-validate the Lenstool parity scripts in autolens_workspace_test.
Detailed implementation plan

Affected Repositories

  • PyAutoGalaxy (primary — library phase)
  • autolens_workspace (workspace phase)
  • autolens_workspace_test (parity re-validation)

Branch Survey

Repository Current Branch Dirty? Claim
./PyAutoGalaxy main clean claimed by potential-correction-port (PR#505 in flight) — this task queues behind it
./autolens_workspace main clean free
./autolens_workspace_test main clean free

Suggested branch: feature/dpie-lenstool-default
Worktree root: ~/Code/PyAutoLabs-wt/dpie-lenstool-default/ (created by /start_library)
Work classification: Both (library first, workspace follow-up)

Phase 1 — PyAutoGalaxy (library)

All in autogalaxy/profiles/mass/total/dual_pseudo_isothermal_mass.py:

  1. Paper/source audit (before code): confirm against Lenstool C source and the papers:
    • sigma is the fiducial v_disp σ_LT, not central σ₀ (σ₀ = √(3/2)·σ_LT — Elíasdóttir 2007 App. A; Bergamini 2019 Eq. 5).
    • b0 = 6·648000·(σ_LT/c)²·(D_LS/D_S) arcsec, distance ratio folded in (Lenstool applies it at deflection time; ours is fully normalized).
    • ellipticity is Lenstool's emass = (a²−b²)/(a²+b²), converted internally to epot = (1−q)/(1+q) = |ell_comps|.
    • r_core/r_cut map 1:1 onto ra/rs (arcsec; kpc variants pre-converted by caller).
    • Scaling-relation form: σ = σ*·(L/L*)^¼, r_cut = r_cut*·(L/L*)^½ anchored to a reference luminosity (BCG/BGG or L*), exponents fixed (Faber–Jackson), only normalization free ⇒ θ_E ∝ L^½.
  2. Class swap:
    • Rename current dPIEMassdPIEMassB0, dPIEMassSphdPIEMassB0Sph (all math — _ci05f, _mdci05, _pi05, deflections/convergence/potential/hessian — stays here unchanged).
    • Rename dPIEMassLenstooldPIEMass, dPIEMassLenstoolSphdPIEMassSph (subclassing the B0 classes; constructor signature centre, ellipticity, angle_pos, sigma, r_core, r_cut, redshift_object, redshift_source, H0, Om0 — H0/Om0 remain flat-float model constants).
    • Move from_lenstool semantics into the default constructor; add dPIEMass.from_b0(centre, ell_comps, ra, rs, b0) / dPIEMassSph.from_b0(...) classmethods returning the B0 variant (the non-standard construction path, per the approved design).
    • Docstrings: default class documents the Lenstool prescription + paper refs; B0 variant explicitly labelled non-standard/internal.
  3. Config/exports: update autogalaxy/profiles/mass/total/__init__.py, mass/__init__.py; update autogalaxy/config/priors/mass/total/dual_pseudo_isothermal_mass.yaml (priors keyed per class — sensible Lenstool-style priors on sigma/r_core/r_cut for the default; keep B0 entries).
  4. Tests: test_autogalaxy/profiles/mass/total/ — rename/extend so both parameterizations are covered; equivalence test dPIEMass(...) ≡ dPIEMassB0(from converted params); NumPy-only (no JAX in unit tests).
  5. Serialization note: any saved results referencing old dPIEMass (ra/rs/b0 signature) will not load into the new class — acceptable (profile shipped 2026-07, no release users yet); call out in PR body.

Phase 2 — autolens_workspace (workspace)

  1. scripts/cluster/{modeling,simulator,csv_api,likelihood_function,start_here}.py + scripts/cluster/lenstool/{modeling,data}.py: swap to new default names; express the scaling tier in Lenstool form (reference-anchored: free normalization on the reference member, exponent fixed 0.5, r_cut ∝ L^0.5 truncation scaling).
  2. scripts/group/features/scaling_relation/modeling.py: same convention (per the Slack-settled design: einstein_radius_ref on the brightest scaling member, luminosity ratios only).
  3. SLaM pipelines (absorbs lenstool-scaling-slam, planned.md): apply the reference-magnitude convention consistently through scripts/group/slam.py + group/cluster-relevant features/*/slam.py variants — the previously-deferred PR3 of autolens_workspace#265.
  4. Guides: scripts/guides/profiles/mass.py, light_and_mass_profiles.py; scripts/weak/features/strong_lensing/a2744.py.
  5. CSV API: cluster mass.csv profile-name mapping updated in lockstep with the library rename.
  6. Notebook regen gotcha (from Feature/gaussian mass #265): generate.py autolens surfaces pre-existing catalogue drift — stage only task-scoped files.

Phase 3 — autolens_workspace_test

  • scripts/cluster/{lenstool_parity,likelihood_sanity,csv_api,simulator}.py, scripts/mass/total.py: update names, re-run parity — deflections/convergence/potential must still match Lenstool like-with-like.

Key Files

  • PyAutoGalaxy/autogalaxy/profiles/mass/total/dual_pseudo_isothermal_mass.py — the whole profile family (PIEMass, dPIE variants, _b0_from_lenstool_sigma).
  • PyAutoGalaxy/autogalaxy/config/priors/mass/total/dual_pseudo_isothermal_mass.yaml — priors per class name.
  • autolens_workspace/scripts/cluster/modeling.py — cluster scaling tier (b0 = scaling_factor·L^exp today).
  • autolens_workspace_test/scripts/cluster/lenstool_parity.py — the like-with-like Lenstool match.

Notes

  • Feature Agent scored this too-large / 4 phases; overridden to the standard 2-stage library→workspace routing under one task — design already settled by the existing dPIEMassLenstool wrapper (PyAutoGalaxy@0a8c6bb4) and the Slack-converged convention.
  • dPIEPotential/dPIEPotentialSph (O'Donnell port) are out of scope.
  • PyAutoLens needs no source change (re-exports ag.mp).

Original Prompt

Click to expand starting prompt

The final step now is to make our default dPIE the LensTool one, whereas before
I think we made it a classmethod of it, so swap them (e.g. the classmethod can
be the current one which is non standard). Also, compare again to some lens
tool papers to make sure we have the same parameterization, especially given
that SLACK chat, and note that we had some issues making sure our slam.py
pipelines are updated throughout in a consistent fashion. The end goal is for
our dPIE to perfectly match the standard LensTool prescription, so readers of
those papers know exactly what our model is doing.

Full prompt: PyAutoMind/active/dpie_lenstool_default_parameterization.md (context: referee comment on Eq. 5 scaling-relation parameterization + 2026-07 Slack discussion converging on the reference-anchored Faber–Jackson convention).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions