Hydrologyc Balance

[raj...@gmail.com]

Dear SWAT users

I tried to ckeck the hydrologic balance with the AVSWAT-X 2005
output.hru:

Water Balance Equation Swf = Swi + sum ( Rday - Qsurf - Ea
- Wseep - Qgw)

My output calcualtion for a year
SW_ENDmm = SW_INITmm + (PRECIPmm - SURQ_GENmm - ETmm -
PERCmm - GW_Qmm)
57.606 ?=? 63.568 1331.400
549.557 820.107 31.420 28.159
57.606 ?=? - 34.27

If there is a mistake, who is able to explain me this mistake ?

Thanks in advance

[matt yarr]

I am working with a SWAT2005 project that uses user-defined soil, landuse, and meteorological data. I have been having problems with basin water balance, using average annual values in mm. I have been using two water balance equations:

1. precipitation = runoff + lateral_flow + percolation + evapotranspiration + sublimation + revap
2. precipitation = wateryield + evapotranspiration + deep aquifer recharge + sublimation + revap

I am concerned because the processes on the right hand side add up to 85.30% of the precipitation in the case of equation 1 and  84.84% of the precipitation in the case of equation 2. This is for a 21 year simulation.

I have look over my input data and nothing strikes me as being missing or out of range. If anyone has solved water balance problems in SWAT before, I would appreciate any ideas on what could be causing this discrepancy.

Thanks,

Matt Yarrow

[Jim Almendinger]

Matt -- 

At least in SWAT2000, any water that infiltrates through a surface-water body (Pond, Wetland, Reservoir, or transmission losses from channels) gets trapped in shallow aquifer storage, and thus removed from the water balance.  (I've checked this personally for Ponds -- and have been told it's true for the other surface-water bodies as well.)  This loss is different than loss to deep aquifers, btw.  As far as we can tell, this is a bug in the SWAT code that the developers were unaware of, at least as of July this year.  If indeed it is a bug, I suspect it has been propagated to SWAT2005 as well.  

So -- perhaps this is where your lost 15% of water yield has gone.  

Cheers,

-- Jim

On Sep 20, 2007, at 5:01 PM, matt yarr wrote:

I am working with a SWAT2005 project that uses user-defined soil, landuse, and meteorological data. I have been having problems with basin water balance, using average annual values in mm. I have been using two water balance equations:

1. precipitation = runoff + lateral_flow + percolation + evapotranspiration + sublimation + revap
2. precipitation = wateryield + evapotranspiration + deep aquifer recharge + sublimation + revap

I am concerned because the processes on the right hand side add up to 85.30% of the precipitation in the case of equation 1 and  84.84% of the precipitation in the case of equation 2. This is for a 21 year simulation.

I have look over my input data and nothing strikes me as being missing or out of range. If anyone has solved water balance problems in SWAT before, I would appreciate any ideas on what could be causing this discrepancy.

Thanks,

Matt Yarrow

Dr. James E. Almendinger, Senior Scientist

St. Croix Watershed Research Station

Science Museum of Minnesota

16910  152nd St. N

Marine on St. Croix, MN  55047

tel: 651-433-5953 X 19

fax: 651-433-5924

email: din...@smm.org

web: www.smm.org/SCWRS/

[matt yarr]

Hi Jim,

Thanks for the reply. I checked out seepage and transmission looses. I have 8-9 reservoirs in the model, but I have not allowed any seepage at this point. And transimission losses make up only 0.05% of the total precipitation. So about 15% of the precipitation in the model still appears to be missing. Any other suggestions, anybody?

Thanks, Matt

[matt yarr]

Hello Jim, Nancy, everyone:

I have taken a couple of steps toward figuring out my water balance problem. The short answer is that it appears to be an issue with the ET calculations. Below I discuss the details:

 
Jim asked about the SWAT setup for my basin. I have 122 subbasins, 9 reservoirs, 0 ponds or wetlands. I have set hydraulic conductivity in my reaches to 0 (CH_K2) and also in the reservoirs (RES_K). Therefore I should not have any transmission losses, although the output.std file indicates that 0.05% of the precipitation goes to precipitation losses. Because this is a minor discrepancy, I'll ignore it for now, but I would be curious how I can have losses if all my K values are 0.

 
I used values from the output.std file to calculate the different equations below. As you can see, the annual storage is about 15%, and the question is: where?

 

Annual water balance calculation: Δstorage = Input-output -evap-seep-irr withdrawals						14.97%
Reservoirs (.res) and ponds/wetlands (.hru) have to be balanced individually.						0.17%
First, distinguish between soil water and shallow aquifer.
Precip+irr-ET-perc-sur q-lat q (-tile if applicable) = soil water						14.51%
Recharge-gw q - deep perc -revap = shallow aquifer balance						0.05%
Total Water yield = surf q + lat q + gw q (+tile q if applicable)						-0.05%
Baseflow = [gw q+ lat q (+tile q) ]/ total water yield						88.80%
Precip + irr - wtr yield - deep perc = ET						35.80%
Difference between ET calculated above and output.std value						14.97%
Rule of thumb: ET/precip = 80%					Currently	18.71%

 
It appears that the actual ET calculation is 15% lower than it should be. So, two problems remain to be solved: 1) determine why this is happening and where in the code it is happening 2) determine where the extra 'water' in the model is going.

 
As far as the first question, I switched the PET method from Penman/Monteith to the Hargreaves method and the results showed that roughly the same fraction of the water was not accounted for.

 
As far as the second questions, I looked at the soil water of a few HRUs. Although, the end of the simulation has higher values that the beginning, I am not convinced 15% of the water is stored there. I am also somewhat perplexed by the sudden dropoffs in soil water content that can be seen in the graph attached to this email. It would be helpful to be able to look at the annual soil water storage for the entire basin, anybody know an easy way to do this?

 

I will continue to work on this problem, If anyone knows fast diagnostic methods to pinpoint the problem, or has solved this problem before, please let me know.

 Thanks!

-Matt

On 21/09/2007, Jim Almendinger <din...@smm.org> wrote:

Matt --

Seems to me that you're looking at the right terms in your equations -- and the fact that they give similar results suggests that there is some other component that's missing from both...  but I can't see what it is offhand.  I suppose I should be safe and remind you (though you probably already know this) that SWAT creates conceptual tributaries within subbasins, and you should set their bottom hydraulic conductivity (K) to zero to preclude transmission losses there as well.  I presume groundwater is included in the overall basin water yield...  Otherwise you might just check shallow aquifer storage over time, to see if it is accumulating water -- if so then figure out how much and what's contributing it. Are there any ponds or reservoirs that could be accumulating this much water each year?  After a 21-year run I'd think they'd be at some sort of equilibrium... so this seems unlikely.  

Sorry -- I'm out of ideas.  When you get if figured out, let me know what the answer is!

Thanks,

-- Jim

Spam
Not spam
Forget previous vote

[R. Srinivasan]

I assume you do not have any irrigation at this point. The Soil moisture is direct reflection of ET including soil evaporation.

Even though you have main channel hydraulic conductivity set to zero, have you looked at the tributary channel in .sub files, there the default hydraulic conductivity is 0.5mm/hour

it is surprising you are not getting any difference if you use the two different method of PET models. Where is this watershed and what should be the normal range of AET and PET and what SWAT is simulating?

Srini

At 04:40 PM 9/26/2007, matt yarr wrote:

Hello Jim, Nancy, everyone:

I have taken a couple of steps toward figuring out my water balance problem. The short answer is that it appears to be an issue with the ET calculations. Below I discuss the details:

 
Jim asked about the SWAT setup for my basin. I have 122 subbasins, 9 reservoirs, 0 ponds or wetlands. I have set hydraulic conductivity in my reaches to 0 (CH_K2) and also in the reservoirs (RES_K). Therefore I should not have any transmission losses, although the output.std file indicates that 0.05% of the precipitation goes to precipitation losses. Because this is a minor discrepancy, I'll ignore it for now, but I would be curious how I can have losses if all my K values are 0.

 
I used values from the output.std file to calculate the different equations below. As you can see, the annual storage is about 15%, and the question is: where?

 

Annual water balance calculation:

|¤storage = Input-output -evap-seep-irr withdrawals

Content-Type: image/jpeg
Content-Disposition: inline;
         filename="soilwater.jpg"
X-Attachment-Id: f_f72d0d7d

[matt yarr]

Srini: Thanks for the reply.  Yes, you are correct, the K values in the .sub files are set to 0.5mm/hr.

To clarify, I am getting a difference in the actual value of AET when I use the two different methods of PET calculations. In an 11 year simulation the AET calculated using these methods was:
                       AET             PET
Penman/Monteith    353 mm            754 mm
Hargreaves            484 mm            900 mm

However, what I meant to communicate is that even though the value of AET increases with the Hargreaves method, there is still about 15% of the water that is unaccounted in the global averages. This means that runoff and other processes decrease with Hargreaves.

I am working with a basin in Southern Chile that includes very wet forested areas (>4000mm precip/year), and more open and dryer areas (600-1000mm /year). I have some measured evaporation values from two stations that area representative of these two climatic areas. The winter values are the average daily pan evaporation for a winter month and a summer month and their yearly equivalent ( i.e. multiplied by 365) so as to make comparisons with SWAT output.

	Daily evap mm		yearly equivalent mm
	Winter	Summer	Winter	Summer
Wet /forested	0.64	3.2	233.6	1168
Dryer/open	1.4	4.8	511	1752

In general, because of the low temperatures, high humidity and precipitation in the basin, low AET values would be expected.

Thanks, Matt

[willem vervoort]

Dear all,
I have been following your discussion with interest and have decided to do some of my own calculations.
I am sorry to say that I can also not make heads or tails out of it, but maybe I am doing something wrong.

I have found some water, it is stored in the reaches, and it amounts to about 12.5% in my case.
I found this by opening the output.rch file and doing:
Flow_in - ET - Tloss - Flow out
Summing over the averages for all years gives me about 89 mm on average 703 mm rainfall. I assume SWAT assumes thisis stored in puddles, billabongs, stream sections etc. Whether this is Matt's missing water, I am not sure. I haven't thought through the total conceptual thing:
Does SWAT assume the reaches are empty when you start?
That would be an important reason for a considerable warm-up time.

I started at the HRU level, thinking that this would be easier. I thought, at least the water balance at the HRU level should close. So I did (using output.hru):
SW_INIT + PRECIP + Irr - ETmm  + REVAP - PERC - Wyield
I think this should  be = SW_END But..... It is not (see attached file). While they are correlated the values in individual HRU's can be quite different and the regression is not exactly 1:1. So why is there a difference?
I checked whether it was only the first year, but it is not.

Another issue I noted, I would expect Recharge <= PERC, but in my case it  is often PERC < Recharge ??? Where does that water come from ? Is that Tloss? It does not seem to be...

I hope someone who is very familiar with the source code of the water balance can give us a clue
Willem

[Alejandra Stehr]

The way I calculate the water balance is as follow, maybe this will help you

 

Water Yield = SURQ + LATQ + GWQ – TLOSS

Water Balance: PP = WYLD + ET + DSW + Percolate - GWQ

 

 

WATER BALANCE	Example for one year
Precipitation (PP)	1501
Evapotranspiration	606
Surf/Subsurface runoff (SURQ + LATQ)	439
Baseflow (GWQ)	282
Water Yield (WYLD)	720
DSoil Water Content (DSW)	31
Percolate	414
Transmission Losses (TLOSS)	1
Balance_year	12

 

I hope this help

 

Alejandra

 

 

 

 

-----Mensaje original-----
De: swat...@googlegroups.com [mailto:swat...@googlegroups.com] En nombre de willem vervoort
Enviado el: Viernes, 28 de Septiembre de 2007 11:15
Para: matt yarr
CC: r-srin...@tamu.edu; swat...@googlegroups.com
Asunto: [SWAT-user:684] Re: Hydrologyc Balance

[matt yarr]

Hello all:

I have not posted again, because I have not found a solution. I looked at what Willem had posted and calculated the .rch balance for my model setup: Flow_in - ET - Tloss - Flow out. It turns out that this balance is slightly negative, but also very minor in the overall basin waterbalance (i.e. about 0.1%). So I doubt this is a problem in my case.  But yes, SWAT does initialize the various water stores (reaches, reservoirs, soilwater) with water. You can see that water yield is positive on the first day of simulation, even with no rain.

I also used the equations Alejandra posted, but this is similar to what I've done in the past. The lack of water balance is still evident using these equations.

I have have looked at snow and it seems that snow balances well and is not accumulating in my basin. In other words, snowfall-snowmelt-sublimation=0.

I have also been examining what is happening with soilwater and AET calculations. But I have not found the silver bullet yet. I will post again when I find something else of interest.

Thanks, Matt

On 02/10/2007, Jim Almendinger <din...@smm.org> wrote:

Willem and Matt --

I haven't seen any further responses to your water balance questions -- were they ever resolved?  Did the post from 

Alejandra Stehr help?  In her case, the numbers seemed to balance.  I too would like to know whether SWAT starts with all of the various "buckets" or "reservoirs" of water (soil moisture, shallow aquifer, channels, ponds, reservoirs, etc.) empty, or with some default initial quantity > 0.  Did Srini ever answer this?  

I briefly checked one of my model runs -- but it was complicated by many Ponds and Wetlands; while Pond output was included in the standard output summary, Wetland output was not.  So to do a proper water balance I'd have to dig into the more complicated output files, and I didn't take the time to do that.  I'm also hindered in this discussion by the fact that I'm using SWAT2000 at present (not SWAT2005), and not all the variables and files have the same names.  

I appreciate your questions on issues like this -- I think they're essential to check the model function, and to give better understanding of what the model is doing.  Sorry I have not been able to shed any more light on the issue.  Let us know if/when you get things figured out.  In general, we have spent a great deal of time just trying to figure out what the SWAT output means -- things that should be easily answerable in a few minutes by the developers.  I'd think they'd be able to figure out the water-balance issues in just a few minutes.  

Cheers,

-- Jim

[willem vervoort]

Hi,
just back and having another look.
Our calculations conform the waterbalance described on page 9 in the
introduction (theory docs). I still have no clue what is happening.
The calculation should be right, the only difference I noted is that
Wyield includes GWQ, and I think I might have to redo the calculation
including the groundwater bucket (but that is a subbasin component).
So I extracted the GWQ, but it makes very little difference. I have
noticed that the problem gets worse when irrigation is included.

I will have to start digging in the source code.

Willem

[willem vervoort]

Digging in the source code I have found a few more things, but I am
not sure whether this will actually solve the gap in the annual
balances.

At the HRU level, some of the surface runoff is stored (I don't know
where) in the HRU level channel. This is related to the lag, so I
probably should not be calculating the water balance at the HRU level.
but at the sub level. However output.sub cannot list irrigation as an
output, which means the calculation becomes quite akward in Excel
(i.e. have to sum irrigation over all HRU's in the sub). It also means
that I then have to add the water in the reaches to make the balance
work. I might have a crack at that.

Maybe someone from the SWAT team in Texas can answer whether we are
wasting our time or give us some guidance.

Willem

[matt yarr]

Hello

With the help of an observant colleague of mine, we figured out that the problem with the waterbalance in our model was the use of WATR land use class. We initially used WATR because we had numerous small lakes and ponds with no detailed information about their volumes or output flow rates and we have areas of permanent snow and a few glaciers in our basin. We figured that using the WATR class would allow water to runoff these areas quickly and would not allow vegetation growth and the potential distortion of nutrient cycles in the basin. However, it seems that WATR does not allow for surface flow or groundwater flow. Instead, all water leaves these HRUs by ET. If the PET is not higher than the precipitation, then water is effectively stored in these HRUs, but not visible in the output, thus affecting global water balance. I have now replaced my WATR landuse with RNGE for the time being (waterbalance is now fine). However, I am not comfortable with the fact that areas of permanent snow will be able to support plant growth and other processes. I would like to ask the SWAT community if anyone has a better way to deal with such areas.

Thanks, Matt

On 08/10/2007, willem vervoort <willemv...@gmail.com> wrote:

Hi,
just back and having another look.
Our calculations conform the waterbalance described on page 9 in the
introduction (theory docs). I still have  no clue what is happening.
The calculation should be right, the only difference I noted is that
Wyield includes GWQ, and I think I might have to redo the calculation
including the groundwater bucket (but that is a subbasin component).
So I extracted the GWQ, but it makes very little difference. I have
noticed that the problem gets worse when irrigation is included.

I will have to start digging in the source code.

Willem

On 10/3/07, matt yarr <yarrm...@gmail.com> wrote:
> Hello all:
>
> I have not posted again, because I have not found a solution. I looked at
> what Willem had posted and calculated the .rch balance for my model setup:
> Flow_in - ET - Tloss - Flow out. It turns out that this balance is slightly

> negative, but also very minor in the overall basin waterbalance ( i.e. about

[Jim Almendinger]

Matt --

Very well done!  Nice job figuring out the cause of the problem -- though I realize a "fix" is not clear at this time.  

Some potential options:

(1) After converting these areas to RNGE (or some other land use that you otherwise don't need), could you not force complete runoff by making CN2 = 1 for these areas?  Not sure how to handle the atmospheric exchanges (P and AET) -- perhaps put an aquatic crop (like rice) in it to approximate perennial open water conditions.  (How odd to think of "rice" growing at altitude in Chile...!  Perhaps it is not worthwhile...)   

(2) In our watershed, we aggregated all areas of closed depression in each subbasin as the fractional area contributing to a SWAT Pond, and we set the area of this Pond equal to the aggregate area of open water in each subbasin.  The problem with this is that all runoff and groundwater "captured" by the Pond becomes trapped in shallow aquifer storage and does not contribute appropriately to baseflow via groundwater recharge.  We feel this is a bug in SWAT2000 that may have been propagated to SWAT2005. The end result is that the water yield from these areas of closed depression ends up, once again, being lost from the whole-watershed water balance. One fix to this is to make Pond storage very large and days to reach target volume likewise large, so that eventual spillage from these areas is as smooth as possible, to mimic what they should be contributing to baseflow.  

Option (1) is a lot simpler to start with.  But in pocked landscapes derived from glacial drift, closed depressions can play an important role in moderating net sediment and nutrient yields from the watershed.  Option (2), however, is not a great "fix" unless the code really can handle delivery of water from Ponds to the channel via groundwater flow.  Then you would just make the Pond bottom K value high enough to infiltrate all water delivered to it from the subbasin.  

Thanks again for your perseverance,

-- Jim

Spam
Not spam
Forget previous vote