Skip to content

2018 MARBL Dev team meetings

Jump to bottom
Michael Levy edited this page Sep 17, 2018 · 146 revisions

September 18, 2018

General discussion

MARBL Software Updates

  1. Thoughts on #318

    • Getting k-loop out of marbl_interior_tendency_compute() will require thought re: update_particulate_terms_from_prior_level()
    • Refactor idea: instead of blocks of code like
       !-----------------------------------------------------------------------
   ! compute zooplankton loss routing
   !-----------------------------------------------------------------------
   do zoo_ind = 1, zooplankton_cnt
     zoo_loss_poc(zoo_ind,k) = f_zoo_detr(zoo_ind,k) * zoo_loss(zoo_ind,k)
     zoo_loss_doc(zoo_ind,k) = (c1 - parm_labile_ratio) * (c1 - f_zoo_detr(zoo_ind,k)) * zoo_loss(zoo_ind,k)
     zoo_loss_dic(zoo_ind,k) = parm_labile_ratio * (c1 - f_zoo_detr(zoo_ind,k)) * zoo_loss(zoo_ind,k)
   end do
    Maybe that could be a method object on zooplankton_derived_terms_type? 
       call zooplankton_derived_terms%compute_routing_loss()
    (Is this a good idea? Is it worth doing in current pull request or should it be a new issue ticket?)

POP Software Updates

September 11, 2018

General discussion

  1. Previous discussion: how can we make it easy for developers to track changes to MARBL?

    • Given how we have been doing merges since marbl0.26.2, git log --first-parent will only show the merge commits. Up until marbl0.28.6 these are just the default merge commit messages, though:
    $ git log marbl0.26.2..marbl0.28.6 --first-parent

    • I talked to Bill Sacks, who showed me some git tools that might be useful

      • We could start using annotated tags, though I don't see much purpose now that I've started replacing the default merge commit message with something more descriptive. Seems to be recommended practice without any real reason why
      $ git help tag
...
       Annotated tags are meant for release while lightweight tags are meant for private or temporary object
       labels. For this reason, some git commands for naming objects (like git describe) will ignore
       lightweight tags by default.
...
      • git show [tag name] will show commit message for an individual tag:
      $ git show marbl0.28.5
$ git show marbl0.28.6
      • git tag -n999 [tag names] will show commit message of each tag:
      $ git tag -n999  marbl0.2[89]* marbl0.3[0-9].*

    • I emailed Nate Wilhelmi to see if CISL still has a backup of the old release notes from NCAR/MARBL; if so, we could create a ChangeLog post on the wiki (either just for old tags, or to keep up-to-date with new tags as well; I prefer the former). I could probably create a changelog even without the old release notes, but that doesn't seem like a good use of my time right now.

    • Regardless of the decision on the ChangeLog, a wiki page about best practices / how to determine what changed between tags seems useful

    • Template(s) for issue tickets and PRs? I like the idea of being able to copy the first comment in a Pull Request to use as the commit message, or at least the basis for a commit message, when doing the merge. Starting with the CTSM example, I think key points we want available to people trying to figure out what is in a tag:

      1. Summary of changes
      2. Summary of testing performed
      3. Link to github issue(s) fixed by PR, and maybe also issues addressed but not fully fixed
      4. Did the interface change at all? We have a pretty loose definition of "interface", this is asking if the GCM driver layer or scripts will need to change. Renaming a variable that appears in the MARBL input file is an interface change.
      5. Scenarios where we expect answers to change, e.g. "new science in marbl_ciso_*_mod will only change answers when running with the carbon isotope tracer module enabled"

    • Not related to people learning more about a specific tag, but we also need to know if we need to update the documentation web page following a pull request

MARBL Software Updates

  1. #318 update:
    • "Interface" change: renamed lots of parameters found in the settings file:
      • autotrophs -> autotroph_settings
      • zooplankton -> zooplankton_settings
      • grazing -> grazer_settings
    • Lots of types have been renamed as well (and moved from marbl_pft_mod -> marbl_interface_private_type)

POP Software Updates

  1. Small change to python support scripts dealing with name-changes in MARBL settings file as part of #318 
    Index: MARBL_scripts/MARBL_wrappers/MARBL_settings.py
===================================================================
--- MARBL_scripts/MARBL_wrappers/MARBL_settings.py	(.../marbl_dev_levy_n198_marbl_dev_n99_cesm_pop_2_1_20180830)	(revision 89882)
+++ MARBL_scripts/MARBL_wrappers/MARBL_settings.py	(.../marbl_dev_levy_n199_marbl_dev_n99_cesm_pop_2_1_20180830)	(revision 89882)
@@ -86,9 +86,9 @@
         """
         autotroph_list = []
         for n in range(1, self._MARBL_settings.settings_dict['autotroph_cnt']+1):
-            autotroph_name = self._MARBL_settings.settings_dict['autotrophs(%d)%%sname' % n].strip('"')
-            imp_calcifier = (self._MARBL_settings.settings_dict['autotrophs(%d)%%imp_calcifier' % n].strip('"') == '.true.')
-            exp_calcifier = (self._MARBL_settings.settings_dict['autotrophs(%d)%%exp_calcifier' % n].strip('"') == '.true.')
+            autotroph_name = self._MARBL_settings.settings_dict['autotroph_settings(%d)%%sname' % n].strip('"')
+            imp_calcifier = (self._MARBL_settings.settings_dict['autotroph_settings(%d)%%imp_calcifier' % n].strip('"') == '.true.')
+            exp_calcifier = (self._MARBL_settings.settings_dict['autotroph_settings(%d)%%exp_calcifier' % n].strip('"') == '.true.')
             if imp_calcifier or exp_calcifier or (not calcifier_only):
                 autotroph_list.append(autotroph_name)
         return autotroph_list
@@ -100,7 +100,7 @@
         """
         zooplankton_list = []
         for n in range(1, self._MARBL_settings.settings_dict['zooplankton_cnt']+1):
-            zooplankton_name = self._MARBL_settings.settings_dict['zooplankton(%d)%%sname' % n].strip('"')
+            zooplankton_name = self._MARBL_settings.settings_dict['zooplankton_settings(%d)%%sname' % n].strip('"')
             zooplankton_list.append(zooplankton_name)
         return zooplankton_list

September 4, 2018

General discussion

  1. IOMB update: the python stack is broken on cheyenne; Alice walked me through everything but until she (or someone in CISL) fixes how a package is installed I can't actually do anything.
    • Workflow requires CESM post processing tools (namely time slices -> time series conversion) before even using the IOMB code so it's hard to set up a pure IOMB environment

MARBL Software Updates

  1. Email from Keith asks about notifying users re: new tags

    I see on github that you made a new MARBL tag yesterday. While I do get emails from github when there is action on pull requests and issues, I did not get a message for the tag. I think we should consider posting a message to the MARBL developers mailing list when tags are made. This suggestion could be refined by restricting what levels of tags are announced (e.g., for tags of the form x.y.z, only announce if x or y change).

  2. Priorities now that marbl_mod refactor is done?

    • I was thinking about #68, #311, and #314: clean up types split between marbl_interface_public and marbl_interface_private, including better type names and proper public / private attributes in marbl_interface_class

POP Software Updates

August 28, 2018

General discussion

MARBL Software Updates

  1. Final touches for PR #308:
    • Code review finished
    • Revisions stemming from review finished
    • Running aux_pop_MARBL as we speak => new tag coming tonight or tomorrow (assuming no surprises in testing)
  2. Next up: Keith working on #272? [ladjust_bury_coeff drifting due to marginal seas]
    • Mike will spend a few days on the IOMB stuff, come back to MARBL next week?
  3. Lots of new small issues (mostly things Keith and I noticed while reviewing #308):
    • #312: Jessica's work highlighted a bug in routines called from set_interior (autotroph_secondary_species argument was intent(out) in a few places where it should have been intent(inout); caused issues when she added an allocatable array to the type)
    • #313: Keith pointed out that we should revisit what POC remin term gets sent to the carbon isotope computation -- currently, the remin term given to ciso does not include sediment flux
    • #314: future code clean-up reducing how many variables and datatypes use the marbl_ prefix
    • #315: we are not consistent in how we name similar method objects across multiple classes (constructors, etc)

POP Software Updates

  1. New MARBL tag will be brought into marbl_dev
  2. marbl_dev is behind POP trunk, will merge that on as well
  3. I want to bring this POP tag to trunk and add to CESM 2.1 and 2.2 alpha tags
  4. "zig-zag" merge to make a new marbl_dev tag with latest POP ChangeLog (and updated trunk tag in branch tag name)

August 21, 2018

General discussion

  1. Upcoming priorities:
    • Finish open pull request, get changes onto marbl_dev and the POP trunk
    • Either fix issues in IOMB or get enough info to have N. Collier know what needs to be fixed
    • Keith has mentioned getting MARBL restoring fix onto development (ensure conservation in open ocean when restoring in marginal seas?)
  2. Rolling CESM 2.1 releases -- sounds like 2.1.0 is coming "soon" (October-ish?), but there will also be 2.1.1 and 2.1.2 releases as more CMIP experiments are run and compsets are added to the code base. So should we keep the focus on bit-for-bit code cleanup as long as possible? Lots to do according to the projects page, so I think that's a reasonable path forward.

MARBL Software Updates

  1. Update on #308: cleaned up all usage of the term surface_forcing. Either surface_flux or surface_flux_forcing now. Working on interior_forcing
    • Variable rename options: what to call intent(in) to marbl_surface_flux_compute() and interior_tendency_compute()? Currently surface_vals and column_tracers, respectively (link to interface code). Options:
      1. tracers_at_surface and tracers
      2. tracer_surface_vals and tracer_vals

POP Software Updates

August 16, 2018

General discussion

MARBL Software Updates

  1. 3 PRs since last meeting
    • #298: code consistency tests as part of Travis CI
    • #302 and #306: clean up all gfortran warnings, have gfortran elevate warnings -> errors (so Travis CI will fail if code mods introduce something gnu warns about). Not automated, but we're currently error-free with NAG as well -- common warning that nagfor throws and gfortran doesn't is use marbl_foo_mod, only : bar without any actual use of bar in the scope of the use statement... so keeping those from creeping in would be nice.
  2. Current open PR (#308) for changing "surface forcing" to "surface flux" and "interior forcing" to "interior tendency"
    • Lots of refactoring code: marbl_mod.F90 split to marbl_surface_flux_mod.F90 and marbl_interior_tendency_mod.F90 (similar split for marbl_ciso_mod.F90), and CISO diagnostics pulled into new marbl_ciso_diagnostics_mod.F90. Several new share modules as a result.
    • Try to limit where ciso_on is used. Ideally we always call marbl_ciso_ routines, but they return immediately if ciso_on == .false.; exceptions are things like index constructors, where we don't have a ciso equivalent.
    • Besides modules, some changes to interface subroutine names: set_surface_forcing -> surface_flux_compute, set_interior_forcing -> interior_tendency_compute and so on
    • Lots of variable name changes; variables with forcing in their name are related to the forcings provided by the GCM!

POP Software Updates

  1. marbl_dev is one commit behind the trunk (Keith's final_CMIP6_BGC tag):
Tag Summary: Merge latest final_CMIP6_BGC_tags branch tag (n13) onto trunk

correct IAGE reset when lrobert_filter=.true., add CMIP tracer budget diagnostics
move submeso and diag_gm_bolus-dependent tavg vars into separate tavg_contents files
update 1850 Ndep forcing from recent coupled B1850 WACCM run
correct EBM tavg vars, enable some 2D EBM tavg vars by default
  1. Current MARBL PR will require [small] POP update due to interface name changes

No Meetings

  • Aug 7, 2018 (Keith L out of town)
  • July 31, 2018 (Matt L out of town)
  • July 24, 2018 (Matt L out of town)

July 20, 2018

General discussion

MARBL Software Updates

  1. marbl0.30.0 -- CMIP6 parameter defaults
  2. marbl0.31.0 -- Keep CMIP6 default values, but allow easy way to switch to CESM 2.0 defaults
  3. Using pylint to enforce python coding conventions
    • By default, assumes PEP 8 convention (PEP = Python Enhancement Proposal)... we can use it out-of-the-box or set up our own conventions
    • Biggest change to our code: "Limit all lines to a maximum of 79 characters" and "For flowing long blocks of text with fewer structural restrictions (docstrings or comments), the line length should be limited to 72 characters." (Though in actuality default from pylint is 100 character max...)
    • I'll talk to CIME folks about how they use this tool
  4. Should we fix the "cksi -> cks" bug on CESM 2.0? [step towards having OCN_BGC_CONFIG=cesm2.0 actually match CESM 2.0 results]
    • Maybe have a lfix_known_bugs flag that is .false. by default to maintain consistency with the CESM 2.0 control run?

POP Software Updates

  1. cesm_pop_2_1_20180716 -- update out-of-the-box tuning for CMIP6 (misleading name, actually made on July 19)
  2. cesm_pop_2_1_20180720 -- add ability to run with CESM 2.0 tuning
  3. marbl_dev_n96 -- identical to cesm_pop_2_1_20180720 trunk tag.
  4. Should we fix Robert Filter bug on CESM 2.0? How about the passive tracer tavg bug? [step towards having OCN_BGC_CONFIG=cesm2.0 actually match CESM 2.0 results]

July 10, 2018

General discussion

  1. Catch-up since it's been 4 weeks since last meeting
  2. State of CESM 2.1 spin-up?

MARBL Software Updates

  1. A couple of PRs are ready
    • #297 provides mechanism for multiple default settings files
    • #296 is a small update to account for changes to the hobart modules (stand-alone driver scripts load the same modules as CESM 2.0.1; the modules from 2.0.0 have been removed)

POP Software Updates

  1. There are some POP changes corresponding to #297 above

No Meetings

  • July 3, 2018 (Matt L out of town)
  • June 27, 2018 (everyone out of town)
  • June 20, 2018 (CESM Workshop)

June 13, 2018

General discussion

  1. Upcoming meeting dates
    • No meeting next week (CESM workshop)
    • Skip next week? Reschedule for Monday (June 25)? Mike out Tues - Fri
  2. Documentation

MARBL Software Updates

  1. Testing via Travis CI seems to be working, #286 discusses improvements
  2. I still need to send email out to development mailing list

POP Software Updates

  1. I want to make a new CESM 2.0 release tag with updated documentation and fix to support python3, but waiting to figure out sphinx theme issue
  2. After making one more CESM 2.0 release tag, we can start focusing on CESM 2.1
  3. Keith: best way forward with global sums / open-ocean sums

June 5, 2018

General discussion

  1. Strawman set of rules for coding standards
    • Will make a bunch of issue tickets once we nail down requirements
  2. Some existing tickets fall into bit-for-bit code clean-up, added to "CESM 2.1" column of MARBL 1.0.0 Release project
  3. Working on the auto-generated documentation of MARBL settings file (for CESM 2.0 web page)

MARBL Software Updates

  1. Public code, new organization
  2. Github pages forwards to Read the Docs!
    • Is a single cesm2.0 version enough? Or should we tag each version of MARBL that appears in a CESM 2.0.Z release?
    • Also walk through branch version before pushing

POP Software Updates

  1. Alper updated the trunk and release branch to get MARBL from our public repo
  2. Despite an email stating noon on June 6 as deadline for non-source code (documentation) updates, the release code was declared frozen (except for CIME bugfixes and possibly a CLM / DART bugfix) at June 4 CSEG meeting... so any changes now will end up in CESM 2.0.1
    • On plus side, documentation will end up live on webpage as soon as we push it to github

May 29, 2018

General discussion

  1. Gokhan and Mariana - plans for CESM 2.1
  2. Documentation as part of the CESM 2.0 release -- do we need to coordinate with Alice B to get the MARBL settings file documented along side component namelists?
  3. Update on MARBL repo shift

MARBL Software Updates

POP Software Updates

May 22, 2018

General discussion

  1. Things we need for the CESM 2.0 release
    • Migrate to public repo
      1. Inform users of the changes listed below! (email everyone? Should we start a marbl-dev mailing list?)
      2. Rename master branch as development. Also, create a stable branch from the marbl0.29.0 tag and make a new v1.0-beta01 tag at that point.
      3. Procedure for release notes? I don't think we want full release notes for every development tag we make, but we do need a way to track changes between development tags. Maybe we want to introduce a change log? It could be in the repository or just a separate wiki page. (After we have saved the info from existing release notes, I think we want to delete them and then add a single note for v1.0-beta01.
      4. Make NCAR/MARBL public (will lock existing private forks; what happens if we make forks public and then make NCAR/MARBL public?)
      5. Transfer NCAR/MARBL to marbl-ecosys (will maintain forks)
    • Well-defined workflow for adding new code to the repository
    • Well-defined tag name convention
    • Documentation
      • Make sure what exists on current documentation page is accurate
      • Make sure all critical features are documented
      • Host our sphinx documentation on Read The Docs
    • POP release tag that points to new repository

MARBL Software Updates

POP Software Updates

May 15, 2018

General discussion

  1. CESM workshop: a couple of questions
    • The BGCWG meeting is going to be focused on land, right? Ocean BGC talks are in the OMWG section?
    • OMWG and SEWG meet at same time, so I can't give two talks. Maybe one talk and one poster? (I was thinking OMWG poster with instructions on modifying BGC diagnostic output would be a good reference to for people to look back on.) Another option would be to give an OMWG talk and nothing at SEWG.
  2. We still need a plan for releases, which means deciding on public / private development. If we go public development, what if "master" branch is named vetted-science (default when you clone the repository) and then development is the main branch for development?
    • Releases would all be on vetted-science, while beta tags would point to development
    • We could create release branches as needed -- initially CESM 2.0 would point to the cesm2.0-v1.0.beta01 tag of vetted-science, but the cesm2.0-rel branch can be made in the future if we need cesm2.0-v1.0.beta01-patch01 down the line.

MARBL Software Updates

  1. marbl0.29.0: add calcToFloor diagnostic
  2. I missed getting #109 (CISO scale factor) into CESM 2. Known issue? Ask Mariana / Gokhan about updating in a release tag?

POP Software Updates

  1. cesm_pop_2_1_20180514: bring latest MARBL developments onto the trunk 
    -- fix bug where initializing base tracers and ciso tracers from different restart files breaks running means
-- Add new MARBL diagnostic (calcToFloor)
-- build-namelist only calls xmlchange for CPL_I2O_PER_CAT if value doesn't match what is in env_build.xml
-- New riverine forcing files for gx3v7 (to go with new maps)
-- Better PE layout on hobart (gx3v7 uses 24 cores, which is only half a node)
-- Add hobart_nag test to prealpha
-- Add gx1v7 test to aux_pop_MARBL on hobart
  2. marbl_dev_n93: identical to above trunk tag

May 8, 2018

General discussion

  1. At CSEG meeting on April 30, Mariana talked about possibility of CESM adopting entirely-open development... she's joining us to talk about implication this has to MARBL's proposed development process
  2. Documentation
    • Keith pointed out that current use of github pages doesn't provide an easy mechanism for publishing multiple versions of documentation at once (we need a page for MARBL in CESM 2.0, MARBL in CESM 2.1, MARBL v1.0.0, etc)
    • I talked to Bill Sacks:
      1. CTSM is relying on many subdirectories in a single master branch of github pages repository
      2. Read the Docs should do what we want
      3. CTSM is not using RtD because of limitation in build time (CTSM tech note takes ~1 hr to build and that's right around the RtD limit)

MARBL Software Updates

POP Software Updates

  1. Upcoming POP trunk tag (still need riverine files)
FINAL MARBL UPDATES FOR CESM 2 CODE FREEZE

Definitely going in:
-- fix bug where initializing base tracers and ciso tracers from different restart files breaks running means
-- Add new MARBL diagnostic (calcToFloor)
-- build-namelist only calls xmlchange for CPL_I2O_PER_CAT if value doesn't match what is in env_build.xml
-- New riverine forcing files for gx3v7 (to go with new maps)

May 2, 2018

General discussion

MARBL Software Updates

  1. marbl0.28.9
    • Make the threshold when caco3_bury_thres_opt = 'omega_calc' tunable
    • Raise Jint_Ctot_thres_molpm2pyr from 1e-10 to 1e-9
  2. marbl0.28.10: introduce DOP_loss_P_bal to account for lost P when POP%prod is negative (since setting POP%prod = 0 without accounting for it elsewhere violates mass balance)

POP Software Updates

  1. marbl_dev_n86: bump MARBL to 0.28.9, clean up build-namelist
  2. marbl_dev_n87: bump MARBL up to 0.28.10 (negative POP%prod pulls from DOP)
  3. cesm_pop_2_1_20180427: merge marbl_dev_n87 onto trunk 
    PENULTIMATE MARBL UPDATE BEFORE CESM 2 CODE FREEZE

bit-for-bit changes
-- clean up CISO zooplankton diagnostics (better names & they are not per-zoo diags)
-- add reference to CISO paper in marbl_ciso_mod
-- only apply NHx surface emissions if lapply_nhx_surface_emis is true
-- add biomass-weighted average of limitation factors to diagnostic output
-- instead of full 3D diagnostic field for limitation factors, just return surface value
-- include grazing of zooplankton terms in ciso dtracer computations
   (requires new CESM test in POP's cime_config/)
-- Clean up interface to marbl_ciso (reduce duplicate computations in set_interior)
-- Threshold when caco3_bury_thres_opt = 'omega_calc' now tunable
-- Increase default value for Jint_Ctot_thres_molpm2pyr

potential answer change
-- Fix computation of POP production term: POP%prod(k) should be non-negative, but negative values were
   not being properly handled. Also, when setting negative values to zero, need to take phosphate from
   DOP otherwise mass balance (conservation) checks fail. POP%prod only goes negative in some tests,
   though, and it is hard to know ahead of time which tests will pass or fail.
  4. [not made yet] New trunk tag 
    FINAL MARBL UPDATES FOR CESM 2 CODE FREEZE

Definitely going in:
-- fix bug where initializing base tracers and ciso tracers from different restart files breaks running means

Wishlist (we probably won't have these done by May 11 in which case we'll wait till after release):
-- poc_remin sometimes has a very small magnitude negative value
-- loops should run to kmt, not km

April 24, 2018

General discussion

  1. CESM release update
  2. CMIP6 release
    • Do we need new column headers on the project page to sort the post-CESM2 column into "CMIP6" and "post-CMIP6"? Group input on prioritizing these would be nice
  3. Keith's fun with CESM testing (non-reproducible test failures)
  4. Proposed [strawman] MARBL versioning scheme detailed in google doc, but basics are vX.Y.Z with
    • X for science version (Science driving major version number seems to be no-brainer)
    • Y for API version [resets to 0 with new science] (I want this to make it easy to know if bringing in new version will require updates to the GCM driver)
    • Z for everything else: bugfixes, software enhancements that maintain API, etc (It doesn't seem worth the extra digits to differentiate between these types of changes)

MARBL Software Updates

  1. marbl0.28.8 -- PRs #262 and #263 address issues #240, #241, and #243
    • Fix typo in floor for POP%prod (Fixing this bug uncovered a mass-balance issue in Jint_Ptot: need to account for increase production somehow!)
    • Include zooplankton being grazed in ciso tracer tendency computation
    • Clean up interface to ciso_set_interior_forcing() (significantly reduce size of share types / number of memory copies, sum over all zooplankton before packing zooplankton_share_type, pass tracer_local instead of recomputing in marbl_ciso_mod.F90, etc)

POP Software Updates

  1. marbl_dev_n85 -- bring in latest trunk (April 19)

April 17, 2018

General discussion

  1. More discussion on MARBL in CESM 2.0

    • CESM 2.0 will be released through ESCOMP, with recommendation depending on the final tag name but probably being something like
    $ git clone --branch cesm2_0_0 [email protected]:ESCOMP/cesm.git
    • MARBL can stay in private repository for development, but we will need a release branch in a public repository [so I'm now leaning towards making a new cesm2_0 branch of NCAR/MARBL that is mirrored in MARBL-ecosys/MARBL] and this branch would be tagged cesm2_0_n00, used for CESM 2.0.0, 2.0.1, etc. cesm2_1 would be a new branch.

MARBL Software Updates

POP Software Updates

April 10, 2018

General discussion

  1. CESM 2.0 freeze update (email from Mariana)

    Science freeze: now

    What does science freeze mean? Only bit-for-bit changes for pre-industrial and historical simulations unless getting high-level approval from Gokhan and co-chairs. Bug fixes and tunings can be made with high-level approval.

    Code freeze: May 11.

    What does code freeze mean? No changes to code other than what's needed to get failing tests passing. Not allowed to make other bug fixes at this point – i.e., not allowed to fix a bug unless it's needed to get a failing test (from the release testing) passing.

    Freeze for tuning parameters: We'd like this to also be May 11. Is that realistic?

    • Given the above, I think our goal for MARBL is "only accept PRs that will go into CESM 2.0 between now and the release"; this will (hopefully) let us use a commit on master in the release and we won't need to make a release branch until the first bug is found (at which point we will hopefully have worked out details of public MARBL git repository)

    • Keith had already emailed Gokhan and gotten "high-level approval" for

      The answer-changing aspects of these mods is to update some BGC forcings, update values of tuning parameters (with some associated code mods), and correct a bug with respect to the temperature dependence of BGC processes.

    • I plan on getting the following onto the POP trunk before the freeze:

      -- clean up CISO zooplankton diagnostics (they are not per-zoo diags)

      —only apply NHx surface emissions if lapply_nhx_surface_emis is true

      -- add reference to CISO paper in marbl_ciso_mod

      —include grazing of zooplankton terms in ciso dtracer computations (requires new CESM test in POP's cime_config/)

      -- Fix computation of POP production term

    • After last week's meeting, I put together a google doc with some thoughts on making MARBL public and what the workflow would look like

  2. Future discussion: strategy for merging, searching through history, etc. I had been leaning towards git rebase instead of git merge, but Bill S has talked me out of it. More thoughts on active wiki page.

MARBL Software Updates

  1. marbl0.28.5: new tunings from Keith M
  2. marbl0.28.6: Three "quick fix" tickets
  3. marbl0.28.7: Update limitation diags (and adjust units on other diags)

POP Software Updates

  1. marbl_dev_n81: fe_bioavail fix (uses marbl0.28.5)
  2. marbl_dev_n82: merge pop trunk onto marbl_dev (uses marbl0.28.5)
  3. cesm_pop_2_1_20180406: merge marbl_dev_n82 onto the trunk (uses marbl0.28.5)
  4. marbl_dev_n83: merge pop trunk onto marbl_dev (akin to starting a new branch, uses marbl0.28.5)
  5. marbl_dev_n84: Update per-tracer diagnostics to account for a fix in marbl0.28.6 (zoo1[34]C -> zoo1[34]Ctot), and update DO1[34]C -> DO1[34]Ctot as well (overlooked in marbl0.28.0). Also, fix units of U10_SQR, which trunk has as cm^2/^s instead of cm^2/s^2 (uses marbl0.28.7)

April 3, 2018

General discussion

  1. Email from Jim E: looks like we are rapidly approaching CESM 2 code freeze, need to talk about plan forward.
    • I'd really like to get the quick fix issues closed before bringing marbl_dev onto the trunk
    • Keith to-do list?
    • Note: POP trunk is using marbl0.22.0, which was made Dec 1st (16 versions behind master)
  2. For CESM 2.0, do we want to use release_tag/ in subversion mirror of development repository or should we make whatever release ends up in CESM publicly available via github?
    • Pro git: easier to manage, especially if we need to address bugs in MARBL after master has moved beyond release version
    • Pro subversion: manage_externals doesn't currently support switching protocols in an existing sandbox, and discussion on expected behavior has stalled

MARBL Software Updates

  1. marbl0.28.2: add FESEDFLUX to diagnostic output, update units of requested forcing fields
  2. marbl0.28.3 / marbl0.28.4: update more forcing field units, also fix bug from adding FESEDFLUX

POP Software Updates

  1. marbl_dev_n80: box atmosphere trace gas model; uses marbl0.28.4

No Meeting

  • March 27, 2018 (spring break for local school district, lots of folks taking vacation)

March 20, 2018

General discussion

  1. No meeting next week (BVSD spring break, most folks out of town)
  2. CESM Workshop registration -- should I plan anything for the summer meeting?
    • SEWG talk?
    • OMWG talk?
    • Tutorial?
  3. Now that we are in git, should we separate some of the software engineering infrastructure and use a git subtree?
    • Singletrack folks would like to share our logging datatype (and expand on it, probably in ways that we can take advantage of e.g. warnings that get traced, __LINE__)
    • Some of our simple math routines (linear regression, etc)
  4. Prioritizing issue tickets with no milestone defined

MARBL Software Updates

  1. marbl0.28.1: mass balance checks and full depth column integrals rather than full depth and 100m integrals

POP Software Updates

March 13, 2018

General discussion

MARBL Software Updates

  1. marbl0.27.0: better Carbon diagnostics (vertical integrals of fluxes added, full 3D fields no longer output by default; still available for testing / debugging)
  2. marbl0.28.0: use DOC + DOCr as input to ciso module, rather than just DOC.
  3. I'm tracing flux units through the code, which seems like a necessary detour on the way to producing forcing data for stand-alone test of set_{surface,interior}_forcing()

POP Software Updates

  1. marbl_dev_n78: latest from Keith (better Carbon diags and improvements to PHYS CYCLE compsets)
  2. marbl_dev_n79: actual latest from Keith (better initial condition files; recognize that MARBL tracers are now named DO{13,14}Ctot when initializing.

March 6, 2018

General discussion

  1. Target MARBL v1 release date? September-ish, maybe?
  2. Follow-up with remote-atom and multiple users: version of ssh on hobart and cheyenne are both too old to support forwarding sockets (and I couldn't get it to work on goldhill, which has a more recent ssh version). Stuck claiming ports, I guess?

MARBL Software Updates

  1. Jupyter notebook for init / forcing data in single-column regression tests

POP Software Updates

March 1, 2018

(meeting on Thursday rather than Tuesday due to scheduling conflicts)

General discussion

MARBL Software Updates

  1. Prioritizing Jessica's new issues:
    • #231: there are a few hard-coded parameters that she would like to set via the input file.
    • #236: zooplankton-specific diagnostics.
    • No issue yet, but possibly have multiple implicit POC? (Make POC allocatable array in marbl_share_particulate_type, length would come from input settings file via new variable POC_cnt or something)
  2. Proposed implementation of new stand-alone test for set_surface_forcing() and set_interior_forcing():
    • Generate netCDF files that contain single column of forcing data, tracer init data (and column domain data); keep in new repository in marbl-ecosys github organization. (Tags used to ensure right version of file is pulled if we add tracers.)
    • Stand-alone namelist will have num_inst (integer) and forcing_data_files (array of strings)
    • Question: what output do we want? Definitely STF and tendencies, but need anything else?

POP Software Updates

February 20, 2018

General discussion

MARBL Software Updates

  1. marbl0.24.4: fix #224 (bug Jessica found in mass balance terms)
  2. marbl0.25.0: MARBL provides scripts to tell GCM what diagnostics are available prior to running the model
  3. Pending PRs
    • #209: python cleanup (case-insensitive matching from settings input file, better Fortran logical matching, and python v3 compatibility)... raises some issues on how to best test, and I'm not sure who to review this code with.
    • #229: lots of small fixes

POP Software Updates

  1. marbl_dev_n73: merge POP trunk from Feb 5 [meant for use in sandbox using cesm2_0_beta09 or later]
  2. marbl_dev_n74: use marbl0.24.4 (bugfix for mass balance terms)
  3. marbl_dev_n75: MARBL provides buildnml, build-namelist, and ocn.ecosys.tavg.csh with diagnostic information to be converted to tavg_contents
  4. One more tag coming to address #202: remove marbl_in_line_cnt parameter and broadcast marbl_in line by line

No Meeting

  • February 13, 2018 (Ocean Sciences conference)

February 6, 2018

General discussion

  1. Hartmut Frenzel (U. of Washington) visit to discuss ROMS / MARBL interface: looks like week of Feb 26 - Mar 2
  2. Have started review process before merging updated diagnostics code to master and marbl_dev, would like to walk through python scripts and make sure comments / documentation are clear and the code is easy to understand.

MARBL Software Updates

  1. PR #225: bug in conservation of budget terms that Jessica found; I haven't run test suite with it in place yet, but I will once development on the diagnostics branch is complete (I'd like this to come to master before the diagnostics, but I don't want to interrupt my work to set up the correct sandbox for testing)

POP Software Updates

  1. cesm2_0_beta08 was made over the weekend, so testing for alpha09a (using manage_externals) should begin soon.
    • Once beta09 is made, I'll bring the latest POP trunk onto marbl_dev and we can start moving our sandboxes to the new manage_externals-based CESM tags.

January 30, 2018

General discussion

MARBL Software Updates

  1. A few pull requests:
    • #225: bug fix for conservation issues Jessica found in her runs [I'd like to test these and get them onto master soon]
    • #227: Diagnostics in YAML for easier scripting / inclusion in GCM scripts [POP side isn't ready yet]
    • [from December] #209: I think we want to support both python 2[.7] and 3[.x], but the majority of development was done in 2.7-specific ways. In December I created a branch, tried to run a handful of MARBL_tools/ scripts with Python3, and then fixed issues as they came up. After merging #227 (see above), I should update this branch and make sure all the scripts still run as-expected. Note that I haven't touched the testing scripts at all, but they should probably be updated as well. This is a fairly low priority, in my opinion.
  2. Update on POP interaction with diagnostics: what if POP had an equivalent of marbl_diagnostics? (No more than) three step process for users to change ecosystem diags:
    • ocn.ecosys.tavg.csh would still contain changes to tavg_nml (e.g. if you want daily output instead of monthly)
    • Copy Buildconf/popconf/marbl_diagnostics to SourceMods/src.pop/ and edit to change what MARBL diagnostics appear in history files
    • Copy Buildconf/popconf/pop_ecosys_diagnostics to SourceMods/src.pop/ and edit to change what POP-driven ecosystem diagnostics appear in history files (e.g. J_{tracer} or {tracer}_RIV_FLUX)
    • Benefit: marbl_diagnostics and pop_ecosys_diagnostics would be in the same format
    • Do the files even need to be separated? Could we combine POP and MARBL diags into a single file that a user could edit?

POP Software Updates

  1. Still to do on marbl_dev_levy: clean up python scripts that interact with MARBL scripts

January 23, 2018

General discussion

  1. PGI update from CSEG -- CSEG will nominally support specific versions of PGI (e.g. 17.4 & 17.5), and components can advise users on whether other versions work as well.

Mike: Marbl wouldn't build with pgi 16. It worked with 17.4. He just tried 17.10 (the latest free version), and it built but died with a memory error.

Jim: E3SM will need pgi for gpu stuff.

Mariana: Gut feeling is that it would be good to support pgi... but don't want to spend a lot of time on this. A compromise could be that we say that certain configurations are supported with pgi.

Jim: What does it mean to say that we support pgi, given that only select versions work?

cheyenne now has pgi. cime has been ported to it. We'll add some cesm tests with cheyenne_pgi Rather than saying something like, "We support pgi": We can say that we regularly test with pgi 17.4 and 17.5 (for example).

Tony: are most pgi problems related to Fortran 2003? Mike: some of each, it seems.

MARBL Software Updates

  1. Lots of new releases:
    • marbl0.24.0 uses in situ temperature rather than potential temperature (fixes #217)
    • marbl0.24.1 catches a few more potential division-by-0 issues in marbl_ciso_mod.F90 (fixes #222)
    • marbl0.24.2 fixes a bug in computing POP bury coeff (fixes #207)
    • marbl0.24.3 changes kinetic fraction during gas transfer to value specified for CMIP6 (fixes #216)
  2. More discussion on moving moving diagnostics into YAML / python framework
    • Each tracer has associated [tracer]_RESTORE_TEND diagnostic. By default, we want GCMs to output with medium frequency this diagnostic for all tracers listed in the tracer_restore_vars(:) setting in marbl_in. I'm having trouble figuring out how to split this logic between YAML and python. (In talking to Keith before this meeting, it's pretty clear that I should start by walking through the python code and giving a better overview on how MARBL provides the GCM with these recommended diagnostic settings... which will almost certainly uncover some python code that needs to be cleaned up.)

POP Software Updates

  1. Not as many tags:
    • marbl_dev_n71: adds 'lat_bands' option to initializing d14C and also uses in situ temp rather than potential temp
    • marbl_dev_n72: uses marbl0.24.3 instead of 0.24.0

January 16, 2018

General discussion

MARBL Software Updates

  1. Fixed restoring bug in marbl0.23.0
  2. Some issue tickets aren't linked to a milestone yet, can we sort into "CESM2", "MARBL 1.0.0 after CESM2", or "after MARBL 1.0.0"?
  3. I think MARBL's python scripts should return full list of tracers to GCM set-up scripts rather than just NT
    • downside: adds to list of things duplicated between config scripts and Fortran [eventually use to autogenerate Fortran]
    • immediate upside: better inclusion of tracer-specific diagnostics (both in MARBL and in the GCM)
  4. More PGI issues: on a whim, I installed the latest free version (17.10) and it has a weird memory issue that prevents MARBL from running. I have no plans to try to develop a work-around, but think two things should be done:
    • Inform CSEG that only 17.4 and 17.5 have been verified to work with MARBL
    • Email the guy at PGI who got the previous issues fixed -- I can point him to a branch that highlights problem

POP Software Updates

  1. marbl_dev_n70 uses latest MARBL and also restores ALK_ALT_CO2

January 9, 2018

General discussion

MARBL Software Updates

  1. Keith found a bug in how we apply tracer restoring; I have put together a fix, but one question remains about when to apply restoring
    • Should we get this onto the trunk in cesm2_0_beta08 or can it wait until cesm2_0_beta10? (Should this be added to Cecile's run before or after getting onto the trunk?)

POP Software Updates

  1. Following on last week's discussion, the latest POP trunk tag pulls in the full CVMix repository rather than just src/shared/

January 2, 2018

General discussion

  1. New CESM tool to manage externals: rather than svn:externals, a new git repo (ESCOMP/cesm) uses a home grown tool NCAR/manage_externals) to pull in components with git or subversion
    • CSEG has asked us to use this tool for POP checkouts as well, because the svn hooks on github occasionally cause problems with checkouts (not with CVMix that we know of, but CLM devs have had trouble getting externals from time to time)
    • This is obviously a change in our development workflow, but has the potential to make it easier to track changes in our testing sandboxes [for example, I can manage my various CESM setups in my fork of ESCOMP/cesm -- it's like my own personal set of CESM exp_tags]

MARBL Software Updates

POP Software Updates

  1. Jim Edwards will be making minor changes to how buildnml ensures MARBL_NT matches the value used when POP was built [CIME is changing the generic XML interface that I used to get this value]
  1. Design Document
  2. How to Submit Code Modifications
  3. Dev meeting agenda / rough notes
  4. Processes Still Being Developed
Clone this wiki locally