dict/dataclass boundary is inverted in build_models (raw dicts re-parsed downstream) #38

New Issue

2026-08-13T15:07:05+02:00

lars commented

2026-08-13 15:07:05 +02:00

build_models takes model_config: dict, parses it into the frozen
dataclasses, then passes raw dicts (particle_cfg, material_cfg,
particle_type_cfg) back down into every module constructor — which re-read
them with string-literal defaults: .get("target", "physical") appears in
models.py (×4), sample.py (×2), stage2_inputs.py (×3), trainers.py.

That's the exact drift the branch already had to fix once (making config
dataclasses the single source of truth): the dataclass default and the inline
.get fallback are two independent copies of the same fact.

Proposal: pass ConditioningAxisConfig / ParticleTypeConfig themselves.
ty then catches a misspelled field instead of it silently falling back.

Migrated from issues.md (v0.3.0 branch review, 2026-08-13), Issue 13.

`build_models` takes `model_config: dict`, parses it into the frozen dataclasses, then passes raw dicts (`particle_cfg`, `material_cfg`, `particle_type_cfg`) *back down* into every module constructor — which re-read them with string-literal defaults: `.get("target", "physical")` appears in `models.py` (×4), `sample.py` (×2), `stage2_inputs.py` (×3), `trainers.py`. That's the exact drift the branch already had to fix once (making config dataclasses the single source of truth): the dataclass default and the inline `.get` fallback are two independent copies of the same fact. **Proposal:** pass `ConditioningAxisConfig` / `ParticleTypeConfig` themselves. `ty` then catches a misspelled field instead of it silently falling back. --- Migrated from `issues.md` (v0.3.0 branch review, 2026-08-13), Issue 13.

lars added the modularity label 2026-08-13 15:07:05 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: lars/giant#38