2017-09-15 55 views
5

Więc mam trobule z gmsh.Jak uruchamiać aplikacje kompatybilne z MPI z notebooków Jupyter?

bezpośrednie wykonanie działa dobrze:

!gmsh -3 -algo meshadapt tmp_0.geo -o SFM.msh 

Chociaż wykonanie z kodu nie powiedzie:

try: 
    out = subprocess.check_output(
      ["gmsh", "gmsh -3 -algo meshadapt tmp_0.geo -o SFM.msh"], 
      stderr=subprocess.STDOUT 
      ).strip().decode('utf8') 
except subprocess.CalledProcessError as e: 
    out = e.output 
print(out) 

z:

b "----------- -------------------------------------------------- ------------- \ n [[23419,1], 0]: Wysoce wydajny moduł przesyłania komunikatów typu "point-to-point" Open MPI \ nwas unabl e, aby znaleźć odpowiednie interfejsy sieciowe: \ n \ nModule: OpenFabrics (openib) \ n Host: 931136e3f6fe \ n \ nInny transport zostanie użyty zamiast tego, chociaż może to spowodować \ nlower wydajność. \ n ---- -------------------------------------------------- -------------------- \ n \ x1b [1m \ x1b [31mFatal: Nie można otworzyć wyświetlacza: (błąd wewnętrzny FLTK ) \ x1b [0m \ n- -------------------------------------------------- ----------------------- \ nMPI_ABORT został wywołany na pozycji 0 w komunikatorze MPI_COMM_WORLD \ nz kodem błędu 1. \ n \ nUWAGA: wywołanie MPI_ABORT powoduje otwarcie MPI na zabij wszystkie procesy MPI. \ nMożesz zobaczyć dane wyjściowe z innych procesów lub nie, w zależności od \ nw rzeczywistej sytuacji, gdy Otwórz MPI zabije ich . \ n ------------------- -------------------------------------------------- ----- \ n "

Jak więc emulować wykonanie ! w jupyter z kodu Python 3?


@Hristo:

_ =/opt/Conda/bin/jupyter SHLVL = 1 PATH =/opt/Conda/bin:/opt/Conda/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin HOSTNAME = 931136e3f6fe HOME =/root LC_ALL = C.UTF-8 PWD =/JPY_PARENT_PID = 1 LANG = C. UTF-8 TERM = xterm-color CLICOLOR = 1 PAGER = cat GIT_PAGER = cat MPLBACKEND = moduł: //ipykernel.pylab.backend_inline env DISPLAY =: 0 gmsh -3 -algo meshadapt tmp_0.geo -o SFM.msh

@Gilles: Ten sam wynik.

+0

Czy ty 'eksport OMPI_MCA_btl =^openib' i spróbuj ponownie ? Trudno jest ustalić, czy główną przyczyną jest infiniband (MPI), czy problem z wyświetlaniem (prawdopodobnie związany z aplikacją). –

+0

Narzeka, że ​​nie może otworzyć połączenia z serwerem wyświetlającym, co oznacza, że ​​zmienna środowiskowa 'DISPLAY' nie jest ustawić prawidłowo. Spróbuj uruchomić polecenie jako '[" env "," env DISPLAY =: 0 gmsh -3 -algo ... "]'. Wykonaj 'echo $ DISPLAY' w terminalu graficznym, aby uzyskać prawidłową wartość. Jeśli serwer Jupyter działa na innym koncie, najprawdopodobniej nie będzie działał, jeśli '' '' '' '' '' '' '' '' '' '' 'nie będzie działał, dopóki' '' Prawdopodobnie nie zadziała, jeśli Jupyter działa na innym hoście. –

Odpowiedz

1

Wydaje się, że przyczyną źródłową jest zmienna środowiskowa $DISPLAY, która nie jest ustawiona.

najpierw upewnij się, że $DISPLAY jest ustawiony po uruchomieniu notebooka Jupyter. może być konieczne wybranie polecenia mpirun w celu wyeksportowania go do wszystkich zadań MPI.

począwszy od Open MPI 3.0.0, można to osiągnąć z export OMPI_MCA_mca_base_env_list=DISPLAY przed rozpoczęciem notebook Jupyter

Nawiasem mówiąc, powinien aplikacji należy otworzyć wyświetlacz X? Jeśli nie ma żadnej grafiki, może być dostosowany do poprawnego działania, gdy żaden wyświetlacz nie jest dostępny.

[DODATEK]

Inną możliwością jest to, że gmsh myśli wyświetlacz jest dostępny od DISPLAY jest ustawiona, więc próbuje go otworzyć i się nie powiedzie. Można spróbować rozbroić tę zmienną, i zobaczyć, jak sprawy potoczą, zarówno z linii poleceń (np interaktywny tryb) i za pośrednictwem komputera (np partia tryb)