2017-03-21 4 views
1

J'écris un problème OpenMDAO qui appelle un groupe de codes externes dans un groupe parallèle. L'un de ces codes externes est un code fortran FEM basé sur PETSc. Je réalise que cela est potentiellement problématique puisque OpenMDAO utilise également PETSc. Pour l'instant, j'appelle le code externe dans un composant en utilisant le sous-processus de python.Impossible d'appeler le code externe PETSc/MPI en parallèle OpenMDAO

Si j'exécute mon problème OpenMDAO en série (c'est-à-dire python2.7 omdao_problem.py), tout fonctionne, y compris le code externe. Lorsque je tente de l'exécuter en parallèle, cependant (c.-à-mpirun np 4 python2.7 omdao_problem.py), il fonctionne jusqu'à l'appel subprocess, à quel point je reçois l'erreur:

*** Process received signal *** 
Signal: Segmentation fault: 11 (11) 
Signal code: Address not mapped (1) 
Failing at address: 0xe3c00 
[ 0] 0 libsystem_platform.dylib   0x00007fff94cb652a _sigtramp + 26 
[ 1] 0 libopen-pal.20.dylib    0x00000001031360c5 opal_timer_darwin_bias + 15469 
*** End of error message *** 

je peux » J'en fais beaucoup, mais il me semble raisonnable que le problème viendrait de l'utilisation d'un code python basé sur MPI pour appeler un autre code compatible MPI. J'ai essayé d'utiliser un exécutable non-mpi "hello world" à la place du code externe et qui peut être appelé par le code OpenMDAO parallèle sans erreur. Je n'ai pas besoin que le code externe fonctionne réellement en parallèle, mais j'ai besoin d'utiliser les solveurs PETSc et autres, d'où la dépendance inhérente à MPI. (Je suppose que je pourrais envisager d'avoir une version de PETSc compatible MPI et non-MPI) Je préférerais ne pas le faire si possible car je peux voir que cela devient un désordre pressé.)

I trouvé this discussion qui semble présenter un problème similaire (et déclare en outre que l'utilisation de sous-processus dans un code MPI, comme je le fais, est un non-non). Dans ce cas, il semble que l'utilisation de MPI_Comm_spawn puisse être une option, même si elle n'est pas prévue pour cette utilisation. Une idée si cela fonctionnerait dans le contexte d'OpenMDAO? D'autres avenues à poursuivre pour que cela fonctionne? Toutes les pensées ou suggestions sont grandement appréciées.

Répondre

0

Vous n'avez pas besoin d'appeler le code externe en tant que sous-processus. Enveloppez le code fortran dans python en utilisant F2py et passez un objet comm dans celui-ci. This docs example montre comment travailler avec des composants qui utilisent un comm.

Vous pouvez utiliser un spawn MPI si vous le souhaitez. Cette approche a été faite, mais loin d'être idéale. Vous serez beaucoup plus efficace si vous pouvez envelopper le code dans la mémoire et laisser OpenMDAO vous transmettre un comm.

+1

Cette suggestion m'a définitivement indiqué dans la bonne direction. F2py est assez simple à utiliser pour les codes Fortran simples, mais il était un peu compliqué de l'associer à PETSc. Pour tous ceux qui veulent faire la même chose, voir la discussion à ce poste: http://stackoverflow.com/questions/42978049/unable-to-use-f2py-to-link-large-petsc-slepc-fortran- code? noredirect = 1 # comment73227077_42978049 – aherrema