Métriques incohérentes et graphe incomplet en CLI avec Graphab 3.0.5

AnthoK

Bonjour,

Dans le cadre de mon stage de Master 2 OTG, je travaille sur des modélisations de connectivité écologique à grande échelle spatiale avec Graphab 3.0.5, en ligne de commande (CLI), sur un cluster SLURM.
Je cherche à comparer différents scénarios d’occupation du sol, avec des variations sur certains objets du paysage, afin d’évaluer leur impact sur la connectivité.

java -Xmx240G -jar \"$GRAPHAB_JAR\" \
--create TEST \"$RASTER_CLASSE\" nodata=0 dir=\"$OUTDIR\" \
--habitat name=... codes=2,7,8,9 minarea=300 con8 \
--linkset distance=cost name=jeulien1 topo=complete maxcost=0 remcrosspath extcost=\"$RASTER_FRICTION\" \
--graph name=Graph1 nointra threshold={10000} \
--usegraph Graph1 \
--gmetric EC d={10000} p=0.1 \
--gmetric PC d={10000} p=0.1 \
--lmetric IF d={10000} p=0.05 beta=0 \
--lmetric BC d={10000} p=0.05 beta=0\

Ci-joint un exemple du code que j'utilise pour lancer les modélisations.

Contexte technique :

Raster de friction : Taille variable en moyenne 10000 x 10000 pixels, résolution de 5m, aucune présence d'artefacts.
Seuil de graphe élevé (10 Km), justifié par la mobilité de l'espèce étudiée.
Modélisations lancées sur 250GB de RAM, en mode mono thread.
Version CLI avec java 23.

Problèmes rencontrés :

Les métriques globales (EC, PC) sont générées sans erreur mais varient très peu entre scénarios, alors que les modifications de l’occupation du sol sont importantes.
Les métriques locales (IF, BC) ne produisent pas toujours les fichiers attendus ou ne semblent pas calculées, sans message d’erreur apparent.
Certains fichiers structurels comme patches-topo.gpkg ou Graph1-topo_links.gpkg sont parfois absents du dossier projet, bien que les autres couches (links.gpkg, jeulien1-links.gpkg) soient bien présentes
Aucune alerte ou erreur critique dans les logs, ce qui rend le diagnostic difficile.

Ainsi je me pose plusieurs questions :

1) Les métriques globales peuvent-elles être calculées sans que le graphe défini via --graph soit réellement généré ? Y a t'il un système de mise en mémoire du graphe et de son élagage ?

2) Y a-t-il des cas où les métriques locales échouent sans retour d'erreur, notamment sur des jeux de données volumineux ou de grandes emprises spatiales ?

3) Auriez-vous des recommandations spécifiques concernant la gestion de projet à grande échelle en mode ligne de commande ? (J'ai abandonné l'interface graphique en raison de l'erreur de mémoire... J'ai essayé de résoudre le problème de mémoire selon les recommandations d'un autre channel de message sur ce forum, sans succès).

4) La génération des fichiers de graphe topologique peut-elle échouer silencieusement en cas de fragmentation excessive ou de surcharge de la mémoire ?

Merci par avance pour vos précieux conseils et éclairages.
Je peux si nécessaire vous transmettre une partie de mon code et plus de détails au sujet de mon étude.

Bien cordialement,
Anthonin Kumm.

gvuidel

Bonjour,

Pour vos questions :
1 - Les métriques sont toujours calculées sur un graphe généré précédemment
2 - Si le calcul d'une métrique locale n'arrive pas au bout, un message d'erreur est généré par Graphab. Par contre si votre système arrête le processus Java, Graphab ne peut rien faire. Vous êtes sur un cluster de calcul qui peut, pour différentes raisons, arrêter un processus ; investiguez de ce côté là.
3 - Difficile de donner une réponse générale. Cela dépend fortement du traitement réalisé par Graphab et des données.
4 - les fichiers "-topo" sont générés par le plugin Graphab sous QGIS. Tant que vous n'ouvrez pas votre projet Graphab dans QGIS, ces fichiers n'apparaissent pas. Ces fichiers servent uniquement à l'affichage des graphes en vue topologique dans QGIS. Ils ne sont pas utilisés pour les traitements.

Pour vos autres remarques :
Les variations de métriques globales peuvent être très faibles, ce n'est pas incohérent. L'intérêt est dans la comparaison des différents scénarios de changements. Comme vous ne définissez pas les coûts à partir de l'occupation du sol, il faut bien faire attention de reproduire sur chaque carte de friction vos variations dans le paysage.

En ligne de commande si une erreur est générée par Graphab elle sera toujours affichée sur la console. Mais comme vous êtes sur un cluster, c'est sans doute SLURM qui coupe le processus Graphab.

Dans votre ligne de commande plusieurs remarques :

Vous ne précisez pas le nombre de coeurs/processeurs que Graphab doit utiliser (option -proc). Ce n'est pas une bonne pratique car vous ne savez pas combien il en utilise, par défaut n-1 cœurs de la machine.
Vous calculez un jeu de liens complet sans seuil de distance (maxcost=0) c'est très très lourd à calculer. Il faut mettre une distance cout maximale pour limiter le temps de calcul et la charge mémoire
Quand on réalise des comparaisons entre scénarios, il ne faut faire la conversion de distance métrique en distance coût (accolades) que dans le scénario initial, puis conserver cette distance coût pour tous les autres scénarios.

Gilles