2019 meeting notes

February 26, 2019

Lots of talk about the diagnostics package. Some thoughts:

1. Have datasets.yml be a curated list of datasets, while user_datasets.yml can be used for one-off experiments
2. Remove variable names from defaults in analysis elements block (user must specify variables to look at)
3. Analysis can be based on python-defined categories (e.g. 3d_maps_on_levels, surface_processes, biological_pump_processes, oxygen_cycle, forcing)
   • Would need to track what operators are needed by each category, preferably not hard-coded in python
4. replace MidPointNorm with other class from matplotlib (binned colorbar?)
5. stats_in_title should be True by default

---

January 29, 2019

Lots of discussion on what a stand-alone test for the interior tendency and surface flux compute() subroutines should look like. Some decisions:

1. Test will need to read in initial state and forcings, and provide output (diagnostics, tendencies, and surface fluxes)
2. Extract above data from a POP run
3. Test will run on multiple columns. Some possible choices:
   1. OMZ column (eq. Pacific)
   2. multiple PAR columns (Southern Ocean)
   3. Some functional groups = 0 (e.g. high-latitude => no diaz)
   4. Arctic vs Antarctic @ Jan 1 [darkness vs ice]?
   5. Subtropical Atlantic (high Fe)
4. Ability to run with multiple instances & multiple columns per instance would be valuable for documenting the process
5. Test written in Fortran to provide additional example for GCM developers

Thoughts on a python version of the test. Something like

>>> import MARBL
>>> MARBL.init() ...

1. How to deal with diagnostics? black-box ODE solvers might not be compatible with how we typically think of diagnostics
2. Possibility: marbl.F90 -> python, replace marbl_driver_nml with python options (argparse? pytest?) and then keep everything called in the select case (trim(testname)) block in Fortran

---

January 15, 2019

Started with a brief discussion about DOIs -- the big question is "what happens with the Zenodo DOIs if we delete code from github?" There doesn't seem to be a way to point to a different repository, and it is unclear if the zip files available for download on Zenodo are actually stored there or if they are provided by github. Mike contacted the NCAR librarians to see if they have any guidance - perhaps NCAR has a better way of assigning DOIs to code?

Lots of talk about what the MARBL documentation should look like. Main conclusions:

1. Mike will update the github.io page for the CESM 2.1 release, but the current implementation (especially including code snippets via cut & paste) should be rethought
2. Creating an instructional stand-alone driver is highest priority (designed to teach others what functional GCM <-> MARBL interface looks like) * instructional driver is likely different than testing driver to avoid confusing new users (testing driver may depend on instructional code?)
3. doxygenize marbl_interface.F90
4. What we currently refer to as the Dev Guide and the User Guide should be combined into a single Dev Guide that clearly differentiates between "GCM Developers looking to bring MARBL into their GCM" and "BGC experts looking to bring their science into MARBL"; a new User Guide should target "scientists running a GCM that happens to include MARBL"
5. The new dev guide should be entirely based on stand-alone driver; GCMs will want to base their driver off of that code
6. Science guide should definitely include sections on the elemental cycles (oxygen, iron, etc) and the ecosystem (growth / loss)

CMIP is requesting some specific documentation that might be useful in the science guide. There was discussion on how to organize the science guide -- laying the document out in a manner similar to how the code is organized would be nice, but does not seem practical from an upkeep point of view.

Matt raised the point about documenting parameters. The YAML files provide a mechanism for maintaining this information, and CESM converts it to HTML, but the actual descriptions in the YAML need to be updated. For example, describing the variable agg_rate_min as "Minimum agg rate" is not particularly useful.

The last topic covered was the diagnostics. There were some small updates that will be easy to incorporate:

1. Rely on OCNDIAG_DEPTHS for the depth list
2. Use esmlab for computing RMS)
3. Use land mask from dataset rather than cartopy's continents
4. No need to save Elem, just run marbl_diags.AnalysisElements(k, config_dict[k], var_dict).do_analysis()

and a big-picture thought: env_diags_ocn.xml could have a single field, OCNDIAG_USE_MARBL_DIAGS and then YAML would be used to control the marbl-diags package itself

• Matt raises point that users that want to add new BGC diagnostic plots should not have to touch the postprocessing scripts at all - it should be contained entirely in marbl-diags
• Mike likes the idea of hard-coding config_dict in python, but giving user ability to write it as a YAML file to $CASEROOT/postprocess and then edit it as desired
• Lots of possibilities for what this looks like, but we need to make more progress on the short-term task list before deciding how this will be implemented