2017-02-09 5 views
0

Я адаптирую программу fortran mpi от последовательной параллельной записи для определенных типов файлов. Он использует netcdf 4.3.3.1/hdf5 1.8.9 параллельно. Я использую компилятор Intel версии 14.0.3.174.fortran netcdf close parallel deadlock

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

Mpi стек Мастер Процессор вызовов:

__sched_yield,         FP=7ffc6aa978b0 
opal_progress,         FP=7ffc6aa978d0 
ompi_request_default_wait_all,     FP=7ffc6aa97940 
ompi_coll_tuned_sendrecv_actual,    FP=7ffc6aa979e0 
ompi_coll_tuned_barrier_intra_recursivedoubling, FP=7ffc6aa97a40 
PMPI_Barrier,         FP=7ffc6aa97a60 
H5AC_rsp__dist_md_write__flush,    FP=7ffc6aa97af0 
H5AC_flush,         FP=7ffc6aa97b20 
H5F_flush,          FP=7ffc6aa97b50 
H5F_flush_mounts,        FP=7ffc6aa97b80 
H5Fflush,          FP=7ffc6aa97ba0 
NC4_close,          FP=7ffc6aa97be0 
nc_close,          FP=7ffc6aa97c00 
restclo,          FP=7ffc6aa98660 
driver,          FP=7ffc6aaa5ef0 
main,           FP=7ffc6aaa5f90 
__libc_start_main,        FP=7ffc6aaa6050 
_start,  

Остальные процессоры называют стеком:

__sched_yield,         FP=7fffe330cdd0 
opal_progress,         FP=7fffe330cdf0 
ompi_request_default_wait,      FP=7fffe330ce50 
ompi_coll_tuned_bcast_intra_generic,   FP=7fffe330cf30 
ompi_coll_tuned_bcast_intra_binomial,   FP=7fffe330cf90 
ompi_coll_tuned_bcast_intra_dec_fixed,   FP=7fffe330cfb0 
mca_coll_sync_bcast,       FP=7fffe330cff0 
PMPI_Bcast,         FP=7fffe330d030 
mca_io_romio_dist_MPI_File_set_size,   FP=7fffe330d080 
PMPI_File_set_size,       FP=7fffe330d0a0 
H5FD_mpio_truncate,       FP=7fffe330d0c0 
H5FD_truncate,         FP=7fffe330d0f0 
H5F_dest,          FP=7fffe330d110 
H5F_try_close,         FP=7fffe330d340 
H5F_close,          FP=7fffe330d360 
H5I_dec_ref,         FP=7fffe330d370 
H5I_dec_app_ref,        FP=7fffe330d380 
H5Fclose,          FP=7fffe330d3a0 
NC4_close,          FP=7fffe330d3e0 
nc_close,          FP=7fffe330d400 
RESTCOM`restclo,        FP=7fffe330de60 
driver,          FP=7fffe331b6f0 
main,           FP=7fffe331b7f0 
__libc_start_main,        FP=7fffe331b8b0 
_start, 

я понимаю, один стек вызовов содержит BCAST с другого барьера. Это может вызвать тупик. Но я не предвижу, как продолжить дальше. Если вызов mpi не выполняется должным образом (например, только вызываемый в 1 proc), я ожидал бы сообщение об ошибке вместо такого поведения.

Обновление: исходный код составляет около 100 тыс. Строк.

файлы открываются так:

cmode = ior(NF90_NOCLOBBER,NF90_NETCDF4) 
cmode = ior(cmode, NF90_MPIIO) 
CALL ipslnc(NF90_CREATE(fname,cmode=cmode,ncid=ncfid, comm=MPI_COMM, info=MPI_INFO)) 

И закрыли как:

iret = NF90_CLOSE(ncfid) 
+1

Нам нужно будет увидеть код. –

+1

Если код длинный, подготовьте [mcve]. Это происходит для какого-то простого кода, который просто записывает файл и закрывается? –

+0

Я на этом. Но это одна из больших проблем. – rgrun

ответ

0

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