nancycollins
commented
9 months ago brett and i discussed this. we think he has an expedient solution that can update fields in the history files but the variable names will be hard-coded in the converter for now.
the longer term solution, i think, would be to add a third column to the clm model_mod namelist of fields in the states. the values would be the strings other models already use: 'update' and 'no_copy_back'.
the defaults should be restart file fields are 'update' and history file fields are 'no_copy_back'. the history fields are only needed for computing forward operators and are diagnostic, not prognostic. adding a column to the namelist does two things -- it makes clear what fields are and aren't updated by filter, and gives a place in the docs to discuss the scientific merits of updating diagnostic fields in the history files and a way to do it easily for testing and comparison.
several models implement an update list but then pass it into the add_domain() call for dart to process. clm does its own i/o to handle missing and fill values, so this array of field names and flags would need to be passed into the clm specific routines in dart_to_clm.f90.
a good example for parsing a 2d array of strings into 1d fortran variables might be the verify_state_variables() routine in MOM6/model_mod.f90 and an example of the layout of a namelist variable is the model_nml :: model_state_variables array in the work/input.nml file.
hkershaw-brown
Use case
Provide the user the ability to update history files in CLM. Currently
dart_to_clmexcludes updating (overwriting) any files that belong to domains other than the restart domains.Is your feature request related to a problem?
Updating the restart domain only in CLM-DART is the standard approach because restart files are the CLM prognostic variables thus impacting the forecast evolution. However, there are rare cases where it would be helpful to update other domains (history files). For example the strong correlation of the SIF observation with photosynthetic flux (GPP) is an obvious example.
Describe your preferred solution
Provide user the option to update selected history file variables. Provide namelist option in
&dart_to_clm_nmlthat works with source code changes indart_to_clm.f90Describe any alternatives you have considered
I believe the updated history variable information can also be output through the DART filter stages as well. The preferred solution makes it easier for the user by limiting the amount of files that need to be generated.