Refactor build-namelist to remove most command line options in favor of using XML variables for settings
- Dominant language
- Fortran
- Stars
- 352
- Forks
- 361
- Avg merge
- 2d 21h
- Merged PRs (30d)
- 7
Description
We discussed this at more than one CTSM-Software meetings. One of the challenges with the build-namelist system is that we have several different ways to manage namelist settings. Namely
- Command line options that go into the CLM_BLDNML_OPTS catchall XML variable
- Use-cases that have namelist defaults settings in xml that go into use cases set by the CLM_NML_USE_CASE use case variable
- User mod directories that contain shell_commands and user_nl_* files in a directory
- Specific CTSM clm xml variable settings (such as: CLM_PHYSICS_VERSION, CLM_CONFIGURATION, CLM_STRUCTURE, CLM_CO2_TYPE, CLM_ACCELERATED_SPINUP, CLM_USRDAT_NAME, CLM_USRDAT_DIR, CLM_ACCELERATED_SPINUP, CLM_CO2_TYPE, NEONSITE, NEONVERSION)
- The CLM_NAMELIST option that adds settings with a higher priority than user_nl_clm
- Compsets that use a combination of all of the above to get the configuration desired
- Directly setting namelist options in the user_nl_clm file for a case
There are advantages and disadvantages of each type. I think we do want to keep more than one method as there are advantages of each and keeping a few would be reasonable. One of the reasons for the first was to provide a way to do the build-namelist outside of CESM case. This was important when running in a CESM case wasn't the only option. Now it's not. And the catch-all nature of the CLM_BLDNML_OPTS option makes it awkward to use and sometimes causes problems. Similarly the CLM_NAMELIST option can cause problems and if we could eliminate it, would be good. The syntax for it is problematic for example.
As such I think we should restructure the build-namelist user-interface to add XML variable options to control it removing most of the build-namelist command line options. The XML variables are better documented in a case and more separable. This does mean there will likely be a much longer list of XML variables, and the list will change in time. An advantage of CLM_BLDNML_OPTS is that it was always backward compatible.
Contributor guide
Assessment
This issue has not been assessed yet.