Skip to content

2019 meeting notes

Jump to bottom
Michael Levy edited this page Jan 14, 2020 · 15 revisions

November 5, 2019

Lots of discussion on the CESM2 special edition paper:

  1. Keith has a script for pulling data off of HPSS -- can be modified for ocean needs

    • Data should be stored in /glade/p/cgd/oce/projects/cesm2-marbl/intake-esm-data/

  2. Once data is on /glade/p, I need to set up intake-esm catalog for it

  3. Keith also has a script (/glade/work/klindsay/analysis/CESM2_coup_carb_cycle_JAMES/run_nb_ocn.csh) to re-run notebooks from a shell that may prove useful. Main line is

      jupyter nbconvert --to notebook --inplace \
      --ExecutePreprocessor.kernel_name=python \
      --ExecutePreprocessor.timeout=3600 \
      --execute $NOTEBOOK_FILENAME

October 22, 2019

No notes from this meeting available...

September 24, 2019

MOM initial conditions -- stick with WOA vertical grid:

$ cd /glade/p/cesm/bgcwg/OMIPinit
$ ncdump -v depth woa13_nitrate_OMIPinit.nc
...
 depth = 0, 5, 10, 15, 20, 25, 30, 35, 40, 45, 50, 55, 60, 65, 70, 75, 80,
    85, 90, 95, 100, 125, 150, 175, 200, 225, 250, 275, 300, 325, 350, 375,
    400, 425, 450, 475, 500, 550, 600, 650, 700, 750, 800, 850, 900, 950,
    1000, 1050, 1100, 1150, 1200, 1250, 1300, 1350, 1400, 1450, 1500, 1550,
    1600, 1650, 1700, 1750, 1800, 1850, 1900, 1950, 2000, 2100, 2200, 2300,
    2400, 2500, 2600, 2700, 2800, 2900, 3000, 3100, 3200, 3300, 3400, 3500,
    3600, 3700, 3800, 3900, 4000, 4100, 4200, 4300, 4400, 4500, 4600, 4700,
    4800, 4900, 5000, 5100, 5200, 5300, 5400, 5500
  1. Skip vertical remap step for WOA vars
  2. Update dst_grid vertical for remapping POP vars

Consensus on SIParCS: would be nice to have, but this isn't the best time to put together a project proposal. If Xdev gets a student, we can work with them on a pre-defined project... and maybe we can come up with something better for the 2020 deadline (summer 2021 students)

August 27, 2019

One thing to talk to Kristen about: resetting to wrong time level at the moment (using oldtime instead of average of oldtime and curtime) [coming back to these notes a little late, but I believe that's the correct time level)

Also, I should run the netCDF comparison tests for the stand-alone driver on izumi in addition to hobart

August 13, 2019

Got some tips on reworking MOM driver and some co2calc code:

  1. add a block with comment ! initialize configurable tracer packages above

    !    Add other user-provided calls to register tracers for restarting here. Each
!  tracer package registration call returns a logical false if it cannot be run
!  for some reason.  This then overrides the run-time selection from above.

  2. short-term: co2calc_coeffs_type has arrays rather than scalars, memory allocation done in init (max of num_columns and num_levels so surface and interior can both use it)

Regarding gnu bug: Support 4.8 because it seems like it might be necessary for mex and python drivers?

July 16, 2019

In the MOM driver, Mike will look into moving the marbl_instance%init() call from register_tracers() to init_MARBL_tracers(). And for the MARBL diagnostics, he'll spend a few days ironing out the interface / tying in to pop-tools and intake-esm (either mid-August or sometime in September).

For MARBL, we discussed dropping the Jint_*tot diagnostics altogether. PR #247 addressed issue #1, and MARBL will now abort if mass is not conserved. One idea that was floated was to include an option to turn off the abort, and only provide the diagnostic output if the abort is turned off.

We also noticed that lecovars_full_depth_tavg only applies to tracers, not to other truncated diagnostics. To make it live up to its name, this variable should be used to determine truncate for variables like PAR_avg and graze_auto_TOT. Also, there is no need for a separate ciso version -- the carbon isotope diagnostics should behave the same way as the base tracer diagnostics.

Lastly, the stand-alone driver that Mike is using should mimic POP diagnostic names for the surface flux and interior tendencies. This means outputting STF_[tracer] instead of [tracer]_SFLUX and J_[tracer] instead of TEND_[tracer]. This will just make it easier to compare output from the test with data extracted from a POP run.

May 7, 2019

Single column test notes: picked some POP grid points to potentially use:

  • OMZ -- (264, 230): 257.6 E, 11.5 N
  • Arctic Circle (no sunlight, near-zero diazC?) -- (195, 360): 216.7 E, 81.9 N
  • Low KMT (sediment burial with non-trivial biomass) -- (158, 148): 138.3 E, -10.3 N
  • Negative diazCHL (update this coordinate?) -- (202, 68)
  • Multiple PAR columns (largest QSW_BIN_06) -- (157, 37): 137.2 E, -59.5 N
  • High Iron (two possibilities)
    • (288, 297): 285.2 E, 38.6 N
    • (288, 294): 285.1 E, 37.2 N
  • Extreme Latitudes (two possibilities)
    • (174, 365): 217 E, 87.3 N
    • (210, 2): 196.8 E, -78.2 N

More thoughts on diagnostics:

  1. Definitely want time series / global averages in MARBL diags
    • vars to include: get list from Keith (it's a lot)
  2. No need to put time series of Who's run in /glade/p -- setting up a new hindcast (will start after cheyenne comes back up)
  3. Eventually get from an upcoming hindcast (or PI control)
  4. Regression testing: write a cprnc-esque python script using numpy and allclose
  5. Look at docker (Anderson) as a way to generate consistent environment across machines
  6. instead of marbl-diags framework, can we combine notebooks and sphinx to make an easy-to-browse set of plots?
  7. diagnostics: better use of collections (xcollections was an early attempt); tell the class "I want the average of years 5 - 7 of variable X" and it looks to see if it exists, then looks to see if annual averages of years 5, 6, and 7 exist, then just computes the annual averages of those years and averages them together. Need flag to cache specific steps?
    • maybe team up with Anderson?
    • maybe limp along with ad-hoc diagnostics and then work towards more optimal solution laid out above

April 9, 2019

  1. Talk to Kristen about getting her branch onto CESM 2.1 in addition to development / stable
    • alternatively, if Kristen's work only goes on development / stable, can a sandbox based on CESM 2.1 use development tag? (Or use Kristen's branch directly at a commit compatible with 2.1)
  2. Guiding principle: cesm2.1 branch is primarily for bugfixes (that will also go on development); bit-for-bit refactors can be decided on a case-by-case basis (some might be useful to have in 2.1). Feature of spin-up mods is also necessary for 2.1 release.
  3. Finding nearest neighbor (for Loess filter): take dot products, look for largest (i.e. largest cos theta)
    • basin mask to avoid mixing atlantic and pacific?
  4. Diagnostics: still haven't vetted JRA runs
    • are we the hold up on JRA progress?
  5. Should we start with the MOM coupling soon?
    • aim to have MARBL implementation by end of 2019
    • having it prior to MARBL 1.0.0 release will raise confidence in MARBL interface

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
  1. Design Document
  2. How to Submit Code Modifications
  3. Dev meeting agenda / rough notes
  4. Processes Still Being Developed
Clone this wiki locally