-
Notifications
You must be signed in to change notification settings - Fork 25
2017 meeting notes
Most of the meeting was spent discussing the best way to initialize PFTs. We will introduce a new MARBL parameter named PFT_defaults; a value of 'user-specified' will force the user to set all PFT-related variables; the default value will be 'CESM2', which will provide the 3 autotrophs, 1 zooplankton, and 3 grazing prey classes that are currently the default.
We will also rename grazer_prey_cnt to max_grazer_prey_cnt as that is a more descriptive name -- if we have 2 zooplankton, one of which grazes on three different biomass aggregates and another that only grazes on two then we need max_grazer_prey_cnt = 3; in the future, we may consider grazer_prey_cnt(zooplankton_cnt).
We will have some CESM-specific comments in MARBL, but only temporarily -- not all of the MARBL parameters that can be changed via put_setting() calls are available in the POP build-namelist script, and we want to make it clear to CESM users which parameters need to be changed in the Fortran code as opposed to which default values are over-written by put_setting() calls from POP. After MARBL has its own tool to generate input files, the comments will change to alert users to variables that should be changed via input file.
Our plan for CESM 2.0 is to continue to develop at our natural pace and see where MARBL stands at the code freeze - we already have several more features in than we expected thanks to delays in the CESM finalization. Keith is working on a new initial condition file; ecosys_jan_IC_gx1v6_20161123.nc is an intermediate file useful for some testing but is not needed in place of ecosys_jan_IC_gx1v6_20150108.nc given that it will not be the final version of the file and updating from the old version will require new baselines for all our tests.
Lots of progress was made towards #189. Most notable is that POP's build-namelist tool generates a separate marbl_in file that MARBL parses without Fortran's namelist functions. This is a great step towards having MARBL generate its own input file, which will be tackled after #189 is accepted.
I have a fork of the repository holding the MARBL documentation, and I will keep it up to date with my code changes so that the documentation can be updated once 189 is pulled to master.
Most of the meeting was spent discussing initialization; the current plan is to have marbl_instance%user_settings replace both %configuration and %parameters; the %put() call would store the keyword - value pairs in a linked list until after each round of %add_var() calls; at that point, variables that have been added would be updated (and the linked list entry would be deleted), while put() calls for variables that haven't been added yet would be kept (and tried again after the next round of %add_var()). If the linked list is not empty at the end of init() then it indicates a put() call did not match any of the parameters and MARBL will abort with an error.
We also talked about using a single monolithic init() instead of breaking the calls into different phases. One reason for doing this is that the different phases were introduced just so that GCMs had the opportunity to call put() in between phases, but that will no longer be necessary. Also, we will add some error checking to make sure different initialization routines are called in the right order (for example, we can not initialize tracer_restore_vars until we have constructed marbl_tracer_indices): this will likely mimic POP's initialization error checking, where we register a string with the subroutine name at the beginning of each phase and check to see if routines that are depended on have been run by looking for that name in the registry.
In the future, we can perhaps abandon the MARBL namelist altogether -- POP's build-namelist tool could write a separate file (marbl_in?) that contains a generic format like
var1_name var1_type var1_value
var2_name var2_type var2_value
...Which would turn into the default format of MARBL's gen_parameters tool. The POP driver would then read this file and call marbl_instance%settings%put() and we could strip all namelist support out of MARBL.
We talked about what the next steps in MARBL development should be. After bringing runtime configurability to PFT counts in to MARBL (currently in progress), it will probably be a good time to work on MARBL setting up its own namelist, and it would be useful to have better control over diagnostic output before bringing abio tracers into MARBL. So the recommended path forward is
- Finish runtime-configurable PFT
- MARBL building its own namelist
- More flexibility in
marbl_domain_type - Better control over what diagnostics are returned to GCM
For the namelist generation, we compiled a list of options the namelist generation tool should support
-
--output-file-format: default will be Fortran namelist, but also support MPAS and MOM parameter file formats -
--default-file: XML file containing general defaults -
--non-default-files: a way to have MARBL provide multiple XML files that build on each other (e.g. turning CISO on) -
--user-specified-file: a way for the user to specify changes from the default settings -
--user-specified-file-format: XML file? something like CESM'suser_nltext files? Something MPAS or MOM specific? etc etc.
For better control of diagnostics, what if MARBL did not allocate field_2d or field_3d but instead left that up to the GCM? Instead of compute_now we could just look to see if memory was allocated. (Maybe make them pointers, then check if associated?) This led to the follow up question about whether there are other parts of the interface that could be updated in this manner (state, forcings, fluxes, tendencies, etc). Conclusion was that it probably doesn't make sense to determine which tracer tendencies are returned in this manner, it's easier to think of tracers in natural groupings than as individual quantities).