[GRASS-dev] question about any July changes in hydrology functions

Michael Barton michael.barton at asu.edu
Thu Aug 2 01:46:45 EDT 2007




On 8/1/07 10:24 PM, "Helena Mitasova" <hmitaso at unity.ncsu.edu> wrote:

> That is what I call a gridding effect -
> check it out here - and this was done only with simwe and r.mapcalc
> - no r.flow, r.neighbors, etc.
> (some of the problem actually may be hidden in r.mapcalc computations)
> 
> http://skagit.meas.ncsu.edu/~helena/gmslab/oxfordms/oxf.html
> 
> you can see how it evolves here (you start seeing it after several
> iterations - it is there from the start
> but it is small at the beginning and just grows over time until you
> start seeing it)
> 
> http://skagit.meas.ncsu.edu/~helena/gmslab/oxfordms/eledhedge.gif

These displays match what we are getting. Apparently, this only begins to
show up with long, recursive simulations.

One characteristic of recursive cellular automata simulations, of course, is
emergent patterns that are not easily predicted by the original
processes--including cascades of deviation amplifying effects. I didn't
expect this to pop up in this part of our simulation, but in retrospect, it
is not all that surprising. But is is annoying and we'll have to correct it
somehow.

> 
> I thought that smoothing will take care of it but apparently just the
> opposite

This does seem strange. Even odder is the fact that the anomalies get bigger
the larger the smoothing neighborhood. Usually, increasing the neighborhood
creates greater smoothing.

It might be the way we are using smoothing. We check to see if an
erosion/deposition value exceeds the smoothed value by some user-determined
amount. It is does, the smoothed value is used instead of the original
value. The goal was to get rid of extreme values but leave the rest alone.

Perhaps we should just use the smoothed value for all cells instead of just
extreme ones.

> We need to find out what to do about it - I think that
>   it is more related to the modeling approach than GRASS itself,
> 

Is this perhaps a function of dx and dy calculations?

> BTW as I understand it median is computed by dividing the values into
> a finite number of classes
> so the median from a continuous field would not change continuously
> from cell to cell and
> the effect you are getting could be expected especially for larger
> number of cells.

I don't know how r.neighbors computes the median. However, it is supposed to
be a value such that half the neighbor cells have larger values and half
have smaller values. I would have thought that the way to compute would be
to order the neighborhood values from smallest to largest and find the
middle. Since the neighborhood is always an odd number, the middle is always
a single cell. 

> Mean is computed directly from the floating point values - is that
> right?

This ought to be the sum of the neighbor cell values divided by the number
of cells. 

The median is less affected by a single extreme cell than the mean, which is
why we preferred the median. However, if the median calculation algorithm is
problematic, then we'll have to switch to the mean.

Thanks for looking at this. I'll be very interested to hear any further
ideas you have.

Michael

> 
> Helena
> 
> Helena Mitasova
> Dept. of Marine, Earth and Atm. Sciences
> 1125 Jordan Hall, NCSU Box 8208,
> Raleigh NC 27695
> http://skagit.meas.ncsu.edu/~helena/
> 
> 
> 
> On Aug 1, 2007, at 11:39 PM, Michael Barton wrote:
> 
>> Tests over the last couple days suggest that r.neighbors may be
>> the, or one
>> of, the causes. We lose most of the artifacts if we turn off
>> smoothing using
>> r.neighbors, and the artifacts are much worse with a neighborhood
>> of 7x7
>> than 3x3.
>> 
>> We're probably wrong about the date, however. This seems to only
>> show up
>> clearly in very long runs (a simulation of 50 recursive models) and
>> is most
>> pronounced with larger smoothing neighborhoods. Previously we'd
>> done a small
>> neighborhood of 3x3 and done most of our tests for no more than 10
>> iterations. We only did a couple of long ones and were looking more
>> at stats
>> from the output than the maps themselves. Now we are doing a number
>> of 50+
>> iteration runs (the most recent one ran for nearly 600 years simulated
>> time).
>> 
>> using a median smoother gives much worse results than a mean smoother,
>> though a median ought to be better the larger the neighborhood is,
>> since it
>> should not be affected as much by extreme values.
>> 
>> Our next test it to find out if there is some kind of issue with
>> region
>> setting that is interacting with the smoothing. Probably not, but
>> we need to
>> make sure.
>> 
>> I'll report more later after. If anyone is interested in seeing
>> what I've
>> tried to describe, I've posted images of the effects of different
>> smoothing
>> parameters at:
>> 
>> <http://www.public.asu.edu/~cmbarton/files/LandDyn>
>> 
>> Michael
>> 
>> 
>> 
>> On 8/1/07 7:34 PM, "Glynn Clements" <glynn at gclements.plus.com> wrote:
>> 
>>> 
>>> Michael Barton wrote:
>>> 
>>>> Helena also mentioned r.neighbors as a possible culprit, as I'd
>>>> forgotten to
>>>> mention that we also use this to smooth results.
>>> 
>>> Neither r.neighbors or lib/stats changed during the first half of
>>> July.
>> 
>> __________________________________________
>> Michael Barton, Professor of Anthropology
>> Director of Graduate Studies
>> School of Human Evolution & Social Change
>> Center for Social Dynamics & Complexity
>> Arizona State University
>> 
>> phone: 480-965-6213
>> fax: 480-965-7671
>> www: http://www.public.asu.edu/~cmbarton
>> 
>> 
> 

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton





More information about the grass-dev mailing list