Maybe I am overlooking it but the man page for r.watershed does not say what units
the option "flow" should be in - I am guessing it is fraction of 1 (or percent given as decimal - e.g. 50% will be 0.5)
so should flow amount read as fraction or something like that, so that if
all rainfall turns to runoff = 1
only 50% rainfall turns to runoff (rest is captured by vegetation or infiltrates) = 0.5
am I understanding it correctly? if yes should some explanation go into manual?
thanks,
Helena
Helena wrote:
Maybe I am overlooking it but the man
page for r.watershed does not say what units
the option "flow" should be in - I am guessing it is
fraction of 1 (or percent given as decimal - e.g. 50% will
be 0.5)so should flow amount read as fraction or something
like that, so that if all rainfall turns to runoff = 1
only 50% rainfall turns to runoff (rest is captured by
vegetation or infiltrates) = 0.5
I don't think so, it seems to be reading the map as CELL, so
giving it input data in the range of 0.0-1.0 would be binary.
ram/init_vars.c
/* read flow accumulation from input map flow: amount of overland flow per cell */
opened with
G_open_cell_old(run_name, "")
read with
G_get_c_raster_row()
into
G_allocate_cell_buf()
value set as
wat[SEG_INDEX(wat_seg, r, c)] = buf[c];
after that I lose track of what it does.. maybe it is setting up
initial conditions??
should some explanation go into manual?
once we know the answer, sure 
Hamish
Hamish wrote:
Helena wrote:
Maybe I am overlooking it but the man
page for r.watershed does not say what units
the option "flow" should be in - I am guessing it is
fraction of 1 (or percent given as decimal - e.g. 50% will
be 0.5)so should flow amount read as fraction or something
like that, so that if all rainfall turns to runoff = 1
only 50% rainfall turns to runoff (rest is captured by
vegetation or infiltrates) = 0.5I don't think so, it seems to be reading the map as CELL, so
giving it input data in the range of 0.0-1.0 would be binary.
From the manual:
"Overland flow units represent the amount of overland flow each cell
contributes to surface flow. If omitted, a value of one (1) is
assumed."
Therefore I think that Helena is right, but there is a bug in
r.watershed because any given input flow map is read as CELL, probably
because accumulation was of type CELL before MFD came in. For MFD,
accumulation must be floating point, so it was changed to DCELL
(probably too much precision, FCELL should do as in r.terraflow).
Changing r.watershed in order to read flow as DCELL seems IMHO
appropriate and would be a small fix.
BTW, an input flow map could be used to determine where water or some
other liquid is distributed to by setting flow to 100 for selected
start points e.g. houses and zero otherwise. Running r.watershed with
MFD would give as accumulation output percentage distributed from
start point (in this example always 100 for SFD), assuming that
nothing is lost by infiltration, evaporation etc.
Markus M
ram/init_vars.c
/* read flow accumulation from input map flow: amount of overland flow per cell */
opened with
G_open_cell_old(run_name, "")
read with
G_get_c_raster_row()
into
G_allocate_cell_buf()value set as
wat[SEG_INDEX(wat_seg, r, c)] = buf[c];after that I lose track of what it does.. maybe it is setting up
initial conditions??should some explanation go into manual?
once we know the answer, sure
Hamish
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Helena Mitasova wrote:
Maybe I am overlooking it but the man page for r.watershed does not say what units
the option "flow" should be in - I am guessing it is fraction of 1 (or percent given as decimal - e.g. 50% will be 0.5)so should flow amount read as fraction or something like that, so that if
all rainfall turns to runoff = 1
only 50% rainfall turns to runoff (rest is captured by vegetation or infiltrates) = 0.5
I was thinking about this flow option a bit more, and understand it
even less. Using infiltration rates or some value representing the
amount of rainfall captured by vegetation might not make sense here
because these values have a time component, e.g. x liter per
squaremeter and hour are absorbed by soil/vegetation, and surface
runoff as calculated by r.watershed does not have a time component. If
all but one cell have flow = 1 and this cell has flow = 0.5, and this
cell receives surface runoff from 1000 upstream cells, this cell would
distribute a surface runoff value of 1000.5 downstream, assuming that
none of the water coming from upstream is absorbed, only the rainfall
this particular cell receives is absorbed, in this example 50%. The
real absorption capacity might well allow to absorb some of the runoff
received from upstream.
IOW, considering that surface runoff is cumulative and
time-independent, I don't know what hydrological mechanism/theory
would give me different initial surface flow values for different
cells (e.g. the Montgomery option in r.stream.extract weighs the
accumulated surface flow (SCA to be precise), no the initial one), but
then I am not a hydrologist.
The reason why a given input flow map is read as CELL is most probably
that back then (1991, version 4.0, r.watershed no longer alpha as in
3.2) GRASS supported only CELL raster maps.
Markus M
Martin,
I have a quick question about nviz_cmd: does it have the same problem with light control
as wxnviz?
Everything that I tried with nviz_cmd so far seems to work great except for the light - it does something,
but the light does not go all the way down, closer to the horizon as it should and it is not possible
to reduce its brightness , so it looks like
it keeps moving too close around zenith at constant brightness (I did not try the colors).
Please let me know whether this is something that can be fixed easily or whether we should try
to look at it as well (a hint where to look in the code would help)
With nviz_cmd it has become really easy to do the dynamic surfaces (I would say easier
than with the broken File sequencing tool) so it would be great to get it finished and move it
from experimental to official working module.
Below are some animations that were quick and easy (the second one includes shifted
data so it wiggles - the animated surface has been thus also useful for finding out that we have a shift
in the data that we haven't even noticed with other types of analysis).
thanks a lot - it was great to meet you in Barcelona,
Helena
http://skagit.meas.ncsu.edu/~helena/grasswork/elev_dischtest.gif
http://skagit.meas.ncsu.edu/~helena/grasswork/NH9908p_anim.gif