python.exe funktioniert nicht mehr

Ein Python-Skript wurde vor ungefähr 18 Monaten von einer Person geschrieben, die jetzt gegangen ist. Es wurden dann die erforderlichen Ausgaben erzeugt. Ich wurde gebeten, es erneut auszuführen, jedoch mit anderen (feineren) Dateneingaben. Der Eingabedatensatz wurde in 20 Teilmengen von jeweils ca. 2.700 Datenpunkten aufgeteilt. Das Skript stürzt jedoch ab ("python.exe funktioniert nicht mehr"), nachdem ca. 300 Datenpunkte verarbeitet wurden (Bereich 295 bis 306 und schlägt NICHT immer im selben Datensatz fehl).

Wie sein altes (ish) wurde das Skript mit arcgisscripting und nicht mit arcpy geschrieben. Im Allgemeinen wird Folgendes mit Cursorn ausgeführt:

Berechnen Sie für einen bestimmten Punkt die Kostenentfernung (mit gp.CostDistance_sa) mit einem Grenzwert von 60 Minuten Fahrzeit.
Ruft gp.ExtractValuesToPoints_sa auf, um alle Einzelwerte an jedem Datenpunkt zu extrahieren, und gibt eine Feature-Class an eine Datei-Geodatabase aus.
Liest die in b) oben erstellte Feature-Class und schreibt die Werte in eine CSV-Datei (ohne Punkte mit "Keine Daten" (Wert -9999)).

Wiederholt 1, 2 und 3 für alle verbleibenden Datenpunkte in der Eingabedatei.

Die Bearbeitungszeit beträgt ca. Durchschnittlich 1 Minute pro Datenpunkt. Hier sind einige relevante technische Spezifikationen:

Der PC verfügt über eine Quad-Core-Intel i7-2720QM-CPU mit 2,20 GHz und 8 GB RAM unter Windows 7 (64 Bit).
Die Python-Version ist 2.6.6 (die Shell gibt auch "[MSC v, 1500 32 Bit (Intel)] unter win32" an).
ArcMap 10.0 (SP4) ist ebenfalls installiert.

Ich habe versucht, es auf einem anderen PC auszuführen (bisher ohne Absturz). Derzeit wird der Job auf einem älteren PC erfolgreich (aber langsamer) ausgeführt und hat 419 Datensätze ohne Absturz erreicht. Die relevanten Spezifikationen für diese Maschine sind:

Intel Core 2 DUO E7500 Prozessor mit 2,93 GHz, 4 GB RAM und 64 Bit Windows 7.
Python Version 2.5.1 (Shell gibt auch "[MSC v, 1310 32 Bit (Intel)] unter win32" an).
ArcMap 9.3 ist installiert (keine Erwähnung von Service Packs).

Kann jemand einen Rat geben, warum das Skript eine Weile zu funktionieren scheint und dann abstürzt und wie man es löst?

Die Tatsache, dass (bisher) ein anderer PC für die Verarbeitung des Skripts angezeigt wird, deutet auf etwas "Umweltfreundliches" hin.

Als Update verarbeitet der PC mit ARCGIS 9.3 die Daten weiterhin erfolgreich und hat 1.300 verarbeitete Datenpunkte erreicht (und zählt noch). Ein Kollege hat die Daten auch auf seinem PC mit ARCGIS 10.1 ausgeführt - sie stürzten nach 267 Datensätzen zweimal ab. Obwohl dies nicht schlüssig ist, scheint der rote Faden zu sein, dass Arc 9.3 die Daten verarbeitet, Arc 10.x jedoch nicht.

— user14134
quelle

ArcGIS 10.0 verwendet jetzt das arcpy-Modul (ArcGIS 9.x verwendet das arcgisscripting-Modul). Sie müssen Ihren Code neu konfigurieren, um arcpy aufzurufen, und die Namen aller Geoverarbeitungswerkzeuge anpassen, wenn Sie möchten, dass er in einer AGS 10-Umgebung funktioniert.

— Dchaboya

Nein, das ist nicht richtig - alte Skripte, die in 9.3 funktionierten, funktionieren weiterhin in 10 und 10.1. Sie müssen gp nicht in arcpy ändern. Sie können gp und arcpy sogar in einem Skript miteinander vermischen, wenn Sie neue Funktionen hinzufügen möchten, diese jedoch nicht vollständig konvertieren möchten. ..... warum dieser spezielle Fall oben abstürzt, weiß ich nicht. Mein Vorschlag ist, es in Abschnitte zu

— zerlegen

KHibma, ja, ich denke, das macht Sinn, da es teilweise funktionierte, als es von AGS 10 lief.

— Dchaboya

Haben sich die Datenpunkte geändert? Ich gehe davon aus, dass Sie Einrichtungen in der Nähe des Straßennetzes (Reisezeit) nutzen. Es gibt keine Garantie dafür, dass der Algorithmus zum Verarbeiten von Datenpunkten die Punkte bei jedem Ausführen des Prozesses genau gleich verwaltet. 300 oder 306 oder was auch immer könnte Zufall sein. Ich habe NA für die Kostenanalyse eines Netzwerks verwendet, das auf Straßen und Standorten in einem Python-Skript basiert, und ich frage mich, ob Sie eine kleinere Teilmenge ausprobiert haben. Ich würde weitaus kleinere Gruppen von Punkten auf meiner Workstation ausführen, um 60 Minuten auf meiner Workstation zu fahren. Die Analyse der Reisezeit zerstört die Rechenleistung.

— JLP Wisc.

Leider haben wir auch Stabilitätsprobleme mit arcpy GP (das eigentlich nur ein COM-Wrapper ist und wie ein Buggy aussieht). arcpy ist das einzige mir bekannte Site-Paket, das den Python-Interpreter tatsächlich zum Absturz bringen kann. CLJ schlug hier unten in den Antworten einige Problemumgehungen vor (verwenden Sie 64-Bit-GP, uns GA-Cursor usw.), aber ESRI hat uns bereits geantwortet, dass diese Probleme Fehler sind. Hoffentlich bringt das nächste Service Pack Verbesserungen

— Jürgen Zornig

Wenn Sie den Task-Manager ausführen und beobachten, wie die Speicherkapazität der ausführbaren Python-Datei zunimmt und mehr als 1 GB überschreitet, bevor sie stirbt, können Sie von einem Upgrade auf 10.1 64-Bit-Geoverarbeitung profitieren.

Wenn Sie Cursor verwenden, können Sie für die Leistung von den neuen arcpy.da-Cursorn profitieren. http://resources.arcgis.com/de/help/main/10.1/index.html#//018w00000008000000

Ich habe ein Projekt auf arcpy.da aktualisiert und es war eine Verbesserung um 2 Größenordnungen.

— CLJ
quelle

Dies ist einfach ein Arcpy-Bug. Sie können versuchen, die Schritte zu vermeiden, die den Absturz verursachen. Dies geschieht jedoch im Allgemeinen unter verschiedenen Tools, wenn eine lange Liste von Daten verarbeitet wird. Die einzige Problemumgehung, die ich gefunden habe, besteht darin, dass mein Skript seinen Fortschritt auf dem Weg zur Festplatte speichert. Wenn Sie den Prozess neu starten, weiß es, wo es abholen soll. Wenn Sie dann die Windows-Debugger-Nachricht durch Ändern der Registrierung deaktivieren (siehe unten), können Sie das Skript in cmd.exe einfach wiederholt ausführen, bis der gesamte Stapel abgeschlossen ist, ohne den Prozess jedes Mal zwischendurch manuell schließen zu müssen.

Ich weiß, dass dies eine schreckliche Problemumgehung ist, aber es ist ziemlich ungewöhnlich, dass eine Python-Bibliothek den Python-Interpreter abschaltet.

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
quelle

Haben Sie überprüft, wie das Skript mit Cursorn umgeht? Meine Anwendungen hängen oft, wenn ich vergesse, sie explizit zu schließen del row, cursor, manchmal erst nach einiger Zeit.

Wenn das nicht hilft, würde ich vorschlagen, einen kleineren Teil des Codes und / oder der Daten zu verwenden.

— Jan Šimbera
quelle