Looking through the code of r.terraflow I discovered that there is one compile time only option that significantly reduces/improves the performance of r.terraflow. At the moment builds produce the less performant version by default, which for such a long running program is not good. Only those who read and modify the source code can get the faster version.
options.h, l. 47, #defines OUTPUT_TCI by default, causing additional files generated and in my case a significant (I think millions) number of error messages from this TCI option from sweep.cc line 143 (tci negative).
Not being a GIS person I have no idea what the error means, the output from r.terraflow seemed to correlate with reality despite the message, and even the author of this bit seemed not sure what the error signified: see line 141: is this true?. Printing the error a zillion times added a night to my program run.
The very quickest way of fixing this would be to have another build of r.terraflow added to the makefile, to compile it with TCI disabled and have yet another executable.
There is also the possibilty of making it a command line option, but I assume that the original authors of r.terraflow have made this a compile time option to avoid the runtime checks this would bring, so there is some argument for a separate executable at the expense of bloating binary distributions.
Ludwig
Hi all,
I am trying to use r.terraflow now as well to analyse a very large dataset.
However, I run into the same issue as the OP. I get millions of warning
messages that are not really relevant, because a negative tci is in my eyes
just valid, however, adding an hour to my initial test run on a smaller
sample.
I think the check on line 143 of sweep.cc should see if the flow or the
slope are negative (giving rise to the log of a negative number resulting in
an error). I am not sure yet what a negative tci means, but a small flow
with a large slope will result in a ratio smaller than 1 giving a negative
value for the logarithm taken.
Has any work been done on this?
Sincerely,
Roderik
Ludwig M Brinckmann wrote:
Looking through the code of r.terraflow I discovered that there is one
compile time only option that significantly reduces/improves the
performance
of r.terraflow. At the moment builds produce the less performant version
by
default, which for such a long running program is not good. Only those who
read and modify the source code can get the faster version.
options.h, l. 47, #defines OUTPUT_TCI by default, causing additional files
generated and in my case a significant (I think millions) number of error
messages from this TCI option from sweep.cc line 143 (tci negative).
Not being a GIS person I have no idea what the error means, the output
from
r.terraflow seemed to correlate with reality despite the message, and even
the author of this bit seemed not sure what the error signified: see line
141: is this true?. Printing the error a zillion times added a night to my
program run.
--
View this message in context: http://www.nabble.com/r.terraflow-performance-tweak-tp3918075p19140066.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
Here the answer/solution from Laura.
I have backported her fix to 6.4.svn.
Markus
On Tue, Aug 26, 2008 at 5:47 PM, Laura Toma <ltoma@bowdoin.edu> wrote:
Hi Markus,
They are right, the ratio of flow to contour can be smaller than 1, so
there is no need for tci to be positive.
I commented out the warning in the grass_trunk. I don't have a working
version of grass6_devel, so if it needs to be changed there as well, maybe
somebody can copy it over.
-Laura
On Aug 26, 2008, at 5:07 AM, Markus Neteler wrote:
Hi Laura,
do you have any suggestion here?
Thanks
Markus
---------- Forwarded message ----------
From: roderikk <roderikk@gmail.com>
Date: Mon, Aug 25, 2008 at 10:51 AM
Subject: Re: [GRASS-dev] r.terraflow performance tweak
To: grass-dev@lists.osgeo.org
Hi all,
I am trying to use r.terraflow now as well to analyse a very large
dataset.
However, I run into the same issue as the OP. I get millions of warning
messages that are not really relevant, because a negative tci is in my
eyes
just valid, however, adding an hour to my initial test run on a smaller
sample.
I think the check on line 143 of sweep.cc should see if the flow or the
slope are negative (giving rise to the log of a negative number resulting
in
an error). I am not sure yet what a negative tci means, but a small flow
with a large slope will result in a ratio smaller than 1 giving a negative
value for the logarithm taken.
Has any work been done on this?
Sincerely,
Roderik
Ludwig M Brinckmann wrote:
Looking through the code of r.terraflow I discovered that there is one
compile time only option that significantly reduces/improves the
performance
of r.terraflow. At the moment builds produce the less performant version
by default, which for such a long running program is not good. Only those
who read and modify the source code can get the faster version.
options.h, l. 47, #defines OUTPUT_TCI by default, causing additional
files
generated and in my case a significant (I think millions) number of error
messages from this TCI option from sweep.cc line 143 (tci negative).
Not being a GIS person I have no idea what the error means, the output
from
r.terraflow seemed to correlate with reality despite the message, and
even
the author of this bit seemed not sure what the error signified: see line
141: is this true?. Printing the error a zillion times added a night to
my program run.