Багатопроцесорні помилки - реалізація ArcGIS

Мені було цікаво, чи хтось із спільноти тут намагався використати багатопроцесорну обробку для просторових аналізів. А саме я намагаюся повторити ряд растрових даних, створити багатопроцесорне завдання для кожного та запустити їх через декілька етапів геообробки в межах однієї функції def. Щось по лінії

def net(RasterImage, OutFolderDir):
    arcpy.env.overwriteOutput = True  
    arcpy.env.workspace = OutFolderDir 
    DEM_Prj = DEM_Prj.tif

    try:
        arcpy.ProjectRaster_management(RasterImage, DEM_Prj....
        FocalStatistics(DEM_prj....)
        ...

if __name__ == '__main__':  
    InputFolder = r'C:\test\somepath'  
    Output = r'C:\test\somepath2'  
    arcpy.env.workspace = InputFolder  
    arcpy.env.scratchWorkspace = r'C:\test.gdb'    

    fcs = arcpy.ListRasters('*')
    pool = multiprocessing.Pool(4)   
    jobs = []                 
    for fc in fcs:
        rIn = os.path.join(InputFolder,fc)
        rOut = os.path.join(Output,fc[:-4])
        jobs.append(pool.apply_async(net,(rIn, rOut)))    

Тепер багатопроцесорна робота працює, як правило, для першої партії! Однак я намагаюся зіткнутися з декількома різними помилками при спробі декількох наборів даних (більше 4-х файлів - тобто 4-х основних процесів), включаючи:

ERROR 010302: Unable to create the output raster: C:\somepath\sr6f8~1\FocalSt_srtm1
ERROR 010067: Error in executing grid expression.
Failed to execute (FocalStatistics).

і

ERROR 999999: Error executing function.
Failed to copy raster dataset
Failed to execute (ProjectRaster)

Зауважте в першій помилці дивну папку, яка створюється (у місці OutFolderDir), пов'язану з фокальною статистикою, яка майже створює точну репліку кінцевого виводу.

Моє запитання засноване на вашому досвіді, чи неможливо створити кілька ступінчасту геообробку в межах однієї багатопроцесорної функції? Або мені потрібно вписати ці етапи в їхні окремі етапи геообробки?

ОНОВЛЕННЯ

Але все-таки зустрічаються подібні помилки - переміщення функцій імпорту до функції def показало це

import arcpy 
from arcpy.sa import *

не може створити вихід із доданим синтаксичним попередженням, що імпорт * не дозволений.

ОНОВЛЕННЯ №2

Я знаю, що це несвоєчасна відповідь, але я подумав, що це може принести користь комусь іншому для подальшого посилання на мій спосіб вирішення, який дозволяє багатопроцесорній роботі працювати з arcpy. Основна проблема, яку я виявив після повернення до цієї проблеми, - це не конкуренція модулів arcpy, а скоріше конкуренція за програму scratchWorkspace, яку ArcObjects використовують для збереження тимчасових файлів. Тому розглянемо запуск лічильника в аргумент багатопроцесорного синтаксичного аналізу для створення унікального простору нуля для кожного процесу, тобто

Counter = 0 
for fc in fcs:              
    rIn = os.path.join(InputFolder,fc)              
    rOut = os.path.join(Output,fc[:-4])                    
    jobs.append(pool.apply_async(net,(rIn, rOut,Counter)))            
    Counter += 1

Потім в основній функції складіть конкретний тимчасовий каталог і призначте унікальну область скретчорксів для кожного багатопроцесорного завдання.

def main(RasterImage,OutFolderDir,Counter)      
    TempFolder = os.path.join(os.path.dirname(OutFolderDir),'Temp_%s'%  (Counter))      
    os.mkdir(TempFolder)      
    arcpy.scratchWorkspace = TempFolder      
    ... 

Сподіваємось, що це допомагає і дякує Рагі за первісну пропозицію використовувати окремі робочі простори temp - все ще викликає здивування, чому це спочатку не працювало.

Додаткові ресурси

Блог багатопроцесорної роботи ESRI

Блог Python, Gis та Stuff

Кожне з'єднання IWorkspace (тобто кожне підключення до бази даних) має спорідненість до потоку. Два потоки не можуть ділити одне робоче поле. Ви можете мати один потік власника ресурсу, а потім синхронізувати доступ, але якщо ви будете використовувати функції прямої gp, то це навіть не є варіантом.

Найпростіший (кульгавий) спосіб - створити окремі процеси, а потім зробити багатопроцесну синхронізацію (на відміну від багатопотокової синхронізації). Вже тоді вам слід знати про тип базової робочої області. якщо ви не використовуєте arcsde (багатокористувацький джерело даних), ви, ймовірно, буде використовувати один користувацький джерело даних (наприклад, персональний або filegdb). Тоді пам’ятайте, що означає, що одночасно може писати лише один процес! Типова (кульгава) синхронізація для цих сценаріїв полягає в тому, що кожен паралельний процес записує в іншу робочу область temp, а потім ви об'єднуєте все це в робочу область вашого призначення в один процес.

У вас є кілька ниток, які змагаються за один і той же ресурс.

Спробуйте перемістити оператор "імпортувати arcpy" в ціль багатопроцесорної обробки. Ви переконайтеся, що arcpy працює з власним набором змінних середовища та пам'яті.

Це звучить абсурдно, але, хоча ви встановлюєте змінні середовища в багатопроцессному цільовому методі, python все ще використовує спільний простір пам’яті для управління модулем arcpy і, отже, будь-якими встановленими вами змінними.

Arcpy не є безпечним для потоків. Він завжди був призначений для використання в рамках одного процесу. Але є обхідні шляхи.

Моя пропозиція полягала в тому, щоб імпортувати архпію в межах цілі для нового процесу.

def _multiprocessing_target(args):
    import arcpy
    ...code