-
Notifications
You must be signed in to change notification settings - Fork 86
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Keep glc-derived runoff as separate fields to ocn if possible #547
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM thank you!
I went over this with @mvertens and she approves of these changes. |
Do you still want a review from @gustavo-marques ? |
Yes. I've asked Gustavo to test with these changes to confirm that this resolves the issue he was seeing. I think it makes sense to wait to merge this until he gives the go-ahead. |
Thank you for this PR @billsacks |
Hi @billsacks, I am trying to test this PR using the compset we have been using for the CESM3 fully-coupled development runs. This is how I created the case:
In my sandbox (cesm3_0_alpha06c_testing), cmeps has been updated to billsacks/separate_glc_rof_fields. I am keeping the original NCPL's:
Writing CPL history files every day
However, both |
Also, it would be great to check the "budget tables" generated by the coupled (diags.log.*). Is it possible to get these tables in short runs (5 days)? |
Great questions, @gustavo-marques . I also noticed in testing that the fluxes from GLC were 0 until the first crossing of the year boundary. To perform testing in a short test case (5 days), I set the model to start near the end of the year. These changes came from the
I have actually never created or looked at budget tables myself, so I'm probably not the best person to ask your question about producing budget tables. But if you remain stuck with that one, I can help look into it. |
@Gustavo you can control the frequency of budget output using the namelist control variables:
Set in user_nl_cpl, so you want to turn on budget_daily or perhaps even budget_inst. |
Thanks, @billsacks and @jedwards4b! Bill, I couldn't get MOM6 to work with |
Just to be clear: are you seeing zeroes for all of the I have a feeling that you need to cross the year boundary to start seeing non-zeros. So, it's not enough to just start in year 2: the run seems to need to actually cross the Dec 31 – Jan 1 boundary. You might be able to solve this with I'm puzzled, though, why I was able to do a test with MOM starting Dec 30 but you're not. So you could also try just reproducing exactly what I did: running |
@gustavo-marques @billsacks What is the status of this PR? |
By setting These tests indicate that the GLC runoff fluxes are correctly transferred to the ocean model, and the ocean interior changes are consistent with the surface fluxes. In the G compset, GLC fluxes are zero. In the B compset, only frozen runoff (primarily around Greenland) is non-zero. While I am confident in approving this PR, I would like confirmation from the land ice developers (@Katetc and @gunterl) that only frozen GLC runoff should be non-zero in the B compset. Additionally, are there any scenarios where liquid GLC runoff is expected to be non-zero? |
Thank you very much for doing that verification @gustavo-marques ! That's great to hear!
I can answer this: For a B compset with DGLC, yes, only frozen GLC runoff should be non-zero: DGLC does not send any liquid runoff. I believe that compsets with CISM could send some (small) liquid runoff in the GLC terms. @jedwards4b - given Gustavo's approval above, are you okay with me merging this? |
Thanks, @billsacks! |
Thanks, @gustavo-marques - that seems like a great idea, and I appreciate your doing that additional testing. It's been a while since I've set up a case with active CISM, so I may be forgetting something and/or it's possible that this won't work, but if you want to test this in a short run, I think you can do this by:
(and keep the But it's quite possible that won't work. If it doesn't, I'd ask Kate or Gunter for help, though feel free to loop me back in as well. |
Description of changes
When @mvertens reworked the GLC -> OCN runoff mapping, she put in place hooks to keep the glc-derived runoff separate from the lnd-derived runoff. However, @gustavo-marques found that these are still being combined into a single merged flux. (That may have been the intent at the time, until ocean models were ready to accept this new flux. I know we had extensive conversations about this, but don't remember all of the details.)
This PR separates these two fluxes so that the ocean can separately account for the lnd vs glc-derived runoff and the associated heat fluxes. I have done this in a way so that, if we're coupled to an ocean model that doesn't expect this separate glc-derived runoff (Forr_rofl_glc and Forr_rofi_glc), then it will continue to be merged into the Foxx_rofl and Foxx_rofi fluxes. (MOM6 is set up to handle the glc-specific fluxes; I'm not sure about BLOM in NorESM.)
Specific notes
Contributors other than yourself, if any: none
CMEPS Issues Fixed (include github issue #): none
Are changes expected to change answers? YES - substantial diffs in a few fields, and expected to be roundoff-level diffs system-wide.
There are large differences in the fields ocnExp_Foxx_rofi, ocnExp_Forr_rofi_glc, ocnExp_Foxx_hrofi, and ocnExp_Foxx_hrofi_glc due to redistribution of fluxes between these different fields. Beyond that, there will be roundoff-level differences if the separation of these runoff terms is just for diagnostic purposes and the ocean model treats them identically. (The differences then just arise from order of operations differences due to having two separate fluxes in place of a single, combined flux.) In theory an ocean model could do different things with these fluxes, and that would lead to more substantial differences, but I don't think that's currently the case, at least for CESM / MOM.
Any User Interface Changes (namelist or namelist defaults changes)? No
Testing performed
Tested in the context of cesm3_0_alpha06c.
I ran a few permutations of the test
SMS_Ld5.ne30pg3_t232.BLT1850.derecho_intel.allactive-decstart
.I confirmed that, with the changes here, ocnExp_Forr_rofi_glc is non-zero, and ocnExp_Foxx_rofi is 0 around Greenland, as expected.
I added hourly coupler history output by making this change:
Comparing with a baseline run, the first diffs appear at time
2002-01-01-07200
.There are diffs in the following fields, as expected:
I summed ocnExp_Forr_rofi_glc+ocnExp_Foxx_rofi in the new run and the baseline and verified that, in this first time with differences, the sums are identical in the new and baseline. Similarly for ocnExp_Foxx_hrofi+ocnExp_Foxx_hrofi_glc, although there are roundoff-level differences in that sum.
In addition, there are diffs in these fields from the ocean:
Note that those are all roundoff-level different.
After that time, differences grow, but the above analysis makes me comfortable that the changes in this PR only introduce roundoff-level diffs in the system.
I also verified that, if MOM doesn't advertise Forr_rofl_glc and Forr_rofi_glc, the behavior reverts to what it was before the changes in this PR. To do this, I needed to change some code in CMEPS related to the calculation of heat fluxes in addition to the changes in MOM. Full diffs were:
and