CosmoStat / CosmoStat/sp_validation
Config cleanup: one source of truth + fiducial-plus-overrides philosophy
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 2
- Forks
- 5
- Avg merge
- 1d 14h
- Merged PRs (30d)
- 19
Description
Problem
sp_validation config is spread across three overlapping surfaces, and no single one owns a given parameter.
config/calibration/mask_v1.X.*.yaml— 12 near-duplicate files. Each catalogue version has its own masking/calibration config. Most differ from the previous only by a version comment and one flag value (for exampleFLAGS <= 2vs<= 3). Copy-paste drift is already visible: label formatting is inconsistent between files (r"$n_{\rm epoch}$"vs$n_{\rm epoch}$). Nothing in the workflow selects these;catalog_builders.pyreads one when invoked by hand, and a test only checks the paths exist.cosmo_val/cat_config.yamlholds per-catalogue metadata: input paths, column names, and survey parameters (A,n_e,n_psf,sigma_eundercov_th).papers/*/config/config.yamlholds the Snakemake config:versions, afiducial:block, scale cuts, and cosmology parameters. Thecosmo_valconfig documents in a comment that several top-level keys exist only to satisfy parse-time lookups of the shared workflow module and "are not exercised by the cosmo_val rules themselves."
The same physical quantity can live in two places. A survey area or sigma_e is declared in cat_config and can be re-declared in the workflow config. There is no rule for which wins.
Proposed philosophy (for discussion)
- One source of truth per parameter. A value is declared once. Every other surface references it, never restates it.
cat_config.yamlowns catalogue facts — paths, column names, and per-catalogue survey parameters (area, number densities,sigma_e). The workflow pulls these at parse time instead of hardcoding them.- The workflow owns one fiducial config. A single
fiducial:block sets the default run (version, binning, scale cuts, cosmology). Grid or comparison runs are declared as overrides on top of the fiducial, not as parallel full configs. - Mask/calibration cuts get one templated config, not one file per version. The cuts that are actually constant across versions live once; only the genuine per-version deltas are expressed as a diff or override.
Cleanup tasks
- Collapse the 12
mask_v1.X.*.yamlfiles into one base + per-version overrides (or confirm which are dead and remove them). - Define which surface owns each parameter; document the rule in a short config README.
- Make the workflow pull survey parameters from
cat_configrather than restating them. - Remove the parse-time-only keys from the paper configs once the shared module reads them from their real home.
- Retire
scripts/calibration/extract_info.py+params.py/params_im_sim.py. Its only remaining job is building the uncut comprehensive catalogue (im_extractin the image-sims workflow); cuts and calibration already come from the mask yaml viacalibrate_comprehensive_cat.py. Once the ShapePipe v2 hdf5 readers (#343) provide the comprehensive catalogue directly, delete it.
Open questions
- Are all 12 mask configs live, or are early versions dead? (Only
catalog_builders.pyand a path test touch them.) - Do we want a schema (pydantic / jsonschema) to enforce the ownership rule, or is convention + README enough?
- Fiducial-plus-overrides: express overrides in YAML anchors, a config-merge layer, or Snakemake
configfilecomposition?
— Claude, on behalf of Cail
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by inventorying config/calibration/mask_v1.X..yaml, cosmo_val/cat_config.yaml, and papers//config/config.yaml, then trace how catalog_builders.py and the shared workflow module load them. Review the path test and the listed calibration scripts to identify live versus dead configuration surfaces. Done means each parameter has one documented owner, workflow configs use the fiducial-plus-overrides approach, and obsolete configs or scripts are retired where supported.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python, yaml
- Domain
- build-system
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 32/100