<div dir="ltr"><div>On Thu, Sep 10, 2015 at 9:00 PM, mael <<a href="mailto:mael.moreni@onf.fr">mael.moreni@onf.fr</a>> wrote:<br>> I am working on a 13407 lines * 11050 columns, 565 MB, raster file (SRTM DEM,<br>> 30m) with a script that calls a series of hydrological modules in GRASS<br>> 7.0.0.<br>> The system I am using is a Windows server 2012 R2, 64 bit Intel Xeon 2.5 GHz<br>> processor, 32GB of RAM.<br>><br>> The first module called in the script is r.watershed. When lunched on that<br>> data set, it generates the following error : G_malloc: impossible to<br>> allocate 1185910608 bytes to raster/r.watershed/ram/init_vars.c:149<br>> It apears to be running out of memory even though there is a lot more<br>> available than what it's asking for.<br><br>Very likely your computational region is wrong, i.e. too large.<br>Check it with<br><br>g.region -p<br><br>I just used the EU DEM 25m to make a test on my tiny ASUS laptop (4GB RAM,<br>Intel i3), using Fedora 22, 64bit:<br><br>> 13407  * 11050  <<--- your DEM<br>[1] 148147350<br>><br>> 12880 * 16370  <<-- my DEM<br>[1] 210845600<br><br>(I just had this DEM ready here to play with)<br><br><span style="font-family:monospace,monospace"><br>GRASS 7.1.svn (eu_laea):~ > g.region -p<br>projection: 99 (Lambert Azimuthal Equal Area)<br>zone:       0<br>datum:      etrs89<br>ellipsoid:  grs80<br>north:      2699750<br>south:      2377750<br>west:       4126750<br>east:       4536000<br>nsres:      25<br>ewres:      25<br>rows:       12880<br>cols:       16370<br>cells:      210845600</span><br><br><br>Results:<br><br>RAM: it used some swap memory since I have browser etc open at the same time.<br><span style="font-family:monospace,monospace"><br>[neteler@oboe ~]$ free<br>              total        used        free      shared  buff/cache   available<br>Mem:        3930508     3600648       32408       93164      297452      165584<br>Swap:       3932156     2735164     1196992</span><br><br>Timing:<br><span style="font-family:monospace,monospace"><br>GRASS 7.1.svn (eu_laea):~ > time -p r.watershed elevation=eu_dem_25_TN accumulation=eu_dem_25_TN.acc basin=eu_dem_25_TN.watersheds threshold=10000<br>SECTION 1a (of 5): Initiating Memory.<br>SECTION 1b (of 5): Determining Offmap Flow.<br> 100%<br>SECTION 2: A* Search.<br> 100%<br>SECTION 3a: Accumulating Surface Flow with MFD.<br> 100%<br>SECTION 3b: Adjusting drainage directions.<br> 100%<br>SECTION 4: Watershed determination.<br> 100%<br>SECTION 5: Closing Maps.<br><br>real 1270.30<br>user 1048.68<br>sys 54.00</span><br><br>... 21 minutes.<br><br><br><br>> I managed to pass that first hurdle using the -m flag on r.watershed. The<br>> scripts now requires 7 GB of disk space; even if it's slow and I don't<br>> understand why it can't use the ram in the first place, r.watershed finishes<br>> correctly.<br><br></div>Given my test on a small laptop, it is very likely that your actual computational region<br>does not match the input map.<br><div><br>> However, when the script gets to the next module, r.fill.dir, GRASS crashes<br>> at 'Reading input elevation raster map...' with the following message:<br><br></div><div>Why do you use the r.fill.dir module?<br></div><div><br></div><div>Markus<br><br>-- <br><a href="http://consulting.neteler.org">http://consulting.neteler.org</a><br><a href="http://gis.cri.fmach.it/neteler/">http://gis.cri.fmach.it/neteler/</a><br><a href="http://courses.neteler.org/blog">http://courses.neteler.org/blog</a><br> <br></div></div>