Replies: 48 comments 9 replies
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
@billsacks where are we on this first action item, changing wetlands to bare ground? Has this been implemented in a place where it can be used for the next round of couple model simulations? |
Beta Was this translation helpful? Give feedback.
-
|
Confirming what we discussed on the call today: the fix for this was applied to the ctsm5.2 branch, so isn't yet on master. However, as I noted in #1890 we could apply these directly to master if that would be helpful for the upcoming coupled testing:
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks for checking on this. As Frank noted this won't really impact MOM science, I don't know it's critical to bring this to main sooner than a CTSM5.2 merge. We'll see if we're told differently at co-chair's tomorrow. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for looking into this @olyson. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. Slide 7 shows that TOTAL_DISCHARGE_TO_OCEAN_LIQ is now positive everywhere in the new simulation (015) unlike in the control (011). There are standard diagnostics here: 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. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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 don't see any discernable impact on our set7 discharge to the ocean diagnostics as shown here: 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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
@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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, that is my understanding as well, thanks. |
Beta Was this translation helpful? Give feedback.
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, definitely should understand that. |
Beta Was this translation helpful? Give feedback.
-
|
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:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Ok, I think this is fine actually. We would expect the global sum of TOTAL_DISCHARGE_TO_OCEAN_LIQ to be conserved. |
Beta Was this translation helpful? Give feedback.
-
|
I don't see any significant differences with the 'negative' option combined with 'direct_in_place'. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
Irrigation increases negative runoff by about 15% (compared 10 year I2000 simulations with irrigation on and off). |
Beta Was this translation helpful? Give feedback.
-
|
Can you put this in terms of negative runoff vs total runoff for the
various configurations? That is, what % of total runoff to the ocean is
negative runoff? Trying to get a better sense of how big a correction
factor would be if that is what we have to do.
…On Fri, Sep 2, 2022 at 9:14 AM Keith Oleson ***@***.***> wrote:
Irrigation increases negative runoff by about 15% (compared 10 year I2000
simulations with irrigation on and off).
—
Reply to this email directly, view it on GitHub
<#1835 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFABYVBFSIW37DEXFMO2YCLV4IKULANCNFSM5762YKKQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Here's a table for land-only: Negative runoff is 4.52% of total runoff to ocean (with irrigation on). These numbers are a bit higher than what I reported on in the meeting. I've updated these numbers to reflect the fact that I'm now using the same land/ocean mesh file that is being used in the coupled simulations for better consistency with those simulations. For comparison, in one of the 1850 fully coupled simulations (46 years), negative runoff is 3.60% of total runoff to ocean which is pretty consistent with land-only, irrigation-off. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry, one more annoying clarification question,
is the last number with or without irrigation (1.45% negative runoff using
the direct_to_outlet + wetland->veg methods)
If it's with irrigation off, what is negative runoff with irrigation on +
direct_to_outlet + wetland->veg methods?
if it's with irrigation on, what is negative runoff with irrigation off +
direct_to_outlet + wetland->veg methods?
Would this information be helpful to have?
…On Fri, Sep 2, 2022 at 10:13 AM Keith Oleson ***@***.***> wrote:
Here's a table for land-only:
https://docs.google.com/spreadsheets/d/18NhG4U9ftj9gE0LACDk7lTk5DMEB5Nqm/edit?usp=sharing&ouid=104026900087612515425&rtpof=true&sd=true
Negative runoff is 4.52% of total runoff to ocean (with irrigation on).
Negative runoff is 3.82% of total runoff to ocean (with irrigation off).
This is reduced to 1.45% using the direct_to_outlet + wetland->veg methods.
These numbers are a bit higher than what I reported on in the meeting.
I've updated these numbers to reflect the fact that I'm now using the same
land/ocean mesh file that is being used in the coupled simulations for
better consistency with those simulations.
For comparison, in one of the 1850 fully coupled simulations (46 years),
negative runoff is 3.60% of total runoff to ocean which is pretty
consistent with land-only, irrigation-off.
—
Reply to this email directly, view it on GitHub
<#1835 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB5IWJEQJ355QJBY3GFGRKLV4IRSNANCNFSM5762YKKQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Irrig on (I updated the table). |
Beta Was this translation helpful? Give feedback.
-
|
Offline conversations we discussed adding a scaling factor prior to exporting runoff. Basically calculate a factor such that: Gokhan prefers this implementation, potentially with some temporal smoothing? One remaining question: In the coupled model, where are runoff fluxes INTO the Caspian mapped to? Should we create a virtual reservior for these fluxes to help with this smoothing? |
Beta Was this translation helpful? Give feedback.
-
|
Three parts to this plan discussed at the SE meeting
|
Beta Was this translation helpful? Give feedback.
-
|
"4" in the list above is now filed as #2222 |
Beta Was this translation helpful? Give feedback.
-
|
I am browsing over #1835 here, where @wwieder suggested that I may work on the last checkbox (same as item 3 in the last post), i.e. "remove remaining negative runoff ..." Relevant questions (some of them tangential):
|
Beta Was this translation helpful? Give feedback.
-
|
Regarding (1) maybe I was missing that there's a new proposal to do #1878 at runtime? And, therefore, the issue remains open. |
Beta Was this translation helpful? Give feedback.
-
|
Regarding (3) it seems best to me that we complete #1886 now as part of ctsm5.2. Otherwise we will need to regenerate surface datasets, unless I have misunderstood. |
Beta Was this translation helpful? Give feedback.
-
|
Regarding (1) I think we were leaving the issues open until they are resolved on master - so once the ctsm5.2 branch is merged. I have a slight preference for sticking with that, but if you prefer to go ahead and close them now, that's okay with me. The fix for #1878 does make the changes at runtime, though it was coordinated with some mksurfdata changes. I think we decided to defer #1886 to the future. |
Beta Was this translation helpful? Give feedback.
-
|
From discussion with @slevis-lmwg and @swensosc today: We are tentatively planning to remove negative runoff in CMEPS by reducing positive runoff grid cells proportionally to conserve water - see ESCOMP/CMEPS#405. The tentative plan is for me to take this on sometime in the next few months. We also discussed the idea of adding annual dribblers to negative runoff from lakes and wetlands. We tentatively thought we could defer that piece because:
But we are open to feedback on this. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for offering to help with this, Bill |
Beta Was this translation helpful? Give feedback.
-
|
@billsacks this makes sense to me. By putting it in CMEPS it's then handled for any land model that's used. So for example would be handled for SLIM this way. I just have a question. In CMEPS this won't care what type of landunit is being run, it'll just handle any reason that runoff is negative. We expect this over: glacier, wetland, ocean, and lake, but we could only assess that inside the land model. Inside of CMEPS you won't know what landunit it is. If you get negative runoff elsewhere that could indicate something is wrong inside of CTSM. I'm just wondering if that's a "con" for this approach? Although on the other hand you could check if runoff is negative over other landunits where it's not expected and still have that inside of CTSM, even with the general handling of negative runoff in CMEPS. Any reaction to that? I'm kind of thinking the check for negative runoff for landunits that this isn't expected might be the thing to do. |
Beta Was this translation helpful? Give feedback.
-
|
I agree that any checks for negative runoff should be in CTSM. Not only are things separated by landunit there, but they are also separated by different runoff variables, so you can check that certain runoff variables are non-negative while allowing others (like qrgwl) be negative. |
Beta Was this translation helpful? Give feedback.
-
|
I talked to Frank Bryan on the shuttle and he gave a few reasons why negative runoff is problematic. The context was that I said we were wondering how hard we need to work to remove all traces of negative runoff vs just removing most negative runoff. He gave the following reasons why negative runoff is or may be problematic:
For all these reasons, he would really like to see no instances of negative runoff so they can just assume that it is always non-negative. In particular, he feels like the solution we have proposed to distribute negative runoff globally (decreasing positive runoff proportionally) would be significantly better than having negative runoff. (Though I realize that there is still a theoretical possibility that we'd end up with a negative runoff residual that cannot be compensated for by positive runoff in this time step, so they may still need conditionals to deal with this unlikely possibility.) |
Beta Was this translation helpful? Give feedback.
-
|
Following up with Gustavo today, he's less worried about the non-physical nature of moving water globally, as long as it gets rid of our negative runoff issues. @billsacks I'll let you circle back with a plan on handling this in cmeps vs. the river model after conversations with @slevis-lmwg and @mvertens. |
Beta Was this translation helpful? Give feedback.
-
|
I'm closing this discussion, as we believe the issue on the land side has been resolved. |
Beta Was this translation helpful? Give feedback.
-
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
I'm putting our solution at the top of this discussion for easier tracking
Three parts to this plan discussed at the SE meeting
Beta Was this translation helpful? Give feedback.
All reactions