Likely wrong RTM river flux to MOM6 within cesm2_3_beta17

[jiang-zhu]

The river runoff flux to MOM6 is likely wrong when run RTM within cesm2_3_beta17.

See screenshort of the variable 'friver' in MOM6 output

The left plot is from the simulation with RTM, while the right is with MOSART.

This could indicate an error in the units in the coupler or in the mesh/mapping files. It could also be due to my error in setting up the simulation.

case directory
Run with RTM: /glade/u/home/jiangzhu/cesm/cases/b.e23.BLT1850.ne30pg3_t232.cesm2_3_b17.PI.01
Run with MOSART: /glade/campaign/cesm/cesmdata/cseg/runs/cesm2_0/b.e23_alpha17f.BLT1850.ne30_t232.091

Thank you!

[ekluzek]

@swensosc can you comment on this for us? This is looking like something we will need to fix for CESM3.0 as RTM is still important for Paleo work.

@slevis-lmwg @wwieder

[jiang-zhu]

Just in case it is helpful for diagnosing the problem, here are the water budget table from diags.log. Note the rof column (the 3rd column)

With RTM
(med_diag_print_summary) NET WATER BUDGET (kg/m2s*1e6): period = all_time: date = 220101 0
atm lnd rof ocn ice nh ice sh glc SUM
wmelt 0.00000000 0.00000000 0.00000000 0.42213238 -0.17388272 -0.24824966 0.00000000 -0.00000000
wrain -33.48871865 7.17317864 0.00000000 26.26049525 0.04545559 0.00977133 0.00000000 0.00018216
wsnow -2.47817569 0.92433299 0.00000000 1.14055897 0.14703244 0.26626659 0.00000000 0.00001530
wevap 35.95316028 -4.71595296 0.00000000 -31.18873952 -0.01745794 -0.03117410 0.00000000 -0.00016424
wrunoff 0.00000000 -3.20140904 3.20119642 0.00019894 0.00000000 0.00000000 0.00000000 -0.00001368
wfrzrof 0.00000000 -0.19240404 0.19237792 0.00000391 0.00000000 0.00000000 0.00000000 -0.00002221
SUM -0.01373407 -0.01225440 3.39357433 -3.36535005 0.00114737 -0.00338584 0.00000000 -0.00000267

With MOSART
(med_diag_print_summary) NET WATER BUDGET (kg/m2s*1e6): period = all_time: date = 900101 0
atm lnd rof ocn ice nh ice sh glc SUM
wmelt 0.00000000 0.00000000 0.00000000 0.57658999 -0.26336089 -0.31322910 0.00000000 -0.00000000
wrain -32.63109762 6.93500029 0.00000000 25.63555545 0.04503345 0.01559731 0.00000000 0.00008888
wsnow -2.86333889 0.93884215 0.00000000 1.39404831 0.17269882 0.35778977 0.00000000 0.00004017
wevap 35.47078470 -4.57599744 0.00000000 -30.82817940 -0.01956524 -0.04723873 0.00000000 -0.00019611
wrunoff 0.00000000 -3.18175621 -0.00278653 3.18452902 0.00000000 0.00000000 0.00000000 -0.00001372
wfrzrof 0.00000000 -0.16424818 0.00000000 0.16424493 0.00000000 0.00000000 0.00000000 -0.00000325
SUM -0.02365181 -0.04815938 -0.00278653 0.12678829 -0.06519386 0.01291925 0.00000000 -0.00008405

[swensosc]

I suspect that there is an issue with units conversion. It may be that the rtm fluxes are not being multiplied by the area correctly. I ran an older codebase using mct, and compared it to a current nuopc simulation, and the patterns of QCHANR in the rtm history files look the same, except that the magnitudes are different by roughly 1.2e5, which might be the area in km2 (I ran 0.9x1.25 ctsm).

…

On Wed, May 29, 2024 at 11:24 AM jiang-zhu ***@***.***> wrote: Just in case it is helpful for diagnosing the problem, here are the water budget table from diags.log. Note the rof column With RTM (med_diag_print_summary) NET WATER BUDGET (kg/m2s*1e6): period = all_time: date = 220101 0 atm lnd rof ocn ice nh ice sh glc *SUM* wmelt 0.00000000 0.00000000 0.00000000 0.42213238 -0.17388272 -0.24824966 0.00000000 -0.00000000 wrain -33.48871865 7.17317864 0.00000000 26.26049525 0.04545559 0.00977133 0.00000000 0.00018216 wsnow -2.47817569 0.92433299 0.00000000 1.14055897 0.14703244 0.26626659 0.00000000 0.00001530 wevap 35.95316028 -4.71595296 0.00000000 -31.18873952 -0.01745794 -0.03117410 0.00000000 -0.00016424 wrunoff 0.00000000 -3.20140904 *3.20119642* 0.00019894 0.00000000 0.00000000 0.00000000 -0.00001368 wfrzrof 0.00000000 -0.19240404 0.19237792 0.00000391 0.00000000 0.00000000 0.00000000 -0.00002221 *SUM* -0.01373407 -0.01225440 3.39357433 -3.36535005 0.00114737 -0.00338584 0.00000000 -0.00000267 With MOSART (med_diag_print_summary) NET WATER BUDGET (kg/m2s*1e6): period = all_time: date = 900101 0 atm lnd rof ocn ice nh ice sh glc *SUM* wmelt 0.00000000 0.00000000 0.00000000 0.57658999 -0.26336089 -0.31322910 0.00000000 -0.00000000 wrain -32.63109762 6.93500029 0.00000000 25.63555545 0.04503345 0.01559731 0.00000000 0.00008888 wsnow -2.86333889 0.93884215 0.00000000 1.39404831 0.17269882 0.35778977 0.00000000 0.00004017 wevap 35.47078470 -4.57599744 0.00000000 -30.82817940 -0.01956524 -0.04723873 0.00000000 -0.00019611 wrunoff 0.00000000 -3.18175621 *-0.00278653* 3.18452902 0.00000000 0.00000000 0.00000000 -0.00001372 wfrzrof 0.00000000 -0.16424818 0.00000000 0.16424493 0.00000000 0.00000000 0.00000000 -0.00000325 *SUM* -0.02365181 -0.04815938 -0.00278653 0.12678829 -0.06519386 0.01291925 0.00000000 -0.00008405 — Reply to this email directly, view it on GitHub <#50 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGRN57AMFX5S3KYHI2I7K43ZEYFOVAVCNFSM6AAAAABINWVIWWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZXHEYTOMRVHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[jiang-zhu]

Thank you very much!

Your explanation makes sense to me. The order mismatch is also roughly consistent with the number in the diag table (e.g., 0.00019894 vs 3.18452902, the ocn & wrunoff numbers).

[wwieder]

If this looks OK, I suggest we wait to fix this until after the science code freeze if that's OK @jiang-zhu?

Also, @jiang-zhu is this something that you can open a PR to fix in RTM?

[jiang-zhu]

@wwieder we need this for the LGM simulation that I am doing. It would be best if we have the fix sooner.
I am not sure about how to fix this right now. Perhaps, @swensosc could give me some instructions? I am happy to perform any testing on this.

[swensosc]

try this file and see if it fixes your problem: /glade/u/home/swensosc/cases/test_rtm/SourceMods/src.rtm/rof_import_export.F90

…

On Thu, May 30, 2024 at 4:02 PM jiang-zhu ***@***.***> wrote: @wwieder <https://github.com/wwieder> we need this for the LGM simulation that I am doing. It would be best if we have the fix sooner. I am not sure about how to fix this right now. Perhaps, @swensosc <https://github.com/swensosc> could give me some instructions? I am happy to perform any testing on this. — Reply to this email directly, view it on GitHub <#50 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGRN57H3IMODWPE7YR2HK3TZE6OW3AVCNFSM6AAAAABINWVIWWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNBQHEZDQMZWHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[jiang-zhu]

@swensosc @wwieder @ekluzek
Thank you for the fix.

Based on the salinity distribution and budget summary in diags.log, the fix worked.

Just in case you want to examine the rtm output, here is the case data: /glade/derecho/scratch/jiangzhu/b.e23_beta17.BLT1850.ne30pg3_t232.PI.02/run

[wwieder]

Thanks for looking into this, @jiang-zhu .

@swensosc can you open a PR for this code modification?

[swensosc]

an SE should probably review the change first to see if it's the proper way to implement the fix.

…

On Tue, Jun 4, 2024 at 11:19 AM will wieder ***@***.***> wrote: Thanks for looking into this, @jiang-zhu <https://github.com/jiang-zhu> . @swensosc <https://github.com/swensosc> can you open a PR for this code modification? — Reply to this email directly, view it on GitHub <#50 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGRN57HKIOCG6NL7GUODFDTZFXZKBAVCNFSM6AAAAABINWVIWWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNBYGAZTKOBUGQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[wwieder]

Agreed, but can this just happen in the PR review processes before it's merged?

[ekluzek]

@swensosc I agree with @wwieder propose a PR and @slevis-lmwg and I will look it over and let you know if we think it might need any changes. The primary thing I'd like to do is to do some checking and comparison to MOSART to make sure we are sure it's correct. I suspect the actual change you have is pretty small and it's easiest to inspect in a PR.