has anybody seen (or have an explanation) for the following vm_allocate error
that we got from v.proj when projecting rather large point file on Mac running recent CVS GRASS
(I was able to run v.proj with the same data on a FC5 machine without problem).
We got similar error from v.surf.rst after 86% done on 5000x5000 raster (but I was able
to compute bigger raster on a smaller mac laptop). I am trying to find out whether it is the data
or something specific to Mac (a 2GB memory machine) or a bug that is causing this error.
thanks, Helena
GRASS 6.1.cvs (jockeyspft):~ > v.proj input=earl030921oregoni
location=coastll mapset=PERMANENT output=earl030921oregoni
Input Projection Parameters: +proj=latlong +a=6378137 +rf=298.257222101
+no_defs +towgs84=0.000000,0.000000,0.000000
Input Unit Factor: 1
Output Projection Parameters: +proj=lcc +x_0=0.6096012192024384e+06 +y_0=0
+lon_0=79dw +lat_0=33d45'n +lat_1=36d10'n +lat_2=34d20'n +a=6378137
+rf=298.257222101 +no_defs +towgs84=0.000000,0.000000,0.000000
Output Unit Factor: 0.3048006096012192
Creating vector file...
Building topology ...
Registering lines: v.proj(2057) malloc: *** vm_allocate(size=8421376)
failed (error code=3)
v.proj(2057) malloc: *** error: can't allocate region
v.proj(2057) malloc: *** set a breakpoint in szone_error to debug
node.c:48: failed assertion `n'
Abort trap
--- end printout 030921-----
Although the vector was created, I wasn't able to display it. On the
contrary, I was able to display the 030916 vector despite reporting a
similar error without abortion:
---- error printout 030916---
(v.proj(753) malloc: *** error: can't allocate region
v.proj(753) malloc: *** set a breakpoint in szone_error to debug
v.proj(753) malloc: *** vm_allocate(size=24088576) failed (error code=3)
---- end error printout 030916---
there may be a huge segment in the masked area, but the error message is not comming from the rst code
v.surf.rst input=L18 layer== dmax=3.0 dmin=1.0 elev=surf500501Lidar maskmap=MASK zmult=1.0 tension=40.0
smooth=10.0 segmax=20 npmin=120
86%
WARNING: taking too long to find points for interpolation--please change
the region to area where your points are. Continuing
calculations...
v.surf.rst(1340) malloc: *** vm_allocate(size=8421376) failed (error code=3)
v.surf.rst(1340) malloc: *** error: can't allocate region
v.surf.rst(1340) malloc: *** set a breakpoint in szone_error to debug
v.surf.rst(1340) malloc: *** vm_allocate(size=8421376) failed (error code=3)
v.surf.rst(1340) malloc: *** error: can't allocate region
v.surf.rst(1340) malloc: *** set a breakpoint in szone_error to debug
v.surf.rst(1340) malloc: *** vm_allocate(size=8421376) failed (error code=3)
v.surf.rst(1340) malloc: *** error: can't allocate region
v.surf.rst(1340) malloc: *** set a breakpoint in szone_error to debug
v.surf.rst(1340) malloc: *** vm_allocate(size=8421376) failed (error code=3)
v.surf.rst(1340) malloc: *** error: can't allocate region
v.surf.rst(1340) malloc: *** set a breakpoint in szone_error to debug
ERROR: G_malloc: out of memory
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 Jun 28, 2006, at 8:24 PM, Helena Mitasova wrote:
On Jun 17, 2006, at 5:26 AM, Māris Nartišs wrote:
Re-posting, as previous mail was larger than lists accept.
Hello all GRASSers.
GRASS CVS contains new module r.lake. This module can be used to create lake
maps if only place and lake level is known. To use this module You need
terrain raster map (DEM), water level for lake in same units as DEM values
and coordinates for any point in lake.
Module uses 3x3 sliding window to fill whole area connected to seed point (can
be coordinate pair or already existing raster map) and having height values
below water level. Output map will have lake depth in DEM units. More
information about module is in help page.
I use this module for palaeolake reconstructions based on single shore line
measurement. It also can be usefull for reservoir planing, creating maps with
scenarios for lake level changes etc. Unfortunately mailing lists does not
accept attachments larger than 100kb - no sample images with r.lake in
action.
Currently this module has some limitations and I ask for help to other GRASS
developers to help me to fix them.
Most important - module is NOT large file safe.
Lake volume calculations work only if DEM is in meters.
G_area_of_cell_at_row() always returns cell area in square meters, but I
could not figure out how to get information about DEM units. Thus if both are
in meters, volume is correct, else not ...
we have already discussed this in relation to r.slope.aspect which has the same problem,
currently it gives warning when x,y in feet is converted to meters so that user
can check and make sure that the elevation is in meters too.
There is no place currently in GRASS to store DEM z-units (and vertical datum) so it is left to
the user to make sure that the units are handled correctly (big pain here in US where
feet and meters are about equally common and mixed in various ways).
I believe that for GRASS7 we should include the vertical datum and units information for each location even if we
do not provide the transformation tools - this should help users better manage
their elevation and volume data and they can use external tools to convert the vertical datum
for the data that they want to import to the datum used in the GRASS location.
For example there is an official open source code for US coastal vertical datums conversion
available here (it is written in Java2 though)
http://chartmaker.ncd.noaa.gov/csdl/vdatum.htm
This would not prevent the users to mix misc. vert. and horiz. datums and units in their database
(at their own peril as I have learned the hard way), but it will encourage the management
of data in a well defined coordinate system and units in all 3 dimensions.
Helena
P.S. I would like to add this suggestion to the wiki development page - apparently it should go
under Plans but it does not fit into Overview, should I add it to sand box?
Or should we start a GRASS7 proposals/suggestions/todo section?
Thanks to all who helped me to code this module.
Any comments, ideas, enhancements - always welcome.
Maris Nartiss.
_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev
_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev