-
Notifications
You must be signed in to change notification settings - Fork 25
2018 meeting notes
Testing the diagnostics with Jessica's size-structured set-up highlighted a bug with how logical settings are handled - e.g. length of tracer_restore_vars depends on whether ciso_on = ".true." but some users would set ciso_on = "T" instead. (Solution is to convert all acceptable Fortran logical values to either ".true." or ".false." so the comparison is always valid.) We also discussed combining POP and MARBL diagnostics into a single file (ecosys_diagnostics).
My plan once the diagnostics work is on the trunk will be to go back and address several tickets that seemingly have quick fixes; this should coincide nicely with everyone else being at Ocean Sciences.
The majority of time in this meeting was spent digging into the weeds of the YAML / python setup for defining diagnostics. Lots of good suggestions, such as better implementation of templating (things like ((autotroph_sname)) for autotroph short name) and not introducing an additional level of dictionaries just to handle per-autotroph and per-tracer diagnostics.
PGI continues to introduce compiler bugs that prevent MARBL from running (which is actually an improvement from the days where PGI compiler bugs prevented MARBL from building). Need to figure out if dropping PGI support is okay with CESM / E3SM, or if some nominal testing needs to continue as PGI updates its compiler.
Walking through the updates to default_settings.yaml (to include tracer short-names instead of just total count) raised some internal inconsistencies -- marbl_interface_private_types.F90 refers to tracers in all lower-case (po4 and caco3) while marbl_init_mod.F90 actually sets up the tracer metadata using proper atomic case (PO4 and CaCO3). The YAML file will use the marbl_init_mod.F90 case, and hopefully we can auto-generate both marbl_interface_private_types.F90 and marbl_init_mod.F90 based on the YAML so that they will be consistent as well.
We prioritized current open tickets to determine what we want in the CESM2.0 sub-milestone of the MARBL 1.0.0 milestone.
Discussion on how to fix the bug in interior restoring, which should be on master by the next meeting. This fix will definitely go into CESM 2.0, but it does not need to be in the next beta tag... so the fix will get merged onto marbl_dev immediately but not pushed to the trunk just yet.
Not much MARBL-specific conversation, just walked through NCAR/manage_externals and how it will be used in CESM tags following cesm2_0_beta08 (and also in POP starting in whatever trunk tag goes into cesm2_0_beta09)