determining baseflow from SWAT output files

[Grey Evenson]

Hello!

I have a question regarding interpretation of the output.sub file.  Is it appropriate to take the GW_Qmm attribute as meaning a subbasin's contribution to base flow in the reach network?  I see that elsewhere in the I/O documentation, there is a sentence that states, "Groundwater flow is also referred to as baseflow," in discussing the GW_Q_D parameter describing a HRU's deep aquifer ground water flow contribution.  

Is it appropriate to state that GW_Qmm in output.sub is a subbasin's baseflow contribution?  If not, can someone enlighten me as to how to go about determining baseflow from the SWAT output files?  Sorry if this is an incredibly elementary question.

Thanks!

[Grey Evenson]

No need to answer.  Evidently, there's a need to run the output.rch file through a baseflow separation program.  Please correct me if I'm wrong though!

[Jim Almendinger]

It's not a simple question and deserves further consideration. 

I think the short answer is that you can extract baseflow in two ways:

(1) run the model output hydrograph through a baseflow filter program.

(2) sum up the GW contributions from the subbasins.

If you've got lots of lakes (reservoirs), ponds, and/or wetlands, then you might get quite a difference between these two methods.  And scale may matter -- in simple first order subbasins, the low-frequency component of flow is likely the GW component.  But in a large system with many tributaries, the low frequency component may be due to a mixture of flows from tributaries with different timing of contribution. 

I haven't searched the literature -- but it seems an obvious comparison to make (SWAT GW output vs a baseflow filter).  Perhaps it's published somewhere...

-- Jim

---

From: "Grey Evenson" <greye...@gmail.com>
To: swat...@googlegroups.com
Sent: Wednesday, July 30, 2014 9:06:58 AM
Subject: [SWAT-user:4917] determining baseflow from SWAT output files

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

---

Spam
Not spam
Forget previous vote

--

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

[Grey Evenson]

Thanks, Jim!  Your reply is pretty interesting - especially since my study area does indeed have a lot of wetlands.  In fact, my objective in this SWAT exercise is to tease out the effect of the wetlands upon baseflow.  

I'll do both ways to ensure my conclusions are dependent upon method.  I'll also look into it more and report back if I find anything particularly relevant.

Thanks as always!

Grey

[Grey Evenson]

Hi again Jim and the list, 

It seems there is literature on the topic showing general agreement between groundwater flow from all subbasins and the output from a baseflow filter program (see attached Allen et al. 2000).  Yet I'm uncomfortable using groundwater flow from the subbasins.  It would seem there's a logical inconsistency in that the subbasin approach does not account for the temporal lag from subbasin GW flow (subbasin ground water to reach, and then reach routing procedures to the catchment outlet).  Is that lag not meaningful?  Additionally, looks like there are other reasons for not conflating groundwater flow with baseflow.  See the bit below taken from Price 2011 (also attached).  Again, sorry if this is all obvious to others but I'm just getting into the subject.

"Several sources emphasize that ‘baseflow’ is

not synonymous with groundwater flow, as it

includes water transmitted from shallow unsaturated

storage in addition to significant contributions

as hyporheic flow from phreatic storage

(Anderson and Burt, 1980; Brutsaert, 2005;

Buttle, 1998; Ward and Robinson, 1990). In

addition to bedrock water storage, baseflow is

also derived from the drainage of near-surface

valley soils and riparian zones, as water concentrates

in these areas during and following precipitation

events (Brutsaert, 2005; Smakhtin,

2001)...."

Thus, I think I'll use a baseflow filter program.  I'd be interested to hear alternative opinions though!

[Jim Almendinger]

Grey et al. --

I think the lags you mention are mostly built in to SWAT already.  The delays between recharge and discharge in a subbasin are already accounted for by the gw_delay and alpha_bf parameters, aren't they?  The purpose of these parameters is to spread out the episodic input of groundwater recharge over time, so that its output as gw_q to the reach is appropriately smooth and gradual. 

   The channel routing delay you mention is probably real.  That is, adding up all the gw_q from all the subbasins on any one day probably doesn't correspond exactly to the baseflow-q at the watershed outlet on the same day, because of lags due to channel storage and routing.  But at monthly or annual time scales, I'd think the lags would be of inconsequential.  I suppose it depends on the scale of the basin, and all basins are different, etc. (the usual caveats). 

   In general I think it's encouraging that there is general agreement between gw_q from SWAT and baseflow from hydrograph separation.  They should match up somewhat, because SWAT is trying to mimic streamflow recession explicitly with the alpha_bf parameter.  But SWAT at least is constrained by a mass balance of soil moisture, whereas hydrograph separation is constrained only by the shape of the hydrograph, without regard to mechanism.  They may not always match up, but it's good when they do. 

Thanks for the references.

-- Jim

---

From: "Grey Evenson" <greye...@gmail.com>
To: "Jim Almendinger" <jalmen...@smm.org>
Cc: swat...@googlegroups.com
Sent: Friday, August 15, 2014 8:52:00 AM
Subject: Re: [SWAT-user:4921] determining baseflow from SWAT output files

[Willem Vervoort]

Grey and Jim,

I have been wanting to respond to your discussion as this is definitely a topic of interest for me. Attached is a slide from one of my lectures in which I try to explain this dilemma to students. Basically the spreading of the hydrograph can happen in two ways, either through different flow types (groundwater, shallow subsurface, surface etc) or through arriving from different areas. This makes this whole discussion somewhat complicated.

In SWAT at the subbasing level, Jim is right, here it is a classical groundwater bucket that is used for the groundwater, but there are also delays through SURLAG and possibly through bank storage in the sub basin channel. And if you have tiles switched on, there is another flow paths. Routing in the main channel introduces further delays and spreading, as Jim points out. And yes, at larger time scales some of these delays dissapear.

In the end, this is all just dependent on how you have conceptualised your real catchment and how you think this is best represented in SWAT.

The baseflow program is just a digital filter, it really isn't anything fancy and has no real physical interpretation. While a low pass filter can be understood as groundwater flow in some catchment, Grey is right that you cannot apply this uniformly. It really depends on your hydrological understanding of the catchment.

The reason why I am interested in this is because here in Australia, I believe there is in many places very little groundwater input and most of the spreading in the hydrograph is due to in channel or other delays. We are playing around with hydrochemistry to understand this, but that is also not that easy, depending on the pathways you can have similar signatures for different pathways.... And given long surface water flow paths and high Evaporation, isotopes are also not always helpful.

I guess, if you use the baseflow filter on the real data, and your catchment is groundwater dominated, then inserting an alpha_bf from the filter into SWAT should come out again if you apply the filter to the modelled data. Again, it depends on how you conceptualise the catchment and if you think this should happen or not.

I am still understanding how the model essentially just tells you what you tell it to do, there is just some internal convolution due to the different algorithms interacting. In principle this should mimic reality, but a certain random system might also approach this, and this might explain the popularity of neural networks....

Regards
Willem

--
http://blogs.usyd.edu.au/waterhydrosu/