Ctsm sectorwater pull request v2

[TaranuDev]

Description of changes

In this model development, we add support for sectoral water abstractions in CESM. In many ways, this development is similar to the one done for irrigation abstractions already.

The withdrawal, consumption and return flow fluxes are computed daily in the land component based on monthly input data. The information about the fluxes is communicated through the coupler to the routing model MOSART, from where the requested water is supplied. At 1 day cycle, withdrawal and recycling of water happens at the same time. For example, if 1km3 is abstracted and there is a local 80% recycling rate, then 0.8km3 is returning to the river network in the same day. The consumption flux (considered water lost in the process of usage due to various factors) is disposed on the surface of soil columns with natural vegetation. From there this water, will participate in the surface water-energy balance through evaporation, runoff, infiltration...

The supported sectors are domestic, livestock, thermoelectric, manufacturing and mining. Together with irrigation, this cover most of the known human water usage across the globe.

In addition to expected fluxes, if the user activates through the namelist, to limit sectoral abstraction based on river water availability, the model computes actual water withdrawals. In this case, when water is limited, a sectoral competition is happening between the sectors. At the moment, the sectoral competition algorithm is very simplistic. It is based on the principle that each sector is satisfied in the order of their priority. The current priority from highest to lowest is the following: domestic, livestock, thermoelectric, manufacturing, mining, irrigation (we also connected the irrigation module to our development, so irrigation also competes for water now).

Specific notes

Contributors other than yourself, if any: I am the sole contributor in terms of code development. But I did received support and feedback during the development and validation process. See more information about people involved in the corresponding issue section.

CTSM Issues Fixed (include github issue #): #1699

Are answers expected to change (and if so in what way)? In the land component, there will be some small changes in the surface water-energy balance due to the fact that we apply the consumed water for sectoral usage on top of the soil columns covered by natural vegetation.

In the routing model, there will be some changes to the total water storage (VOLR) and final discharge into the oceans, since the sectoral water usage have a consumption element (meaning that the withdrawal is larger than the return flow, as some water is lost in the process and may not return to the river).

Any User Interface Changes (namelist or namelist defaults changes)? Yes, we introduce 4 namelist variables and multiple output variables. Normally, everything is very well documented in the code, and the addition of namelist variables and output variables was done following existing CESM practices. The namelist variables added are: sectorwater = .true. or .false. (if .true. we allow sector water abstractions; default is .false.) limit_sectorwater_if_rof_enabled = .true. or .false. (if .true. limit abstractions based on river water availability) sectorwater_river_volume_threshold = [0, 1] (default 0.1, which fraction of current river volume storage can be used to satisfy demand; as for irrigation, simply used to avoid negative routing or taking too much) path_sectorwater_input_data = 'some_path' (path to input data .txt file, default ' ' )

Then we also have multiple outputs which can be specified by the user in the namelist (both for the CLM and MOSART).

Testing performed, if any: Many tests were performed to make sure the model is performing as intended. This include:

1. Model is running without issues or crashing (including longer runs of 30 years)
2. Matching original input data at global scale, but also spatial details, with the data prepared with CTSM tools (check robustness of surface data)
3. Expected withdrawal, consumption and return flow fluxes aggregated at monthly level are matching the input data (inside the model)
4. Actual withdrawal, consumption and return flow fluxes always lower or equal to their corresponding expected fluxes
5. Globally when water limitation is off the actual fluxes are the same as the expected ones; but when water limitation is on the actual fluxes becomes lower than the expected ones according to local availability of water
6. When water limitation is on, we should see coherent sectoral competition according to the provided sectoral priority
7. Fluxes from land model matching fluxes from routing model
8. Consumed total flux should be consistent with input data (internal check) and the water conservation should be kept (check at column and gridcell level performed)
9. When there is no limit on both irrigation and sector water abstractions, the total irrigation abstractions should not change much as consumption flow applied on the columns with natural vegetation, so there is little to interference with irrigated columns.
10. If limit is placed on abstractions, total irrigation withdrawal should be lowered when there is competition with other sectors.

For all these tests we have got positive results. Currently, we are beginning the preparation for our first paper on the topic, where we will present the development. If during the preparation of the paper any bug will be found, we will swiftly communicate this and make the corrections. But we hope this will not happen, taking into account the extensive testing and validation, and the carefull checking of code on a dozen occasions.

For any questions, please contact me at [email protected].

Cheers, Sabin

[wwieder]

Thanks for opening up this PR, Sabin. This is exciting work.

Have you been working with or communicating with anyone else in the LMWG on this work that we should bring into the conversation? Regardless, we'll have a look at your PR and start making a plan to move forward.

[TaranuDev]

Hi Will,

Thanks for the interest in our work! Please let me know if there will be any questions/problems.

Yes, as I mentioned in the issue section #1699, I was communicating and getting feedback from: David Lawrence, Erik Kluzek, Sean Swenson, Naoki Mizukami and Andrew Wood. They are all more or less aware of this development, and some of the earlier stage results.

I was also thinking to invite Peter Lawrence at some point in the discussion, specifically for the future sectoral water usage scenarios part, which we will do quite soon (probably this summer). He seemed interested during our mail exchanges, but I didn't have the chance to have a proper meeting with him yet.

If you have some suggestions of other scientists which may be interested in this project and this line of research, please let me know.

Best regards, Sabin

[wwieder]

Thanks for the discussion today @Ivanderkelen, @TaranuDev, @ekluzek, @dlawrenncar, @swensosc & Wim.

We want to support continued contributions from your group, but clarify that this PR may not be a priority for a CESM3 release timeline (mainly because of limitations in the dataset time series (1970-2010). That said, there are some suggestions for how to continue developing this work so it doesn't fall off our radar and is easier to maintain.

• [ ] Bringing in the CTSM code for sector water use may be easier to accomplish. This could be done by @ekluzek or another CTSM SE.
  • Should this be integrated into main development branch, and only used for limited application (e.g. MIMICS), or migrated to a separate development branch (like FAN)?
  • One question I still had was: I'd suspect at this point mosart application is preferred, realizing this will duplicate effort to translate into mizuRoute down the road (which is the long-term goal)?
• [ ] Managing datasets is a more difficult task that can be maintained (for now) by @TaranuDev and Wim’s group. Maybe this can be separated from this PR?
  • To facilitate wider integration into CTSM @TaranuDev can create a full historical and SSP time series (1850-2100) that integrates with the GCAM team?
  • After generating this raw dataset, it should be simple enough to maintain with tools from mksurfdata_esmf (currently on CTSM-5.2 branch).

---

A few questions that came up in the meeting and Sabin's response are in italics below:

1. Where does water go that's removed for different sectors? Spread on vegetated land surface or it goes back to the river.
2. Is irrigation on your input dataset, or calculated dynamically by CLM (as before). Model calculates own demand, but can be compared with dataset estimates of irrigation withdraws
3. Why not use groundwater option in CTSM? Opted not to use ground water because it's spatially poorly constrained. @dlawrenncar emphasized the updated groundwater scheme is using the resolved soil existing soil water + @swensosc clarified there is also an unconfined aquifer storage term.
4. Dataset suggestions for longer runs? Discussions of ongoing with GCAM & ISIMIP communities
5. How are the demand files ingested? It seems like these data are on surface datasets, Would creating them as steams be easier to maintain, @ekluzek?
6. Timeline for @TaranuDev PhD's & continued work by Wim's group ? Sabin has another 2.5 years, but unsure about next steps (maybe creating future datasets)?

[TaranuDev]

Thanks for the detailed feedback and interesting discussion @wwieder, @ekluzek, @dlawrenncar and @swensosc!

We understand that considering the time and resources constraints, your current priority is to integrate the PRs with the highest value in terms of climate applications and consider the role of CTSM within the CESM3 coupled system. In addition to this, the fact that our current PR is supporting only the period 1970-2010, relies on the old CTSM tools, ingest the input data through the surfdata and have support for MOSART only, is not optimal and is too much to handle on your side.

As mentioned before, I have 2.5 more years in my PhD, and with Wim we already approved that having this sectoral water abstractions module into CTSM will be our main priority. We see a lot of value in this development for impact applications (e.g. water scarcity, droughts impact, food-energy-water nexus, etc.) and increasing the presence of the CLM/CTSM model in the ISIMIP community.

As such, we do intend to provide full support in making this PR possible and here is the plan we suggest:

1. Currently we are writing a model development paper for the historical period 1970-2010, where we will document the modelling, which was done, validation and some applications. We expect to submit the paper this summer.
2. Directly after, we will work on a paper for future applications. Here we will prepare harmonized water usage datasets from 1850-2100 for all scenarios (in this regard we need to coordinate with you to get the full list of scenarios which may be required). We will also update the way input data is ingested by using the new mksurfdata_esmf tool and changing to timeseries instead of surfdata if needed (again, we will coordinate with you on this).
3. Normally after (1) and (2), most of your concerns will be covered, so once this work will be finished we will update the PR and meet again to discuss potential timeline for this integration.
4. When it comes to extend the support to MizuRoute, we are 100% ready to do this ourselves. To be able to do so, it would be helpful to already have (3) in progress, have MizuRoute fully coupled to the CTSM, as well as the irrigation support already being done. If all conditions are satisfied, it wouldn't be too hard for us to add support for the sector abstractions to MizuRoute.

Now, when it comes to bringing our code into the development branch of CTSM, this would be extremely helpful and we would gladly accept this offer. As you also mentioned during our meeting, keeping up to the development branch updates is extremely difficult, so this would help a lot. Most of the source code will not change, as for now it seems that we will only have to update the mksurfdata_esmf tool and the input ingestion method. So having our code on the development branch already, will also speed the integration process later on when we will satisfy all the concerns we previously discussed.

I would like to know your opinions on this work plan? As we mentioned, there will be some instances where we will reach to you to further coordinate our actions. This way we can maximize the chance that our development is in line with CTSM long-term plans.

Best regards, Sabin

[wwieder]

After further discussion we'd like to bring in the CTSM side of this PR with namelist changes so that users have to turn on this feature under limited applications. @samsrabin is likely going to have time to work on this after doing some additional crop model developments (maybe by the end of this summer). The code should also have a science review, maybe @swensosc can have a look on this (also not urgent given other priorities)?

[dlawrenncar]

Has any testing been done? Perhaps to accelerate things, Sabin could run the short test suite. That would catch it if there is a big problem (i.e., that when turned off it is not bit-for-bit. In general, it would be good to make it possible for external collaborators to easily run the simple test suite, which could help things move along faster. I know we have talked about this before and some people have done it, I think.

On Thu, May 25, 2023 at 10:24 AM will wieder @.***> wrote:

After further discussion we'd like to bring in the CTSM side of this PR with namelist changes so that users have to turn on this feature under limited applications. @samsrabin https://github.com/samsrabin is likely going to have time to work on this after doing some additional crop model developments (maybe by the end of this summer). The code should also have a science review, maybe @swensosc https://github.com/swensosc can have a look on this (also not urgent given other priorities)?

— Reply to this email directly, view it on GitHub https://github.com/ESCOMP/CTSM/pull/1975#issuecomment-1563185870, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFABYVEGTBCP3WLO6XZSJLLXH6BUXANCNFSM6AAAAAAWLWRPFI . You are receiving this because you were mentioned.Message ID: @.***>

[TaranuDev]

@wwieder, thanks for the update. As mentioned, we can provide any required assistance in the process.

@dlawrenncar, I did some tests (a complete list can be found in the description of this pull request https://github.com/ESCOMP/CTSM/pull/1975). My intention was to compile all the testing and validation into a series of Jupyter notebooks, which will be published with the development paper. Please, let me know if there is some additional testing, which is required.

[dlawrenncar]

I am referring to our systems tests which we use to make sure things like exact restarts work and that there aren't any divide by zero possible situations, etc. These are not science tests, but software tests. The full suite of tests runs into the hundreds of tests, but there is a smaller one that catches some of the most common errors.

On Wed, May 31, 2023 at 2:03 AM Sabin @.***> wrote:

@wwieder https://github.com/wwieder, thanks for the update. As mentioned, we can provide any required assistance in the process.

@dlawrenncar https://github.com/dlawrenncar, I did some tests (a complete list can be found in the description of this pull request #1975 https://github.com/ESCOMP/CTSM/pull/1975). My intention was to compile all the testing and validation into a series of Jupyter notebooks, which will be published with the development paper. Please, let me know if there is some additional testing, which is required.

— Reply to this email directly, view it on GitHub https://github.com/ESCOMP/CTSM/pull/1975#issuecomment-1569691362, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFABYVDMJG4OPW2SY3JJB5LXI33LHANCNFSM6AAAAAAWLWRPFI . You are receiving this because you were mentioned.Message ID: @.***>

[samsrabin]

Thanks for the extensive testing you've done already, @TaranuDev ! Dave is right that a bit more using the built-in testing tools would be nice to try and identify any hidden bugs. Fortunately, it's pretty simple to do a few quick tests using the run_sys_tests script.

Some notes first:

• If you run into any issues running the tests, please start a discussion rather than replying here. This will keep the issue focused and provide help for others with similar issues in the future.
• This works for me on the Cheyenne cluster; I haven't tried others.
• My instructions assume you've cd'd to the top level of your CTSM codebase, where run_sys_tests lives.
• Make a directory (or choose an existing one) I'll refer to as $BASELINE_ROOT. In there, a directory will be created that will take up about 250 MB.

First, run the test suite with the version of CTSM you branched from (or the most recent version you merged in), which seems to be ctsm5.1.dev119:

git checkout ctsm5.1.dev119
./run_sys_tests -s clm_short --generate ctsm5.1.dev119_clmshort_baseline --skip-compare --baseline-root $BASELINE_ROOT

The tests will be set up and run from the directory given in the first line of the output of that command. Once they've started, you can check their status by going there and doing ./cs.status. When they're complete, you should see a bunch of lines starting with PASS.

The tests whose names start with ER are "exact restart" tests. These check that the code produces the same results when doing a run straight through vs. the same period but split into two parts. The results of these checks are indicated on the COMPARE_base_rest lines.

When that's done, you can re-run the tests with your code like so, which will also compare the outputs bit-for-bit with the previous run:

git checkout ctsm_sectorwater_pull_request_v2
./run_sys_tests -s clm_short --compare ctsm5.1.dev119_clmshort_baseline --skip-generate --baseline-root $BASELINE_ROOT

./cs.status should eventually give you the same outputs as before, but with new BASELINE ctsm5.1.dev119 lines for the comparison results.

You can find more details on any failed comparisons using the instructions here. Try looking for output variables with large normalized root mean square (RMS) errors, as these are the ones that see the largest relative difference between runs.

[TaranuDev]

@dlawrenncar, thanks for the clarifications, we didn't run these tests yet, but we will do it.

@samsrabin, thank you for the detailed instructions, it is very helpful! I will run these tests in the near future. If I have any issues, as suggested, I will start a discussion in the dedicated section.

[samsrabin]

Just an update about the timeline here: The plan at this point is for me to work on integrating this in the late summer.

@TaranuDev, if you could get those tests done in the next couple of months that'd be excellent. It's not a big deal for me to do the tests myself, but if they reveal any issues it'd be best for you to get a head start on fixing them.

[TaranuDev]

Thanks for the update @samsrabin!

I planned to do the tests by the end of the next week. I will update you on the status and if there are any issues as soon as the results are available.

Cheers, Sabin

[TaranuDev]

Quick update on the requested testing:

I did the run_sys_test. For each case, I got a PASS for all tests except NLCOMP and BASELINE (DIFF).

I expected the NLCOMP to fail since I add new namelist variables. But I was surprised to see the BASELINE tests to fail.

At the moment, I did a quick check of the log files for the ERP_D case, and I found many non-zero differences. Also in terms of RMS, the normalized differences are not large, but I find it strange that so many variables are affected from carbon cycle, to surface energy partitioning and water cycle.

In principle, it is possible that there is a domino effect, where an error in one variable can propagate to many others. As of now, I think two things are possible:

1. I indeed introduced a bug somewhere, and there is a domino effect taking place, with many variables being impacted.
2. I didn't use the correct baseline (the difference in code between the selected baseline version and my development goes beyond what I changed).

For now, I am more inclined to believe that it is the option (2), because when I checked why the NLCOMP failed for ERP_D case, there are a lot of differences unrelated to my development (e.g. a different topography file, extra fields related to O3, etc).

I am giving this incomplete update because I promised to finish the testing last week, and experienced a delay due to work on a different project. I will be on vacation the following two weeks, but when I will be back I will redo the testing and make sure that everything works perfectly.

Sorry for the delays!

Best regards, Sabin

P.S. for the record here is the location of my tests: /glade/scratch/staranu/tests_0704-072504ch ( test results) /glade/work/staranu/run_sys_test_results/results/ctsm5.1.dev085_clmshort_baseline ( I selected my baseline by running git describe --tags on my master branch, does it make sense to do it this way?) /glade/work/staranu/run_sys_test_results/CTSM_code_repo (my code repo used for testing)

[samsrabin]

Hi Sabin,

Thanks for doing those tests! This might indeed be a result of choosing the wrong baseline. From your branch's commit history, it looks like you branched from commit f72479b, which is actually tag ctsm5.1.dev119. Try generating a baseline from that commit instead and see how it looks. But first, enjoy your vacation!

[TaranuDev]

I redid the tests with the correct baseline (ctsm5.1.dev119). I get a PASS on all tests except for NLCOMP and BASELINE.

For the NLCOMP, the test is failing because: "Found extra variable: 'sectorwater'; Found extra namelist: sectorwater_inparm". So this is normal behavior related to the new namelist variables I introduced for this development.

For the BASELINE fails, I get the message: ctsm5.1.dev119_clmshort_baseline: FIELDLIST field lists differ (otherwise bit-for-bit). This is also normal, since I added new output variables. The log files are confirming, that the only difference are the variables I added.

I get the same result for each experiment in the test suit and compiler. Overall, with the additional testing I did on my side on the implementation robustness in terms of model results and stability, it is most likely that the model is ready to be integrated.

The tests results can be found here: /glade/scratch/staranu/tests_0712-040306ch To reproduce the tests results, two changes are required to the code:

1. Add the SectorWaterMod.F90 to the CMakeLists.txt in the src/biogeophys/
2. Delete the space between the beginning of the line for the #include "shr_assert.h" in the src/biogeophy/SectorWaterMod.F90. I think one of the compilers was not happy if there is some spaces/identation for the #include statement. (at the same time, I did not have any issues previously with the compilation, so it was strange to see this problem)

Please let me know if anything else is required.

I will try to finish the paper on this development this August, so that everything, including testing and validation, is well documented. Directly after, I will work on extending the model functionality for future scenarios too, as we previously discussed.

Best regards, Sabin

[samsrabin]

That's great, thanks Sabin! There are more tests to do, but I can handle those. Best wishes for the paper-writing phase; I'm happy to look over a complete draft if you'd like, but totally not necessary.

[swensosc]

I don't understand where the factor of 8 comes from?

On Fri, Sep 8, 2023 at 9:35 AM Sam Rabin @.***> wrote:

@.**** commented on this pull request.

In src/biogeophys/SectorWaterMod.F90 https://github.com/ESCOMP/CTSM/pull/1975#discussion_r1320003453:

•           liv_demand_volr_limited(bounds%begg:bounds%endg)       = liv_demand(bounds%begg:bounds%endg)
  

•           liv_consumption_volr_limited(bounds%begg:bounds%endg)  = liv_consumption(bounds%begg:bounds%endg)
  

•           elec_demand_volr_limited(bounds%begg:bounds%endg)      = elec_demand(bounds%begg:bounds%endg)
  

•           elec_consumption_volr_limited(bounds%begg:bounds%endg) = elec_consumption(bounds%begg:bounds%endg)
  

•           mfc_demand_volr_limited(bounds%begg:bounds%endg)       = mfc_demand(bounds%begg:bounds%endg)
  

•           mfc_consumption_volr_limited(bounds%begg:bounds%endg)  = mfc_consumption(bounds%begg:bounds%endg)
  

•           min_demand_volr_limited(bounds%begg:bounds%endg)       = min_demand(bounds%begg:bounds%endg)
  

•           min_consumption_volr_limited(bounds%begg:bounds%endg)  = min_consumption(bounds%begg:bounds%endg)
  

•      end if
  

•      ! Convert demand to withdrawal rates [mm/s]
  

•      ! Here it also seems like I could directly operate with the this%arrays instead of generating new ones (to check)
  

I will do this.

In src/biogeophys/SectorWaterMod.F90 https://github.com/ESCOMP/CTSM/pull/1975#discussion_r1320023447:

•           ! I think the algorithm is potentially too conservative
  

•           ! I will need to check river discharge when there is high amount of unsatisfied demand
  

•           ! The reason why I am saying this is because we compare the expected demand for the entire day with the current volume available in the river...
  

•           ! It would make sense to use such an algorithm under the condition that volr does not change much during a day for a given gridcell
  

•           ! But if this is not the case we maybe underestimate the amount of water available for usage.
  

•           ! If this would be done once a day, then no problem, but we do it at each time step
  

•           ! This means that volr get
  

Conservative because it's looking at the river once and saying "this is how much water we have." But 3 hours later (timescale of coupling) that river will have flowed some more. So it's basically underestimating the available water by a factor of 8.

Seemingly this is how it's done for irrigation, but it's not as much of an issue there because irrigation is only applied over a 4-hour window (as opposed to 24 for other sectors' demand).

Calculating availability limitation at the 3-hour timestep seems tricky. For now, to see how much difference this might make,Sabin will test multiplying available water in the timestep by 8. Conservation errors will be handled, as for irrigation, by taking extra needed water from ocean.

@swensosc https://github.com/swensosc, do you have any thoughts on the best way to handle this?

In src/biogeophys/SectorWaterMod.F90 https://github.com/ESCOMP/CTSM/pull/1975#discussion_r1320023979:

•           ! I think the algorithm is potentially too conservative
  

•           ! I will need to check river discharge when there is high amount of unsatisfied demand
  

•           ! The reason why I am saying this is because we compare the expected demand for the entire day with the current volume available in the river...
  

•           ! It would make sense to use such an algorithm under the condition that volr does not change much during a day for a given gridcell
  

•           ! But if this is not the case we maybe underestimate the amount of water available for usage.
  

•           ! If this would be done once a day, then no problem, but we do it at each time step
  

•           ! This means that volr get
  

Conservative because it's looking at the river once and saying "this is how much water we have." But 3 hours later (timescale of coupling) that river will have flowed some more. So it's basically underestimating the available water by a factor of 8.

Seemingly this is how it's done for irrigation, but it's not as much of an issue there because irrigation is only applied over a 4-hour window (as opposed to 24 for other sectors' demand).

Calculating availability limitation at the 3-hour timestep seems tricky. For now, to see how much difference this might make,Sabin will test multiplying available water in the timestep by 8. Conservation errors will be handled, as for irrigation, by taking extra needed water from ocean.

@swensosc https://github.com/swensosc, do you have any thoughts on the best way to handle this?

— Reply to this email directly, view it on GitHub https://github.com/ESCOMP/CTSM/pull/1975#discussion_r1320003453, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGRN57A6RT5YVGBWNPY65S3XZM3NLANCNFSM6AAAAAAWLWRPFI . You are receiving this because you were mentioned.Message ID: @.***>

[samsrabin]

Some notes from our very productive meeting this morning:

(1) Sector water input data should probably be provided as a single netCDF file instead of providing path_sectorwater_input_data, which is a list of paths with one netCDF file for each year. Unless there's a reason I'm not aware of?

Sabin modeled this after how flanduse_timeseries was handled in the version of the code he branched from. In the autumn, as he puts together and tests future-period datasets, he will convert to using stream files using the new tooling.

(2) You say that "The consumption flux (considered water lost in the process of usage due to various factors) is disposed on the surface of soil columns with natural vegetation." Could you clarify? "Consumption" to me implies everything that is used; i.e., withdrawals minus conveyance losses (e.g., leaks from pipes). But here it sounds like "consumption" is just anything that's withdrawn for non-irrigation sectors and ends up back on the ground. So, e.g., water evaporated in industrial processes wouldn't be included here. If that's the case, where is that water included?

(3) Dumping all "consumed" water on the natural column will affect plants and soils. That's true for some consumed water, but in reality some goes directly into rivers (or is evaporated, as discussed above). Is there any way around this? Could dump it all into ocean, but even that wouldn't account for evaporated "consumption."

All consumption is added to precipitation. The thought here was to minimize how directly we mess with coupled components. Sending to the ocean would likely cause similar complaints about how we withdraw from the ocean for unmet irrigation demand in the existing model; sending everything to atmosphere might mess with energy fluxes too much. For what it's worth, these fluxes are pretty minimal—on average ≤ 50 mm/year almost everywhere. I think I'd like to have a discussion with some others about whether there's a better way to do this, but for now we'll leave it.

(4) What is the reason for passing both withdrawal and return flow from the land to the rivers? Could these be combined into one "net withdrawal" value?

Eventually, we may want to add some sort of pollution tracers to the return flows (e.g., sediment from mining operations), so we'll keep these separated.

(5) Could all sectors be combined when passing from land to rivers?

This should be possible, yes. Of course, we'll still want to have them separate within CTSM so we can do the demand competition.

---

The plan moving forward is that we can do one PR now without the changes to how the input data files work (or two PRs, first independent of and then dependent on externals updates). Then, when Sabin is done with the input data file rework, we can do another PR to bring that in.

I will also:

• [ ] Add a test configuration
• [ ] Add unit tests as needed

[ekluzek]

This is a work in progress, so converting to draft.

[TaranuDev]

Some potential issue raised by one of the reviewers for the corresponding paper:

-> In the manuscript we mention "It is important to mention here that while the sectoral demand for non-irrigative sectors is generated at the grid-cell level, the consumption (the net transport of water from the river to the land model) is distributed at subgrid level, on the natural vegetation land unit (Fig. A1). This is done to not interfere with the195 cropland and urban land units, which have their own soil columns."

Potential problem: Since we distribute the consumption over natural vegetation land unit, if we go very high resolution, and there will be a grid cell with a single land unit (e.g. urban or cropland), what will happen? (we might add to the code an exception for this case to avoid crashes).

[wwieder]

This won't make it into CLM6 and has been assigned a later milestone. Removing the CLM6 highlights label, Sorry @TaranuDev