Re: [GRASS-user] Repeated r.watershed runs

[Laurent C.]

Hello Marco,

Itzï (www.itzi.org) is built upon GRASS and employs a partial inertia
simplification of the Saint-Venant equations.
It is certainly not as hydraulically accurate as the finite-volume
approach of ANUGA, but it gives quite good results as a flood model,
and is likely to be much faster.

Regards,
Laurent


2017-09-04 2:41 GMT-05:00 Marco Alicera :
> Reading the subject and agreeing with Thomas about the limitations of
> r.watershed, I wonder if there is any effort to port any of the models based
> on the shallow water wave equations to grass. I recently read about the
> anuga project https://anuga.anu.edu.au/wiki and it would be nice to use it
> with a more friendly GIS environment.
> Regards
> --
> Marco
>
> 2017-09-01 11:04 GMT+02:00 Moritz Lennert :
>>
>> On 01/09/17 09:50, Ken Mankoff wrote:
>>>
>>> Dear Moritz,
>>>
>>> Yes, the three day estimate is from the first hour of this command:
>>>
>>> seq 14000 | parallel --bar r.watershed elevation=DEM.fixed
>>> flow=runoff.{#} accumulation=acc.{#}
>>
>>
>> Have you checked memory usage. Setting memory= to something higher than
>> the default value of 300MB could possibly speed things up a bit.
>>
>>>
>>> I have a 4-core laptop.
>>
>>
>> Time to find more cores... ;-)
>>
>>
>> Moritz
>>
>>
>>
>> ___
>> grass-user mailing list
>> grass-user@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/grass-user
>
>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Repeated r.watershed runs

[Ken Mankoff]

Dear List,

I solved the issue (defining a fuzzy watershed boundary based on cells that
contribute partial flow to the catchment outlet) by using TauDEM. That
software provides an Upslope Dependency product that is the fractional
contribution of each upslope cell:
http://hydrology.usu.edu/taudem/taudem5/help53/DInfinityUpslopeDependence.html

Note also that in my original post I was concerned about excluding cells
that contribute <50% to a catchment (the real concern is that those cells
had large upstream catchments themselves). The opposite case may also be a
concern: Large quantities of cells that contribute only 51% to a catchment,
but using a binary catchment boundary are considered to be fully in the
catchment.

   -k.
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Repeated r.watershed runs

[Marco Alicera]

Reading the subject and agreeing with Thomas about the limitations of
r.watershed, I wonder if there is any effort to port any of the models
based on the shallow water wave equations to grass. I recently read about
the anuga project https://anuga.anu.edu.au/wiki and it would be nice to use
it with a more friendly GIS environment.
Regards
--
Marco

2017-09-01 11:04 GMT+02:00 Moritz Lennert :

> On 01/09/17 09:50, Ken Mankoff wrote:
>
>> Dear Moritz,
>>
>> Yes, the three day estimate is from the first hour of this command:
>>
>> seq 14000 | parallel --bar r.watershed elevation=DEM.fixed
>> flow=runoff.{#} accumulation=acc.{#}
>>
>
> Have you checked memory usage. Setting memory= to something higher than
> the default value of 300MB could possibly speed things up a bit.
>
>
>> I have a 4-core laptop.
>>
>
> Time to find more cores... ;-)
>
>
> Moritz
>
>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Repeated r.watershed runs

[Moritz Lennert]

On 01/09/17 09:50, Ken Mankoff wrote:

Dear Moritz,

Yes, the three day estimate is from the first hour of this command:

seq 14000 | parallel --bar r.watershed elevation=DEM.fixed 
flow=runoff.{#} accumulation=acc.{#}


Have you checked memory usage. Setting memory= to something higher than 
the default value of 300MB could possibly speed things up a bit.




I have a 4-core laptop.


Time to find more cores... ;-)

Moritz



___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Repeated r.watershed runs

[Ken Mankoff]

Dear Moritz,

Yes, the three day estimate is from the first hour of this command:

seq 14000 | parallel --bar r.watershed elevation=DEM.fixed flow=runoff.{#}
accumulation=acc.{#}

I have a 4-core laptop.

   -k.
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Repeated r.watershed runs

[Moritz Lennert]

Le 1 septembre 2017 09:33:52 GMT+02:00, Moritz Lennert 
 a écrit :
>On 01/09/17 06:41, Ken Mankoff wrote:
>> Hi Micha,
>> 
>> We are getting closer to the issue. Unfortunately I'm also becoming
>more 
>> certain the limitation is real and in GRASS and not my mental model. 
>If 
>> this email does not clarify it, I will draw a picture which may help.
>> 
>>> On 01 Sep 2017, at 00:08, Micha Silver >> > wrote:
>>>
>>> You won't have many upstream cells for those cells along the basin 
>>> boundary, only the few that drain exactly along the watershed
>divide.
>> 
>> I think you are picturing the NC data set and mountains. Greenland is
>
>> flatter. Why can't a divide in an extreme case be near or across a
>lake? 
>> Or alternatively, why can't a major stream flow along the boundary 
>> outside of a divide? In these cases the boundary cells contribute
>49%, 
>> but have large (massive?) upstream catchments themselves, all of
>which 
>> is excluded if a mask is generated from r.water.outlet. If I were
>only 
>> losing the boundary cells (max of n of them, for a boundary n cells 
>> long), I would not worry. This seems like the case in mountainous 
>> regions, but perhaps not on the flatter Greenland ice sheet.
>> 
>> 
>>> The only way that r.watershed can return different results is if you
>
>>> input a different elevation grid. 
>> 
>> R.watershed w/o flow -> r.water.outlet produces a "minimum" basin
>where 
>> partial contributor cells (and the upstream catchments of those
>cells) 
>> are not included.
>> 
>> R.watershed WITH flow produces runoff at point x,y with the
>contribution 
>> from other catchments that partially contribute to this catchment.
>> 
>> Correct?
>
>I think so. If you know how much overland flow you have in each cell (=
>
>flow parameter), then r.watershed should calculate the accumulation of 
>that flow along the way based on the extremely simplified assumption 
>that all that flow remains overland across such a large area.

P.S. One important issue with your approach is that r.watershed is static in 
time. There is no notion whatsoever of how long it takes for flow to move from 
one cell to the next... 

Moritz

___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Repeated r.watershed runs

[Moritz Lennert]

On 01/09/17 06:41, Ken Mankoff wrote:

Hi Micha,

We are getting closer to the issue. Unfortunately I'm also becoming more 
certain the limitation is real and in GRASS and not my mental model.  If 
this email does not clarify it, I will draw a picture which may help.


On 01 Sep 2017, at 00:08, Micha Silver > wrote:


You won't have many upstream cells for those cells along the basin 
boundary, only the few that drain exactly along the watershed divide.


I think you are picturing the NC data set and mountains. Greenland is 
flatter. Why can't a divide in an extreme case be near or across a lake? 
Or alternatively, why can't a major stream flow along the boundary 
outside of a divide? In these cases the boundary cells contribute 49%, 
but have large (massive?) upstream catchments themselves, all of which 
is excluded if a mask is generated from r.water.outlet. If I were only 
losing the boundary cells (max of n of them, for a boundary n cells 
long), I would not worry. This seems like the case in mountainous 
regions, but perhaps not on the flatter Greenland ice sheet.



The only way that r.watershed can return different results is if you 
input a different elevation grid. 


R.watershed w/o flow -> r.water.outlet produces a "minimum" basin where 
partial contributor cells (and the upstream catchments of those cells) 
are not included.


R.watershed WITH flow produces runoff at point x,y with the contribution 
from other catchments that partially contribute to this catchment.


Correct?


I think so. If you know how much overland flow you have in each cell (= 
flow parameter), then r.watershed should calculate the accumulation of 
that flow along the way based on the extremely simplified assumption 
that all that flow remains overland across such a large area.


But I won't get more into the actual sens of doing this as others have 
done this very well.


However, to get to you original problem, you wrote:

"If I do "r.watershed" ~14,000 times I'll get the results, but it will 
take 3 days."


First of all, 3 days running time is not that bad for such an amount of 
data. We're talking less than 20 seconds for each run...


My answer to this would be parallelization. If you have enough cores and 
enough memory (but IIRC r.watershed does not need that much), you can 
make this go much faster, as each run is independent of the others 
(again IIUC). So, if you have 8 cores to spare, you can divide the time 
by (probably a bit less than) 8...


You can look at [1] for some general information and [2] for a specific 
GRASS Python API module for that.


Moritz

[1] https://grasswiki.osgeo.org/wiki/Parallelizing_Scripts
[2] 
https://grass.osgeo.org/grass73/manuals/libpython/pygrass.modules.interface.html?highlight=parallelmodulequeue#pygrass.modules.interface.module.ParallelModuleQueue


Moritz

___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Repeated r.watershed runs

[Ken Mankoff]

Hi Micha,

We are getting closer to the issue. Unfortunately I'm also becoming more 
certain the limitation is real and in GRASS and not my mental model.  If this 
email does not clarify it, I will draw a picture which may help. 

> On 01 Sep 2017, at 00:08, Micha Silver  wrote:
> 
> You won't have many upstream cells for those cells along the basin boundary, 
> only the few that drain exactly along the watershed divide.

I think you are picturing the NC data set and mountains. Greenland is flatter. 
Why can't a divide in an extreme case be near or across a lake? Or 
alternatively, why can't a major stream flow along the boundary outside of a 
divide? In these cases the boundary cells contribute 49%, but have large 
(massive?) upstream catchments themselves, all of which is excluded if a mask 
is generated from r.water.outlet. If I were only losing the boundary cells (max 
of n of them, for a boundary n cells long), I would not worry. This seems like 
the case in mountainous regions, but perhaps not on the flatter Greenland ice 
sheet. 


> The only way that r.watershed can return different results is if you input a 
> different elevation grid. 

R.watershed w/o flow -> r.water.outlet produces a "minimum" basin where partial 
contributor cells (and the upstream catchments of those cells) are not 
included. 

R.watershed WITH flow produces runoff at point x,y with the contribution from 
other catchments that partially contribute to this catchment. 

Correct?

Therefor, running r.watershed 14,000 times gives the correct (including partial 
contributions) runoff each day. 

> The only situation that I can envision where you would rerun r.watershed is 
> when massive earthwork was done, and you have a new/revised elevation dataset

Or I want access to the cells that contribute partially to my drainage basin. 
This matters when those boundary cells may tap into large lakes or catchments 
themselves. This scenario might only exist on the unique topography of 
Antarctica and Greenland. 

  -k. ___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Repeated r.watershed runs

[Ken Mankoff]

Hi Tom,

You sound like my friend reviewer #2. :)

But seriously, I thank you for thinking critically about what I'm trying to do. 
However, the inputs I have come from a couples land/ice/snow/atmosphere 
regional climate model with rain, snowfall, eval, condensations, storage in 
snow and land, and melting of snow and ice. I think it would be incorrect to 
take this product and do anything other than route instantaneously and 
completely at this point. 

  -k. 

Please excuse brevity. Sent from pocket computer with tiny non-haptic feedback 
keyboard. 

> On 31 Aug 2017, at 22:49, Thomas Adams  wrote:
> 
> Ken,
> 
> That would be a gross misapplication of r.watershed and, I'm afraid, is just 
> bad science; I just don't know how to be more clear on that...
> 
> Tom
> 
>> On Thu, Aug 31, 2017 at 3:52 PM, Ken Mankoff  wrote:
>> Hi Tom,
>> 
>> What if we are assuming instantaneous flow and no storage and all of the 
>> input flow variable leaves the system. Then is r.watershed usable to 
>> calculate accumulation?
>> 
>>   -k. 
>> 
>> Please excuse brevity. Sent from pocket computer with tiny non-haptic 
>> feedback keyboard. 
>> 
>>> On 31 Aug 2017, at 21:17, Thomas Adams  wrote:
>>> 
>>> Ken,
>>> 
>>> You wrote:
>>> 
>>> 'If I give r.watershed a precip map as input (flow parameter), doesn't it 
>>> route that water down the DEM? And if I know the x,y coordinate of a point 
>>> in a stream, doesn't the accumulation at that point represent all of the 
>>> up-basin precip that is routed past that point?'
>>> 
>>> ANSWER: NO r.watershed is NOT a hydrologic model and does NOT take 
>>> precipitation as an input raster.
>>> 
>>> 'Daily water runoff from the Greenland ice sheet for ~50 years'
>>> 
>>> ANSWER: NO same as above
>>> 
>>> You want something like r.topmodel or r.sim.water in GRASS, not that I'm 
>>> necessarily suggesting these would meet your needs. There is also ITZI 
>>> (https://www.itzi.org/) which may be appropriate since flow over glaciers 
>>> (if you're focused on glaciers) in Greenland, should be largely impervious.
>>> 
>>> You would need r.watershed and r.water.outlet to aid you in the application 
>>> of hydrologic models like topmodel, ITZI, and sim.water. But, there are 
>>> many dozens more hydrologic models, such as VIC, PRMS, etc.
>>> 
>>> Tom
>>> 
>>> 
 On Thu, Aug 31, 2017 at 3:01 PM, Ken Mankoff  wrote:
 Hi Tom,
 
 > On 31 Aug 2017, at 20:30, Thomas Adams  wrote:
 > You "want 14,000 values" of what??
 
 One grid cell from each of 14,000 accumulation rasters.
 
 > Your original email stated you were "trying to determine flow past a 
 > drainage basin outlet" -- r.watershed does NOT do this, if indeed this 
 > is what you want.
 
 If I give r.watershed a precip map as input (flow parameter), doesn't it 
 route that water down the DEM? And if I know the x,y coordinate of a point 
 in a stream, doesn't the accumulation at that point represent all of the 
 up-basin precip that is routed past that point?
 
 > And you say you have "14,000 flow rasters to be used as input" -- what 
 > exactly are these 'flow rasters';
 
 Daily water runoff from the Greenland ice sheet for ~50 years.
 
 > what is your goal? I may not understand...
 
 To find the daily stream flow at a point, based on the runoff that feeds 
 into that point, or any upstream runoff that eventually makes it to that 
 point.
 
 Clearly there is a miscommunication issue here. I apologize if I am not 
 being clear or using incorrect terminology.
 
   -k.
> 
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Repeated r.watershed runs

[Micha Silver]

  
  


On 08/31/2017 11:03 PM, Ken Mankoff
  wrote:


  
  Hi Micha,
  
  
  I understand what you wrote (I think). I get that the basin
product from r.watershed does not change with SFD or MFD. I
think this is because the flow direction raster from r.watershed
only provides the primary flow direction.

Yes, each pixel gets a single flow direction, one of 8 directions.


  
  
  But the accumulation map doesn't know about boundaries or
basins, does it? At a divide, can water can flow equally in all
8 directions? If so, I think that at the boundary of the basin
delineated by 

That can happen only for a single pixel at the very peak of a
mountain. 

  r.water.outlet there may be a cell that contributed 49%. The
flow direction would show this cell flows away from the basin
boundary because 51% of it does do that, so it is not in the
basin. If I use this basin as a mask, I'm losing 49% of that
cell, and the many upstream cells that contribute to it. 
  

You won't have many upstream cells for those cells along the basin
boundary, only the few that drain exactly along the watershed
divide. And these cells will eventually become part of one basin or
the other. So I guess theoretically you could "loose" some flow
accumulation: 49% of the drainage from those few cells right along
the watershed divide. But this would be an accurate representation
of reality, since that 49% is actually not part of the basin you're
investigating.


  
  
  The inefficient method, running r.watershed 14,000 times,
never considers basins and is therefore not impacted by this
issue. 
  

Not sure I understand that.
The only way that r.watershed can return different results is if you
input a different elevation grid. The r.watershed module is strictly
a geo-morphological analysis - nothing to do with real runoff, only
the terrain, slopes, flow direction, etc. It creates a theoretical
model of where runoff would go. The only situation that I can
envision where you would rerun r.watershed is when massive earthwork
was done, and you have a new/revised elevation dataset.


  
  -k. 


Please excuse brevity. Sent from pocket computer with tiny
  non-haptic feedback keyboard. 
  
  
On 31 Aug 2017, at 21:18, Micha Silver 
wrote:

  
  

  
  The r.water.outlet module takes as input a flow direction
  raster that needs to be created first by r.watershed. So the
  SFD/MFD question is irrelevant at this stage. When you first
  ran r.watershed you chose which method to use for determining
  flow direction for each pixel. Further, SFD/MFD influences
  only the stream routing, not the total number of cells in the
  basin. I'm pretty sure that if you run r.watershed once with
  MFD and again with SFD, you'll get the same basin, only with
  slightly different stream networks. 
  AFAIK there should never be a situation where water is
  directed out of the basin. So all cells that flow into cell C
  are then directed downstream to your final drainage point.
  
  On 08/31/2017 10:04 PM, Ken
Mankoff wrote:
  
  

Yes. This! What you wrote. 


But the issue is that r.water.outlet make basins based
  on SFD, right? What if there are 10,000 cells that feed
  into cell C at x,y, and then cell C feeds 49% (based on
  MFD) into the basin. These 10,000 cells are not included
  in the r.water.outlet basin, are they?
  
    -k. 
  
  
  Please excuse brevity. Sent from pocket computer with
tiny non-haptic feedback keyboard. 


  On 31 Aug 2017, at 20:51, Micha Silver 
  wrote:
  


  

I'm also not clear what you are asking. But risking a
guess:
You could run r.water.outlet *1 time* to get the basin.
Then use that raster as a MASK, so that the next process
will address only the pixels within the basin. Now do a
loop with r.univar on all 14,000 flow rasters, and
you'll get 14,000 results with total, min, max, mean,
etc of the basin pixels for each of the flow rasters.

--
Micha

On 08/31/2017 09:30 PM,
  

Re: [GRASS-user] Repeated r.watershed runs

[Thomas Adams]

Ken,

That would be a gross misapplication of r.watershed and, I'm afraid, is
just bad science; I just don't know how to be more clear on that...

Tom

On Thu, Aug 31, 2017 at 3:52 PM, Ken Mankoff  wrote:

> Hi Tom,
>
> What if we are assuming instantaneous flow and no storage and all of the
> input flow variable leaves the system. Then is r.watershed usable to
> calculate accumulation?
>
>   -k.
>
> Please excuse brevity. Sent from pocket computer with tiny non-haptic
> feedback keyboard.
>
> On 31 Aug 2017, at 21:17, Thomas Adams  wrote:
>
> Ken,
>
> You wrote:
>
> 'If I give r.watershed a precip map as input (flow parameter), doesn't it
> route that water down the DEM? And if I know the x,y coordinate of a point
> in a stream, doesn't the accumulation at that point represent all of the
> up-basin precip that is routed past that point?'
>
> ANSWER: NO r.watershed is NOT a hydrologic model and does NOT take
> precipitation as an input raster.
>
> 'Daily water runoff from the Greenland ice sheet for ~50 years'
>
> ANSWER: NO same as above
>
> You want something like r.topmodel or r.sim.water in GRASS, not that I'm
> necessarily suggesting these would meet your needs. There is also ITZI (
> https://www.itzi.org/) which may be appropriate since flow over glaciers
> (if you're focused on glaciers) in Greenland, should be largely impervious.
>
> You would need r.watershed and r.water.outlet to aid you in the
> application of hydrologic models like topmodel, ITZI, and sim.water. But,
> there are many dozens more hydrologic models, such as VIC, PRMS, etc.
>
> Tom
>
>
> On Thu, Aug 31, 2017 at 3:01 PM, Ken Mankoff  wrote:
>
>> Hi Tom,
>>
>> > On 31 Aug 2017, at 20:30, Thomas Adams  wrote:
>> > You "want 14,000 values" of what??
>>
>> One grid cell from each of 14,000 accumulation rasters.
>>
>> > Your original email stated you were "trying to determine flow past a
>> drainage basin outlet" -- r.watershed does NOT do this, if indeed this is
>> what you want.
>>
>> If I give r.watershed a precip map as input (flow parameter), doesn't it
>> route that water down the DEM? And if I know the x,y coordinate of a point
>> in a stream, doesn't the accumulation at that point represent all of the
>> up-basin precip that is routed past that point?
>>
>> > And you say you have "14,000 flow rasters to be used as input" -- what
>> exactly are these 'flow rasters';
>>
>> Daily water runoff from the Greenland ice sheet for ~50 years.
>>
>> > what is your goal? I may not understand...
>>
>> To find the daily stream flow at a point, based on the runoff that feeds
>> into that point, or any upstream runoff that eventually makes it to that
>> point.
>>
>> Clearly there is a miscommunication issue here. I apologize if I am not
>> being clear or using incorrect terminology.
>>
>>   -k.
>
>
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Repeated r.watershed runs

[Ken Mankoff]

Hi Micha,

I understand what you wrote (I think). I get that the basin product from 
r.watershed does not change with SFD or MFD. I think this is because the flow 
direction raster from r.watershed only provides the primary flow direction.

But the accumulation map doesn't know about boundaries or basins, does it? At a 
divide, can water can flow equally in all 8 directions? If so, I think that at 
the boundary of the basin delineated by r.water.outlet there may be a cell that 
contributed 49%. The flow direction would show this cell flows away from the 
basin boundary because 51% of it does do that, so it is not in the basin. If I 
use this basin as a mask, I'm losing 49% of that cell, and the many upstream 
cells that contribute to it. 

The inefficient method, running r.watershed 14,000 times, never considers 
basins and is therefore not impacted by this issue. 

  -k. 

Please excuse brevity. Sent from pocket computer with tiny non-haptic feedback 
keyboard. 

> On 31 Aug 2017, at 21:18, Micha Silver  wrote:
> 
> The r.water.outlet module takes as input a flow direction raster that needs 
> to be created first by r.watershed. So the SFD/MFD question is irrelevant at 
> this stage. When you first ran r.watershed you chose which method to use for 
> determining flow direction for each pixel. Further, SFD/MFD influences only 
> the stream routing, not the total number of cells in the basin. I'm pretty 
> sure that if you run r.watershed once with MFD and again with SFD, you'll get 
> the same basin, only with slightly different stream networks. 
> AFAIK there should never be a situation where water is directed out of the 
> basin. So all cells that flow into cell C are then directed downstream to 
> your final drainage point.
> 
>> On 08/31/2017 10:04 PM, Ken Mankoff wrote:
>> Yes. This! What you wrote. 
>> 
>> But the issue is that r.water.outlet make basins based on SFD, right? What 
>> if there are 10,000 cells that feed into cell C at x,y, and then cell C 
>> feeds 49% (based on MFD) into the basin. These 10,000 cells are not included 
>> in the r.water.outlet basin, are they?
>> 
>>   -k. 
>> 
>> Please excuse brevity. Sent from pocket computer with tiny non-haptic 
>> feedback keyboard. 
>> 
>> On 31 Aug 2017, at 20:51, Micha Silver  wrote:
>> 
>>> I'm also not clear what you are asking. But risking a guess:
>>> You could run r.water.outlet *1 time* to get the basin. Then use that 
>>> raster as a MASK, so that the next process will address only the pixels 
>>> within the basin. Now do a loop with r.univar on all 14,000 flow rasters, 
>>> and you'll get 14,000 results with total, min, max, mean, etc of the basin 
>>> pixels for each of the flow rasters.
>>> 
>>> --
>>> Micha
>>> 
 On 08/31/2017 09:30 PM, Thomas Adams wrote:
 Ken,
 
 You "want 14,000 values" of what?? Your original email stated you were 
 "trying to determine flow past a drainage basin outlet" -- r.watershed 
 does NOT do this, if indeed this is what you want. And you say you have
  "14,000 flow rasters to be used as input" -- what exactly are 
 these 'flow rasters'; what is your goal? I may not understand...
 
 Tom
 
 On Thu, Aug 31, 2017 at 2:24 PM, Ken Mankoff  wrote:
> Hi Tom,
> 
> I have 1 DEM and 14,000 flow rasters to be used as input. I want 14,000 
> values, one at a specific coordinate from each acc output. 
> 
> I can do this by running r.watershed 14,000 times. That is slow, unless 
> I'm missing something (e.g. It works with I.group variables or Time 
> Series data more efficiently). 
> 
> An alternative approach is possible if I knew the complete drainage basin 
> *and* the fractional value of each cell that contributed to the basin. In 
> this case I don't need to route. But basins from r.watershed or 
> r.water.outlet, I think, use SFD not MFD (no cell is ever in 2 basins, 
> are they?), and I don't know how to get the fractional contribution from 
> each cell. 
> 
>   -k. 
> 
> Please excuse brevity. Sent from pocket computer with tiny non-haptic 
> feedback keyboard. 
> 
> On 31 Aug 2017, at 19:59, Thomas Adams  wrote:
> 
>> Ken,
>> 
>> I'm confused about what you are trying to do with r.watershed, because 
>> the output from the module is:
>> 
>> accumulation=name 
>> Name for output accumulation raster map 
>> Number of cells that drain through 
>> each cell 
>> tci=name 
>> Name for output topographic index ln(a / tan(b)) map 
>> spi=name 
>> Stream power index a * tan(b) 
>> Name for output raster map 
>> drainage=name 
>> Name for output drainage direction raster map 
>> basin=name 
>> Name for output basins raster map 
>> stream=name 
>> Name for output stream segments 

Re: [GRASS-user] Repeated r.watershed runs

[Ken Mankoff]

Hi Tom,

What if we are assuming instantaneous flow and no storage and all of the input 
flow variable leaves the system. Then is r.watershed usable to calculate 
accumulation?

  -k. 

Please excuse brevity. Sent from pocket computer with tiny non-haptic feedback 
keyboard. 

> On 31 Aug 2017, at 21:17, Thomas Adams  wrote:
> 
> Ken,
> 
> You wrote:
> 
> 'If I give r.watershed a precip map as input (flow parameter), doesn't it 
> route that water down the DEM? And if I know the x,y coordinate of a point in 
> a stream, doesn't the accumulation at that point represent all of the 
> up-basin precip that is routed past that point?'
> 
> ANSWER: NO r.watershed is NOT a hydrologic model and does NOT take 
> precipitation as an input raster.
> 
> 'Daily water runoff from the Greenland ice sheet for ~50 years'
> 
> ANSWER: NO same as above
> 
> You want something like r.topmodel or r.sim.water in GRASS, not that I'm 
> necessarily suggesting these would meet your needs. There is also ITZI 
> (https://www.itzi.org/) which may be appropriate since flow over glaciers (if 
> you're focused on glaciers) in Greenland, should be largely impervious.
> 
> You would need r.watershed and r.water.outlet to aid you in the application 
> of hydrologic models like topmodel, ITZI, and sim.water. But, there are many 
> dozens more hydrologic models, such as VIC, PRMS, etc.
> 
> Tom
> 
> 
>> On Thu, Aug 31, 2017 at 3:01 PM, Ken Mankoff  wrote:
>> Hi Tom,
>> 
>> > On 31 Aug 2017, at 20:30, Thomas Adams  wrote:
>> > You "want 14,000 values" of what??
>> 
>> One grid cell from each of 14,000 accumulation rasters.
>> 
>> > Your original email stated you were "trying to determine flow past a 
>> > drainage basin outlet" -- r.watershed does NOT do this, if indeed this is 
>> > what you want.
>> 
>> If I give r.watershed a precip map as input (flow parameter), doesn't it 
>> route that water down the DEM? And if I know the x,y coordinate of a point 
>> in a stream, doesn't the accumulation at that point represent all of the 
>> up-basin precip that is routed past that point?
>> 
>> > And you say you have "14,000 flow rasters to be used as input" -- what 
>> > exactly are these 'flow rasters';
>> 
>> Daily water runoff from the Greenland ice sheet for ~50 years.
>> 
>> > what is your goal? I may not understand...
>> 
>> To find the daily stream flow at a point, based on the runoff that feeds 
>> into that point, or any upstream runoff that eventually makes it to that 
>> point.
>> 
>> Clearly there is a miscommunication issue here. I apologize if I am not 
>> being clear or using incorrect terminology.
>> 
>>   -k.
> 
> 
> 
> -- 
> Thomas E Adams, III
> 1724 Sage Lane
> Blacksburg, VA 24060
> tea...@gmail.com (personal)
> t...@terrapredictions.org (work)
> 
> 1 (513) 739-9512 (cell)
> 
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Repeated r.watershed runs

[Micha Silver]

  
  
The r.water.outlet module takes as input a flow direction raster
that needs to be created first by r.watershed. So the SFD/MFD
question is irrelevant at this stage. When you first ran r.watershed
you chose which method to use for determining flow direction for
each pixel. Further, SFD/MFD influences only the stream routing, not
the total number of cells in the basin. I'm pretty sure that if you
run r.watershed once with MFD and again with SFD, you'll get the
same basin, only with slightly different stream networks. 
AFAIK there should never be a situation where water is directed out
of the basin. So all cells that flow into cell C are then directed
downstream to your final drainage point.

On 08/31/2017 10:04 PM, Ken Mankoff
  wrote:


  
  Yes. This! What you wrote. 
  
  
  But the issue is that r.water.outlet make basins based on
SFD, right? What if there are 10,000 cells that feed into cell C
at x,y, and then cell C feeds 49% (based on MFD) into the basin.
These 10,000 cells are not included in the r.water.outlet basin,
are they?

  -k. 


Please excuse brevity. Sent from pocket computer with tiny
  non-haptic feedback keyboard. 
  
  
On 31 Aug 2017, at 20:51, Micha Silver 
wrote:

  
  

  
  I'm also not clear what you are asking. But risking a guess:
  You could run r.water.outlet *1 time* to get the basin. Then
  use that raster as a MASK, so that the next process will
  address only the pixels within the basin. Now do a loop with
  r.univar on all 14,000 flow rasters, and you'll get 14,000
  results with total, min, max, mean, etc of the basin pixels
  for each of the flow rasters.
  
  --
  Micha
  
  On 08/31/2017 09:30 PM, Thomas
Adams wrote:
  
  

  
Ken,
  

You "want 14,000 values" of what?? Your original email
stated you were "trying to determine flow past a
drainage basin outlet" -- r.watershed does NOT do this,
if indeed this is what you want. And you say you have
"14,000 flow rasters to be used as input" -- what
exactly are these 'flow rasters'; what is your goal? I
may not understand...

  
  Tom
  
On Thu, Aug 31, 2017 at 2:24
  PM, Ken Mankoff 
  wrote:
  

  Hi Tom,
  
  
  I have 1 DEM and 14,000 flow rasters to be
used as input. I want 14,000 values, one at a
specific coordinate from each acc output. 
  
  
  I can do this by running r.watershed 14,000
times. That is slow, unless I'm missing
something (e.g. It works with I.group variables
or Time Series data more efficiently). 
  
  
  An alternative approach is possible if I knew
the complete drainage basin *and* the fractional
value of each cell that contributed to the
basin. In this case I don't need to route. But
basins from r.watershed or r.water.outlet, I
think, use SFD not MFD (no cell is ever in 2
basins, are they?), and I don't know how to get
the fractional contribution from each cell. 
  
  -k. 


Please excuse brevity. Sent from pocket
  computer with tiny non-haptic feedback
  keyboard. 
  
  

  
On 31 Aug 2017, at 19:59, Thomas Adams 
wrote:

  
  

  

  
Ken,
  

I'm confused about what you are
trying to do with r.watershed,
  

Re: [GRASS-user] Repeated r.watershed runs

[Thomas Adams]

Ken,

You wrote:

'If I give r.watershed a precip map as input (flow parameter), doesn't it
route that water down the DEM? And if I know the x,y coordinate of a point
in a stream, doesn't the accumulation at that point represent all of the
up-basin precip that is routed past that point?'

ANSWER: NO r.watershed is NOT a hydrologic model and does NOT take
precipitation as an input raster.

'Daily water runoff from the Greenland ice sheet for ~50 years'

ANSWER: NO same as above

You want something like r.topmodel or r.sim.water in GRASS, not that I'm
necessarily suggesting these would meet your needs. There is also ITZI (
https://www.itzi.org/) which may be appropriate since flow over glaciers
(if you're focused on glaciers) in Greenland, should be largely impervious.

You would need r.watershed and r.water.outlet to aid you in the application
of hydrologic models like topmodel, ITZI, and sim.water. But, there are
many dozens more hydrologic models, such as VIC, PRMS, etc.

Tom


On Thu, Aug 31, 2017 at 3:01 PM, Ken Mankoff  wrote:

> Hi Tom,
>
> > On 31 Aug 2017, at 20:30, Thomas Adams  wrote:
> > You "want 14,000 values" of what??
>
> One grid cell from each of 14,000 accumulation rasters.
>
> > Your original email stated you were "trying to determine flow past a
> drainage basin outlet" -- r.watershed does NOT do this, if indeed this is
> what you want.
>
> If I give r.watershed a precip map as input (flow parameter), doesn't it
> route that water down the DEM? And if I know the x,y coordinate of a point
> in a stream, doesn't the accumulation at that point represent all of the
> up-basin precip that is routed past that point?
>
> > And you say you have "14,000 flow rasters to be used as input" -- what
> exactly are these 'flow rasters';
>
> Daily water runoff from the Greenland ice sheet for ~50 years.
>
> > what is your goal? I may not understand...
>
> To find the daily stream flow at a point, based on the runoff that feeds
> into that point, or any upstream runoff that eventually makes it to that
> point.
>
> Clearly there is a miscommunication issue here. I apologize if I am not
> being clear or using incorrect terminology.
>
>   -k.




-- 
Thomas E Adams, III
1724 Sage Lane
Blacksburg, VA 24060
tea...@gmail.com (personal)
t...@terrapredictions.org (work)

1 (513) 739-9512 (cell)
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Repeated r.watershed runs

[Ken Mankoff]

Yes. This! What you wrote. 

But the issue is that r.water.outlet make basins based on SFD, right? What if 
there are 10,000 cells that feed into cell C at x,y, and then cell C feeds 49% 
(based on MFD) into the basin. These 10,000 cells are not included in the 
r.water.outlet basin, are they?

  -k. 

Please excuse brevity. Sent from pocket computer with tiny non-haptic feedback 
keyboard. 

> On 31 Aug 2017, at 20:51, Micha Silver  wrote:
> 
> I'm also not clear what you are asking. But risking a guess:
> You could run r.water.outlet *1 time* to get the basin. Then use that raster 
> as a MASK, so that the next process will address only the pixels within the 
> basin. Now do a loop with r.univar on all 14,000 flow rasters, and you'll get 
> 14,000 results with total, min, max, mean, etc of the basin pixels for each 
> of the flow rasters.
> 
> --
> Micha
> 
>> On 08/31/2017 09:30 PM, Thomas Adams   wrote:
>> Ken,
>> 
>> You "want 14,000 values" of what?? Your original email stated you were 
>> "trying to determine flow past a drainage basin outlet" -- r.watershed does 
>> NOT do this, if indeed this is what you want. And you say you have "14,000 
>> flow rasters to be used as input" -- what exactly are these 'flow rasters'; 
>> what is your goal? I may not understand...
>> 
>> Tom
>> 
>>> On Thu, Aug 31, 2017 at 2:24 PM, Ken Mankoff  wrote:
>>> Hi Tom,
>>> 
>>> I have 1 DEM and 14,000 flow rasters to be used as input. I want 14,000 
>>> values, one at a specific coordinate from each acc output. 
>>> 
>>> I can do this by running r.watershed 14,000 times. That is slow, unless I'm 
>>> missing something (e.g. It works with I.group variables or Time Series data 
>>> more efficiently). 
>>> 
>>> An alternative approach is possible if I knew the complete drainage basin 
>>> *and* the fractional value of each cell that contributed to the basin. In 
>>> this case I don't need to route. But basins from r.watershed or 
>>> r.water.outlet, I think, use SFD not MFD (no cell is ever in 2 basins, are 
>>> they?), and I don't know how to get the fractional contribution from each 
>>> cell. 
>>> 
>>>   -k. 
>>> 
>>> Please excuse brevity. Sent from pocket computer with tiny non-haptic 
>>> feedback keyboard. 
>>> 
>>> On 31 Aug 2017, at 19:59, Thomas Adams  wrote:
>>> 
 Ken,
 
 I'm confused about what you are trying to do with r.watershed, because the 
 output from the module is:
 
 accumulation=name 
 Name for output accumulation raster map 
 Number of cells that drain through each cell 
 tci=name 
 Name for output topographic index ln(a / tan(b)) map 
 spi=name 
 Stream power index a * tan(b) 
 Name for output raster map 
 drainage=name 
 Name for output drainage direction raster map 
 basin=name 
 Name for output basins raster map 
 stream=name 
 Name for output stream segments raster map 
 half_basin=name 
 Name for output half basins raster map 
 Each half-basin is given a unique value 
 length_slope=name 
 Name for output slope length raster map 
 Slope length and steepness (LS) factor for USLE 
 slope_steepness=name 
 Name for output slope steepness raster map 
 Slope steepness (S) factor for USLE 
 
 I think you want a hydrologic model, and r.watershed is NOT that. What are 
 you trying to obtain?
 
 Tom
 
 
 
 
 On Thu, Aug 31, 2017 at 1:47 PM, Ken Mankoff  wrote:
> Hi List,
> 
> I'm trying to determine flow past a drainage basin outlet. The 
> complicating factor is that I need to do this each day for 40 years. If I 
> do "r.watershed" ~14,000 times I'll get the results, but it will take 3 
> days. It seems that r.watershed is likely calculating many things each 
> time through the loop. Is there a more efficient way to this? A flag to 
> r.watershed that isn't documented? Something with time-series?
> 
> Alternatively, because I only need the flow at the outlet, I could 
> calculate the basin, not route the flow, and instead sum the values in 
> the basin. I assume this would take seconds or minutes rather than days. 
> In this case I'm not sure of the best 
> way to define the basin. I tried doing r.water.outlet upstream from the 
> outlet, but I think this uses SFD, which means the basin may be 
> significantly underestimated.
> 
> I also tried inverting/flipping the DEM and then running r.watershed with 
> convergence=1, and a flow equal to 0 everywhere except 1000 at the outlet 
> (now the source due to the inversion) to see where it flooded upstream 
> (now downstream due to the inversion). This didn't seem to work... 
> because basins are filled and flow routes to the edge of the DEM, I could 
> not pick out the 
> 
> Any advice how to 

Re: [GRASS-user] Repeated r.watershed runs

[Thomas Adams]

Micha,

I was thinking the same... but the ultimate result wanted is still unclear;
hope you are well!

Tom

On Thu, Aug 31, 2017 at 2:51 PM Micha Silver  wrote:

> I'm also not clear what you are asking. But risking a guess:
> You could run r.water.outlet *1 time* to get the basin. Then use that
> raster as a MASK, so that the next process will address only the pixels
> within the basin. Now do a loop with r.univar on all 14,000 flow rasters,
> and you'll get 14,000 results with total, min, max, mean, etc of the basin
> pixels for each of the flow rasters.
>
> --
> Micha
>
>
> On 08/31/2017 09:30 PM, Thomas Adams wrote:
>
> Ken,
>
> You "want 14,000 values" of what?? Your original email stated you were
> "trying to determine flow past a drainage basin outlet" -- r.watershed does
> NOT do this, if indeed this is what you want. And you say you have "14,000
> flow rasters to be used as input" -- what exactly are these 'flow rasters';
> what is your goal? I may not understand...
>
> Tom
>
> On Thu, Aug 31, 2017 at 2:24 PM, Ken Mankoff  wrote:
>
>> Hi Tom,
>>
>> I have 1 DEM and 14,000 flow rasters to be used as input. I want 14,000
>> values, one at a specific coordinate from each acc output.
>>
>> I can do this by running r.watershed 14,000 times. That is slow, unless
>> I'm missing something (e.g. It works with I.group variables or Time Series
>> data more efficiently).
>>
>> An alternative approach is possible if I knew the complete drainage basin
>> *and* the fractional value of each cell that contributed to the basin. In
>> this case I don't need to route. But basins from r.watershed or
>> r.water.outlet, I think, use SFD not MFD (no cell is ever in 2 basins, are
>> they?), and I don't know how to get the fractional contribution from each
>> cell.
>>
>>   -k.
>>
>> Please excuse brevity. Sent from pocket computer with tiny non-haptic
>> feedback keyboard.
>>
>> On 31 Aug 2017, at 19:59, Thomas Adams  wrote:
>>
>> Ken,
>>
>> I'm confused about what you are trying to do with r.watershed, because
>> the output from the module is:
>>
>> accumulation=name
>> Name for output accumulation raster map
>> Number of cells that drain through each cell
>> tci=name
>> Name for output topographic index ln(a / tan(b)) map
>> spi=name
>> Stream power index a * tan(b)
>> Name for output raster map
>> drainage=name
>> Name for output drainage direction raster map
>> basin=name
>> Name for output basins raster map
>> stream=name
>> Name for output stream segments raster map
>> half_basin=name
>> Name for output half basins raster map
>> Each half-basin is given a unique value
>> length_slope=name
>> Name for output slope length raster map
>> Slope length and steepness (LS) factor for USLE
>> slope_steepness=name
>> Name for output slope steepness raster map
>> Slope steepness (S) factor for USLE
>>
>> I think you want a hydrologic model, and r.watershed is NOT that. What
>> are you trying to obtain?
>>
>> Tom
>>
>>
>>
>>
>> On Thu, Aug 31, 2017 at 1:47 PM, Ken Mankoff  wrote:
>>
>>> Hi List,
>>>
>>> I'm trying to determine flow past a drainage basin outlet. The
>>> complicating factor is that I need to do this each day for 40 years. If I
>>> do "r.watershed" ~14,000 times I'll get the results, but it will take 3
>>> days. It seems that r.watershed is likely calculating many things each time
>>> through the loop. Is there a more efficient way to this? A flag to
>>> r.watershed that isn't documented? Something with time-series?
>>>
>>> Alternatively, because I only need the flow at the outlet, I could
>>> calculate the basin, not route the flow, and instead sum the values in the
>>> basin. I assume this would take seconds or minutes rather than days. In
>>> this case I'm not sure of the best way to define the basin. I tried doing
>>> r.water.outlet upstream from the outlet, but I think this uses SFD, which
>>> means the basin may be significantly underestimated.
>>>
>>> I also tried inverting/flipping the DEM and then running r.watershed
>>> with convergence=1, and a flow equal to 0 everywhere except 1000 at the
>>> outlet (now the source due to the inversion) to see where it flooded
>>> upstream (now downstream due to the inversion). This didn't seem to work...
>>> because basins are filled and flow routes to the edge of the DEM, I could
>>> not pick out the
>>>
>>> Any advice how to either a) efficiently route 14,000 FLOW rasters over 1
>>> DEM or b) determine the full basin will be much appreciated.
>>>
>>> Thanks,
>>>
>>> -k.
>>>
>>> ___
>>> grass-user mailing list
>>> grass-user@lists.osgeo.org
>>> https://lists.osgeo.org/mailman/listinfo/grass-user
>>>
>>
>>
>>
>>
>
>
>
> ___
> grass-user mailing 
> listgrass-user@lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/grass-user
>
>
> --
> Micha Silver
> Ben Gurion Univ.
> Sde Boker, Remote Sensing Lab
> 

Re: [GRASS-user] Repeated r.watershed runs

[Micha Silver]

  
  
I'm also not clear what you are asking. But risking a guess:
You could run r.water.outlet *1 time* to get the basin. Then use
that raster as a MASK, so that the next process will address only
the pixels within the basin. Now do a loop with r.univar on all
14,000 flow rasters, and you'll get 14,000 results with total, min,
max, mean, etc of the basin pixels for each of the flow rasters.

--
Micha

On 08/31/2017 09:30 PM, Thomas Adams
  wrote:


  

  Ken,

  
  You "want 14,000 values" of what?? Your original email stated
  you were "trying to determine flow past a drainage basin
  outlet" -- r.watershed does NOT do this, if indeed this is
  what you want. And you say you have "14,000 flow rasters to be
  used as input" -- what exactly are these 'flow rasters'; what
  is your goal? I may not understand...
  

Tom

  On Thu, Aug 31, 2017 at 2:24 PM, Ken
Mankoff 
wrote:

  
Hi Tom,


I have 1 DEM and 14,000 flow rasters to be used as
  input. I want 14,000 values, one at a specific
  coordinate from each acc output. 


I can do this by running r.watershed 14,000 times.
  That is slow, unless I'm missing something (e.g. It
  works with I.group variables or Time Series data more
  efficiently). 


An alternative approach is possible if I knew the
  complete drainage basin *and* the fractional value of
  each cell that contributed to the basin. In this case
  I don't need to route. But basins from r.watershed or
  r.water.outlet, I think, use SFD not MFD (no cell is
  ever in 2 basins, are they?), and I don't know how to
  get the fractional contribution from each cell. 

    -k. 
  
  
  Please excuse brevity. Sent from pocket computer
with tiny non-haptic feedback keyboard. 


  

  On 31 Aug 2017, at 19:59, Thomas Adams 
  wrote:
  


  

  

  Ken,

  
  I'm confused about what you are trying to
  do with r.watershed, because the output
  from the module is:
  
  accumulation=name 
  Name for output accumulation raster map 
  Number of cells that drain through each
  cell 
  tci=name 
  Name for output topographic index ln(a /
  tan(b)) map 
  spi=name 
  Stream power index a * tan(b) 
  Name for output raster map 
  drainage=name 
  Name for output drainage direction raster
  map 
  basin=name 
  Name for output basins raster map 
  stream=name 
  Name for output stream segments raster map
  
  half_basin=name 
  Name for output half basins raster map 
  Each half-basin is given a unique value 
  length_slope=name 
  Name for output slope length raster map 
  Slope length and steepness (LS) factor for
  USLE 
  slope_steepness=name 
  Name for output slope steepness raster map
  
  Slope steepness (S) factor for USLE 
  

I think you want a hydrologic model, and
r.watershed is NOT that. What are you trying
to obtain?

  
  Tom
   

Re: [GRASS-user] Repeated r.watershed runs

[Thomas Adams]

Ken,

You "want 14,000 values" of what?? Your original email stated you were
"trying to determine flow past a drainage basin outlet" -- r.watershed does
NOT do this, if indeed this is what you want. And you say you have "14,000
flow rasters to be used as input" -- what exactly are these 'flow rasters';
what is your goal? I may not understand...

Tom

On Thu, Aug 31, 2017 at 2:24 PM, Ken Mankoff  wrote:

> Hi Tom,
>
> I have 1 DEM and 14,000 flow rasters to be used as input. I want 14,000
> values, one at a specific coordinate from each acc output.
>
> I can do this by running r.watershed 14,000 times. That is slow, unless
> I'm missing something (e.g. It works with I.group variables or Time Series
> data more efficiently).
>
> An alternative approach is possible if I knew the complete drainage basin
> *and* the fractional value of each cell that contributed to the basin. In
> this case I don't need to route. But basins from r.watershed or
> r.water.outlet, I think, use SFD not MFD (no cell is ever in 2 basins, are
> they?), and I don't know how to get the fractional contribution from each
> cell.
>
>   -k.
>
> Please excuse brevity. Sent from pocket computer with tiny non-haptic
> feedback keyboard.
>
> On 31 Aug 2017, at 19:59, Thomas Adams  wrote:
>
> Ken,
>
> I'm confused about what you are trying to do with r.watershed, because the
> output from the module is:
>
> accumulation=name
> Name for output accumulation raster map
> Number of cells that drain through each cell
> tci=name
> Name for output topographic index ln(a / tan(b)) map
> spi=name
> Stream power index a * tan(b)
> Name for output raster map
> drainage=name
> Name for output drainage direction raster map
> basin=name
> Name for output basins raster map
> stream=name
> Name for output stream segments raster map
> half_basin=name
> Name for output half basins raster map
> Each half-basin is given a unique value
> length_slope=name
> Name for output slope length raster map
> Slope length and steepness (LS) factor for USLE
> slope_steepness=name
> Name for output slope steepness raster map
> Slope steepness (S) factor for USLE
>
> I think you want a hydrologic model, and r.watershed is NOT that. What are
> you trying to obtain?
>
> Tom
>
>
>
>
> On Thu, Aug 31, 2017 at 1:47 PM, Ken Mankoff  wrote:
>
>> Hi List,
>>
>> I'm trying to determine flow past a drainage basin outlet. The
>> complicating factor is that I need to do this each day for 40 years. If I
>> do "r.watershed" ~14,000 times I'll get the results, but it will take 3
>> days. It seems that r.watershed is likely calculating many things each time
>> through the loop. Is there a more efficient way to this? A flag to
>> r.watershed that isn't documented? Something with time-series?
>>
>> Alternatively, because I only need the flow at the outlet, I could
>> calculate the basin, not route the flow, and instead sum the values in the
>> basin. I assume this would take seconds or minutes rather than days. In
>> this case I'm not sure of the best way to define the basin. I tried doing
>> r.water.outlet upstream from the outlet, but I think this uses SFD, which
>> means the basin may be significantly underestimated.
>>
>> I also tried inverting/flipping the DEM and then running r.watershed with
>> convergence=1, and a flow equal to 0 everywhere except 1000 at the outlet
>> (now the source due to the inversion) to see where it flooded upstream (now
>> downstream due to the inversion). This didn't seem to work... because
>> basins are filled and flow routes to the edge of the DEM, I could not pick
>> out the
>>
>> Any advice how to either a) efficiently route 14,000 FLOW rasters over 1
>> DEM or b) determine the full basin will be much appreciated.
>>
>> Thanks,
>>
>> -k.
>>
>> ___
>> grass-user mailing list
>> grass-user@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/grass-user
>>
>
>
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Repeated r.watershed runs

[Ken Mankoff]

Hi Tom,

I have 1 DEM and 14,000 flow rasters to be used as input. I want 14,000 values, 
one at a specific coordinate from each acc output. 

I can do this by running r.watershed 14,000 times. That is slow, unless I'm 
missing something (e.g. It works with I.group variables or Time Series data 
more efficiently). 

An alternative approach is possible if I knew the complete drainage basin *and* 
the fractional value of each cell that contributed to the basin. In this case I 
don't need to route. But basins from r.watershed or r.water.outlet, I think, 
use SFD not MFD (no cell is ever in 2 basins, are they?), and I don't know how 
to get the fractional contribution from each cell. 

  -k. 

Please excuse brevity. Sent from pocket computer with tiny non-haptic feedback 
keyboard. 

> On 31 Aug 2017, at 19:59, Thomas Adams  wrote:
> 
> Ken,
> 
> I'm confused about what you are trying to do with r.watershed, because the 
> output from the module is:
> 
> accumulation=name 
> Name for output accumulation raster map 
> Number of cells that drain through each cell 
> tci=name 
> Name for output topographic index ln(a / tan(b)) map 
> spi=name 
> Stream power index a * tan(b) 
> Name for output raster map 
> drainage=name 
> Name for output drainage direction raster map 
> basin=name 
> Name for output basins raster map 
> stream=name 
> Name for output stream segments raster map 
> half_basin=name 
> Name for output half basins raster map 
> Each half-basin is given a unique value 
> length_slope=name 
> Name for output slope length raster map 
> Slope length and steepness (LS) factor for USLE 
> slope_steepness=name 
> Name for output slope steepness raster map 
> Slope steepness (S) factor for USLE 
> 
> I think you want a hydrologic model, and r.watershed is NOT that. What are 
> you trying to obtain?
> 
> Tom
> 
> 
> 
> 
>> On Thu, Aug 31, 2017 at 1:47 PM, Ken Mankoff  wrote:
>> Hi List,
>> 
>> I'm trying to determine flow past a drainage basin outlet. The complicating 
>> factor is that I need to do this each day for 40 years. If I do 
>> "r.watershed" ~14,000 times I'll get the results, but it will take 3 days. 
>> It seems that r.watershed is likely calculating many things each time 
>> through the loop. Is there a more efficient way to this? A flag to 
>> r.watershed that isn't documented? Something with time-series?
>> 
>> Alternatively, because I only need the flow at the outlet, I could calculate 
>> the basin, not route the flow, and instead sum the values in the basin. I 
>> assume this would take seconds or minutes rather than days. In this case I'm 
>> not sure of the best way to define the basin. I tried doing r.water.outlet 
>> upstream from the outlet, but I think this uses SFD, which means the basin 
>> may be significantly underestimated.
>> 
>> I also tried inverting/flipping the DEM and then running r.watershed with 
>> convergence=1, and a flow equal to 0 everywhere except 1000 at the outlet 
>> (now the source due to the inversion) to see where it flooded upstream (now 
>> downstream due to the inversion). This didn't seem to work... because basins 
>> are filled and flow routes to the edge of the DEM, I could not pick out the 
>> 
>> Any advice how to either a) efficiently route 14,000 FLOW rasters over 1 DEM 
>> or b) determine the full basin will be much appreciated.
>> 
>> Thanks,
>> 
>> -k.
>> 
>> ___
>> grass-user mailing list
>> grass-user@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/grass-user
> 
> 
> 
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Repeated r.watershed runs

[Thomas Adams]

Ken,

I'm confused about what you are trying to do with r.watershed, because the
output from the module is:

accumulation=name
Name for output accumulation raster map
Number of cells that drain through each cell
tci=name
Name for output topographic index ln(a / tan(b)) map
spi=name
Stream power index a * tan(b)
Name for output raster map
drainage=name
Name for output drainage direction raster map
basin=name
Name for output basins raster map
stream=name
Name for output stream segments raster map
half_basin=name
Name for output half basins raster map
Each half-basin is given a unique value
length_slope=name
Name for output slope length raster map
Slope length and steepness (LS) factor for USLE
slope_steepness=name
Name for output slope steepness raster map
Slope steepness (S) factor for USLE

I think you want a hydrologic model, and r.watershed is NOT that. What are
you trying to obtain?

Tom




On Thu, Aug 31, 2017 at 1:47 PM, Ken Mankoff  wrote:

> Hi List,
>
> I'm trying to determine flow past a drainage basin outlet. The
> complicating factor is that I need to do this each day for 40 years. If I
> do "r.watershed" ~14,000 times I'll get the results, but it will take 3
> days. It seems that r.watershed is likely calculating many things each time
> through the loop. Is there a more efficient way to this? A flag to
> r.watershed that isn't documented? Something with time-series?
>
> Alternatively, because I only need the flow at the outlet, I could
> calculate the basin, not route the flow, and instead sum the values in the
> basin. I assume this would take seconds or minutes rather than days. In
> this case I'm not sure of the best way to define the basin. I tried doing
> r.water.outlet upstream from the outlet, but I think this uses SFD, which
> means the basin may be significantly underestimated.
>
> I also tried inverting/flipping the DEM and then running r.watershed with
> convergence=1, and a flow equal to 0 everywhere except 1000 at the outlet
> (now the source due to the inversion) to see where it flooded upstream (now
> downstream due to the inversion). This didn't seem to work... because
> basins are filled and flow routes to the edge of the DEM, I could not pick
> out the
>
> Any advice how to either a) efficiently route 14,000 FLOW rasters over 1
> DEM or b) determine the full basin will be much appreciated.
>
> Thanks,
>
> -k.
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user