Parallel Grass jobs

[Ripsime]

Здравствуйте... !!!
Уже 1.5 месяцев начала работать с Grass , но пока не очень хорошо разбираюсь. Установила grass 64* на кластере (где среда Scientific Linux 5.5 (grid) ) . Как я поняла пораллелизация растра происходит по строкам (если конечно правильно поняла ) . или может по слоям растра
Теперь моя задача импортировать какой-то растр и понять как вообще работает параллельно ((выполнить любую функцию(+ без графического режима ) ). КТО РАБОТАЛ,ЗНАЕТ и МОЖЕТ ПОМОЧЬ МНЕ С ПАРАЛИЗАЦИЕЙ (хоть как нибудь)?????
Буду очень благодарна !!!

[KolesovDmitry]

С параллелизацией я работал, но очень мало -- для баловства, и не на кластере, а на многопроцессорной системе, но постараюсь помочь, если буду знать как. Первый вопрос: по какому мануалу вы работаете (есть несколько способов паралелльной обработки данных в GRASS, нужно знать, чем пользуетесь вы).

[Александр Мурый]

В кластерах (как любой юзер) ничего не понимаю, хотя параллелизация и т.п. очень интересует.
Grid --- имеется в виду, как описано здесь?

Было бы хорошо побольше технической информации про среду и grid.. Как всё устроено, количество узлов, как устроена связь между узлами, тип файловой системы, какое ПО для параллелизации установлено и планируется для использования (типа Open Grid Scheduler) и т.д.

Как я понимаю, параллелизация происходит НЕ по "строкам" или "слоям", а всё-таки по целым растрам. Обработка растров в GRASS "параллельно" по сути ничем не отличается от обычной работы модулей. Как описано на GRASS-Wiki, надо написать несколько shell-скриптов с использованием утилит Open Grid Scheduler и скрипты для обработки собственно в GRASS, всё это по типу "назначение заданий" --> "исполнение" --> "сбор полученных данных". На указанной вики-странице есть пример реальных скриптов, с их помощью был обработан большой массив данных MODIS. Кстати, там тоже был Scientific Linux.

[Ripsime]

С параллелизацией я работал, но очень мало -- для баловства, и не на кластере, а на многопроцессорной системе, но постараюсь помочь, если буду знать как. Первый вопрос: по какому мануалу вы работаете (есть несколько способов паралелльной обработки данных в GRASS, нужно знать, чем пользуетесь вы).

Я только начинаю и не очень хорошо разбираюсь... А какие мануалы вообще есть??? и каким лучше пользоваться???

и ещё у меня сейчас вот какая проблема: когда я вызываю grass , открывается

это

unknown.png (63.5 КБ) 10190 просмотров

и я не могу создать LOCATION. На своём компьютере когда создавала . сделала это с помощью графического интерфейса. а так не могу . Как сделать это????

Потом взяла и отправила уже готовую, созданную на моём компьютере папку на кластер . там открыла и всё нормально заработала.

[Ripsime]

Grid --- имеется в виду, как описано здесь?

Да!!! именно это имеется ввиду. Но пока я работаю только на кластере (Grid пока не использую).
Вся среда Linux (Scientific Linux 5.7). и мне пока нужно всего 2 нода. просто.чтобы понять принцип роботы... и вообще возмозно это или нет.

Как я понимаю, параллелизация происходит НЕ по "строкам" или "слоям", а всё-таки по целым растрам. ]

если так, то тогда зачем нужна параллелизация???
а то что ппараллелизация происходит по строкам прочитла тут

W06P08_20100308142046.pdf

grass

(1.66 МБ) 783 скачивания

[Александр Мурый]

По-моему, вы путаете параллелизацию в коде программы и параллелизацию на кластере. Это "две большие разницы".
С распараллеливанием на уровне коде пока у GRASS туго (всего несколько модулей).
Вы сами определитесь, что вам надо. Если надо "параллельно" обрабатывать большой объём данных на кластере, используя имеющиеся модули GRASS, то надо смотреть в сторону <Open Grid Scheduler> и т.п.

Кстати, интересно, как за пару дней Scientific Linux поменял версию с 5.5 на 5.7. Быстро обновляетесь
И главное: читайте мануалы и пособия, без них -- никуда. Там есть создание области "с нуля" и прочее. Дело в том, что при написании скриптов для массовой обработки понадобится понимание принципов работы GRASS и отдельных модулей. И спрашивайте побольше --- очень уж интересная у вас тема

[Ripsime]

По-моему, вы путаете параллелизацию в коде программы и параллелизацию на кластере.

Может быть

Кстати, интересно, как за пару дней Scientific Linux поменял версию с 5.5 на 5.7. Быстро обновляетесь

Scientific Linux 5.7!!!! В первый раз не правильно написла. но нет разници, они почти не отличаются.

[KolesovDmitry]

Amyriy уже давал (но я на всякий случай повторю) ссылку на вики http://grass.osgeo.org/wiki/Parallel_GRASS_jobs где описаны варианты параллельной обработки.

Другой вариант -- использование Batch jobs http://grass.osgeo.org/wiki/GRASS_and_S ... Batch_jobs , которым я в свое время и пользовался. Идея там проста: исходная область разбивается на пересекающиеся подобласти, создается скрипт, который запускается каждой подобласти одновременно. Потом происходит объеденение результатов.

Также я пробовал собирать конвейер, когда один узел (в моем случае было ядро) выполняет первую часть задания, решает ее, передает ответ второму узлу, который продолжает решение. А первый узел тем временем начинает обработку и т.д. Но для того, чтобы конвейер был оправдан, нужна специфическая задача.

[Александр Мурый]

Другой вариант -- использование Batch jobs http://grass.osgeo.org/wiki/GRASS_and_S ... Batch_jobs , которым я в свое время и пользовался. Идея там проста: исходная область разбивается на пересекающиеся подобласти, создается скрипт, который запускается каждой подобласти одновременно. Потом происходит объеденение результатов.

Разве "Batch_jobs" в этом случае имеет отношение к разбиению областей? Вроде бы это просто удобный способ запуска скрипта массовой обработки. Хотя, конечно, в самом скрипте может быть и создание "подобластей" и т.п.

Я пробовал играться с GNU Parallel, пока только для выведения данных на терминал (r.stats, например), с растрами всё сложнее.

[KolesovDmitry]

Разве "Batch_jobs" в этом случае имеет отношение к разбиению областей? Вроде бы это просто удобный способ запуска скрипта массовой обработки.

Все верно, но представь, что у тебя есть подобласти с одинаковым набором карт и которые отличаются только охватом. Тогда можно напистать один скрипт, который обрабатывает эти карты и запустить несколько экземпляров скрипта, передав им имя подрегиона в качестве параметра. Все эти экземпляры будут работать одновременно, но с разными подобластями, в результате -- простая и дешевая параллелизация.

[Александр Мурый]

Тогда можно напистать один скрипт, который обрабатывает эти карты и запустить несколько экземпляров скрипта, передав им имя подрегиона в качестве параметра. Все эти экземпляры будут работать одновременно, но с разными подобластями

Дмитрий, а нет ли "работающего прототипа" такого скрипта? Очень пригодилось бы. Или, может, соорудим вместе скрипт на примере данных набора Spearfish или NC?

[KolesovDmitry]

Дмитрий, а нет ли "работающего прототипа" такого скрипта? Очень пригодилось бы. Или, может, соорудим вместе скрипт на примере данных набора Spearfish или NC?

Давай, соорудим, но лучше на маленьком наборе -- чтобы карты не копировать в больших количествах из общего региона в подрегионы (нам ведь только для примера?). Может, geosample взять?

[Александр Мурый]

чтобы карты не копировать в больших количествах из общего региона в подрегионы (нам ведь только для примера?). Может, geosample взять?

Можно и Geosample, почему нет. Мне хочется понять алгоритм, а дальше можно применять на практике. А то уже достало использовать одно ядро для работы с растрами..
Была ещё и такая идея: скрипт, который на входе принимает целиком какую-либо команду типа "r.shaded.relief dem shadedmap=dem.shaded", ну и распараллеливает всё это дело на несколько (врЕменных?) областей (или наборов в одной области?) с нарезкой искомого растра и соединением в конечный целый растр.

[KolesovDmitry]

может, соорудим вместе скрипт на примере данных набора Spearfish или NC?

Начал потихоньку описывать процесс: здесь пример, как запустить команды GRASS из внешнего скрипта, а здесь пример параллельного запуска скрипта в двух наборах.