Skip to content

2017 MARBL Dev team meetings

Jump to bottom
Michael Levy edited this page Oct 24, 2017 · 88 revisions

October 24, 2017

General discussion

MARBL Software Updates

  1. YAML vs XML

  2. Grazing as part of zooplankton_type?

    *. I haven't looked at the code in detail, but I don't really like the (max_grazing_prey_cnt, zooplankton_cnt) indices. (Jessica is currently trying to run with 4 zooplankton classes, 1 of which grazes on 5 PFTs but the others graze on 2, 3, or 4)

POP Software Updates

  1. New marbl_dev tag: marbl_dev_n60. Moved iron_frac_in_dust and iron_frac_in_bc from MARBL to POP.
  2. Jessica uncovered a bug and something that we probably need to improve
    • Issue 202: unexpected behavior if marbl_in has more than 512 lines
    • Should we add some namelist capability to setting tracer fallback values? She wants to easily test several different options for different PFT classes, and currently needs to rebuild just to make sure she is initializing tracers correctly

October 17, 2017

General discussion

MARBL Software Updates

  1. Still working on generating the input file
    • I think the python tool can now read an input file of its own
    • Some support for elements of a derived type depending on other elements (e.g. size of grazing%auto_ind(:) is grazing%auto_ind_cnt) but I need to generalize it in a better manner
    • Working on design document -- this was a little backwards, as I wrote the design document after coming up with an initial design, but I hope it helps clean up the python code now that I have a better sense of what the YAML needs to contain

POP Software Updates

  1. New marbl_dev tag: marbl_dev_n59. This brought in the latest POP trunk tag (from Oct 8), compatible with cesm2_0_beta07; C compsets are bit-for-bit with tests from marbl_dev_n58 and cesm2_0_alpha07b but updates to CICE mean that G compsets change answers.
  2. When should I make a new trunk tag? I'm thinking once we are happy with the input file generation tool. Two changes since last merge with the trunk (oldest at top): 
    Tag Summary: Merge latest marbl_dev_levy (n119) into marbl_dev

             This brings MARBL up to 0.20.0 (this version of MARBL improves
             the initialization process in MARBL)

Tag Summary: Merge latest marbl_dev_levy (n121) into marbl_dev

             This adds more MARBL variables to marbl_in (only via user_nl_pop,
             there are no new default values for them)

October 10, 2017

General discussion

MARBL Software Updates

  1. Getting closer to YAML / python combo for generating namelist
    • Have included derived types for autotrophs and zooplankton, but not grazing (yet)
    • Updated how arrays are initialized (using YAML's array notation rather than parsing a string with commas)
  2. Problems that still need solving
    • Need to know tracer count because that is dimension of tracer_restore_vars(:)
    • autotrophs_type and zooplankton_type both contain members that should NOT be set by user (for example, user sets autotrophs%alphaPI_per_day and then the Fortran code converts it to cgs units and stores it in autotrophs%alphaPI)
    • grazing_type contains two components that are allocatable arrays

POP Software Updates

October 3, 2017

General discussion

  1. Follow-up from discussion on how to use YAML to generate input file
    • Support for arrays (sort of)
    • Support for multiple defaults (resolution dependent, for example)

MARBL Software Updates

POP Software Updates

  1. Best approach for some refactoring Keith is doing
    • abio and ciso can both read d14c forcing from file (or set to constant); we want to ensure consistency between the two modules with both are active
    • abio and ecosys have same issue, but with atmospheric CO2. And do we want to force consistency or is it okay if, for example, ecosys gets value from coupler but abio reads from a file?

No Meeting

  • September 26 (canceled due to travel)

September 22, 2017

This is a special meeting to discuss the possibility of MARBL providing a tool to generate its own namelist in CESM rather than having it handled by POP's build-namelist script. The same tool would also provide ECOSYS_BASE_NT and CISO_NT to buildcpp rather than relying on the user to update OCN_TRACER_MODULES_OPT.

One possibility would be to use MARBL's stand-alone driver for this task. That would require building the Fortran tool before any other building is done in CESM [*]; one possible workflow would be:

  1. Will introduce a new python script in $POPROOT/cime_config/ that
    1. creates a place to build the MARBL driver ($CASEROOT/Tools/marbl_drv/ or $EXEROOT/ocn/marbl_drv?) if it doesn’t exist
    2. copies $POPROOT/source/marbl/{*.F90,makedep.py} and marbl driver F90 files to new directory
    3. replaces anything in new directory with version from SourceMods/src.pop/ (if applicable)
    4. Builds executable (will require yet another Makefile, should probably live in POP repo)
  2. buildcpp would run the get_tracer_cnt test
    1. requires tracer_cnt.nml in $POPROOT/marbl_tools
    2. uses user_nl_marbl as input file
  3. buildnml would run the gen_inputfile test
    1. requires gen_inputfile.nml in $POPROOT/marbl_tools
    2. uses user_nl_marbl as inputfile

[Minor] issues I've stumbled upon in first ten minutes of playing with the above proposal:

  1. CIME only copies user_nl_pop from $POPROOT/cime_config/
    • Solution: will need new CIME tag to copy user_nl_marbl as well
  2. POP needs $MARBL/tests/driver_src/ as an external
    • Solution: $POPROOT/marbl_tools/Makefile is in POP repo and $POPROOT/marbl_tools/driver comes from externals

I'm starting to play with this on hobart, and can maybe show some examples.

[*]

Buildtimes:

15s locally with gnu ; 25s locally with pgi ; 40s on hobart with nag ; 60s on cheyenne with intel

Sept 19, 2017

General discussion

  1. Visit from UCI folks led to generic MARBL interface project
    • Fortran interface module that links to full MARBL library, can be used from Matlab or Python
    • Still need to figure out best way to distribute / test it
  2. Build namelist

MARBL Software Updates

  1. MARBL 0.20.0: made MARBL more runtime-configurable, closed ~5 issue tickets
    • no more namelist, MARBL uses "input files" that it parses line by line instead
    • single init phase
    • PFT counts are all set via input file instead of namelist
    • PFT_defaults = 'CESM2' gives default PFTs, PFT_defaults = 'user-specified' requires user to set all PFT-related parameters via input file
    • merged autotroph_config_type and autotroph_parms_type back into autotroph_type (similar for zooplankton_type and grazing_type)

POP Software Updates

  1. marbl_dev_n57: updates required to move from MARBL 0.19.2 to 0.20.0
  2. marbl_dev_n58: added more autotroph_type objects to namelist_definitions_pop.xml to allow CESM users to use PFT_defaults = 'user-specified'

No Meetings

  • September 12 (canceled due to travel)
  • September 5 (canceled due to travel)

August 29, 2017

General discussion

MARBL Software Updates

  1. Status update for #189
    • Reworked initialization of PFTs -- default is still the same, but defaults when you change autotroph_cnt, zooplankton_cnt, and / or grazer_prey_cnt are coded differently (for one thing, no longer dependent on sname)
    • Created gen_inputfile test; Fortran-based way to produce input files

POP Software Updates

No Meeting

  • August 22 (canceled in favor of code review for #189)

August 15, 2017

General discussion

  1. Catch up on CESM 2.0 timeline
  2. POP initial condition question: gx1v6 and gx1v7 use ecosys_jan_IC_gx1v6_20150108.nc but ecosys_jan_IC_gx1v6_20161123.nc is in the repo and contains diatP, diazP, spP, and Lig (plus Fe is different). Should we switch, or is this an intermediate file with plans to introduce a new version before the 2.0 release?

MARBL Software Updates

  1. Update on #189
    • No more namelist!
    • No more build-time configuration!
    • Still need to clean up the code, but functionality is where we want it
    • Show documentation updates (still on branch)
  2. Merge Keith science changes before 189?
    • Initialization is very different, will be easier for me to handle conflicts than Keith
    • My changes are bit-for-bit, which will make testing more manageable

POP Software Updates

No Meetings

  • August 8 (travel)
  • August 1 (travel)

July 25, 2017

General discussion

  1. Retooling the initialization stage of MARBL... we need to separate init into distinct phases to allow us to define parameters and determine tracer count in a consistent manner, but instead of requiring GCMs to use put() calls between phases, could we pre-stage all the put calls and then process them between phases? We could use a logical flag to track which put calls had been applied, and then error out with variable not found if any statements had NOT been applied.
  2. The above point may render this moot, but how should we name the individual init phases? We are currently using a semantic naming convention (config, init, complete_config_and_init) but it's not entirely clear what each of those phases means. It would be nice to just use init_phase1, init_phase2, etc... but that doesn't give users a clear indication of what is happening in each phase. Two points of confusion with the current scheme:
    • We tend to think of init as "setting parameters in the parameterization sense of the word" and config as "variables that may affect tracer count, and also other logical variables that aren't really part of a parameterization" but I am working on a "pre-config" phase that would determine PFT counts (and possibly be a good place for configuring sinking detritus types if we add that feature) and suddenly this semantic description doesn't seem useful
    • I'd like to come up with a good rule of thumb for answering "I am adding a new step to initialization, where does it go?" Two possible answers are "initialize it as soon as everything else it depends on is locked" or "initialize it in the phase prior to when it is needed by other features." I have put together a quick list of every process that occurs in initialization, including which phase it occurs in and any dependencies it has.
  3. Another possibility is to keep all the init_phase#() routines public, but also provide a blank namelist on the interface so that developers can start with a single init() call and whatever default parameter values MARBL provides to get up and running, and then switch to the multi-phase calls with put() statements in between if necessary.
  4. CESM Tutorial -- anything MARBL-specific? Should we work something into the POP exercises?

MARBL Software Updates

  1. Working on #189, trying to rely less on build-time configuration options (which spawned the two discussion points above). This PR will let us remove marbl_sizes.F90 altogether, which is a huge step forward.

POP Software Updates

No Meeting

  • July 18 (canceled due to travel)

July 12, 2017

General discussion

  1. New tracer module to add: abio gasses

MARBL Software Updates

  1. New tags
    • 0.19.0: namelist size runtime configurable, consistent diagnostic names for autotroph Si Uptake, molw_Fe used in marbl_mod.F90
    • 0.19.1 & 0.19.2: lots of code clean-up (no interface changes, no answer changes). Two highlights: better error message when CO2 solver does not converge; consistent use of CaCO3_form throughout the code
  2. Currently working on making PFT counts runtime configurable, need smart way to ensure consistency between POP build-time settings and MARBL run-time settings
    • Use put() statements to override whatever is in MARBL namelist?
    • Have namelist defaults depend on POP build-time settings? For example MARBL_OPT = CMIP6_SETUP and several variables can depend on MARBL_OPT (will then get ported to MARBL when it builds its own namelist)

POP Software Updates

  1. Merged marbl_dev (n52) onto trunk, so MARBL 0.19.2 will be available in cesm2_0_alpha07a.

No Meetings

  • July 4 (National holiday)
  • June 27 (canceled due to travel)
  • June 20 (CESM workshop)

June 13, 2017

General discussion

  1. Gloss over topics that we didn't really get to last week
  2. Testing question: should we switch from T62_g16 to T62_g17? Or test a combination of the two resolutions? See #179.
  3. Unsorted tickets in the MARBL 1.0.0 project

MARBL Software Updates

  1. Lots of small updates (without interface changes) coming in marbl0.18.1
  2. Is now the right time to have MARBL produce list of diagnostics that POP converts into tavg_contents?

POP Software Updates

  1. New marbl_dev tag because I removed gcm_num_interior_forcing_elements from the interface (hardcoded to 1 until we update the code)

June 6, 2017

General discussion

  1. Try using github projects for MARBL 1.0.0 milestone?
    • Also added project page for Post-MARBL 1.0.0 milestone to better visualize (maybe we want to change some tickets to MARBL 1.0.0?)
  2. Three tickets without a milestone: should we try to get any (or all) of these into MARBL 1.0.0?
    • I think 22 needs to be done before CESM 2.0 or not at all -- another major release with an inconsistent tavg variable name will make it harder to correct afterwards

MARBL Software Updates

  1. 168 -- apparently PGI 17.4 is somewhat buggy, because for some reason a string being set wasn't always populated with the right value the first time it was accessed... but the workaround for it actually ties in to #167
  2. 169 -- easy way to use PGI compiler on local machines (--mach local-pgi); not urgent to accept, but useful for testing since PGI 17.4 is free and fixed previous PGI bugs that prevented MARBL from building / running (though, as noted above, it's still not perfect)
  3. 170 -- drop gcm_num_elements_interior_forcing from interface (has a related POP update)
  4. 171 -- found some bad use whitespace when examining log files
  5. 172 -- split thermodynamic_coefficients_type to separate species concentrations from actual coefficients.

POP Software Updates

  1. MARBL 0.17.1 is on the trunk (as part of marbl_dev_n46, which contains marbl_dev_klindsay_n73 and marbl_dev_levy_n91)
  2. Alper made a new trunk tag for Jim (cleaning up some XML info, no expected conflicts), so marbl_dev is a little behind

May 30th

General discussion

  1. Best tool for linking meeting agenda to github?
    • Using the github projects doesn't seem sustainable long-term
    • How about a wiki?
  2. Some discussion on MARBL 1.0.0 milestone
    • @mnlevy1981 will talk to @klindsay28 over coming weeks to prioritize open tickets
    • Will see where we are when CESM 2.0 is frozen

MARBL Software Updates

There are currently four open pull requests, that will be merged in the following order:

  1. 165 -- bit-for-bit, no interface changes
  2. 166 -- bit-for-bit unless ladjust_bury_coeff = .true., no interface changes
  3. 164 -- round-off level answer changes, no interface changes
  4. 157 -- big answer changes (default parameter values changed); changes namelist as well so there is corresponding GCM tag to make

First three should be merged and tagged by the end of May (as MARBL version 0.16.1); last one will be merged later in the week

POP Software Updates

Two recent marbl_dev tags:

  1. marbl_dev_n43 -- changed default PE layouts for better out-of-the-box throughput (with and without ecosystem) on NCAR machines. See this google spreadsheet for timing details
  2. marbl_dev_n44 -- branch is up-to-date with the current trunk (May 16th, 2017 tag)

Upcoming marbl_dev tags:

  1. All changes between marbl_dev_klindsay_n58 and marbl_dev_klindsay_n71 have been reviewed / are ready to merge
  2. marbl_dev_klindsay_n72 needs to be reviewed
  3. marbl_dev_klindsay_n73 and beyond are in progress, should be merged when ready / reviewed
  1. Design Document
  2. How to Submit Code Modifications
  3. Dev meeting agenda / rough notes
  4. Processes Still Being Developed
Clone this wiki locally