Description of the issue:
The process for calling define_tavg() for the MARBL-generated diagnostics script is complicated, and involves generating several different files in Buildconf/popconf/ for different purposes. ecosys_diagnostics contains a list of variables to include in POP's tavg_contents file, and a modified copy can be placed in SourceMods/. marbl_diagnostics_operators is read by the Fortran code and used to call define_tavg(), but it can not be copied from SourceMods/.
The crux of the issue is that one-off experiments where a new diagnostic is added to MARBL can lead to an inconsistency between those two files and, if the new variable is in ecosys_diagnostics is not in marbl_diagnostics_operators then POP will abort during init with a message about an undefined diagnostic being requested in tavg_contents. (There's also an intermediate file marbl_diagnostics_list that is used in conjunction with ecosys_diagnostics to generate marbl_diagnostics_operators, but I need to track down how that file is generated and if it can be placed in SourceMods or not).
I've opened a similar issue in the MARBL repo to update the documentation for this process, but some POP script changes will be necessary to allow users to have more control over the diagnostic lists.
Version:
- CESM: this issue has existed since MARBL was added to POP
- POP2: latest, and probably the CESM 2.1 release branch as well?
Machine/Environment Description:
Any xml/namelist changes or SourceMods:
Description of the issue:
The process for calling
define_tavg()for the MARBL-generated diagnostics script is complicated, and involves generating several different files inBuildconf/popconf/for different purposes.ecosys_diagnosticscontains a list of variables to include in POP'stavg_contentsfile, and a modified copy can be placed inSourceMods/.marbl_diagnostics_operatorsis read by the Fortran code and used to calldefine_tavg(), but it can not be copied fromSourceMods/.The crux of the issue is that one-off experiments where a new diagnostic is added to MARBL can lead to an inconsistency between those two files and, if the new variable is in
ecosys_diagnosticsis not inmarbl_diagnostics_operatorsthen POP will abort during init with a message about an undefined diagnostic being requested intavg_contents. (There's also an intermediate filemarbl_diagnostics_listthat is used in conjunction withecosys_diagnosticsto generatemarbl_diagnostics_operators, but I need to track down how that file is generated and if it can be placed inSourceModsor not).I've opened a similar issue in the MARBL repo to update the documentation for this process, but some POP script changes will be necessary to allow users to have more control over the diagnostic lists.
Version:
Machine/Environment Description:
Any xml/namelist changes or SourceMods: