[GRASS-user] Repeated r.watershed runs

mankoff · August 31, 2017, 5:47pm

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.

teaiii1 · August 31, 2017, 5:59pm

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 <mankoff@gmail.com> 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

mankoff · August 31, 2017, 6:24pm

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 Thu, Aug 31, 2017 at 1:47 PM, Ken Mankoff <mankoff@gmail.com> 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

teaiii1 · August 31, 2017, 6:30pm

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 <mankoff@gmail.com> 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 <tea3rd@gmail.com> 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 <mankoff@gmail.com> 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

Micha_Silver1 · August 31, 2017, 6:51pm

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.

···

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 <mankoff@gmail.com> 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 <tea3rd@gmail.com> 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 <mankoff@gmail.com> 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](mailto:grass-user@lists.osgeo.org)
[https://lists.osgeo.org/mailman/listinfo/grass-user](https://lists.osgeo.org/mailman/listinfo/grass-user)

-- 
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918

teaiii1 · August 31, 2017, 6:53pm

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:24 PM, Ken Mankoff <mankoff@gmail.com> 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 <tea3rd@gmail.com> 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 <mankoff@gmail.com> 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

Sent from Gmail Mobile

mankoff · August 31, 2017, 7:04pm

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 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 <mankoff@gmail.com> 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 <tea3rd@gmail.com> 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 <mankoff@gmail.com> 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](mailto:grass-user@lists.osgeo.org)
[https://lists.osgeo.org/mailman/listinfo/grass-user](https://lists.osgeo.org/mailman/listinfo/grass-user)

-- 
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918

teaiii1 · August 31, 2017, 7:17pm

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 <mankoff@gmail.com> wrote:

Hi Tom,

On 31 Aug 2017, at 20:30, Thomas Adams <tea3rd@gmail.com> 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
tea3rd@gmail.com (personal)
tea@terrapredictions.org (work)

1 (513) 739-9512 (cell)

Micha_Silver1 · August 31, 2017, 7:18pm

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 <tsvibar@gmail.com> 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

-- 
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918

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 <mankoff@gmail.com> 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 <tea3rd@gmail.com> 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 <mankoff@gmail.com> 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](mailto:grass-user@lists.osgeo.org)
[https://lists.osgeo.org/mailman/listinfo/grass-user](https://lists.osgeo.org/mailman/listinfo/grass-user)

-- 
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918

mankoff · August 31, 2017, 7:52pm

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 Thu, Aug 31, 2017 at 3:01 PM, Ken Mankoff <mankoff@gmail.com> wrote:

Hi Tom,

On 31 Aug 2017, at 20:30, Thomas Adams <tea3rd@gmail.com> 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
tea3rd@gmail.com (personal)
tea@terrapredictions.org (work)

1 (513) 739-9512 (cell)

mankoff · August 31, 2017, 8:03pm

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 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 <tsvibar@gmail.com> 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 <mankoff@gmail.com> 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 <tea3rd@gmail.com> 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 <mankoff@gmail.com> 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](mailto:grass-user@lists.osgeo.org)
[https://lists.osgeo.org/mailman/listinfo/grass-user](https://lists.osgeo.org/mailman/listinfo/grass-user)

-- 
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918

-- 
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918

teaiii1 · August 31, 2017, 8:49pm

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 <mankoff@gmail.com> 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 <tea3rd@gmail.com> 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 <mankoff@gmail.com> wrote:

Hi Tom,

On 31 Aug 2017, at 20:30, Thomas Adams <tea3rd@gmail.com> 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.

Micha_Silver1 · August 31, 2017, 10:08pm

Yes, each pixel gets a single flow direction, one of 8 directions. That can happen only for a single pixel at the very peak of a mountain. 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. 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.

···

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.

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 <tsvibar@gmail.com> 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.

-- 
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918

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 <tsvibar@gmail.com> 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 <mankoff@gmail.com> 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 <tea3rd@gmail.com> 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 <mankoff@gmail.com> 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](mailto:grass-user@lists.osgeo.org)
[https://lists.osgeo.org/mailman/listinfo/grass-user](https://lists.osgeo.org/mailman/listinfo/grass-user)

-- 
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918

-- 
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918

mankoff · September 1, 2017, 4:23am

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 Thu, Aug 31, 2017 at 3:52 PM, Ken Mankoff <mankoff@gmail.com> 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 <tea3rd@gmail.com> 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 <mankoff@gmail.com> wrote:

Hi Tom,

On 31 Aug 2017, at 20:30, Thomas Adams <tea3rd@gmail.com> 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.

mankoff · September 1, 2017, 4:41am

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 <tsvibar@gmail.com> 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.

mlennert · September 1, 2017, 7:33am

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 <tsvibar@gmail.com <mailto:tsvibar@gmail.com>> 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

mlennert · September 1, 2017, 7:42am

Le 1 septembre 2017 09:33:52 GMT+02:00, Moritz Lennert <mlennert@club.worldonline.be> 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 <tsvibar@gmail.com
<mailto:tsvibar@gmail.com>> 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

mankoff · September 1, 2017, 7:50am

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.

mlennert · September 1, 2017, 9:04am

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

Marco_Alicera · September 4, 2017, 7:41am

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

···

2017-09-01 11:04 GMT+02:00 Moritz Lennert <mlennert@club.worldonline.be>:

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