Hello, 2010/9/8 Hanlie Pretorius <[email protected]>: > Thanks for the reply, Soeren. > > I have had similar results on rasters with fewer than 1 million cells. > The process runs for a litte longer but then also gets killed. > > I made the resolution very fine on purpose because I was trying to > crash r.sim.water to get to the debugging messages. Does that make > sense?
Unfortunately not really. The process get killed because it tries to allocate much to much memory and this may be not related to the problems you face when computing with a fewer number of cells. The debug messages will always be printed if the environmental variable was set correctly. Maybe using breakpoints while debugging will point to the problem? Best Soeren > > 2010/9/8, Soeren Gebbert <[email protected]>: >> Hello, >> IMHO your region resolution is much to large for r.sim.water: >> 33008x33443 cells -> 1.1 billion cells. >> You can use a coarse resolution or you can split your dataset in >> smaller pieces for computation. >> >> r.sim.water loads all raster maps into your memory and creates >> additionally a maximum of 7000000 walkers. I would suggest to use >> about 1000000 cells for computation. >> >> Best >> Soeren >> >> 2010/9/8 Hanlie Pretorius <[email protected]>: >>> Hi, >>> >>> I've been posting about problems with r.sim.water. I have compiled >>> GRASS64 SVN with debugging symbols and set the GRASS DEBUG environment >>> variable to level 5. I'm also running GRASS from gdb. >>> >>> I ran r.sim.water on a region with 1103886544 cells and it bombed out >>> quickly. The output was: >>> ----- >>> GRASS 6.4.0svn (c83a_tm_29deg_e):~ > r.sim.water --overwrite >>> elevin=c83a_dem_...@permanent >>> dxin=c83a_dem_25m_clipped...@rsimwater_toetse >>> dyin=c83a_dem_25m_clipped...@rsimwater_toetse >>> rain=rain...@rsimwater_toetse infil=infil...@rsimwater_toetse >>> manin=manning_0...@rsimwater_toetse >>> depth=depth_1mres_rain50_infil0_nite...@rsimwater_toetse >>> disch=disch_1mres_rain50_infil0_nite...@rsimwater_toetse >>> D2/5: G__read_Cell_head >>> D2/5: G__read_Cell_head_array >>> D3/5: region item: proj: 99 >>> D3/5: region item: zone: 0 >>> D3/5: region item: north: -3122229.69982072 >>> D3/5: region item: south: -3155672.30728643 >>> D3/5: region item: east: -33474.90929218 >>> D3/5: region item: west: -66483.27873573 >>> D3/5: region item: cols: 33008 >>> D3/5: region item: rows: 33443 >>> D3/5: region item: e-w resol: 1.00001119 >>> D3/5: region item: n-s resol: 0.99998826 >>> D3/5: region item: top: 0.5 >>> D3/5: region item: bottom: -0.5 >>> D3/5: region item: cols3: 33008 >>> D3/5: region item: rows3: 33443 >>> D3/5: region item: depths: 1 >>> D3/5: region item: e-w resol3: 1.00001119 >>> D3/5: region item: n-s resol3: 0.99998826 >>> D3/5: region item: t-b resol: 1 >>> D3/5: rain_val is set to: -999.990000 >>> >>> D3/5: manin_val is set to: -999.990000 >>> >>> D3/5: infil_val is set to: -999.990000 >>> >>> default nwalk=-2087194208, rwalk=2207773088.000000 >>> Killed >>> ----- >>> >>> Since GRASS itself doesn't exit abnormally, gdb doesn't seem to notice >>> that anything is wrong. >>> >>> Is there anywhere else (a log file perhaps) where I can try and find >>> out what is going on? >>> >>> Thanks >>> Hanlie >>> _______________________________________________ >>> grass-dev mailing list >>> [email protected] >>> http://lists.osgeo.org/mailman/listinfo/grass-dev >>> >> > _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
