Проблема с OpenMDAO, с которой я работаю, довольно сложна, поэтому я не думаю, что было бы полезно публиковать весь сценарий. Тем не менее, базовая установка заключается в том, что корень моей проблемы — это ParallelFDGroup (на самом деле пока не конечная разность — просто запуск задачи один раз), которая содержит несколько обычных компонентов, а также параллельную группу. Параллельная группа отвечает за выполнение 56 экземпляров внешнего кода (один компонент на экземпляр кода). Странно, когда запускаю задачу с 4-8 процессорами, вроде все нормально работает (иногда работает даже с 10-12 процессорами). Но когда я пытаюсь использовать больше процессоров (20+), я постоянно получаю следующие ошибки. Он обеспечивает две трассировки:
Traceback (most recent call last):
File "opt_5mw.py", line 216, in <module>
top.setup() #call setup
File "/home/austinherrema/.local/lib/python2.7/site-packages/openmdao/core/problem.py", line 644, in setup
self.root._setup_vectors(param_owners, impl=self._impl, alloc_derivs=alloc_derivs)
File "/home/austinherrema/.local/lib/python2.7/site-packages/openmdao/core/group.py", line 476, in _setup_vectors
self._u_size_lists = self.unknowns._get_flattened_sizes()
File "/home/austinherrema/.local/lib/python2.7/site-packages/openmdao/core/petsc_impl.py", line 204, in _get_flattened_sizes
return self.comm.allgather(sizes)
File "MPI/Comm.pyx", line 1291, in mpi4py.MPI.Comm.allgather (src/mpi4py.MPI.c:109194)
File "MPI/msgpickle.pxi", line 746, in mpi4py.MPI.PyMPI_allgather (src/mpi4py.MPI.c:48575)
mpi4py.MPI.Exception: MPI_ERR_IN_STATUS: error code in status
Traceback (most recent call last):
File "opt_5mw.py", line 216, in <module>
top.setup() #call setup
File "/home/austinherrema/.local/lib/python2.7/site-packages/openmdao/core/problem.py", line 644, in setup
self.root._setup_vectors(param_owners, impl=self._impl, alloc_derivs=alloc_derivs)
File "/home/austinherrema/.local/lib/python2.7/site-packages/openmdao/core/group.py", line 476, in _setup_vectors
self._u_size_lists = self.unknowns._get_flattened_sizes()
File "/home/austinherrema/.local/lib/python2.7/site-packages/openmdao/core/petsc_impl.py", line 204, in _get_flattened_sizes
return self.comm.allgather(sizes)
File "MPI/Comm.pyx", line 1291, in mpi4py.MPI.Comm.allgather (src/mpi4py.MPI.c:109194)
File "MPI/msgpickle.pxi", line 749, in mpi4py.MPI.PyMPI_allgather (src/mpi4py.MPI.c:48609)
File "MPI/msgpickle.pxi", line 191, in mpi4py.MPI.Pickle.loadv (src/mpi4py.MPI.c:41957)
File "MPI/msgpickle.pxi", line 143, in mpi4py.MPI.Pickle.load (src/mpi4py.MPI.c:41248)
cPickle.BadPickleGet: 65
Я работаю под Ubuntu с OpenMDAO 1.7.3. Я пробовал работать как с mpirun.openmpi (OpenRTE) 1.4.3, так и с mpirun (Open MPI) 1.4.3, и в каждом случае получал одинаковый результат.
Я нашел этот пост, который, кажется, предполагает, что что-то не так с установка МПИ. Но если бы это было так, мне кажется странным, что задача работала бы для небольшого количества процессоров, но не для большего числа. Я также могу запустить относительно простую задачу OpenMDAO (без внешних кодов) с 32 процессорами без происшествий.
Поскольку трассировка ссылается на неизвестные OpenMDAO, я задался вопросом, существуют ли ограничения на размер неизвестных OpenMDAO. В моем случае каждый компонент внешнего кода имеет несколько десятков выходных массивов, каждый из которых может содержать до 50 000–60 000 элементов. Может это проблематично? Каждый компонент внешнего кода также считывает один и тот же набор входных файлов. Это тоже может быть проблемой? Я попытался убедиться, что доступ для чтения и записи определен правильно, но, возможно, этого недостаточно.
Любые предложения о том, что может быть виновником в этой ситуации, приветствуются.
РЕДАКТИРОВАТЬ: я должен добавить, что я пытался запустить проблему без фактического запуска внешних кодов (т.е. компоненты в параллельной группе вызываются и настраиваются, но внешние подпроцессы фактически никогда не создаются), и проблема сохраняется.
EDIT2: я сделал еще несколько отладок по этой проблеме и подумал, что должен поделиться тем немногим, что я обнаружил. Если я сведу проблему только к параллельной группе, содержащей экземпляры внешнего кода, проблема не исчезнет. Однако если я уменьшу количество компонентов в параллельной группе практически до нуля — только функцию печати для настройки и дляsolve_nonlinear— тогда задача может успешно «выполняться» с большим количеством процессоров. Я начал добавлять строки настройки одну за другой, чтобы посмотреть, что создаст проблемы. Я столкнулся с проблемами при попытке добавить в компоненты много больших неизвестных. На самом деле я все еще могу добавить только одно большое неизвестное — например, это работает:
self.add_output('BigOutput', shape=[100000])
Но когда я пытаюсь добавить слишком много больших выходных данных, как показано ниже, я получаю ошибки:
for i in range(100):
outputname = 'BigOutput{0}'.format(i)
self.add_output(outputname, shape=[100000])
Иногда я просто получаю общую ошибку нарушения сегментации от PETSc. В других случаях я получаю довольно длинную трассировку, которая слишком длинна, чтобы публиковать ее здесь — я опубликую только начало на случай, если она даст какие-либо полезные подсказки:
*** glibc detected *** python2.7: free(): invalid pointer: 0x00007f21204f5010 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x7da26)[0x7f2285f0ca26]
/home/austinherrema/miniconda2/lib/python2.7/lib-dynload/../../libsqlite3.so.0(sqlite3_free+0x4f)[0x7f2269b7754f]
/home/austinherrema/miniconda2/lib/python2.7/lib-dynload/../../libsqlite3.so.0(+0x1cbbc)[0x7f2269b87bbc]
/home/austinherrema/miniconda2/lib/python2.7/lib-dynload/../../libsqlite3.so.0(+0x54d6c)[0x7f2269bbfd6c]
/home/austinherrema/miniconda2/lib/python2.7/lib-dynload/../../libsqlite3.so.0(+0x9d31f)[0x7f2269c0831f]
/home/austinherrema/miniconda2/lib/python2.7/lib-dynload/../../libsqlite3.so.0(sqlite3_step+0x1bf)[0x7f2269be261f]
/home/austinherrema/miniconda2/lib/python2.7/lib-dynload/_sqlite3.so(pysqlite_step+0x2d)[0x7f2269e4306d]
/home/austinherrema/miniconda2/lib/python2.7/lib-dynload/_sqlite3.so(_pysqlite_query_execute+0x661)[0x7f2269e404b1]
/home/austinherrema/miniconda2/bin/../lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x8942)[0x7f2286c6a5a2]
/home/austinherrema/miniconda2/bin/../lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x86c3)[0x7f2286c6a323]
/home/austinherrema/miniconda2/bin/../lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x86c3)[0x7f2286c6a323]
/home/austinherrema/miniconda2/bin/../lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x89e)[0x7f2286c6b1ce]
/home/austinherrema/miniconda2/bin/../lib/libpython2.7.so.1.0(+0x797e1)[0x7f2286be67e1]
/home/austinherrema/miniconda2/bin/../lib/libpython2.7.so.1.0(PyObject_Call+0x53)[0x7f2286bb6dc3]
/home/austinherrema/miniconda2/bin/../lib/libpython2.7.so.1.0(+0x5c54f)[0x7f2286bc954f]
/home/austinherrema/miniconda2/bin/../lib/libpython2.7.so.1.0(PyObject_Call+0x53)[0x7f2286bb6dc3]
/home/austinherrema/miniconda2/bin/../lib/libpython2.7.so.1.0(PyEval_CallObjectWithKeywords+0x43)[0x7f2286c60d63]
/home/austinherrema/miniconda2/bin/../lib/libpython2.7.so.1.0(+0x136652)[0x7f2286ca3652]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)[0x7f2286957e9a]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f2285f8236d]
======= Memory map: ========
00400000-00401000 r-xp 00000000 08:03 9706352 /home/austinherrema/miniconda2/bin/python2.7
00600000-00601000 rw-p 00000000 08:03 9706352 /home/austinherrema/miniconda2/bin/python2.7
00aca000-113891000 rw-p 00000000 00:00 0 [heap]
7f21107d6000-7f2241957000 rw-p 00000000 00:00 0
etc...
