RE: Reservoir with Simulated Target Release

[Abbaspour, Karim]

Reservoirs are not always operated based on their physical characteristics, but as needed. Anyhow, when RES_EVOL is reached, then water is released. But if you have outflow from the dam, then this overrides everything. You can just edit reservoir parameters in .res files without needing ArcSWAT.

 

Karim

 

 

 

 

From: swat...@googlegroups.com [mailto:swat...@googlegroups.com] On Behalf Of Bethy Johnstonbaugh
Sent: Thursday, August 03, 2017 8:37 PM
To: SWAT-CUP
Subject: Reservoir with Simulated Target Release

 

Hello,

I am struggling with the Simulated Target Release parameters for the reservoir in my model. I have been testing a broad range of values for NDTARG, IFLOD1R and IFLOD2R, and monthly STARG, in various combinations, and almost every model run releases water immediately as though the dam were not there (see the attached screenshot from SWAT-CUP).

The only parameterization that seems to make a difference is if I set IFLOD1R=September and IFLOD2R=Jul. That creates a run with no flow, regardless of NDTARG or STARG.

I have a couple of very specific questions:

~Do the monthly entered values override the flood season calculated values?

~How can I erase values in the ArcSWAT interface without entering zero?

And in general, can anyone diagnose where I am going wrong? Or suggest other changes I should test?

Thank you,

Bethy

 

--
You received this message because you are subscribed to the Google Groups "SWAT-CUP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to swat-cup+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jim Almendinger]

Things change in the code, but my understanding is  --

(1) All volume above EVOL is released the same day it arrives (i.e., no flood mitigation).   I often set EVOL = 1.3 or 1.5 * PVOL. 

(2) Under IRESCO=2 (targeted release), all volume below EVOL but above the "target" volume is released at a rate of 1/NDTARG each day.  I commonly use NDTARG=3, but have occasionally used as large as 10 for some small basins with lots of wetlands.  NDTARG is constrained to be an integer in the code, although in theory it could be a real number. 

(3) If you set monthly STARG values, I believe they take priority, and IFLOD1&2 don't have an effect.  I routinely set all 12 STARG values = PVOL, so my "target" volume is the same as PVOL all the time.  I do this to avoid the next step:

(4) If you don't set STARG values and use IFLOD1&2, then SWAT will set the target volume = EVOL for non-flood months (in the belief that when flooding is not a problem, dam operators will hold back a much water as possible), and for flood-prone months it will calculate a target volume based on soil-moisture in the subbasin (wet soils imply flooding could be a problem so SWAT sets the target volume closer to PVOL to create some available storage volume to mitigate flood flows; dry soils imply flooding is unlikely and so SWAT sets the target volume back up towards EVOL to maximize water stored in the reservoir). 

In other words, unless you set the STARG values yourself as in (3) above, then SWAT will assume (4), namely, that your reservoirs are manipulated to store as much water as is safely possible.  My lakes are never managed this way, and so I avoid it entirely by setting STARG values. 

-- Jim

---

---

NOTE: This message was trained as non-spam. If this is wrong, please correct the training as soon as possible.
Spam
Not spam
Forget previous vote

--
You received this message because you are subscribed to the Google Groups "SWAT-CUP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to swat-cup+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Dr. James E. Almendinger
St. Croix Watershed Research Station
Science Museum of Minnesota
16910 152nd St N
Marine on St. Croix, MN  55047
tel: 651-433-5953 ext 19

[Bethy Johnstonbaugh]

Thank you both for replying.

Karim: I see where I can enter parameters directly into the .res file. It looks as though even where I have not entered anything, the file has "0.0" as a default. Does it treat that as a null value?

Jim: Your summary matches what I came up with from reading documentation. So, if all water is being released the same day it arrive, which is not what I want, should I increase the STARG values?

Also, I just double-checked, and the STARG values were held constant on the run where IFLOD1&2 caused there to be no outflow at all. Can you think of any reason that would happen?

Thanks again,

Bethy

[Jim Almendinger]

Karim: I see where I can enter parameters directly into the .res file. It looks as though even where I have not entered anything, the file has "0.0" as a default. Does it treat that as a null value?

If you're talking about the res table in the ArcSWAT project database, you should populate the table with real values.  Often, when SWAT sees a "0.0" in input, it then uses a default value -- but I'm not sure SWAT has any defaults for reservoir parameters (I've never tried using zeroes as input).

Jim: Your summary matches what I came up with from reading documentation. So, if all water is being released the same day it arrive, which is not what I want, should I increase the STARG values?

No.  When all the water is released the same day, it usually means either (a) the reservoir is at its EVOL and hence has no storage available, or (b) NDTARG = 1 which forces all water above the target volume to be released.  You want to create a credible gap in volume between EVOL and your target volume (for which I use PVOL) so there is a range of volumes over which flow will be released incrementally.  So either increase EVOL or decrease PVOL & STARG, or both.  And set NDTARG > 1. 

Also, I just double-checked, and the STARG values were held constant on the run where IFLOD1&2 caused there to be no outflow at all. Can you think of any reason that would happen?

STARG1-12 are constant input values, not output, and so they don't change during a model run.  If there's no outflow, that means the res vol was below the target, which can happen when evaporation or seepage is controlling the volume.  I don't know what you mean by IFLOD1&2 causing no outflow...  so perhaps I'm missing something. 

Cheers,

-- Jim

Spam
Not spam
Forget previous vote

--

[Bethy Johnstonbaugh]

Well, just for testing, I have tried running it with STARG and PVOL much lower (I dropped the value from 2,391 10^4 m3 down to 1,000) and EVOL much higher (raised from 8,083 up to 16,000). NDTARG=10. All the water is still released the same day.

Is there any other tactic I can use to isolate which of the multiple possible causes is affecting my model? Or other parameters I should be testing, since these do not seem to be controlling the situation?

After a crash and a failed back-up last night, I can't recreate the no-flow issue with IFLOD, so I'm not going to worry about that any more right now.

[Jim Almendinger]

A few more comments:

-- Make sure your reservoir K = 0, to stop any out-seepage that may lower the volume below PVOL. 

-- After making changes to the database -- you are writing the results to the text files in the txtinout folder, right? 

Other than that I'm at a loss. 

-- Jim

---

[Bethy Johnstonbaugh]

Well, thank you for the help. If I figure it out, I will post again.

[Bethy Johnstonbaugh]

As is often the case, my results were flawed because I misunderstood the structure of the model. I was reading flow from the .rch file, when I should have been using the .rsv file. The reach calculation stops upstream of the reservoir, which is why no changes to the .res file made any difference.  The inflow to the next subbasin downstream is also equal to the outflow from the reservoir, which allow a nice work-around in SWAT-CUP.

Thanks you professor Srinivasan for helping me figure this out.

[Jim Almendinger]

Good to know it's just a simple mistake.  If you're like the rest of us, you'll only have a couple hundred more of these...

As for inflow to the next downstream reach from the reservoir -- it includes not only the outflow from the reservoir, but also any water yield from that reach's subbasin, I believe.  Flows_in can be heavily dominated by the outflow from above, but usually includes a little contribution from the local subbasin. 

In contrast -- the inflow to a reservoir exactly equals the outflow from that subbasin's reach, because there is no direct input to the reservoir from the subbasin -- it's all handled as water yield to the reach. 

[lijua...@gmail.com]

Dear  Bethy and Jim,

After reading the conversation between both of you, I have sucessfully run my SWAT with reservoir  under IRESCO=2 (targeted release).

And my SWAcup under three hydrological station with good NS and R2.

However, when I compare the  reservoir volume from .rsv output, I found that the simulated results are largely higher than observed  reservoir volume. And the flowout from .RSV output is not euqal to flowout of the subbasin where reservoir is.

Therefore, I have two problems:

First, could I use the  reservoir volume to calibrate with SWATcup and I did not see .RSV in the SWAT cup.
Second, why is the flowout from .RSV output not euqal to flowout of the subbasin where reservoir is?

Looking forward to hear from you.

Thank you very much.

[rimno...@gmail.com]

Dear all, 

I built swat model with reservoirs, calibrate it and validate it. I noticed that the water balance in the model with reservoirs and without reservoirs appears to be identical. I tested this further by changing the reservoir parameters using extreme input values in order to force large variations. However, the water balance reported in the .std file remained unchanged, while the outputs in the .res file did change.

Based on this observation, I concluded that the reservoir package calculations might be performed separately from the main basin water balance reported in the .std file.

I would appreciate it if you could confirm whether this deduction is correct, or if there is another explanation for this behavior.

Best regards,