search

ESCOMP / POP2-CESM

Parallel Ocean Program (POP2) in CESM
http://www.cesm.ucar.edu/models/cesm2/ocean/
4 stars 24 forks source link

Bgc updates for cesm2 2 #35

Closed mnlevy1981 closed 4 years ago

mnlevy1981 commented 4 years ago

Description of changes:

This branch will update BGC configurations for the CESM2.2 release

  1. OCN_BGC_CONFIG=with_cocco will use latest tunings with coccolithophores
  2. OCN_BGC_CONFIG=cesm2.1 will use same MARBL parameters as CESM 2.1 (though some bugfixes in POP will prevent bit-for-bit solutions when compared to CESM 2.1)
  3. Provide a newly-created init_ecosys_init_file for OCN_BGC_CONFIG=with_cocco
  4. Update fesedflux_input%filename
  5. Update version of MARBL being used to latest available (marbl0.39.0)
  6. Update ecosys_add_cocco to use latest tunings

  7. Add POP2%CESM21 compset option similar to POP2%CESM20 (but to get OCN_BGC_CONFIG=cesm2.1)

    • Create C1850ECO_ECOCESM21 compset and test it in aux_pop_MARBL

Testing:

Test case/suite: aux_pop on cheyenne (intel only), and aux_pop_MARBL on cheyenne (intel & gnu) and hobart (nag and pgi). cheyenne tests were compared against cesm_pop_2_1_20200709, hobart tests did not include baseline comparison Test status: compsets with ecosystem enabled were answer-changing (even ECOCESM20 changes answers due to round-off level changes in MARBL) and failed NLCOMP (again due to clean-up on the MARBL side); compsets without the ecosystem are bit-for-bit and pass NLCOMP

Fixes #32

User interface (namelist or namelist defaults) changes? None

mnlevy1981 commented 4 years ago

Opening this PR so I can keep track of what still needs to be done on this branch. I've done (1) - (4) already, and am going to point @kristenkrumhardt to this branch so she can finalize the MARBL tuning (necessary to address (5). I will work on (6) and (7) while waiting for the final MARBL parameters.

mnlevy1981 commented 4 years ago

I noticed that (6) means there is no longer a test for cesm2.1+cocco; one thought is to add some logic to shell_commands in the ecosys_add_cocco test, but I'm not exactly sure what we want the logic to be:

Some options for the last case:

The only other options would be cesm2.0, which doesn't have an equivalent parameter set with tunings, or SPECTRA1.0, which isn't accessible via compset right now

mnlevy1981 commented 4 years ago

I noticed that (6) means there is no longer a test for cesm2.1+cocco; one thought is to add some logic to shell_commands in the ecosys_add_cocco test, but I'm not exactly sure what we want the logic to be:

* If `OCN_BGC_CONFIG=latest`, change to `with_cocco`

* If `OCN_BGC_CONFIG=cesm2.1`, change to `cesm2.1+cocco`

* If `OCN_BGC_CONFIG=with_cocco` or `OCN_BGC_CONFIG=cesm2.1+cocco` leave unchanged

* Otherwise ???

Some options for the last case:

* use `with_cocco`

* leave unchanged

* throw an error

The only other options would be cesm2.0, which doesn't have an equivalent parameter set with tunings, or SPECTRA1.0, which isn't accessible via compset right now

89bd6d8 implements the "leave unchanged" option cesm2.0 and SPECTRA1.0.

All that remains:

  1. Update to latest MARBL tag (following multiple MARBL PRs)
  2. potentially set up ecosys_add_cocco test to throw an error if run with the C1850ECO_ECOCESM20 compset
mnlevy1981 commented 4 years ago

362f819 prevents ecosys_add_cocco testmods from being applied to compsets where OCN_BGC_CONFIG does not have an equivalent with coccolithophores. The error is reported as

ERROR: OCN_BGC_CONFIG=${ocn_bgc_config} does not have equivalent option with coccolithophores

create_test notes the failure:

Finished CREATE_NEWCASE for test SMS.T62_g37.C1850ECO_ECOCESM20.cheyenne_gnu.pop-ecosys_add_cocco in 1.629356 seconds (FAIL). [COMPLETED 1 of 3]
    Case dir: /glade/scratch/mlevy/tests/new_BGC_stuff.004/SMS.T62_g37.C1850ECO_ECOCESM20.cheyenne_gnu.pop-ecosys_add_cocco.20200619_144548_dgjc83
    Errors were:
        Leaving broken case dir /glade/scratch/mlevy/tests/new_BGC_stuff.004/SMS.T62_g37.C1850ECO_ECOCESM20.cheyenne_gnu.pop-ecosys_add_cocco.20200619_144548_dgjc83
        ERROR: Command: '/glade/scratch/mlevy/tests/new_BGC_stuff.004/SMS.T62_g37.C1850ECO_ECOCESM20.cheyenne_gnu.pop-ecosys_add_cocco.20200619_144548_dgjc83/shell_commands' failed with error 'ERROR: OCN_BGC_CONFIG=cesm2.0 does not have equivalent option with coccolithophores' from dir '/glade/scratch/mlevy/tests/new_BGC_stuff.004/SMS.T62_g37.C1850ECO_ECOCESM20.cheyenne_gnu.pop-ecosys_add_cocco.20200619_144548_dgjc83'

And TestStatus.log contains the same error message

RUN: /glade/scratch/mlevy/tests/new_BGC_stuff.004/SMS.T62_g37.C1850ECO_ECOCESM20.cheyenne_gnu.pop-ecosys_add_cocco.20200619_144548_dgjc83/shell_commands
FROM: /glade/scratch/mlevy/tests/new_BGC_stuff.004/SMS.T62_g37.C1850ECO_ECOCESM20.cheyenne_gnu.pop-ecosys_add_cocco.20200619_144548_dgjc83
  stat: 1

  output: ERROR: OCN_BGC_CONFIG=cesm2.0 does not have equivalent option with coccolithophores
Leaving broken case dir /glade/scratch/mlevy/tests/new_BGC_stuff.004/SMS.T62_g37.C1850ECO_ECOCESM20.cheyenne_gnu.pop-ecosys_add_cocco.20200619_144548_dgjc83
ERROR: Command: '/glade/scratch/mlevy/tests/new_BGC_stuff.004/SMS.T62_g37.C1850ECO_ECOCESM20.cheyenne_gnu.pop-ecosys_add_cocco.20200619_144548_dgjc83/shell_commands' failed with error 'ERROR: OCN_BGC_CONFIG=cesm2.0 does not have equivalent option with coccolithophores' from dir '/glade/scratch/mlevy/tests/new_BGC_stuff.004/SMS.T62_g37.C1850ECO_ECOCESM20.cheyenne_gnu.pop-ecosys_add_cocco.20200619_144548_dgjc83'

The TestStatus file is more concise:

$ cat TestStatus
FAIL SMS.T62_g37.C1850ECO_ECOCESM20.cheyenne_gnu.pop-ecosys_add_cocco CREATE_NEWCASE

I also verified that running this test with theC1850ECO compset still results in OCN_BGC_CONFIG=with_cocco and C1850ECO_ECOCESM21 results in OCN_BGC_CONFIG=cesm2.1+cocco.

mnlevy1981 commented 4 years ago

One more change that will be on this branch: we want kappa_isop_deep = 0.1 for more configurations. Currently the default is 0.1, except when the ocean is running on a gx1 grid in which case the default value is 0.2.

This is still being discussed on zulip but one possibility would setting the variable to 0.1 for gx1 grids using JRA forcing. One way to check is to have the default value depend on ocn_transient, which is JRA or JRA_OMIP when using JRA forcing.

mnlevy1981 commented 4 years ago

@klindsay28 and I reviewed this earlier this week, and aea3a89 addresses the concerns that came up from that review so I'm going to bring this in and tag it (and then start final testing for #34)