Ensure that all user-provided config options are meaningful and actioned

[nichollsh]

Feature description

Currently, there's no functionality in PROTEUS to check that all config options are parsed+implemented correctly. I realised this could be a problem while working on PR #665.

For example, a user might write rayleigh_enabled=True in their config file and believe that they've enabled rayleigh scattering. However, the correct option is rayleigh=True. This could lead to substantial issues when running+interpreting simulation outputs.

This seems quite critical to address, in my opinion.

Preferred solution

Warn the user when TOML file contains variables which are not mapped in the config parser routine. This is separate to having unused optional variables, which are fine to include.

Relevant people

@timlichtenberg @egpbos @EmmaPostolec @planetmariana

[egpbos]

That's a good idea!

Libraries exist with built-in support for this sort of behavior. I'd be happy to have a look at whether something's available that would fit with PROTEUS.

Btw, another thing that could help avoid user confusion (or at least allow them after the run to check their assumptions) is to output a fully specified toml (i.e. with all implicit values also written explicitly) as part of the run output. But perhaps this should be a separate issue.

[nichollsh]

Thanks, @egpbos. Do you think this would be possible to integrate with the existing attrs/catters config parser routines?

We already (kinda) do your second suggestion already. The full config file is written inside each simulation's output folder as init_coupler.toml, but isn't additionally printed to the terminal or log file.

[egpbos]

Thanks, @egpbos. Do you think this would be possible to integrate with the existing attrs/catters config parser routines?

I'd have to take a closer look at the existing setup and at what's out there. We briefly discussed this issue in the dev meeting yesterday and I understand that the (c)attrs are used to do range checks and perhaps other validation. I think this is also something that configuration libraries could do, but again, have to check whether existing libraries (e.g. ConfigArgParse, Hydra, DynaConf) support everything we need or whether adding this (rejection of invalid options) to the existing system makes more sense. Btw, maybe you already considered other systems in the past and concluded they would not suffice for PROTEUS' needs?

We already (kinda) do your second suggestion already. The full config file is written inside each simulation's output folder as init_coupler.toml, but isn't additionally printed to the terminal or log file.

Ah perfect!

[nichollsh]

Rejection of invalid options is also a good (maybe better) idea. I suppose one way to handle this in a bespoke manner, without new libraries, would be to compare the post-parsed init_coupler.toml config file to the one provided by the user. If there are any keys in the user's one which aren't in the post-parsed one, then an error could be raised.