-
Notifications
You must be signed in to change notification settings - Fork 25
2019 MARBL Dev team meetings
- Kristen's PR (#330) to bring in explicit calcifiers:
- Up to date with
development
- Reviewed with Keith and Mike
- Mike made some updates to general infrastructure, now Kristen has some work to do (after OCB)
- Up to date with
- Updates needed to go with explicit calcifier work:
- Add a new test to the test suite
- Question: what's the best way to initialize data? Three options, ranked from Mike's most- to least-preferred
- Create a new initial data set that is just a copy of the current
init_ecosys_init_file
(for bothx1
andx3
grids) but also containingcocco
tracers (that are copies of thesp
tracer values), use it when running with Kristen's tracers - Same as above, but make it the default init file for running regardless of whether user wants cocco tracers or not
- Use
io_read_fallback
to initialize the cocco tracers, don't modify initial condition file at all
- Create a new initial data set that is just a copy of the current
- Updates on marbl-diags
- Worked on it at the early June hackathon
- Mike started work on the MOM driver
- Alper's fork of CESM now includes MARBL as an external
- The
buildlib
script in the MOM6 interface builds MARBL - Setting
USE_MARBL_TRACERS = True
runsmarbl_instances%init()
and registers the 32 resulting tracers- No initial conditions provided, so tracers are all set to 0
- Need a namelist flag somewhere to set
num_PAR_subcols
(current init sets value to 1) - Need to figure out how many active cells can be passed to
surface_flux_compute()
at a time (i.e. the MOM6 equivalent to the number of active cells on a POP block)
- June 18, 2019 (CESM Workshop)
- June 4, 2019 (Python hackathon at NCAR)
- May 21, 2019 (Mike out of town)
- Diagnostics: I have a notebook to compare JRA and CORE: a few time series of global means
- What variables would be useful to look at in this framework? (adding additional 2D fields is trivial, adding 3D fields will just require a vertical integral that I assume
esmlab
can do) - Should we generate these plots in marbl-diags?
- I converted Who's single cycle of the JRA-forced hindcast to time series in order to make these plots -- should I copy them from my scratch space into
/glade/p/cgd/oce/projects/JRA55/IAF
so they don't get scrubbed? It's roughly 1 TB of data.
- What variables would be useful to look at in this framework? (adding additional 2D fields is trivial, adding 3D fields will just require a vertical integral that I assume
- MOM driver as a priority ahead of A. Shao visit this summer?
-
Single column test progress
-
more robust build system (for turning on netCDF support if needed)
-
not sure of the best way to store input data, tempted to just keep it in the MARBL repo (current version is a 2-column file and 98 KB, so even adding 4 or 5 more columns is probably not a burden for git). Test currently fails on TravisCI due to lack of file to read:
(run_exe): Running following command: (run_exe): /home/travis/build/mnlevy1981/MARBL/tests/driver_exe/marbl.exe -n test.nml Beginning compute_cols test... MARBL ERROR (marbl_io_mod:netcdf_check): netCDF error: No such file or directory MARBL ERROR (marbl_io_mod:marbl_io_open): Error reported from nf90_open(marbl.nc) MARBL ERROR (marbl_compute_cols_drv:initalize): Error reported from marbl_io_open MARBL ERROR (marbl_compute_cols_drv:test): Error reported from initialize
-
-
Kristen is happy with her update to make her coccolithophore branch CESM 2.1 compatible (and that's been tagged), but we haven't found time to bring her up to date with the latest MARBL
development
: that's holding up #330 -
PGI latest community edition (i.e. free version) is available - PGI 19.4 includes macos mojave support (18.10, the last community edition, runs on macos 10.13 but not 10.14). No issues building out of the box with it.
- Keith and I talked about what moving POP to git means for MARBL development -- will abandon the idea of a
marbl_dev
branch and just push our changes directly tomaster
. This is in line with the typical git workflow, and I think MARBL is stable enough that we've outgrown the need formarbl_dev
anyway.
- April 23, 2019 (Mike home with a sick kid)
- Merged #328, which adds Arrhenius temperature scaling option and finer-grained grazing diagnostics (Jessica's SPECTRA code should run out-of-the-box now)
- Answer-changing on some compilers (including intel), so only available in CESM 2.2 or later (not in 2.1)
- Upcoming work:
-
cesm_pop_2_1_20190322 has changes necessary to run SPECTRA (larger max tavg count, different initial condition file when running SPECTRA)
-
Working on updates to both CESM 2.1 release branch and CESM 2.2 development to run with poorly-balanced PE layouts
- Run when
nblocks_clinic < max_blocks_clinic
on some tasks - Run in the special case of above when
nblocks_clinic = 0
on some tasks
Note that this issue affect the base POP code as well as the MARBL driver... so Keith fixed the base code and I'm getting the C1850ECO tests to pass
- Run when
- March 26, 2019 (everyone out of town for local school spring break)
- March 12, 2019 (goodbye party for J. Luo)
- Diagnostics
- Current work -- (a) & (b) done a few minutes ago, I'd like to review; (c) not yet started:
- Restructure YAML configuration files for better extensibility
- Update existing annual climatology plots
- Additional diagnostic plot options
- E.g. fields Keith looked at in comparing JRA & CORE: nitrogen fixation and other fields under the heading "Ecosystem: Maps" in CESM 1.3 BGC diags
- I talked with Alice, have a much better grasp on how
marbl-diags
will interact withCESM_postprocessing
. In the meantime,jinja2
inmarbl-diags
to generate stand-alone HTML?
- Current work -- (a) & (b) done a few minutes ago, I'd like to review; (c) not yet started:
- MARBL-adjacent projects
- Kristen is looking for a way to smooth SSH before computing some correlations, Matt asked me to investigate Loess filter as option. I found an existing python package, but have some concerns:
- I'm not sure I can shoehorn in global data (was thinking about applying filter region-by-region, using POP's region mask)
- It's an expensive method (filter weights at a grid point are based on distance to nearest neighbors)
- I need to read up a little more on the parameters controlling the filter (first attempt at filtering a global dataset didn't come out looking so great)
- Kristen is looking for a way to smooth SSH before computing some correlations, Matt asked me to investigate Loess filter as option. I found an existing python package, but have some concerns:
- New PR: #330 has Kristen's explicit calcifier updates to allow adding coccolithophores
- Also have open PRs for Jessica's size-resolved plankton model and a PGI compiler bugfix that is hard to test because PGI's latest community compiler doesn't run on the latest macOS (10.14 / Mojave)
- Single column testing update: mostly stalled as I focus on other work
- Decent notes should allow me to pick it back up again when I have the time
- I'd like to get the explicit calcifiers and size-resolved plankton settings onto
development
before coming back to the single-column tests (requires code review and more thorough CESM test suite; I think both PRs can be done in a bit-for-bit manner but that might require moving Fortran parameters into MARBL's input settings file)
- Stand-alone driver:
- Adding a regression test that calls
surface_flux_compute()
andinterior_tendency_compute()
is top priority- Planning on pulling initial conditions / forcing data from a single column of POP, as I am not aware of any applicable analytic test case
- up for debate: driver can read a netcdf file, or I can hard-code values in Fortran (downside to netcdf is the need to make it available for anyone running the test)
- I like the idea of hard-coding values from a shallow-ish (5 - 10 level?) column if no
- Will need to update documentation to refer back to this test
- This test will be a good launching point for a true stand-alone driver that includes time-stepping
- No need for that driver to be Fortran -- maybe take advantage of python ODE solvers?
- Another advantage to python-based driver: jupyter could incorporate a simple test case AND generate plots
- Adding a regression test that calls
- Diagnostics:
- Did a little more tweaking to plot generation, see PR #11
- Currently on back-burner waiting for Alice B to come back and answer some questions (I have local copy of text document, no need to get into details of what the questions are)
- When I come back to this, will work closely with Matt to ensure we're on the same page
- Update on marbl-diags and CESM_postprocessing:
- Working on a branch with a goal of recreating ecosys sections of CESM 1.3 diags
- First step: Ecosystem: Maps at Depth section, goal is plots similar to NO3 an 0m and Fe at 0m
- Second step: I don't think the current workflow in
marbl-diags
will play nicely with the wayCESM_postprocessing
parallelizes tasks, so it might be worth rethinking workflow. It shouldn't be too hard to introduce a new interface that lets us loop over variables to plot at the driver layer, which I think is the goal. - Still unclear of how to generate HTML (Alice B has been working remotely and I've been focusing on the plot generation, but pretty soon I'll be ready to make the web pages)
- Planning to compare to WOA 2013 -- I originally wanted to also include WOA2005 to make sure statistics are being computed correctly, but
/glade/p/cesm/bgcwg/obgc_diag/data/obs_data/WOA2005/WOA05_ann_avg_gx1v6.nc
doesn't match the min / max from the links above and I don't know if it's worthwhile to track down the dataset used in those original plots.
- DOIs: after setting up a DOI for Kristen, went ahead and got DOIs for MARBL in CESM 2.x releases:
- 2.0.0: doi:10.5281/zenodo.2541008
- 2.0.1: doi:10.5281/zenodo.2541009
- 2.1.0: doi:10.5281/zenodo.2541010
- Documentation: I think this should get bumped up in priority -- our github.io page is missing the CESM 2.1 documentation (and there have been several interface changes so some pages are out of date)
- January 1, 2019 (NCAR closed for New Year's Day)