Problem description
grid_from_config in src/proteus/grid/manage.py decides what counts as a sweep dimension by looking for a dot in the key:
for key in config.keys():
# Skip those without dots, since they aren't config variables
if '.' not in key:
continueThe dot is the only thing separating a dimension from a scalar setting, so a dimension written without one is skipped in silence. Writing struct_mass_tot where struct.mass_tot was meant matches nothing, the loop moves on, and the grid generates and runs with one fewer dimension than the file asks for. The printed setup does not say a key was ignored, and every case it does produce is valid, so the run looks healthy while sweeping the wrong space.
The optional scalars fail the same way. jax_cache is read as config.get('jax_cache', False), so jax_cahce = true leaves the cache off without complaint. The required scalars are safe only by accident: a typo there raises KeyError on the correct name.
A dimension that keeps its dot but names something the schema does not define is caught, though not usefully. It survives until the case configs are written, where recursive_setattr raises AttributeError: 'Planet' object has no attribute 'mass_totl', naming neither the grid file nor the key as the user wrote it.
Expected behavior
Every top-level key of the grid config is accounted for: recognised as one of the scalar settings, or as a dotted path that exists in the PROTEUS schema, or refused by name. A dropped dimension should be impossible to miss, and a misspelled one should be reported against the grid file rather than as an attribute error from deep inside the writer.
Evidence
The three cases, run against a structured config:
planet.mass_tot -> set
planet.mass_totl -> AttributeError: 'Planet' object has no attribute 'mass_totl'
planett.mass_tot -> AttributeError: 'Config' object has no attribute 'planett'
A key with no dot at all never reaches this point: it is dropped by the continue above.
My computer
macOS on arm64, Python 3.12.
Additional notes
The dotted paths could be checked against the schema when the grid is set up, using the same walk find_key_problems already does for nested keys. That turns the late AttributeError into a named refusal before a single case is generated, and it gives the no-dot case somewhere sensible to be reported.
Relevant people
@nichollsh
Problem description
grid_from_configinsrc/proteus/grid/manage.pydecides what counts as a sweep dimension by looking for a dot in the key:The dot is the only thing separating a dimension from a scalar setting, so a dimension written without one is skipped in silence. Writing
struct_mass_totwherestruct.mass_totwas meant matches nothing, the loop moves on, and the grid generates and runs with one fewer dimension than the file asks for. The printed setup does not say a key was ignored, and every case it does produce is valid, so the run looks healthy while sweeping the wrong space.The optional scalars fail the same way.
jax_cacheis read asconfig.get('jax_cache', False), sojax_cahce = trueleaves the cache off without complaint. The required scalars are safe only by accident: a typo there raisesKeyErroron the correct name.A dimension that keeps its dot but names something the schema does not define is caught, though not usefully. It survives until the case configs are written, where
recursive_setattrraisesAttributeError: 'Planet' object has no attribute 'mass_totl', naming neither the grid file nor the key as the user wrote it.Expected behavior
Every top-level key of the grid config is accounted for: recognised as one of the scalar settings, or as a dotted path that exists in the PROTEUS schema, or refused by name. A dropped dimension should be impossible to miss, and a misspelled one should be reported against the grid file rather than as an attribute error from deep inside the writer.
Evidence
The three cases, run against a structured config:
A key with no dot at all never reaches this point: it is dropped by the
continueabove.My computer
macOS on arm64, Python 3.12.
Additional notes
The dotted paths could be checked against the schema when the grid is set up, using the same walk
find_key_problemsalready does for nested keys. That turns the lateAttributeErrorinto a named refusal before a single case is generated, and it gives the no-dot case somewhere sensible to be reported.Relevant people
@nichollsh