Negative runoff fluxes in CESM3 Development Simulations

[olyson]

In the CESM co-chairs meeting of 7/19/22, the OMWG noted that there were significant negative runoff fluxes in several of the recent CESM3 development coupled simulations, in particular, around several small islands.
We of course have had negative runoff fluxes in previous versions of the model (e.g., CESM2), due to irrigation and lakes (negative P-E).
However, these particular islands have neither irrigation nor lakes.
After a bit of analysis and discussion (@olyson @swensosc @wwieder ), we found that there are non-zero land fractions (identified by landfrac on the CLM history file) for gridcells where we don't have any surface data (pfts, lakes, glaciers, urban, crop) on the surface dataset being used. These are being modeled as wetlands which can have negative P-E and therefore negative runoff.
Several of these islands did not exist in CESM2.
For CESM3, there seems to be a bit of a mismatch between the landfrac that CLM actually uses (generated from the mesh file?) and the land/ocean mask on the surface dataset.
Question: Does this go away when we generate new surface datasets or will there always potentially be some kind of a mismatch?
@wwieder @swensosc @ekluzek @billsacks @dlawrenncar

[billsacks]

This could change somewhat with newer raw data, but this issue will potentially always exist given our current method for generating surface datasets. Basically: if some area is outside the ocean model grid then CTSM becomes the owner of that area; if none of CTSM's raw datasets claim ownership of that area, then it is set as wetland. (Though note that we're currently doing this slightly wrong - see #1716 .)

If this negative runoff is a problem we will need to either (1) come up with a different scheme for what to do when CTSM owns an area that appears to be ocean according to CTSM's raw data sets; (2) change the physics in some way to avoid generating negative runoff.

[wwieder]

Thanks for looking into this @olyson.
@billsacks I agree with your suggested solutions, which of these seem like the best option?For option_2 @swensosc suggested we could consider creating desert (bare ground) islands instead of wetland islands, which should avoid negative runoff.

[billsacks]

I'm not sure off-hand. For changing what we call these areas (wetland vs. desert, etc.), I'm worried that solving one problem will create another – like treating substantial areas as bare land that should really be water. Changing the physics to avoid negative runoff sounds like a good idea, but I think could pose some real challenges. Regardless of what we do, I feel like it's going to be hard to avoid having some situations where we generate persistently negative (P-E), and it's hard for me to envision a good solution that avoids relying on the ocean to solve the problem.

[olyson]

We asked Cecile to run a short fully coupled simulation similar to one of the CESM3-dev simulations (b.cesm3_cam058_mom_c.B1850WscMOM.f09_L58_t061.011) to see what the effects are of taking the negative runoff directly from the river mouths.
This was accomplished by setting bypass_routing_option='direct_to_outlet' and qgwl_runoff_option='negative' in the mosart namelist.
Four years of this new simulation have been completed (b.cesm3_cam058_mom_c.B1850WscMOM.f09_L58_t061.015).
Results are shown in slides 7 and 8 of this slide deck:

https://docs.google.com/presentation/d/1gEK5ASR3CNbQPkdCCPm6SIavPjX7BCYh/edit?usp=sharing&ouid=104026900087612515425&rtpof=true&sd=true

Slide 7 shows that TOTAL_DISCHARGE_TO_OCEAN_LIQ is now positive everywhere in the new simulation (015) unlike in the control (011).
Slide 8 (monthly minimum of the lrunoff field from MOM) shows that there are very few ocean grid cells that have negative runoff in 015. Note the scale for 015 is two orders of magnitude smaller than 011.

There are standard diagnostics here:

https://webext.cgd.ucar.edu/B1850/b.cesm3_cam058_mom_c.B1850WscMOM.f09_L58_t061.015/lnd/b.cesm3_cam058_mom_c.B1850WscMOM.f09_L58_t061.015.2_4-b.cesm3_cam058_mom_c.B1850WscMOM.f09_L58_t061.011.2_4/setsIndex.html

In particular, set7 is of interest. The variability in these coupled simulations is probably swamping the effects of this change, particularly since these are only 3 year averages, but I don't see anything alarming in the results for discharge of individual rivers or into the individual ocean basins.

[olyson]

There are BUDGET WARNINGs in the mosart log file. For tracer 1 which I assume is liquid water.

/glade/scratch/hannay/archive/b.cesm3_cam058_mom_c.B1850WscMOM.f09_L58_t061.015/logs/rof.log.5167742.chadmin1.ib0.cheyenne.ucar.edu.220726-082955.gz

[olyson]

Sean has fixed a couple of bugs in the MOSART code with respect to the BUDGET WARNINGs we encountered when we set bypass_routing_option='direct_to_outlet' and qgwl_runoff_option='negative' in the mosart namelist.
I ran a pair of land-only simulations, one a control (with bypass_routing_option set to the default value of 'direct_in_place') and one with 'direct_to_outlet'. There are now no warnings in the log files.
Slide 3 of the slide deck shows the effect of this on reducing the negative TOTAL_DISCHARGE_TO_OCEAN_LIQ. What remains is due to, "For example, for the caspian, those gridcells don't have an outlet on the ocean mask. And the little dots in the continental interiors I think are 'sink' points, which don't touch the ocean. So we would still have negative runoff at those locations that is too large to be compensated for by the rivers. it would get passed to the ocean at those locations just like the direct_in_place method."

https://docs.google.com/presentation/d/1gEK5ASR3CNbQPkdCCPm6SIavPjX7BCYh/edit?usp=sharing&ouid=104026900087612515425&rtpof=true&sd=true

I don't see any discernable impact on our set7 discharge to the ocean diagnostics as shown here:

https://webext.cgd.ucar.edu/I2000/ctsm51_ctsm51d100_1deg_GSWP3V1_directtooutlet_2000/lnd/ctsm51_ctsm51d100_1deg_GSWP3V1_directtooutlet_2000.6_10-ctsm51_ctsm51d100_1deg_GSWP3V1_2000.6_10/set7/set7.html

I'm going to work on quantifying the magnitude of negative runoff with respect to total runoff and the reduction we get using this method.

[ekluzek]

Adding @nmizukami to this issue as we will want to be aware of these issues in mizuRoute. We should for example make sure we implement direct_to_outlet in mizuRoute because of this issue. So direct_in_place and direct_to_outlet for bypass_routing_option should both be implemented in mizuRoute. And any fixes we need to put in place in MOSART we'll also want to get into mizuRoute.

[ekluzek]

@olyson do you have a branch of MOSART with these changes? We should get these into a PR for MOSART. You could start the PR even before we are done with it's evaluation.

[billsacks]

Thanks @olyson and @swensosc . My understanding is that we still want to move ahead with trying the replacement of wetlands with bare ground in addition to this MOSART fix; is that right? If so, I'll work on it today.

[olyson]

Yes, that is my understanding as well, thanks.

[wwieder]

Yes, that would be great, @billsacks, as Sean's mosart changes don't help with the negative runoff from wetland islands.

@olyson, I recall you saying last week that frozen runoff in the log files was different with 'direct_to_outlet' option. Is this something we should investigate?

[olyson]

Yes, definitely should understand that.
Another thing is that in the land-only simulations, global negative runoff was reduced by about 70% (from -7.2e6 m3/s to -2.2e6 m3/s), but I don't see that reflected in the global sum of TOTAL_DISCHARGE_TO_OCEAN_LIQ. There is a difference between the two simulations, but the difference is quite small. Looking at the spatial map of the difference field there are a significant number of grid cells that have an increase in TOTAL_DISCHARGE_TO_OCEAN_LIQ which are apparently offsetting the decreases I would expect to see. I guess I would not expect to see any gridcells like that @swensosc ?

[swensosc]

Another difference between the simulations is that the qgwl_runoff_option = "negative" option is used in the new simulation, but qgwl_runoff_option = "threshold" is used in the default. I think that means that in the default, some of the negative runoff reduces the amount of water in the river if possible, and the remainder is sent to the coupler. I don't see how that would cause the result you are seeing though, but perhaps it's worth doing a direct_in_place simulation with the negative option so we can compare.

…

On Mon, Aug 22, 2022 at 1:51 PM Keith Oleson ***@***.***> wrote: Yes, definitely should understand that. Another thing is that in the land-only simulations, global negative runoff was reduced by about 70% (from -7.2e6 m3/s to -2.2e6 m3/s), but I don't see that reflected in the global sum of TOTAL_DISCHARGE_TO_OCEAN_LIQ. There is a difference between the two simulations, but the difference is quite small. Looking at the spatial map of the difference field there are a significant number of grid cells that have an increase in TOTAL_DISCHARGE_TO_OCEAN_LIQ which are apparently offsetting the decreases I would expect to see. I guess I would not expect to see any gridcells like that @swensosc <https://github.com/swensosc> ? — Reply to this email directly, view it on GitHub <#1816 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGRN57DVFHIOGOEWUQ5H27TV2PK4ZANCNFSM54IL3GOQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[olyson]

Ok, I think this is fine actually. We would expect the global sum of TOTAL_DISCHARGE_TO_OCEAN_LIQ to be conserved.
I'm running a 'negative' option simulation anyway.

[olyson]

I don't see any significant differences with the 'negative' option combined with 'direct_in_place'.

[billsacks]

The question I raised in the co-chairs meeting was about the many inland grid cells that showed negative discharge to ocean in the MOSART history files. My interpretation was that discharge to ocean in these inland cells would only arise from negative contributions, because any positive runoff would be routed to the ocean and so would show up in coastal grid cells. The alternative is that there really are a huge number of grid cells with a negative net runoff over the year, which would be very surprising to me.

[swensosc]

I think in mosart there are terminal points that are not on the coasts ('sink' points). I think runoff at these points would be passed to the ocean at those locations, not the coasts. I think that any negative runoff upstream of these points would send their negative runoff to these points in the 'direct_to_outlet' case, and then to the ocean. Positive runoff would be routed normally, but whatever ends up at an inland sink point will be sent to the ocean at that location, not at the coast. It seems like it would be possible to have long term negative runoff if we specify lakes to exist, but the climate doesn't have sufficient precip to maintain them. Because our lakes cannot dry up, they would continue to evaporate.

…

On Tue, Aug 23, 2022 at 1:11 PM Bill Sacks ***@***.***> wrote: The question I raised in the co-chairs meeting was about the many inland grid cells that showed negative discharge to ocean in the MOSART history files. My interpretation was that discharge to ocean in these inland cells would only arise from negative contributions, because any positive runoff would be routed to the ocean and so would show up in coastal grid cells. The alternative is that there really are a huge number of grid cells with a negative net runoff over the year, which would be very surprising to me. — Reply to this email directly, view it on GitHub <#1816 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGRN57CS4RVHNQRFWZS5GKTV2UO67ANCNFSM54IL3GOQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[billsacks]

Thanks, @swensosc, that helps somewhat. However, the figure in question shows large swaths of area with negative runoff - see below. It seems unexpected to me that all of these grid cells would have net negative runoff - or that all of these points would be "sink" points.

[swensosc]

I think I misunderstood the question. The figure you show is the default, 'direct_in_place' behavior, which splits the negative runoff and sends it 'in place' while the positive runoff is routed normally. In the 'direct_to_outlet' case, some negative runoff is moved to sink points, and added to whatever positive runoff was routed to that point. Then it gets sent to the ocean at that location, whether it's positive or negative.

…

On Tue, Aug 23, 2022 at 1:40 PM Bill Sacks ***@***.***> wrote: Thanks, @swensosc <https://github.com/swensosc>, that helps somewhat. However, the figure in question shows large swaths of area with negative runoff - see below. It seems unexpected to me that all of these grid cells would have net negative runoff - or that all of these points would be "sink" points. [image: image] <https://user-images.githubusercontent.com/6266741/186251080-2e9df092-1ee3-4021-9314-1628b75de888.png> — Reply to this email directly, view it on GitHub <#1816 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGRN57AJA5B3OCGLIKKL3YTV2USMTANCNFSM54IL3GOQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[dlawrenncar]

So I understand better, can you remind me what happens with the negative runoff in the 'direct_in_place' option. Does that mean that it is sent directly to the nearest ocean grid point. Apologies. I know you have answered this before. Dave

…

On Tue, Aug 23, 2022 at 1:47 PM swensosc ***@***.***> wrote: I think I misunderstood the question. The figure you show is the default, 'direct_in_place' behavior, which splits the negative runoff and sends it 'in place' while the positive runoff is routed normally. In the 'direct_to_outlet' case, some negative runoff is moved to sink points, and added to whatever positive runoff was routed to that point. Then it gets sent to the ocean at that location, whether it's positive or negative. On Tue, Aug 23, 2022 at 1:40 PM Bill Sacks ***@***.***> wrote: > Thanks, @swensosc <https://github.com/swensosc>, that helps somewhat. > However, the figure in question shows large swaths of area with negative > runoff - see below. It seems unexpected to me that all of these grid cells > would have net negative runoff - or that all of these points would be > "sink" points. > > [image: image] > < https://user-images.githubusercontent.com/6266741/186251080-2e9df092-1ee3-4021-9314-1628b75de888.png > > > — > Reply to this email directly, view it on GitHub > <#1816 (comment)>, or > unsubscribe > < https://github.com/notifications/unsubscribe-auth/AGRN57AJA5B3OCGLIKKL3YTV2USMTANCNFSM54IL3GOQ > > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> > — Reply to this email directly, view it on GitHub <#1816 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFABYVFFUWHA3PXPAECOTSLV2UTFVANCNFSM54IL3GOQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[swensosc]

it is sent 'in place', i.e. it is sent at its location, not moved to an ocean point. The ocean model (or maybe in the coupler?) has its own algorithm for finding the nearest ocean point and applying a mask that spreads out the input over some area (to avoid numerical issues with dropping it all in one ocean gridcell). On Tue, Aug 23, 2022 at 3:44 PM David Lawrence ***@***.***> wrote:

…

So I understand better, can you remind me what happens with the negative runoff in the 'direct_in_place' option. Does that mean that it is sent directly to the nearest ocean grid point. Apologies. I know you have answered this before. Dave On Tue, Aug 23, 2022 at 1:47 PM swensosc ***@***.***> wrote: > I think I misunderstood the question. The figure you show is the default, > 'direct_in_place' behavior, which splits the negative runoff and sends it > 'in place' while the positive runoff is routed normally. In the > 'direct_to_outlet' case, some negative runoff is moved to sink points, and > added to whatever positive runoff was routed to that point. Then it gets > sent to the ocean at that location, whether it's positive or negative. > > On Tue, Aug 23, 2022 at 1:40 PM Bill Sacks ***@***.***> wrote: > > > Thanks, @swensosc <https://github.com/swensosc>, that helps somewhat. > > However, the figure in question shows large swaths of area with negative > > runoff - see below. It seems unexpected to me that all of these grid > cells > > would have net negative runoff - or that all of these points would be > > "sink" points. > > > > [image: image] > > < > https://user-images.githubusercontent.com/6266741/186251080-2e9df092-1ee3-4021-9314-1628b75de888.png > > > > > > — > > Reply to this email directly, view it on GitHub > > <#1816 (comment)>, or > > unsubscribe > > < > https://github.com/notifications/unsubscribe-auth/AGRN57AJA5B3OCGLIKKL3YTV2USMTANCNFSM54IL3GOQ > > > > . > > You are receiving this because you were mentioned.Message ID: > > ***@***.***> > > > > — > Reply to this email directly, view it on GitHub > <#1816 (comment)>, or > unsubscribe > < https://github.com/notifications/unsubscribe-auth/AFABYVFFUWHA3PXPAECOTSLV2UTFVANCNFSM54IL3GOQ > > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> > — Reply to this email directly, view it on GitHub <#1816 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGRN57CWTWDUZRJI4RJBP5DV2VA3VANCNFSM54IL3GOQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[dlawrenncar]

Got it. That's what I thought. So, the reality is that in CESM2, when we move to MOSART, there is a lot more negative runoff being sent to the ocean than in CESM1 when we sent it to the rivers (RTM, which could handle negative runoff). The direct_to_outlet is resolving a lot of that negative runoff that occurs in CESM2.

…

On Tue, Aug 23, 2022 at 3:53 PM swensosc ***@***.***> wrote: it is sent 'in place', i.e. it is sent at its location, not moved to an ocean point. The ocean model (or maybe in the coupler?) has its own algorithm for finding the nearest ocean point and applying a mask that spreads out the input over some area (to avoid numerical issues with dropping it all in one ocean gridcell). On Tue, Aug 23, 2022 at 3:44 PM David Lawrence ***@***.***> wrote: > So I understand better, can you remind me what happens with the negative > runoff in the 'direct_in_place' option. Does that mean that it is sent > directly to the nearest ocean grid point. Apologies. I know you have > answered this before. > > Dave > > On Tue, Aug 23, 2022 at 1:47 PM swensosc ***@***.***> wrote: > > > I think I misunderstood the question. The figure you show is the default, > > 'direct_in_place' behavior, which splits the negative runoff and sends it > > 'in place' while the positive runoff is routed normally. In the > > 'direct_to_outlet' case, some negative runoff is moved to sink points, > and > > added to whatever positive runoff was routed to that point. Then it gets > > sent to the ocean at that location, whether it's positive or negative. > > > > On Tue, Aug 23, 2022 at 1:40 PM Bill Sacks ***@***.***> wrote: > > > > > Thanks, @swensosc <https://github.com/swensosc>, that helps somewhat. > > > However, the figure in question shows large swaths of area with > negative > > > runoff - see below. It seems unexpected to me that all of these grid > > cells > > > would have net negative runoff - or that all of these points would be > > > "sink" points. > > > > > > [image: image] > > > < > > > https://user-images.githubusercontent.com/6266741/186251080-2e9df092-1ee3-4021-9314-1628b75de888.png > > > > > > > > > — > > > Reply to this email directly, view it on GitHub > > > <#1816 (comment) >, > or > > > unsubscribe > > > < > > > https://github.com/notifications/unsubscribe-auth/AGRN57AJA5B3OCGLIKKL3YTV2USMTANCNFSM54IL3GOQ > > > > > > . > > > You are receiving this because you were mentioned.Message ID: > > > ***@***.***> > > > > > > > — > > Reply to this email directly, view it on GitHub > > <#1816 (comment)>, or > > unsubscribe > > < > https://github.com/notifications/unsubscribe-auth/AFABYVFFUWHA3PXPAECOTSLV2UTFVANCNFSM54IL3GOQ > > > > . > > You are receiving this because you were mentioned.Message ID: > > ***@***.***> > > > > — > Reply to this email directly, view it on GitHub > <#1816 (comment)>, or > unsubscribe > < https://github.com/notifications/unsubscribe-auth/AGRN57CWTWDUZRJI4RJBP5DV2VA3VANCNFSM54IL3GOQ > > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> > — Reply to this email directly, view it on GitHub <#1816 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFABYVAOFSI5D6WZBOU5S73V2VB4HANCNFSM54IL3GOQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[olyson]

I'm curious how mosart is able to split negative from positive runoff. Does it get passed the gridcell average runoff but in component form (surface, drainage, qrgwl, etc.) and then checks for negative runoff from each component at each time step?

[swensosc]

read the manual, keith. seriously though, yes, it checks the components separately each time step and can do different operations for each. For example, in the default case with the 'threshold' option, it will first try to offset negative runoff from the main channel storage, and if that is not sufficient, it will just pass the remainder to the coupler. With the 'negative' option, it doesn't do that, it just sends the entire negative amount to the coupler. In the 'direct_to_outlet' case it sends all the negative to the outlet.

…

On Tue, Aug 23, 2022 at 4:26 PM Keith Oleson ***@***.***> wrote: I'm curious how mosart is able to split negative from positive runoff. Does it get passed the gridcell average runoff but in component form (surface, drainage, qrgwl, etc.) and then checks for negative runoff from each component at each time step? — Reply to this email directly, view it on GitHub <#1816 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGRN57CHIALQTDHVK3AI67DV2VF2ZANCNFSM54IL3GOQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[olyson]

Ha, yes, I just read the manual. Point taken :)

[billsacks]

Thanks for all this info. I'm still having trouble discerning the short answer to the question. I think what you're saying supports my original feeling that this figure does NOT imply net negative runoff from all of these grid cells, but I'm not sure....

[olyson]

MOSART PR issued (ESCOMP/MOSART#57) per @ekluzek request.

[olyson]

Regarding the issue I brought up with frozen runoff in the coupler log files (as shown in the last slide of the negative runoff ppt), I ran a clone of the fully coupled direct_to_outlet simulation with Sean's bug fix and that problem appears to be fixed as well. The frozen runoff from the lnd is showing up in the ocn column rather than the rof column as is normal.

[wwieder]

thanks for checking this, Keith.

I still wonder if we addressed @billsacks question on negative net runoff fluxes from amazonian grid cells that we started discussing at co-chairs?

[olyson]

I tested the wetland fix in a land-only combined with direct_to_outlet. Seems to work, there are no longer any wetland areas. Negative runoff is only reduced by another 1% or so, there isn't that much negative runoff associated with wetlands globally. The problematic islands don't seem to have negative runoff anymore, at least in a monthly sense.

My understanding now based on our conversation is that the above figure does NOT imply net negative runoff from all of these grid cells.

[wwieder]

Thanks for working on this Keith.

• Are there appreciable changes in energy or water fluxes around our new beachy islands (or coasts)?
• Are there any relevant updates for co-chairs, beyond "we fixed another tiny fraction of negative runoff"
• Do we need to think about anything else before discussing at the CLM meeting next Thursday?

[wwieder]

@billsacks and @ekluzek is this a good issue that should be converted to a discussion?

[billsacks]

is this a good issue that should be converted to a discussion?

Sure.

[ekluzek]

@wwieder I think it should. I just wanted to check before hand. I'll go ahead and do that.