Stream: ocean-bgc

Topic: tuning CESM2.2


view this post on Zulip Kristen Krumhardt (Jun 18 2020 at 18:45):

@Matt Long , @Keith Lindsay : Mike told me that the cesm 2.2 code freeze is now July 2. Mike and I are currently working on getting my latest cocco tunings (which I've tested with JRA forcing) into CESM2.2 cocco defaults settings.

I was wondering if we could meet sometime at the beginning of next week to discuss the 3PFT tuning I've done so far. I've got a couple of decent parameter sets. However, they are somewhat different with respect to certain metrics (e.g., total NPP, POC flux...) , so I'd like to get your opinions to find out which one is better and see if you have suggestions going forward with tuning (or if what I have is good enough).

view this post on Zulip Matt Long (Jun 18 2020 at 18:49):

Sounds good. I have a wrinkle to add, and I apologize for not thinking this thru this sooner:
The sedimentary iron forcing (fesedflux) dataset we're using in CESM2 has a legacy of ad hoc tweaks from our panicked tuning chasing oxygen biases in the coupled model. These biases are not present in the ocean ice configurations and I think we should be moving to an fesedflux dataset that is documented and reproducible. This will be important as we transition to MOM too.

So I have a new 1° dataset that I hope you can test out at 1°. Perhaps you can switch to this new forcing and run with your latest tunings?

I just changed a few things in my workflow and am creating an updated version of this data now.

view this post on Zulip Keith Lindsay (Jun 18 2020 at 18:51):

Sounds good. My google calendar is up to date, so feel free to schedule a meeting based on that.

view this post on Zulip Kristen Krumhardt (Jun 18 2020 at 18:52):

Ok, yes, I could re-run my latest tunings with the new sedimentary Fe forcing over the weekend.

view this post on Zulip Kristen Krumhardt (Jun 18 2020 at 18:53):

Sounds good. I will figure out a good time and try scheduling a meeting for next week.

view this post on Zulip Matt Long (Jun 18 2020 at 19:45):

Here is the fesedflux dataset:
/glade/work/mclong/cesm_inputdata/fesedflux_total_reduce_oxic_POP_gx1v7.c200618.nc

This puts about 14.2 Gmol Fe/yr into the ocean, whereas the CESM2 dataset is more like 20 Gmol/yr.

view this post on Zulip Matt Long (Jun 18 2020 at 19:46):

Generation documented here
https://github.com/marbl-ecosys/forcing-Fe-sedflux/blob/master/notebooks/output/POP_gx1v7/Fe_sediment_flux_forcing.ipynb

view this post on Zulip Kristen Krumhardt (Jun 18 2020 at 19:46):

Ok cool. I'll give it a try. Thanks!

view this post on Zulip Michael Levy (Jun 24 2020 at 19:50):

@Keith Lindsay and / or @Matt Long: The current namelist defaults for kappa_iso_deep are

<!-------------------------------------------------------------->
<!-- enhanced diffusivity at depth, only default for 1 degree -->
<!-- until validated at other resolutions                     -->
<!-------------------------------------------------------------->
<kappa_thic_deep                               >0.1</kappa_thic_deep>
<kappa_isop_deep                               >0.1</kappa_isop_deep>
<kappa_isop_deep  ocn_grid="gx1v6"             >0.2</kappa_isop_deep>
<kappa_isop_deep  ocn_grid="gx1v7"             >0.2</kappa_isop_deep>

@Kristen Krumhardt's tuning runs are dropping back to kappa_isop_deep = 0.1. So the easiest option for me would be replacing the block of code above with

<kappa_thic_deep>0.1</kappa_thic_deep>
<kappa_isop_deep>0.1</kappa_isop_deep>

but do I need to preserve the 0.2 value for any specific runs? The only example I could think of would be something like

<kappa_thic_deep>0.1</kappa_thic_deep>
<kappa_isop_deep>0.1</kappa_isop_deep>
<kappa_isop_deep ocn_grid="gx1v7" ocn_bgc_config="cesm2.1">0.1</kappa_isop_deep>

but that doesn't really make sense to me given that this isn't a BGC-specific parameter and we don't preserve old defaults for any other non-BGC variables.

view this post on Zulip Matt Long (Jun 24 2020 at 21:00):

@Michael Levy, this setting obviously has implications for the physical configuration. I'll open a thread in #CGD-OCE.

view this post on Zulip Kristen Krumhardt (Jun 25 2020 at 18:59):

@Keith Lindsay and @Matt Long , here are the zonal mean plots for NO3, PO4, SiO3, and O2 . I did global, Pacific basin, Atlantic basin, and Indian basin. These ones are for the 004 simulation, but I also have them for all the other simulations I did (though they are quite similar). You can see those in my notebooks which are all here:

https://github.com/kristenkrumhardt/CESM2_oceanBGC_diag/tree/master/diagnotics_MARBL_tuningV2

(see towards the bottom of the "mean-state" notebooks). Also all the other figures I presented yesterday morning are in these notebooks (the 'mean-state' and 'tseries' notebooks).

Please let me know what you think.

zonal_biases004.pdf

view this post on Zulip Matt Long (Jun 25 2020 at 19:32):

Thanks @Kristen Krumhardt.

I would suggest a run in which we increaseparm_SiO2_diss.

What values do you have for parm_SiO2_gamma? I think increasing this number effectively puts more Si into the hard subclass, which sinks with a much longer length scale. This is another means of push things deeper in the water column.

view this post on Zulip Kristen Krumhardt (Jun 25 2020 at 19:40):

Sure I can increase parm SiO2_diss (right now it's at 400m which I think is a change that was brought over from the OMIP run) so I can increase it back to 700m. or is that too much?

Right now parm_SiO2_gamma is at 0.1

view this post on Zulip Kristen Krumhardt (Jun 26 2020 at 13:29):

parm_SiO2_gamma is zero by default, but I've had it at 0.1 for all my runs. Do you think it should be higher than that?

view this post on Zulip Matt Long (Jun 26 2020 at 13:55):

no, I don't think so. I am pretty sure we zeroed it out during the great CESM2 oxygen chase

view this post on Zulip Kristen Krumhardt (Jun 26 2020 at 14:12):

So do you guys prefer 002 or 004? I would like to use the parameters of one of these runs and then just change the parm_SiO2_diss to 650m (and any other parameters you suggest). I want to start a new simulation this morning so we can see results on Monday.

The benefits of 002 is that the surface SiO3 in the Southern Ocean has less of a positive bias, but the drawback is that NPP is 48% diatoms. I remember Keith saying that we may need to tolerate a high diatom productivity for better silicate distribution. If so, this is the run we want.

The benefit of 004 is that we have slightly more overall NPP and it's 40% diatoms, but the drawback is that a positive surface SiO3 bias in the Southern Ocean is still there (albeit much better than the OMIP run).

view this post on Zulip Kristen Krumhardt (Jun 26 2020 at 14:12):

here is a pdf of my presentation from wednesday, in case you guys want to have a look. CESM2.2_tuning_overview.pdf

view this post on Zulip Keith Lindsay (Jun 26 2020 at 14:51):

When I inspect the zonal SiO3 bias figures, I see too little SiO3 in the deep Southern Ocean and too much SiO3 in mode waters. I'm inferring that we have too little diatom uptake of SiO3. To my eye, this appears worse in 004 than 002. It looks like the area of the plot that goes off both ends of the colorbar has increased.

Based on the surface phyto pool plots, it looks like the North Pacific diatom superbloom is larger in 004 than in 002.

Based on these, I'm leaning towards 002. But I'm skeptical that changing parm_SiO2_diss will improve the SO much. I think we need to reduce sp's competitive advantage in the SO to help out diat. Based on an email from Nov 2019, you found alphaPI_per_day to be a large lever, and I think you're using a larger value in the explicit cocco configuration. How about raising this parameter for diatoms.

view this post on Zulip Kristen Krumhardt (Jun 26 2020 at 15:12):

Sure, so I will go with the 002 setup for now. I'll try increasing alphaPI_per_day for diatoms. I can also trying increasing parm_SiO2_diss to see if this makes any difference

view this post on Zulip Michael Levy (Jun 26 2020 at 19:37):

@Keith Lindsay are you in the loop regarding the WW3-forced entrainment changes that Qing is bringing in via https://github.com/ESCOMP/POP2-CESM/pull/31? Should we be concerned about the effect of that PR on Kristen's tuning runs?

view this post on Zulip Matt Long (Jun 26 2020 at 19:45):

That could have a non-trivial impact. What's the intended default setting? On or off?

view this post on Zulip Michael Levy (Jun 26 2020 at 19:47):

From the PR, it looks like the default will be on

Testing with a longer simulation is underway.

  1. Update the CVMix repository to v0.97b-beta but do not turn on Langmuir induced entrainment (langmuir_opt = 'vr12-ma')
  2. Turn on the Langmuir induced entrainment (langmuir_opt = 'lf17')

...

The second step is climate changing, making the mixed layer deeper in the extratropical regions

One possibility is that we could keep langmuir_opt = 'vr12-ma' in our compset (the same way we'll keep kappa_isop_deep = 0.1)

view this post on Zulip Michael Levy (Jun 26 2020 at 19:49):

The first step is not bit-for-bit, but just the changes are all round-off from differences in the order of operations

view this post on Zulip Keith Lindsay (Jun 26 2020 at 19:53):

I'm having a hard time telling from the PR if they are proposing that this gets turned on by default or not.

They ran a case, with BGC, with the new options turned on, with the CESM2 OMIP JRA as a control. Diagnostics from the physics are available at http://webext.cgd.ucar.edu/GIAF/20200517_LF17_GOMIPECOIAF_JRA-1p4-2018_TL319_g17/ocn/diag_work.42-61/

I'm currently generating regional timeseries plots for this case, compared to CESM2 OMIP JRA. I'll have a link shortly to post.

view this post on Zulip Michael Levy (Jun 26 2020 at 20:02):

I'm having a hard time telling from the PR if they are proposing that this gets turned on by default or not.

It looks like the default in the PR is still langmuir_opt = 'vr12-ma' and he's setting langmuir_opt = 'lf17' in user_nl_pop in his case root (at least for his 20200517_LF17_GOMIPECOIAF_JRA-1p4-2018_TL319_g17 and 20200619_LF17_BHISTcmip6_f09_g17 cases). I got the impression from the first post in his PR that they were going to update the default, but maybe I was mistaken about that? I'll ask him.

view this post on Zulip Michael Levy (Jun 26 2020 at 20:11):

Oh, I had already asked Alper about the entrainment scheme in an email earlier today and just got a response (good job, past self!); double quote is me, single quote is Alper's reply:

Will Qing's tag enable this new entrainment scheme by default?

I think so.

If so, we should probably talk about the effect the new BGC tunings will have on his runs (and the effect his changes will have on the BGC tuning)

I agree. I'll note that the current B case run is being carried out to assess the BGC impact of the entertainment changes. We should probably coordinate with Keith and/or Matt to talk about how to assess the effect the new BGC tunings.

view this post on Zulip Keith Lindsay (Jun 26 2020 at 20:56):

Regional timeseries for the 1 cycle JRA run with these mods are now online at
http://webext.cgd.ucar.edu/GIAF/20200517_LF17_GOMIPECOIAF_JRA-1p4-2018_TL319_g17/ocn/adhoc_ts/

I'm inferring from Alper's response that there is a B case with these mods. I wasn't aware of that.

view this post on Zulip Michael Levy (Jun 26 2020 at 21:08):

I think a whole bunch of us just got cc-ed onto an email thread about this, but I'll try to capture some highlights.

  1. Alper is suggesting keeping the default unchanged in 2.2.0 and waiting until 2.2.1 to enable the new scheme

Perhaps, we can add the WW3 entrainment changes as an optional scheme in CESM 2.2.0, and make it default in the next minor version update (2.2.1) after having assessed its impacts with the new BGC changes.

  1. Qing seems to be okay with that

The B-case is not finished yet. And I think it will take some more time to complete the assessment. But based on the G-case results I think the changes in POP and WW3 are ready to be merged into CESM2.2.0 as an option.

  1. Gokhan is asking about the current status - it seems to me the answer he's going to get is going to lead to the lf17 tests being re-run after our BGC updates go in but maybe I'm missing something?

So, regarding this particular thread with BGC and WW3 mods, are the G-compset results fully vetted? Also, are these using a factor of 0.1 for abbsal isopycnal mixing?

Given the July 2 deadline, all signs seem to be pointing to keeping the vr12-ma default for 2.2.0 and re-running the lf17 analysis ahead of 2.2.1 or on the 2.3 development branches

view this post on Zulip Michael Levy (Jun 29 2020 at 15:48):

An update on the code freeze (email from Bill Sacks):

Based on a discussion this morning with Mariana, Gokhan and others, with a purpose of reducing stress on software engineers and others: For the upcoming CESM2.2.0 release freeze, we are going to relax the definition of "freeze". Thus, for the tags that are already in the test database, with PRs submitted, we will not require that the tags actually be made by the end of this week. Instead, please take whatever time is needed to appropriately review and test these changes, so that we can have a robust CESM2.2 release. This will delay the release itself; Gokhan and others are comfortable with this.

Please note:

So we're in good shape -- we have [draft] PRs for all the outstanding POP tags in the plans database:

  1. New tunings: https://github.com/ESCOMP/POP2-CESM/pull/35
  2. JRA / BGC high-res run: https://github.com/ESCOMP/POP2-CESM/pull/34
  3. Qing's entrainment update: https://github.com/ESCOMP/POP2-CESM/pull/31

I was a little concerned about getting all the test runs for the high-res case done and reviewed before Thursday, and we should think about what to run to make sure the entrainment changes don't have a significant impact -- the first step is probably to ensure the plan is to keep the default at vr12-ma, and second step is to ask them to wait for new tuning tag if they do plan on more lf17 testing during the "freeze".

view this post on Zulip Kristen Krumhardt (Jun 29 2020 at 16:11):

Hello all, I just processed some results from my latest tuning run (005). One caveat is that these diagnostic notebooks are missing the last 10 years of the 2nd IAF cycle (it's still running; I'll update these plots later today). To recap, I used the setup from the 002 run and then increased the alphaPI_per_day for diatoms and increased the parm_SiO3_diss to 650m.

Comparing to the 002 tuning run, I see a slight improvement in the 005 run for SiO3 upon really close inspection. I do see some improvements in the hovmöller diagrams, especially in the global SiO3 hovmöller, which shows less of a trend in declining deep SiO3 in the new 005 run than the 002 run.

Timeseries plots (including the hovmollers) for 002 and 005 are in these notebooks:
https://github.com/kristenkrumhardt/CESM2_oceanBGC_diag/blob/master/diagnotics_MARBL_tuningV2/tseries_bgc_diagnostic_002.ipynb
https://github.com/kristenkrumhardt/CESM2_oceanBGC_diag/blob/master/diagnotics_MARBL_tuningV2/tseries_bgc_diagnostic_005.ipynb

Mean-state plots (including the zonal means) are in these notebooks:
https://github.com/kristenkrumhardt/CESM2_oceanBGC_diag/blob/master/diagnotics_MARBL_tuningV2/mean-state_bgc_diagnostic_002.ipynb

https://github.com/kristenkrumhardt/CESM2_oceanBGC_diag/blob/master/diagnotics_MARBL_tuningV2/mean-state_bgc_diagnostic_005.ipynb

Please take a look and let me know what you think.

view this post on Zulip Keith Lindsay (Jun 30 2020 at 17:19):

Global SiO3 is improved at some depths (500m-1000m, 4500m-seafloor) and degraded at others (top 500m, 1000m-4500m). Perhaps it's better in an RMS sense, it's hard to tell. I'm not sure if it makes sense to try more options, or call it a day, and devise plans for automating this process more for 2.2.1.

One worrisome feature that I see, from an automation point of view, is that the deep (5000m) SiO3 bias in the Southern Ocean goes up for the 1st cycle and then drops over the 2nd cycle. We've suggested shortening the run duration in order to be able to run more experiments. This non-monotonic behavior worries me about going too short.

FYI, Daniel Kennedy is giving an update on the CLM parameter perturbation ensemble (PPE) at the CLM meeting this Thu, July 2 at 1 PM. Let me know if you want the zoom info.

view this post on Zulip Kristen Krumhardt (Jun 30 2020 at 17:31):

Thanks, Keith. I am fine with leaving it here for now, but I may try a few more experimental tuning runs before the end of the week. Yes, I would be interested in hearing Dan Kennedy's talk this Thursday. Please send along the zoom info:)


Last updated: May 16 2025 at 17:14 UTC