[GRASS-user] Problems Running r.flow

[Glynn Clements]

Rich Shepard wrote:

> > That's a bug in r.flow:
> >
> >    if (!((region.ew_res == hd.ew_res)
> > 	  && (region.ns_res == hd.ns_res)))
> > 	G_fatal_error(_("Elevation file's resolution differs from current region resolution"));
> 
> > Try the attached patch. It replaces the exact comparison with a check that
> > the resolutions agree to within 1ppm.
> 
>    Perhaps I've specified the region incorrectly, but the patch makes no
> difference. Upon invoking GRASS I run 'g.region rast=aber5m res=5 -ap'
> followed by 'r.flow elevin=aber5m aspin=aber5aspect flout=aberFlowline
> lgout=aberFlowlength' and immediately see:
> 
> ERROR: Elevation file's resolution differs from current region resolution

Did you try "g.region rast=aber5m" without the other options?

If that doesn't work, you can try changing the tolerance value to
something larger than 1e-6, or simply disabling the test.

The test exists to ensure that the data is read cell-for-cell; if any
duplicates occurred due to resampling, it would introduce plateaux
into the elevation surface. For that purpose, it only matters that the
absolute difference between the resolutions is less than
ns_res/(2*rows) or ew_res/(2*cols), i.e. a cumulative error of less
than 1/2 cell.

>    I'm surprised this issue's not come up before.

Same here. It's possible that any rounding error is usually masked by
truncation of the value written to the WIND and cellhd files. If it
doesn't affect the decimal value written to the file, it won't matter,
but if it causes the last decimal digit to change, it will.

The files are written using %.15g (i.e. 15 significant figures), while
double-precision floating-point has just under 17. There are 11
distinct values which are equal to 5 when written using %.15g, so
there's roughly a 9% chance that an error in the least significant bit
would affect the decimal representation.

-- 
Glynn Clements <glynn at gclements.plus.com>