Ошибка, когда Rmpi ​​slaves вызывают пользовательскую функцию - PullRequest
Новая
       22

Ошибка, когда Rmpi ​​slaves вызывают пользовательскую функцию

0 голосов
/ 06 февраля 2012

Я написал код Rmpi, в котором я хочу, чтобы мастер разделил бремя работы поровну с рабами.Таким образом, функция work_by_master выполняет mpi.bcast.cmd до work_by_slaves, которые оба вызывают по внутреннему вызову work_to_be_done_per_process перед выполнением отправки-получения для обмена результатом.

Я постоянно получаю сообщение об ошибке: 

Error in mpi.probe(source, tag, comm, status) : ignoring SIGPIPE signal
Calls: work_by_master -> mpi.recv.Robj -> mpi.probe -> .Call

Я изо всех сил пытался понять, в чем заключается ошибка, и, наконец, после того, как потратил МНОГО времени, косвенно осознал, что, возможно, ошибка происходит из-за того, что ведомые не могут вызывать пользовательскую функцию вложенным способом.Когда я включил work_to_be_done_per_process в work_by_slaves и разрешил только главный вызов work_to_be_done_per_process, ошибка была устранена.

Я также продублировал функцию work_to_be_done_per_process в work_to_be_done_per_process_by_slaves и work_to_be_done_per_process_by_master и позволилрабы и хозяин называют их соответственно.Даже это не решило проблему.Следовательно, только мой вышеупомянутый вывод кажется причиной.

Это правда?Кто-нибудь еще сталкивался с такой проблемой, что slave не может вызывать пользовательскую функцию изнутри?Есть ли способ правильно сделать это.

1 Ответ

2 голосов
/ 06 февраля 2012

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

...