[GRASS-dev] [GRASS GIS] #1421: scalability of r.terraflow
GRASS GIS
trac at osgeo.org
Fri Mar 28 15:15:11 PDT 2014
#1421: scalability of r.terraflow
--------------------------------------+-------------------------------------
Reporter: dnewcomb | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal | Milestone: 7.0.0
Component: Raster | Version: svn-develbranch6
Keywords: r.terraflow, large grids | Platform: Linux
Cpu: x86-64 |
--------------------------------------+-------------------------------------
Comment(by glynn):
Replying to [comment:4 dnewcomb]:
> The thing that confuses me at the moment is the FILL line below in the
temp file listing below. Why are there a large negative number of
elements?
r.terraflow/main.cpp:410:
{{{
G_message( "\t\t FILL: %s [%d elements, %dB each]",
formatNumber(buf, fillmaxsize),
nrows * ncols, sizeof(waterWindowType));
G_message( "\t\t FLOW: %s [%ld elements, %dB each]",
formatNumber(buf, flowmaxsize),
(long)(nrows * ncols - nodata_count),
sizeof(sweepItem));
}}}
Even if dimension_type is changed to "long", the value is still being
formatted as an "int" ("%d" conversion specifier).
Also, the cast to "long" in the second call is wrong. If nrows and ncols
are of type "int" (or any smaller type, e.g. "short"), the multiplication
will be performed as "int", which may overflow; casting the (possibly
overflowed) result to "long" won't change that.
It should be:
{{{
G_message( "\t\t FLOW: %s [%ld elements, %dB each]",
formatNumber(buf, flowmaxsize),
(long)nrows * ncols - nodata_count, sizeof(sweepItem));
}}}
Casting either of the operands to "long" will force the multiplication to
be performed as "long" and yield a "long" result (however, note that
"long" is still only 32 bits on 64-bit versions of Windows).
--
Ticket URL: <https://trac.osgeo.org/grass/ticket/1421#comment:5>
GRASS GIS <http://grass.osgeo.org>
More information about the grass-dev
mailing list