[GRASS-user] g_malloc on r.watershed with 30GB free ram + r.fill.dir crash

I am working on a 13407 lines * 11050 columns, 565 MB, raster file (SRTM DEM,
30m) with a script that calls a series of hydrological modules in GRASS
7.0.0.
The system I am using is a Windows server 2012 R2, 64 bit Intel Xeon 2.5 GHz
processor, 32GB of RAM.

The first module called in the script is r.watershed. When lunched on that
data set, it generates the following error : G_malloc: impossible to
allocate 1185910608 bytes to raster/r.watershed/ram/init_vars.c:149
It apears to be running out of memory even though there is a lot more
available than what it's asking for.

I managed to pass that first hurdle using the -m flag on r.watershed. The
scripts now requires 7 GB of disk space; even if it's slow and I don't
understand why it can't use the ram in the first place, r.watershed finishes
correctly.

However, when the script gets to the next module, r.fill.dir, GRASS crashes
at 'Reading input elevation raster map...' with the following message:

Problem signature: Problem Event Name: APPCRASH Application Name:
r.fill.dir.EXE Application Version: 7.0.0.0 Application Timestamp: 54e7aaf0
Fault Module Name: r.fill.dir.EXE Fault Module Version: 7.0.0.0 Fault Module
Timestamp: 54e7aaf0 Exception Code: c00000fd Exception Offset: 00001479 OS
Version: 6.3.9600.2.0.0.400.8 Locale ID: 1036 Additional Information 1: 3397
Additional Information 2: 33978ebc9cf04f9490066e458551979d Additional
Information 3: caf7 Additional Information 4:
caf72cf53bf264b7d49f3bd72b0afc04

The script runs fine on a smaller data set.

Any idea how to stop the module from crashing?

Is there a way to use make sure it uses the ram instead of the disk?

Thank you

--
View this message in context: http://osgeo-org.1560.x6.nabble.com/g-malloc-on-r-watershed-with-30GB-free-ram-r-fill-dir-crash-tp5223620.html
Sent from the Grass - Users mailing list archive at Nabble.com.

On Thu, Sep 10, 2015 at 9:00 PM, mael <mael.moreni@onf.fr> wrote:

I am working on a 13407 lines * 11050 columns, 565 MB, raster file (SRTM DEM,
30m) with a script that calls a series of hydrological modules in GRASS
7.0.0.
The system I am using is a Windows server 2012 R2, 64 bit Intel Xeon 2.5 GHz
processor, 32GB of RAM.

The first module called in the script is r.watershed. When lunched on that
data set, it generates the following error : G_malloc: impossible to
allocate 1185910608 bytes to raster/r.watershed/ram/init_vars.c:149
It apears to be running out of memory even though there is a lot more
available than what it’s asking for.

Very likely your computational region is wrong, i.e. too large.
Check it with

g.region -p

I just used the EU DEM 25m to make a test on my tiny ASUS laptop (4GB RAM,
Intel i3), using Fedora 22, 64bit:

13407 * 11050 <<— your DEM
[1] 148147350

12880 * 16370 <<-- my DEM
[1] 210845600

(I just had this DEM ready here to play with)

GRASS 7.1.svn (eu_laea):~ > g.region -p
projection: 99 (Lambert Azimuthal Equal Area)
zone: 0
datum: etrs89
ellipsoid: grs80
north: 2699750
south: 2377750
west: 4126750
east: 4536000
nsres: 25
ewres: 25
rows: 12880
cols: 16370
cells: 210845600

Results:

RAM: it used some swap memory since I have browser etc open at the same time.

[neteler@oboe ~]$ free
total used free shared buff/cache available
Mem: 3930508 3600648 32408 93164 297452 165584
Swap: 3932156 2735164 1196992

Timing:

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
SECTION 1a (of 5): Initiating Memory.
SECTION 1b (of 5): Determining Offmap Flow.
100%
SECTION 2: A* Search.
100%
SECTION 3a: Accumulating Surface Flow with MFD.
100%
SECTION 3b: Adjusting drainage directions.
100%
SECTION 4: Watershed determination.
100%
SECTION 5: Closing Maps.

real 1270.30
user 1048.68
sys 54.00

… 21 minutes.

I managed to pass that first hurdle using the -m flag on r.watershed. The
scripts now requires 7 GB of disk space; even if it’s slow and I don’t
understand why it can’t use the ram in the first place, r.watershed finishes
correctly.

Given my test on a small laptop, it is very likely that your actual computational region
does not match the input map.

However, when the script gets to the next module, r.fill.dir, GRASS crashes
at ‘Reading input elevation raster map…’ with the following message:

Why do you use the r.fill.dir module?

Markus


http://consulting.neteler.org
http://gis.cri.fmach.it/neteler/
http://courses.neteler.org/blog

Here is my region:

g.region -p projection: 1 (UTM)
zone: 22
datum: wgs84
ellipsoid: wgs84
north: 636094.00956457
south: 233878.203125
west: 98924.52245413
east: 430413.65625
nsres: 30.00043309
ewres: 29.99901663
rows: 13407
cols: 11050
cells: 148147350

Given my test on a small laptop, it is very likely that your actual >computational region does not match the input map.

I define the computational area with 'g.region raster=dem zoom=dem' ('dem' being my raster) before launching the script so it should match the elevation map.

Why do you use the r.fill.dir module?

r.fill.dir is to extract depression areas as sinks, sinks being one of the outputs of my script.

Mael

De : Markus Neteler [via OSGeo.org] [mailto:ml-node+s1560n5223631h72@n6.nabble.com]
Envoyé : jeudi 10 septembre 2015 17:07
À : MORENI Mael
Objet : Re: g_malloc on r.watershed with 30GB free ram + r.fill.dir crash

On Thu, Sep 10, 2015 at 9:00 PM, mael <[hidden email]</user/SendEmail.jtp?type=node&node=5223631&i=0>> wrote:

I am working on a 13407 lines * 11050 columns, 565 MB, raster file (SRTM DEM,
30m) with a script that calls a series of hydrological modules in GRASS
7.0.0.
The system I am using is a Windows server 2012 R2, 64 bit Intel Xeon 2.5 GHz
processor, 32GB of RAM.

The first module called in the script is r.watershed. When lunched on that
data set, it generates the following error : G_malloc: impossible to
allocate 1185910608 bytes to raster/r.watershed/ram/init_vars.c:149
It apears to be running out of memory even though there is a lot more
available than what it's asking for.

Very likely your computational region is wrong, i.e. too large.
Check it with

g.region -p

I just used the EU DEM 25m to make a test on my tiny ASUS laptop (4GB RAM,
Intel i3), using Fedora 22, 64bit:

13407 * 11050 <<--- your DEM

[1] 148147350

12880 * 16370 <<-- my DEM

[1] 210845600

(I just had this DEM ready here to play with)

GRASS 7.1.svn (eu_laea):~ > g.region -p
projection: 99 (Lambert Azimuthal Equal Area)
zone: 0
datum: etrs89
ellipsoid: grs80
north: 2699750
south: 2377750
west: 4126750
east: 4536000
nsres: 25
ewres: 25
rows: 12880
cols: 16370
cells: 210845600

Results:

RAM: it used some swap memory since I have browser etc open at the same time.

[neteler@oboe ~]$ free
              total used free shared buff/cache available
Mem: 3930508 3600648 32408 93164 297452 165584
Swap: 3932156 2735164 1196992

Timing:

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
SECTION 1a (of 5): Initiating Memory.
SECTION 1b (of 5): Determining Offmap Flow.
100%
SECTION 2: A* Search.
100%
SECTION 3a: Accumulating Surface Flow with MFD.
100%
SECTION 3b: Adjusting drainage directions.
100%
SECTION 4: Watershed determination.
100%
SECTION 5: Closing Maps.

real 1270.30
user 1048.68
sys 54.00

... 21 minutes.

I managed to pass that first hurdle using the -m flag on r.watershed. The
scripts now requires 7 GB of disk space; even if it's slow and I don't
understand why it can't use the ram in the first place, r.watershed finishes
correctly.

Given my test on a small laptop, it is very likely that your actual computational region
does not match the input map.

However, when the script gets to the next module, r.fill.dir, GRASS crashes
at 'Reading input elevation raster map...' with the following message:

Why do you use the r.fill.dir module?

Markus

--
http://consulting.neteler.org
http://gis.cri.fmach.it/neteler/
http://courses.neteler.org/blog

_______________________________________________
grass-user mailing list
[hidden email]</user/SendEmail.jtp?type=node&node=5223631&i=1>
http://lists.osgeo.org/mailman/listinfo/grass-user
________________________________
If you reply to this email, your message will be added to the discussion below:
http://osgeo-org.1560.x6.nabble.com/g-malloc-on-r-watershed-with-30GB-free-ram-r-fill-dir-crash-tp5223620p5223631.html
To unsubscribe from g_malloc on r.watershed with 30GB free ram + r.fill.dir crash, click here<http://osgeo-org.1560.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5223620&code=bWFlbC5tb3JlbmlAb25mLmZyfDUyMjM2MjB8LTEyMzYwODQ4NTI=&gt;\.
NAML<http://osgeo-org.1560.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html!nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers!nabble%3Aemail.naml-instant_emails!nabble%3Aemail.naml-send_instant_email!nabble%3Aemail.naml&gt;

--
View this message in context: http://osgeo-org.1560.x6.nabble.com/g-malloc-on-r-watershed-with-30GB-free-ram-r-fill-dir-crash-tp5223620p5223818.html
Sent from the Grass - Users mailing list archive at Nabble.com.

I define the computational area with 'g.region raster=dem zoom=dem' ('dem'

being my raster) before launching the script so it should match the
elevation map.

try

g.region -a raster=elevation align=elevation

to match and align your dem

https://grass.osgeo.org/grass70/manuals/g.region.html

-a Align region to resolution
align=name Adjust region cells to cleanly align with this raster map

-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.x6.nabble.com/g-malloc-on-r-watershed-with-30GB-free-ram-r-fill-dir-crash-tp5223620p5223832.html
Sent from the Grass - Users mailing list archive at Nabble.com.

On Fri, Sep 11, 2015 at 5:22 PM, Helmut Kudrnovsky <hellik@web.de> wrote:

> I define the computational area with 'g.region raster=dem zoom=dem' ('dem'
being my raster) before launching the script so it should match the
elevation map.

try

g.region -a raster=elevation align=elevation

to match and align your dem

https://grass.osgeo.org/grass70/manuals/g.region.html

-a Align region to resolution
align=name Adjust region cells to cleanly align with this raster map

consider to also add -p in order to actually see what you have there.

Ideally the resolution should match that of the map, also in order to
avoid non-square pixels as you report above
"
nsres: 30.00043309
ewres: 29.99901663
"

which are not ideal.

best
Markus

I tried to set the resolution with ‘res=30 ‘, also tried with ‘align’, r.watershed finishes without a problem if I add the –m flag but the script keeps crashing at r.fills.dir.

···

I define the computational area with ‘g.region raster=dem zoom=dem’ (‘dem’
being my raster) before launching the script so it should match the
elevation map.

try

g.region -a raster=elevation align=elevation

to match and align your dem

https://grass.osgeo.org/grass70/manuals/g.region.html

-a Align region to resolution
align=name Adjust region cells to cleanly align with this raster map

consider to also add -p in order to actually see what you have there.

Ideally the resolution should match that of the map, also in order to
avoid non-square pixels as you report above
"
nsres: 30.00043309
ewres: 29.99901663
"

which are not ideal.

best
Markus


grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user


If you reply to this email, your message will be added to the discussion below:

http://osgeo-org.1560.x6.nabble.com/g-malloc-on-r-watershed-with-30GB-free-ram-r-fill-dir-crash-tp5223620p5223843.html

To unsubscribe from g_malloc on r.watershed with 30GB free ram + r.fill.dir crash, click here.
NAML