python.exe ne fonctionne plus

Un script python a été écrit il y a environ 18 mois par une personne qui est maintenant partie. Il a alors produit les résultats requis. On m'a demandé de l'exécuter à nouveau mais avec des entrées de données différentes (résolution plus fine). L'ensemble de données d'entrée a été divisé en 20 sous-ensembles d'environ 2 700 points de données chacun. Cependant, le script se bloque («python.exe a cessé de fonctionner») après avoir traité environ 300 points de données (plage de 295 à 306 et n'échoue PAS toujours sur le même enregistrement).

Comme son ancien (ish), le script a été écrit en utilisant arcgisscripting et non arcpy. En gros, il fait ce qui suit en utilisant des curseurs:

Pour un point donné, calculez la distance de coût (en utilisant gp.CostDistance_sa) avec une coupure de 60 minutes de trajet.
Appelle gp.ExtractValuesToPoints_sa pour extraire toutes les valeurs individuelles à chaque point de données et génère une classe d'entités dans une géodatabase fichier.
Lit la classe d'entités créée en b) ci-dessus et écrit les valeurs dans un fichier CSV (en omettant tous les points avec "Aucune donnée" (valeur -9999)).

Répète 1, 2 et 3 pour tous les points de données restants dans le fichier d'entrée.

Le temps de traitement est d'env. 1 minute par point de données en moyenne. Voici quelques spécifications techniques pertinentes:

Le PC est doté d'un processeur Intel i7-2720QM quadricœur fonctionnant à 2,20 GHz avec 8 Go de RAM exécutant Windows 7 (64 bits).
La version Python est 2.6.6 (le shell indique également "[MSC v, 1500 32 bits (Intel)] sur win32).
ArcMap 10.0 (SP4) est également installé.

J'ai essayé de l'exécuter sur un autre PC (jusqu'à présent sans planter). Actuellement, le travail s'exécute avec succès (mais plus lentement) sur un ancien PC et a atteint 419 enregistrements sans se bloquer. Les spécifications pertinentes pour cette machine sont:

Processeur Intel Core 2 DUO E7500 fonctionnant à 2,93 GHz avec 4 Go de RAM et 64 bits Windows 7.
Python version 2.5.1 (le shell indique également "[MSC v, 1310 32 bits (Intel)] sur win32).
ArcMap 9.3 est installé (aucune mention de Service Packs).

Quelqu'un peut-il donner des conseils sur les raisons pour lesquelles le script semble fonctionner pendant un certain temps, puis planter et comment le résoudre?

Le fait qu'un PC différent apparaisse (jusqu'à présent) pour gérer le script suggère quelque chose d '"environnemental".

En tant que mise à jour, le PC exécutant ARCGIS 9.3 traite toujours avec succès les données et a atteint 1 300 points de données traités (et continue de compter). Un collègue a également exécuté les données sur leur PC exécutant ARCGIS 10.1 - elles se sont écrasées après 267 enregistrements à deux reprises. Bien que cela ne soit pas concluant, le fil conducteur semble être qu'Arc 9.3 traitera les données mais pas Arc 10.x.

— user14134
source

ArcGIS 10.0 utilise désormais le module arcpy (ArcGIS 9.x utilise le module arcgisscripting). Vous devrez reconfigurer votre code pour appeler arcpy et ajuster les noms des outils de géotraitement, si vous voulez qu'il fonctionne dans l'environnement AGS 10.

— dchaboya

Non, ce n'est pas correct - les anciens scripts qui fonctionnaient en 9.3 continueront de fonctionner en 10 et 10.1. Vous n'avez pas besoin de modifier gp en arcpy. Vous pouvez même mélanger gp et arcpy tout au long d'un script si vous souhaitez ajouter de nouvelles fonctionnalités, mais pas complètement convertir. ..... pourquoi ce cas particulier se bloque ci-dessus, je ne sais pas. Ma suggestion est de le décomposer en sections et de voir exactement le dernier outil / fonction à se produire avant les bails en python

— KHibma

KHibma, oui, je pense que cela a du sens car cela fonctionnait partiellement lors de l'exécution d'AGS 10.

— dchaboya

Les points de données ont-ils changé? Je suppose que vous utilisez des installations à distance du réseau routier (temps de trajet). Il n'y a aucune garantie que l'algorithme de traitement des points de données gère les points exactement de la même manière à chaque exécution du processus. 300 ou 306 ou tout ce qui pourrait être une coïncidence. J'ai utilisé NA pour l'analyse des coûts d'un réseau basé sur les routes et les emplacements dans un script python et je me demande si vous avez essayé un sous-ensemble plus petit. J'exécuterais des groupes de points beaucoup plus petits sur mon poste de travail pour un trajet de 60 minutes sur mon poste de travail. L'analyse du temps de trajet détruira la puissance de traitement.

— JLP Wisc.

Malheureusement, nous sommes également confrontés à des problèmes de stabilité d'arcpy GP (qui n'est en fait qu'un wrapper COM, et comme il ressemble à un buggy). arcpy est le seul package de site que je connaisse, qui peut en fait planter l'interpréteur python. CLJ a suggéré quelques solutions de contournement ici dans les réponses (utilisez GP 64 bits, curseurs us GA, etc ...), mais nous avons déjà reçu d'ESRI que ces problèmes sont des bogues. J'espère que le prochain service pack apportera des améliorations à ce sujet

— Jürgen Zornig

Si vous exécutez le gestionnaire de tâches et regardez l'augmentation de l'exécutable python en mémoire et dépassez 1 Go avant sa mort, vous pouvez bénéficier de la mise à niveau vers le géotraitement 10.1 64 bits.

Pour les performances, si vous utilisez des curseurs, vous pouvez bénéficier des nouveaux curseurs arcpy.da. http://resources.arcgis.com/en/help/main/10.1/index.html#//018w00000008000000

J'ai mis à niveau un projet pour utiliser arcpy.da et c'était une amélioration de 2 amplitudes.

— CLJ
source

Il s'agit simplement d'un bug arcpy. Vous pouvez essayer d'éviter d'utiliser les étapes qui provoquent le crash, mais cela se produit généralement sous différents outils lorsqu'il est utilisé pour traiter une longue liste de données. La seule solution de contournement que j'ai trouvée est de faire en sorte que mon script enregistre sa progression sur le disque, donc si vous redémarrez le processus, il sait d'où aller. Si vous désactivez ensuite le message du débogueur Windows en modifiant le registre (voir ci-dessous), vous pouvez ensuite simplement exécuter le script dans cmd.exe de manière répétée jusqu'à ce qu'il termine le lot entier sans avoir à fermer le processus manuellement à chaque fois entre les deux.

Je sais que c'est une terrible solution de contournement, mais il est assez rare qu'une bibliothèque python tue l'interpréteur python.

DWORD HKLM or HKCU\Software\Microsoft\Windows\Windows Error Reporting\DontShowUI = "1"
DWORD HKLM or HKCU\Software\Microsoft\Windows\Windows Error Reporting\Disabled = "1"

— Lucas Fortini
source

Avez-vous vérifié comment le script gère les curseurs? Mes applications se bloquent souvent lorsque j'oublie de les fermer en utilisant explicit del row, cursor, parfois seulement après un certain temps.

Si cela n'aide pas, je suggère d'utiliser une plus petite portion de code et / ou de données.

— Jan Šimbera
source