parameter constants from optional features

[rgknox]

The FATES parameter file is getting large. As an example, PR #1021 will add 23 new parameters related to recruitment. I'm concerned that newer users are looking at this parameter file and getting overwhelmed. I'd like to start a discussion on how to buffer users from parameter fatigue.

I had one idea, we could identify parameters that are only relevant in optional modules. We could use namelist switches to activate and deactivate these modules, and also activate or deactivate the reading of these parameters as well. This would allow us to maintain a simplified or reduced scope parameter file for fates users. We would continue to maintain the full parameter file that contains defaults for everything as well. This might not be so straight forward, as some modules may be optional, but seem very core to the most user's needs. So where do we draw the line on parameters to include in the simplified or reduced set...

[mpaiao]

@rgknox I think a modular approach could be interesting. I suspect very few people look/use/change most parameters in any given simulation or even parameter sensitivity analysis.

One way could be to have the default set of parameters to be comprehensive, but then have a user-generated file where people can list the parameters they want to be overwritten along with their values. This is basically what you suggested, but it might work without adding more switches to the name lists. But I haven't thought much and could be missing potential drawbacks...

[rgknox]

I'm realizing that we could just process module switches in the parameter file first, and use those results to determine if groups of constants will be read in.
@mpaiao we do have these xml based pre-processors, that allow a user track just the salient parameters to their needs, here is an example: https://github.com/NGEET/fates/blob/main/parameter_files/patch_default_bciopt224.xml
However, as mentioned, this is a pre-processor, and is used to generate a parameter file.

[glemieux]

I really like this idea of only registering the necessary parameters for a given run mode. It'd be ideal to conduct more error checking to give the user more feedback on what variables might be missing for the selected set of modes. I think it would also be good to update the pre-processing tools to more intentionally act as the user's primary means of interfacing with the parameter file.