Suite

Crash de GRASS 7.0 fill.dir


Je travaille sur un fichier raster de 13407 lignes * 11050 colonnes (SRTM DEM, 30m) avec un script qui appelle une série de modules hydrologiques dans GRASS 7.0. Le système que j'utilise est un serveur Windows 2012 R2, processeur 64 bits Intel Xeon 2,5 GHz, 32 Go de RAM.

Le premier module appelé dans le script est r.watershed. Lorsqu'il est lancé sur cet ensemble de données, il génère l'erreur suivante : G_malloc : impossible d'allouer 1185910608 octets à raster/r.watershed/ram/init_vars.c:149

J'ai réussi à franchir ce premier obstacle en utilisant l'indicateur -m sur r.watershed. Les scripts nécessitent maintenant 7 Go d'espace disque, même si c'est lent et je ne comprends pas pourquoi il ne peut pas utiliser la RAM en premier lieu, r.watershed se termine correctement.

Cependant, lorsque le script passe au module suivant, r.fill.dir, GRASS se bloque à 'Lecture de la carte raster d'altitude en entrée…' avec le message suivant :

Signature du problème : Nom de l'événement du problème : APPCRASH Nom de l'application : r.fill.dir.EXE Version de l'application : 7.0.0.0 Horodatage de l'application : 54e7aaf0 Nom du module d'erreur : r.fill.dir.EXE Version du module d'erreur : 7.0.0.0 Horodatage du module d'erreur : 54e7aaf0 Code d'exception : c00000fd Décalage d'exception : 00001479 Version du système d'exploitation : 6.3.9600.2.0.0.400.8 ID de paramètre régional : 1036 Informations supplémentaires 1 : 3397 Informations supplémentaires 2 : 33978ebc9cf04f9490066e458551979d Informations supplémentaires 3 : caf7 Informations supplémentaires 4 : caf72cf53bf264b7d0fc3bd72b

Le script s'exécute correctement sur un ensemble de données plus petit.

Une idée de la façon de résoudre le crash de l'application?

Edit : comme demandé, voici le résultat de g.region -p :

g.region -p projection : 1 (UTM) zone : 22 datum : wgs84 ellipsoïde : wgs84 nord : 636094.00956457 sud : 233878.203125 ouest : 98924.52245413 est : 430413.65625 nsres : 30.00043309 ewres : 29.99901663 lignes : 13407 cols148147350

Très probablement, votre région de calcul ne correspond pas à la carte d'altitude, c'est-à-dire qu'elle est trop grande. Vérifiez avec

g.région -p

Je viens d'utiliser le EU DEM 25m pour faire un test sur mon petit ordinateur portable ASUS (4 Go de RAM, Intel i3), en utilisant Fedora 22, 64 bits :

13407 * 11050 = 148147350 <<--- votre DEM

12880 * 16370 = 210845600 <<-- mon DEM

(Je viens d'avoir ce DEM prêt ici pour jouer avec)

GRASS 7.1.svn (eu_laea) :~ > g.region -p projection : 99 (Lambert Azimuthal Equal Area) zone : 0 datum : etrs89 ellipsoïde : grs80 nord : 2699750 sud : 2377750 ouest : 4126750 est : 4536000 nsres : 25 ewres : 25 rangs : 12880 cols : 16370 alvéoles : 210845600

Résultats:

RAM : il a utilisé de la mémoire d'échange car j'ai un navigateur, etc. ouvert en même temps.

[[email protected] ~]$ total gratuit utilisé gratuit buff/cache partagé disponible Mem: 3930508 3600648 32408 93164 297452 165584 Swap: 3932156 2735164 1196992

Horaire:

GRASS 7.1.svn (eu_laea) :~ > temps -p r.watershed altitude=eu_dem_25_TN accumulation=eu_dem_25_TN.acc bassin=eu_dem_25_TN.watersheds seuil=10000 SECTION 1a (sur 5) : Initiation de la mémoire. SECTION 1b (sur 5) : Détermination du flux hors carte. 100% SECTION 2 : A* Recherche. 100 % SECTION 3a : Accumulation de flux de surface avec MFD. 100 % SECTION 3b : Ajustement des directions de drainage. 100 % SECTION 4 : Détermination du bassin versant. 100% SECTION 5 : Fermeture des cartes. réel 1270.30 utilisateur 1048.68 sys 54.00

… 21 minutes.

Compte tenu de mon test sur un petit ordinateur portable, il est très probable que votre région de calcul réelle ne corresponde pas à la carte d'entrée.

Concernant r.fill.dir : Pourquoi utilisez-vous le module r.fill.dir ?


Voir la vidéo: Linnunpöntön valmistus moottorisahalla (Octobre 2021).