January 2022 - discuss - mailman3.cels.anl.gov

Re: [mpich-discuss] Fortran 08 tests with 'use mpi'
by Zhou, Hui 14 Jan '22

14 Jan '22

Gregor, I see your issue now. Thanks for reporting. We'll fix it. -- Hui Zhou ________________________________ From: Gregor Corbin <g.corbin(a)fz-juelich.de> Sent: Friday, January 14, 2022, 6:27 AM To: Zhou, Hui; discuss(a)mpich.org; Raffenetti, Ken Subject: Re: [mpich-discuss] Fortran 08 tests with 'use mpi' Dear Hui, I suspect that the issue I reported is a different one. To confirm this, I compiled MPICH (from 4.0rc3 tarball) once with GCC and once with Intel and then compiled the attached test programs each with both MPICHs. The Intel-MPICH does not have the gcc-bug from issue 4170, but the indices returned by MPI_Testsome are still wrong. Gregor On 13.01.22 15:39, Zhou, Hui wrote: Hi Gregor, This issue was reported before. You can track the issue here: https://github.com/pmodels/mpich/issues/4170 -- Hui Zhou From: Gregor Corbin via discuss <discuss(a)mpich.org><mailto:[email protected]> Date: Wednesday, January 12, 2022 at 5:19 AM To: Raffenetti, Ken <raffenet(a)anl.gov><mailto:[email protected]>, discuss(a)mpich.org<mailto:[email protected]> <discuss(a)mpich.org><mailto:[email protected]> Cc: Gregor Corbin <g.corbin(a)fz-juelich.de><mailto:[email protected]> Subject: Re: [mpich-discuss] Fortran 08 tests with 'use mpi' Ken, while updating the F08 tests with this bugfix, I may have found another bug inside the 'use mpi_f08' wrappers. The fix removes (superficially) the error in irsendf08, but I still get the same error in pssendf08. This has to do with the array of indices returned by MPI_Testsome: With the 'use mpi_f08' wrappers, the indices in this array are 0-indexed although they should start from 1 according to the Standard (they do start from 1 with the 'use mpi' and 'mpif.h' functions). I have attached a minimal working example to confirm this. Indeed, the function mpi_testsome_ (in src/binding/fortran/mpif_h/fortran_binding.c) converts the indices: for (int i = 0; i < (*outcount); i++) { array_of_indices[i] += 1; } The subroutine MPI_Testsome_f08 (in src/binding/fortran/use_mpi_f08/wrappers_f/f08ts.f90) does no such conversion. The bug is also in MPI_Testany (and potentially other functions I did not test yet). However, without detailed knowledge about internals of MPICH I might not be the best person to fix the issue. Greetings, Gregor On 11.01.22 22:52, Raffenetti, Ken wrote: Gregor, I believe these are test bugs. A fix for the f77 versions was added previously in https://github.com/pmodels/mpich/pull/3962/commits/69b02eaabcdb0008f3879372…, though it does not cover the prsendf test. Perhaps you could add a commit to your branch to fix these tests in a similar way. Ken On 1/11/22, 2:30 AM, "Gregor Corbin" <g.corbin(a)fz-juelich.de><mailto:[email protected]> wrote: Updating the F08 tests to 'use mpi_f08' was mostly straightforward. However, i ran into problems with three of the tests: irsendf08.f90, pssendf08.f90 and prsendf08.f90. With my modified irsendf08 (attached) for example, the test produces these error messages: Nonnull request in irsend and irecv [ 0 ] Unexpected source: 0 in irsend and irecv [ 0 ] Unexpected tag: 0 in irsend and irecv [ 0 ] Unexpected count: 0 in irsend and irecv Invalid data 0.0 at 1 of 666 in irsend and irecv Invalid data 0.0 at 2 of 666 in irsend and irecv ... Invalid data 0.0 at 666 of 666 in irsend and irecv Found 669 errors That is, the last message from process 1 to 0 is not received correctly. When I replace the call to MPI_Waitany with Waitall or Wait there are not errors. Is there maybe a problem with Waitany or did I just do something wrong? Gregor On 07.01.22 17:59, Raffenetti, Ken wrote: We would consider a patch, yes. First, you would need to sign and return the contributors agreement. https://www.mpich.org/documentation/contributor-docs/ As for whether or not automatic conversion is practical, I think if we structured the tests such that the types needing conversion were easily identifiable, then it could be done. It would require some churn of the existing tests. It may also complicate the addition of new, as the author would need to adhere to guidelines that may not be obvious without prior knowledge. I gave myself a task to support automatic conversion of the tests the `use mpi_f08`, but it is not very high priority at the moment. Ken On 1/7/22, 3:10 AM, "Gregor Corbin via discuss" <discuss(a)mpich.org><mailto:[email protected]> <mailto:[email protected]><mailto:[email protected]> wrote: Hi MPICH, I noticed that some of the tests in test/mpi/f08 still work with 'use mpi' instead of 'use mpi_f08', mostly in the pt2pt folder. These seem to be copies of the tests in f90 which in turn have been generated by f77tof90. Shouldn't these tests be converted to 'use mpi_f08'? If so, would you be interested in a PR that fixes this? I would need to do this anyway. Kind regards, Gregor Corbin PS.: The interfaces for 'use mpi' and 'use mpi_f08' are probably too different for an automatic conversion to be practical (how to change all the integers to type(mpi_xxx) for example?).

1 0

Re: [mpich-discuss] Fortran 08 tests with 'use mpi'
by Gregor Corbin 14 Jan '22

14 Jan '22

Dear Hui, I suspect that the issue I reported is a different one. To confirm this, I compiled MPICH (from 4.0rc3 tarball) once with GCC and once with Intel and then compiled the attached test programs each with both MPICHs. The Intel-MPICH does not have the gcc-bug from issue 4170, but the indices returned by MPI_Testsome are still wrong. Gregor On 13.01.22 15:39, Zhou, Hui wrote: > > Hi Gregor, > > This issue was reported before. You can track the issue here: > https://github.com/pmodels/mpich/issues/4170 > <https://github.com/pmodels/mpich/issues/4170> > > -- > Hui Zhou > > *From: *Gregor Corbin via discuss <discuss(a)mpich.org> > *Date: *Wednesday, January 12, 2022 at 5:19 AM > *To: *Raffenetti, Ken <raffenet(a)anl.gov>, discuss(a)mpich.org > <discuss(a)mpich.org> > *Cc: *Gregor Corbin <g.corbin(a)fz-juelich.de> > *Subject: *Re: [mpich-discuss] Fortran 08 tests with 'use mpi' > > Ken, > > while updating the F08 tests with this bugfix, I may have found > another bug inside the 'use mpi_f08' wrappers. > > The fix removes (superficially) the error in irsendf08, but I still > get the same error in pssendf08. This has to do with the array of > indices returned by MPI_Testsome: With the 'use mpi_f08' wrappers, the > indices in this array are 0-indexed although they should start from 1 > according to the Standard (they do start from 1 with the 'use mpi' and > 'mpif.h' functions). I have attached a minimal working example to > confirm this. > > Indeed, the function mpi_testsome_ (in > src/binding/fortran/mpif_h/fortran_binding.c) converts the indices: > > for (int i = 0; i < (*outcount); i++) { > array_of_indices[i] += 1; > } > > The subroutine MPI_Testsome_f08 (in > src/binding/fortran/use_mpi_f08/wrappers_f/f08ts.f90) does no such > conversion. > > The bug is also in MPI_Testany (and potentially other functions I did > not test yet). > > However, without detailed knowledge about internals of MPICH I might > not be the best person to fix the issue. > > Greetings, > > Gregor > > On 11.01.22 22:52, Raffenetti, Ken wrote: > > Gregor, > > I believe these are test bugs. A fix for the f77 versions was added previously inhttps://github.com/pmodels/mpich/pull/3962/commits/69b02eaabcdb0008f38793… <https://github.com/pmodels/mpich/pull/3962/commits/69b02eaabcdb0008f3879372…>, though it does not cover the prsendf test. Perhaps you could add a commit to your branch to fix these tests in a similar way. > > Ken > > On 1/11/22, 2:30 AM, "Gregor Corbin"<g.corbin(a)fz-juelich.de> <mailto:[email protected]> wrote: > > Updating the F08 tests to 'use mpi_f08' was mostly > > straightforward. However, i ran into problems with three of the > > tests: irsendf08.f90, pssendf08.f90 and prsendf08.f90. > > With my modified irsendf08 (attached) for example, the test > > produces these error messages: > > Nonnull request in irsend and irecv > > [ 0 ] Unexpected source: 0 in irsend and > > irecv > > [ 0 ] Unexpected tag: 0 in irsend and > > irecv > > [ 0 ] Unexpected count: 0 in irsend and > > irecv > > Invalid data 0.0 at 1 of 666 in irsend and irecv > > Invalid data 0.0 at 2 of 666 in irsend and irecv > > ... > > Invalid data 0.0 at 666 of 666 in irsend and irecv > > Found 669 errors > > That is, the last message from process 1 to 0 is not received > > correctly. When I replace the call to MPI_Waitany with Waitall or > > Wait there are not errors. > > Is there maybe a problem with Waitany or did I just do something > > wrong? > > Gregor > > On 07.01.22 17:59, Raffenetti, Ken > > wrote: > > We would consider a patch, yes. First, you would need to sign and return the contributors agreement.https://www.mpich.org/documentation/contributor-docs/ <https://www.mpich.org/documentation/contributor-docs/> > > As for whether or not automatic conversion is practical, I think if we structured the tests such that the types needing conversion were easily identifiable, then it could be done. It would require some churn of the existing tests. It may also complicate the addition of new, as the author would need to adhere to guidelines that may not be obvious without prior knowledge. > > I gave myself a task to support automatic conversion of the tests the `use mpi_f08`, but it is not very high priority at the moment. > > Ken > > On 1/7/22, 3:10 AM, "Gregor Corbin via discuss"<discuss(a)mpich.org> <mailto:[email protected]> <mailto:[email protected]> <mailto:[email protected]> wrote: > > Hi MPICH, > > I noticed that some of the tests in test/mpi/f08 still work with 'use > > mpi' instead of 'use mpi_f08', mostly in the pt2pt folder. These seem > > to be copies of the tests in f90 which in turn have been generated by > > f77tof90. > > Shouldn't these tests be converted to 'use mpi_f08'? If so, would you be > > interested in a PR that fixes this? I would need to do this anyway. > > Kind regards, > > Gregor Corbin > > PS.: The interfaces for 'use mpi' and 'use mpi_f08' are probably too > > different for an automatic conversion to be practical (how to change all > > the integers to type(mpi_xxx) for example?). >

1 0

Segmentation violation when launching 182 local processes
by Edric Ellis 14 Jan '22

14 Jan '22

Hi, There appears to be a problem in MPICH v3.4.3 when launching a job that uses 182 or more processes on a single machine. The problem does not occur in MPICH v3.3.2, I didn't check any other releases. I'm configuring MPICH like this on a 64-bit Linux system: $ ./configure --enable-fortran --enable-shared --disable-cairo --disable-cpuid --disable-libxml2 --disable-pci --disable-opencl --disable-cuda --disable-nvml --disable-gl --disable-libnuma --disable-libudev --prefix= /local/mpich-install-3.4.3 --enable-shared --disable-static --enable-g=dbg --with-device=ch3:nemesis Platform: uname -m = x86_64 uname -r = 4.19.0-18-amd64 uname -s = Linux uname -v = #1 SMP Debian 4.19.208-1 (2021-09-29) Compiler: gcc (Debian 8.3.0-6) 8.3.0 Launching any MPI program using "mpiexec -hosts localhost -n 182" fails with a segmentation fault, "-n 181" works. I got valgrind to emit this (the line numbers might be a little awry because I was fiddling with mpid_nem_init.c to try and figure things out): ==3395== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==3395== Access not within mapped region at address 0xFFFFFFFF85DB6E40 ==3395== at 0x4C7E838: MPL_atomic_relaxed_store_int (mpl_atomic_c11.h:99) ==3395== by 0x4C7E838: MPID_nem_init (mpid_nem_init.c:375) ==3395== by 0x4C65075: MPIDI_CH3_Init (ch3_init.c:94) ==3395== by 0x4C41BD0: MPID_Init (mpid_init.c:162) ==3395== by 0x4A7E9CF: MPIR_Init_thread (initthread.c:158) ==3395== by 0x4A7E62B: PMPI_Init (init.c:131) ==3395== by 0x1091F7: main (check.c:15) The problem appears to be in the MPID_nem_init function which has num_local stored as "int" - when this is 182, some of the computations involving it overflow. For example, the first argument in the line below overflows: size_t fbox_len = MPL_MAX((num_local*((num_local-1) * MPID_NEM_FBOX_LEN)), MPID_NEM_ASYMM_NULL_VAL); I was able to stop the initial crash by fixing that call and the loop involving MAILBOX_INDEX, but I've no idea if there are other similar problems lurking... I discovered this because we have a regression test for this problem: https://lists.mcs.anl.gov/pipermail/mpich-discuss/2012-January/011619.html - that problem was encountered by one of our users on a high-core-count system. Cheers, Edric.

1 0

Re: [mpich-discuss] netcdf-fortran 4.5.4 test hang on s390x
by Zhou, Hui 13 Jan '22

13 Jan '22

The backtrace simply shows the process is in the progress loop, i.e. waiting for a message from another process but never come. The reason could due to a bug in mpich, or a bug in the application library, or in the test. -- Hui ________________________________ From: Orion Poplawski via discuss <discuss(a)mpich.org> Sent: Thursday, January 13, 2022 9:32 PM To: discuss(a)mpich.org <discuss(a)mpich.org> Cc: Orion Poplawski <orion(a)nwra.com> Subject: [mpich-discuss] netcdf-fortran 4.5.4 test hang on s390x Hello - I'm working on updating the Fedora netcdf-fortran package to version 4.5.4. However, a test is hanging when run on s390x (other arches are fine). This is with: mpich-3.4.1-3.fc35.s390x hdf5-mpich-1.12.1-1.fc36.s390x netcdf-mpich-4.8.1-2.fc36.s390x The test program is nf03_test4/f90tst_parallel_compressed and is run with: mpiexec -np 4 ./f90tst_parallel_compressed Here's a backtrace where it seems to be stuck: #0 0x000003ffb14fbc94 in MPID_nem_tcp_connpoll (in_blocking_poll=<optimized out>) at src/mpid/ch3/channels/nemesis/netmod/tcp/socksm.c:1822 #1 0x000003ffb14ef78c in MPID_nem_network_poll (in_blocking_progress=1) at src/mpid/ch3/channels/nemesis/src/mpid_nem_network_poll.c:11 #2 MPID_nem_mpich_blocking_recv (completions=615, in_fbox=<synthetic pointer>, cell=<synthetic pointer>) at ./src/mpid/ch3/channels/nemesis/include/mpid_nem_inline.h:964 #3 MPIDI_CH3I_Progress (progress_state=0x3ffdf66c168, is_blocking=<optimized out>) at src/mpid/ch3/channels/nemesis/src/ch3_progress.c:363 #4 0x000003ffb1b2ecc0 in MPIR_Wait_state (status=<optimized out>, state=0x3ffdf66c24c, request_ptr=0x3ffb1d17510 <MPIR_Request_direct>) at src/mpi/request/wait.c:32 #5 MPIR_Wait_impl.isra.0 (request_ptr=request_ptr@entry=0x3ffb1d17510 <MPIR_Request_direct>, status=<optimized out>) at src/mpi/request/wait.c:55 #6 0x000003ffb1484ca0 in MPID_Wait (status=0x1, request_ptr=0x3ffb1d17510 <MPIR_Request_direct>) at ./src/mpid/ch3/include/mpidpost.h:264 #7 MPIC_Wait (request_ptr=0x3ffb1d17510 <MPIR_Request_direct>, errflag=errflag@entry=0x3ffdf66c8ec) at src/mpi/coll/helper_fns.c:64 #8 0x000003ffb1485a04 in MPIC_Sendrecv (sendbuf=<optimized out>, sendcount=1, sendtype=<optimized out>, dest=<optimized out>, sendtag=<optimized out>, recvbuf=0x2aa1bf8f8b0, recvcount=1, recvtype=1275069445, source=1, recvtag=14, comm_ptr=0x3ffae42f690, status=<optimized out>, errflag=0x3ffdf66c8ec) at src/mpi/coll/helper_fns.c:333 #9 0x000003ffb141fe4e in MPIR_Allreduce_intra_recursive_doubling (sendbuf=<optimized out>, recvbuf=0x3ffdf66c9e0, count=<optimized out>, datatype=<optimized out>, op=<optimized out>, comm_ptr=0x3ffae42f690, errflag=0x3ffdf66c8ec) at src/mpi/coll/allreduce/allreduce_intra_recursive_doubling.c:127 #10 0x000003ffb1322a68 in MPIR_Allreduce_allcomm_auto (sendbuf=0x3ffdf66c9d0, sendbuf@entry=<error reading variable: value has been optimized out>, recvbuf=0x3ffdf66c9e0, recvbuf@entry=<error reading variable: value has been optimized out>, count=count@entry=1, datatype=datatype@entry=1275069445, op=op@entry=1476395011, comm_ptr=0x3ffae42f690, errflag=0x3ffdf66c8ec) at src/mpi/coll/allreduce/allreduce.c:145 #11 0x000003ffb1322c28 in MPIR_Allreduce_impl (sendbuf=<error reading variable: value has been optimized out>, recvbuf=<error reading variable: value has been optimized out>, count=<optimized out>, datatype=<optimized out>, op=op@entry=1476395011, comm_ptr=0x3ffae42f690, errflag=0x3ffdf66c8ec) at src/mpi/coll/allreduce/allreduce.c:210 #12 0x000003ffb1322d6a in MPID_Allreduce (errflag=0x3ffdf66c8ec, comm=0x3ffae42f690, op=op@entry=1476395011, datatype=<optimized out>, datatype@entry=1275069445, count=<optimized out>, count@entry=1, recvbuf=<error reading variable: value has been optimized out>, sendbuf=<error reading variable: value has been optimized out>) at ./src/mpid/ch3/include/mpid_coll.h:41 #13 MPIR_Allreduce (sendbuf=<error reading variable: value has been optimized out>, recvbuf=<error reading variable: value has been optimized out>, count=count@entry=1, datatype=datatype@entry=1275069445, op=op@entry=1476395011, comm_ptr=0x3ffae42f690, errflag=0x3ffdf66c8ec) at src/mpi/coll/allreduce/allreduce.c:262 #14 0x000003ffb1323742 in PMPI_Allreduce (sendbuf=<optimized out>, sendbuf@entry=<error reading variable: value has been optimized out>, recvbuf=<optimized out>, recvbuf@entry=0x3ffdf66c9e0, count=count@entry=1, datatype=datatype@entry=1275069445, op=op@entry=1476395011, comm=-1006632958) at src/mpi/coll/allreduce/allreduce.c:387 #15 0x000003ffb0e11644 in H5D__mpio_array_gatherv.constprop.0 (local_array=<optimized out>, local_array@entry=0x2aa1bfac440, local_array_num_entries=<optimized out>, _gathered_array=<optimized out>, _gathered_array@entry=0x3ffdf66cb78, _gathered_array_num_entries=_gathered_array_num_entries@entry=0x3ffdf66cb88, allgather=allgather@entry=true, comm=-1006632958, sort_func=0x0, root=0, array_entry_size=368) at ../../src/H5Dmpio.c:552 #16 0x000003ffb0e086cc in H5D__link_chunk_filtered_collective_io (fm=0x2aa1bef9c60, type_info=0x3ffdf66ce00, io_info=0x3ffdf66ce80) at ../../src/H5Dmpio.c:1409 #17 H5D__chunk_collective_io (io_info=0x3ffdf66ce80, type_info=0x3ffdf66ce00, fm=fm@entry=0x2aa1bef9c60) at ../../src/H5Dmpio.c:886 #18 0x000003ffb0e0abb4 in H5D__chunk_collective_write (io_info=<optimized out>, type_info=<optimized out>, nelmts=<optimized out>, file_space=<optimized out>, mem_space=0x2aa1bf8fac0, fm=0x2aa1bef9c60) at ../../src/H5Dmpio.c:967 #19 0x000003ffb0b78702 in H5D__write (dataset=0x2aa1bf0cda0, mem_type_id=<optimized out>, mem_space=<optimized out>, file_space=0x2aa1beee270, buf=<optimized out>) at ../../src/H5Dio.c:761 #20 0x000003ffb0dd9598 in H5VL__native_dataset_write (obj=0x2aa1bf0cda0, mem_type_id=216172782113784251, mem_space_id=<optimized out>, file_space_id=288230376151711833, dxpl_id=<optimized out>, buf=0x3ffa41b9010, req=0x0) at ../../src/H5VLnative_dataset.c:206 #21 0x000003ffb0db7b72 in H5VL__dataset_write (obj=<optimized out>, cls=<optimized out>, mem_type_id=mem_type_id@entry=216172782113784251, mem_space_id=mem_space_id@entry=288230376151711834, file_space_id=file_space_id@entry=288230376151711833, dxpl_id=792633534417207358, buf=0x3ffa41b9010, req=0x0) at ../../src/H5VLcallback.c:2079 #22 0x000003ffb0dc1b9a in H5VL_dataset_write (vol_obj=0x2aa1bf0cd00, mem_type_id=216172782113784251, mem_space_id=288230376151711834, file_space_id=288230376151711833, dxpl_id=<optimized out>, buf=0x3ffa41b9010, req=0x0) at ../../src/H5VLcallback.c:2111 #23 0x000003ffb0b7506c in H5Dwrite (dset_id=<optimized out>, mem_type_id=216172782113784251, mem_space_id=288230376151711834, file_space_id=288230376151711833, dxpl_id=792633534417207358, buf=0x3ffa41b9010) at ../../src/H5Dio.c:289 #24 0x000003ffb1f8fdc8 in NC4_put_vars (ncid=<optimized out>, varid=0, startp=0x0, countp=0x2aa1bf0e720, stridep=0x3ffdf66f388, data=<optimized out>, mem_nc_type=5) at ../libhdf5/../../libhdf5/hdf5var.c:1594 #25 0x000003ffb1f90148 in NC4_put_vara (ncid=<optimized out>, varid=<optimized out>, startp=<optimized out>, countp=<optimized out>, op=<optimized out>, memtype=5) at ../libhdf5/../../libhdf5/hdf5var.c:1178 #26 0x000003ffb1f3b96c in NC_put_vara (ncid=<optimized out>, varid=<optimized out>, start=0x2aa1bf8f620, edges=0x2aa1bf8f910, value=value@entry=0x3ffa41b9010, memtype=5) at ../libdispatch/../../libdispatch/dvarput.c:97 #27 0x000003ffb1f3be08 in nc_put_vara_float (ncid=<optimized out>, varid=<optimized out>, startp=<optimized out>, countp=<optimized out>, op=0x3ffa41b9010) at ../libdispatch/../../libdispatch/dvarput.c:695 #28 0x000003ffb269464e in nf_put_vara_real_ (ncid=<optimized out>, varid=<optimized out>, start=<error reading variable: value has been optimized out>, counts=<error reading variable: value has been optimized out>, rvals=...) at ../../fortran/nf_varaio.F90:372 #29 0x000003ffb26ede9e in netcdf::nf90_put_var_4d_fourbytereal (ncid=<error reading variable: value has been optimized out>, varid=<error reading variable: value has been optimized out>, values=<error reading variable: value has been optimized out>, start=<error reading variable: value has been optimized out>, count=<error reading variable: value requires 27021597768417284 bytes, which is more than max-value-size>, stride=<error reading variable: value has been optimized out>, map=<error reading variable: value has been optimized out>) at netcdf_expanded.f90:1035 #30 0x000002aa1b1840ba in f90tst_parallel_compressed () at ../../nf03_test4/f90tst_parallel_compressed.F90:255 #31 0x000002aa1b182588 in main (argc=<optimized out>, argv=<optimized out>) at ../../nf03_test4/f90tst_parallel_compressed.F90:14 It seems to be stuck in MPID_nem_mpich_blocking_recv. I have no idea how to debug this further. Any suggestions would be greatly appreciated. It does appear to have been introduced between netcdf-fortran 4.5.2 and 4.5.4. I can still build and run the tests for 4.5.2. -- Orion Poplawski he/him/his - surely the least important thing about me Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion(a)nwra.com Boulder, CO 80301 https://www.nwra.com/

1 0

netcdf-fortran 4.5.4 test hang on s390x
by Orion Poplawski 13 Jan '22

13 Jan '22

Hello - I'm working on updating the Fedora netcdf-fortran package to version 4.5.4. However, a test is hanging when run on s390x (other arches are fine). This is with: mpich-3.4.1-3.fc35.s390x hdf5-mpich-1.12.1-1.fc36.s390x netcdf-mpich-4.8.1-2.fc36.s390x The test program is nf03_test4/f90tst_parallel_compressed and is run with: mpiexec -np 4 ./f90tst_parallel_compressed Here's a backtrace where it seems to be stuck: #0 0x000003ffb14fbc94 in MPID_nem_tcp_connpoll (in_blocking_poll=<optimized out>) at src/mpid/ch3/channels/nemesis/netmod/tcp/socksm.c:1822 #1 0x000003ffb14ef78c in MPID_nem_network_poll (in_blocking_progress=1) at src/mpid/ch3/channels/nemesis/src/mpid_nem_network_poll.c:11 #2 MPID_nem_mpich_blocking_recv (completions=615, in_fbox=<synthetic pointer>, cell=<synthetic pointer>) at ./src/mpid/ch3/channels/nemesis/include/mpid_nem_inline.h:964 #3 MPIDI_CH3I_Progress (progress_state=0x3ffdf66c168, is_blocking=<optimized out>) at src/mpid/ch3/channels/nemesis/src/ch3_progress.c:363 #4 0x000003ffb1b2ecc0 in MPIR_Wait_state (status=<optimized out>, state=0x3ffdf66c24c, request_ptr=0x3ffb1d17510 <MPIR_Request_direct>) at src/mpi/request/wait.c:32 #5 MPIR_Wait_impl.isra.0 (request_ptr=request_ptr@entry=0x3ffb1d17510 <MPIR_Request_direct>, status=<optimized out>) at src/mpi/request/wait.c:55 #6 0x000003ffb1484ca0 in MPID_Wait (status=0x1, request_ptr=0x3ffb1d17510 <MPIR_Request_direct>) at ./src/mpid/ch3/include/mpidpost.h:264 #7 MPIC_Wait (request_ptr=0x3ffb1d17510 <MPIR_Request_direct>, errflag=errflag@entry=0x3ffdf66c8ec) at src/mpi/coll/helper_fns.c:64 #8 0x000003ffb1485a04 in MPIC_Sendrecv (sendbuf=<optimized out>, sendcount=1, sendtype=<optimized out>, dest=<optimized out>, sendtag=<optimized out>, recvbuf=0x2aa1bf8f8b0, recvcount=1, recvtype=1275069445, source=1, recvtag=14, comm_ptr=0x3ffae42f690, status=<optimized out>, errflag=0x3ffdf66c8ec) at src/mpi/coll/helper_fns.c:333 #9 0x000003ffb141fe4e in MPIR_Allreduce_intra_recursive_doubling (sendbuf=<optimized out>, recvbuf=0x3ffdf66c9e0, count=<optimized out>, datatype=<optimized out>, op=<optimized out>, comm_ptr=0x3ffae42f690, errflag=0x3ffdf66c8ec) at src/mpi/coll/allreduce/allreduce_intra_recursive_doubling.c:127 #10 0x000003ffb1322a68 in MPIR_Allreduce_allcomm_auto (sendbuf=0x3ffdf66c9d0, sendbuf@entry=<error reading variable: value has been optimized out>, recvbuf=0x3ffdf66c9e0, recvbuf@entry=<error reading variable: value has been optimized out>, count=count@entry=1, datatype=datatype@entry=1275069445, op=op@entry=1476395011, comm_ptr=0x3ffae42f690, errflag=0x3ffdf66c8ec) at src/mpi/coll/allreduce/allreduce.c:145 #11 0x000003ffb1322c28 in MPIR_Allreduce_impl (sendbuf=<error reading variable: value has been optimized out>, recvbuf=<error reading variable: value has been optimized out>, count=<optimized out>, datatype=<optimized out>, op=op@entry=1476395011, comm_ptr=0x3ffae42f690, errflag=0x3ffdf66c8ec) at src/mpi/coll/allreduce/allreduce.c:210 #12 0x000003ffb1322d6a in MPID_Allreduce (errflag=0x3ffdf66c8ec, comm=0x3ffae42f690, op=op@entry=1476395011, datatype=<optimized out>, datatype@entry=1275069445, count=<optimized out>, count@entry=1, recvbuf=<error reading variable: value has been optimized out>, sendbuf=<error reading variable: value has been optimized out>) at ./src/mpid/ch3/include/mpid_coll.h:41 #13 MPIR_Allreduce (sendbuf=<error reading variable: value has been optimized out>, recvbuf=<error reading variable: value has been optimized out>, count=count@entry=1, datatype=datatype@entry=1275069445, op=op@entry=1476395011, comm_ptr=0x3ffae42f690, errflag=0x3ffdf66c8ec) at src/mpi/coll/allreduce/allreduce.c:262 #14 0x000003ffb1323742 in PMPI_Allreduce (sendbuf=<optimized out>, sendbuf@entry=<error reading variable: value has been optimized out>, recvbuf=<optimized out>, recvbuf@entry=0x3ffdf66c9e0, count=count@entry=1, datatype=datatype@entry=1275069445, op=op@entry=1476395011, comm=-1006632958) at src/mpi/coll/allreduce/allreduce.c:387 #15 0x000003ffb0e11644 in H5D__mpio_array_gatherv.constprop.0 (local_array=<optimized out>, local_array@entry=0x2aa1bfac440, local_array_num_entries=<optimized out>, _gathered_array=<optimized out>, _gathered_array@entry=0x3ffdf66cb78, _gathered_array_num_entries=_gathered_array_num_entries@entry=0x3ffdf66cb88, allgather=allgather@entry=true, comm=-1006632958, sort_func=0x0, root=0, array_entry_size=368) at ../../src/H5Dmpio.c:552 #16 0x000003ffb0e086cc in H5D__link_chunk_filtered_collective_io (fm=0x2aa1bef9c60, type_info=0x3ffdf66ce00, io_info=0x3ffdf66ce80) at ../../src/H5Dmpio.c:1409 #17 H5D__chunk_collective_io (io_info=0x3ffdf66ce80, type_info=0x3ffdf66ce00, fm=fm@entry=0x2aa1bef9c60) at ../../src/H5Dmpio.c:886 #18 0x000003ffb0e0abb4 in H5D__chunk_collective_write (io_info=<optimized out>, type_info=<optimized out>, nelmts=<optimized out>, file_space=<optimized out>, mem_space=0x2aa1bf8fac0, fm=0x2aa1bef9c60) at ../../src/H5Dmpio.c:967 #19 0x000003ffb0b78702 in H5D__write (dataset=0x2aa1bf0cda0, mem_type_id=<optimized out>, mem_space=<optimized out>, file_space=0x2aa1beee270, buf=<optimized out>) at ../../src/H5Dio.c:761 #20 0x000003ffb0dd9598 in H5VL__native_dataset_write (obj=0x2aa1bf0cda0, mem_type_id=216172782113784251, mem_space_id=<optimized out>, file_space_id=288230376151711833, dxpl_id=<optimized out>, buf=0x3ffa41b9010, req=0x0) at ../../src/H5VLnative_dataset.c:206 #21 0x000003ffb0db7b72 in H5VL__dataset_write (obj=<optimized out>, cls=<optimized out>, mem_type_id=mem_type_id@entry=216172782113784251, mem_space_id=mem_space_id@entry=288230376151711834, file_space_id=file_space_id@entry=288230376151711833, dxpl_id=792633534417207358, buf=0x3ffa41b9010, req=0x0) at ../../src/H5VLcallback.c:2079 #22 0x000003ffb0dc1b9a in H5VL_dataset_write (vol_obj=0x2aa1bf0cd00, mem_type_id=216172782113784251, mem_space_id=288230376151711834, file_space_id=288230376151711833, dxpl_id=<optimized out>, buf=0x3ffa41b9010, req=0x0) at ../../src/H5VLcallback.c:2111 #23 0x000003ffb0b7506c in H5Dwrite (dset_id=<optimized out>, mem_type_id=216172782113784251, mem_space_id=288230376151711834, file_space_id=288230376151711833, dxpl_id=792633534417207358, buf=0x3ffa41b9010) at ../../src/H5Dio.c:289 #24 0x000003ffb1f8fdc8 in NC4_put_vars (ncid=<optimized out>, varid=0, startp=0x0, countp=0x2aa1bf0e720, stridep=0x3ffdf66f388, data=<optimized out>, mem_nc_type=5) at ../libhdf5/../../libhdf5/hdf5var.c:1594 #25 0x000003ffb1f90148 in NC4_put_vara (ncid=<optimized out>, varid=<optimized out>, startp=<optimized out>, countp=<optimized out>, op=<optimized out>, memtype=5) at ../libhdf5/../../libhdf5/hdf5var.c:1178 #26 0x000003ffb1f3b96c in NC_put_vara (ncid=<optimized out>, varid=<optimized out>, start=0x2aa1bf8f620, edges=0x2aa1bf8f910, value=value@entry=0x3ffa41b9010, memtype=5) at ../libdispatch/../../libdispatch/dvarput.c:97 #27 0x000003ffb1f3be08 in nc_put_vara_float (ncid=<optimized out>, varid=<optimized out>, startp=<optimized out>, countp=<optimized out>, op=0x3ffa41b9010) at ../libdispatch/../../libdispatch/dvarput.c:695 #28 0x000003ffb269464e in nf_put_vara_real_ (ncid=<optimized out>, varid=<optimized out>, start=<error reading variable: value has been optimized out>, counts=<error reading variable: value has been optimized out>, rvals=...) at ../../fortran/nf_varaio.F90:372 #29 0x000003ffb26ede9e in netcdf::nf90_put_var_4d_fourbytereal (ncid=<error reading variable: value has been optimized out>, varid=<error reading variable: value has been optimized out>, values=<error reading variable: value has been optimized out>, start=<error reading variable: value has been optimized out>, count=<error reading variable: value requires 27021597768417284 bytes, which is more than max-value-size>, stride=<error reading variable: value has been optimized out>, map=<error reading variable: value has been optimized out>) at netcdf_expanded.f90:1035 #30 0x000002aa1b1840ba in f90tst_parallel_compressed () at ../../nf03_test4/f90tst_parallel_compressed.F90:255 #31 0x000002aa1b182588 in main (argc=<optimized out>, argv=<optimized out>) at ../../nf03_test4/f90tst_parallel_compressed.F90:14 It seems to be stuck in MPID_nem_mpich_blocking_recv. I have no idea how to debug this further. Any suggestions would be greatly appreciated. It does appear to have been introduced between netcdf-fortran 4.5.2 and 4.5.4. I can still build and run the tests for 4.5.2. -- Orion Poplawski he/him/his - surely the least important thing about me Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion(a)nwra.com Boulder, CO 80301 https://www.nwra.com/

1 0

Re: [mpich-discuss] Fortran 08 tests with 'use mpi'
by Zhou, Hui 13 Jan '22

13 Jan '22

Hi Gregor, This issue was reported before. You can track the issue here: https://github.com/pmodels/mpich/issues/4170 -- Hui Zhou From: Gregor Corbin via discuss <discuss(a)mpich.org> Date: Wednesday, January 12, 2022 at 5:19 AM To: Raffenetti, Ken <raffenet(a)anl.gov>, discuss(a)mpich.org <discuss(a)mpich.org> Cc: Gregor Corbin <g.corbin(a)fz-juelich.de> Subject: Re: [mpich-discuss] Fortran 08 tests with 'use mpi' Ken, while updating the F08 tests with this bugfix, I may have found another bug inside the 'use mpi_f08' wrappers. The fix removes (superficially) the error in irsendf08, but I still get the same error in pssendf08. This has to do with the array of indices returned by MPI_Testsome: With the 'use mpi_f08' wrappers, the indices in this array are 0-indexed although they should start from 1 according to the Standard (they do start from 1 with the 'use mpi' and 'mpif.h' functions). I have attached a minimal working example to confirm this. Indeed, the function mpi_testsome_ (in src/binding/fortran/mpif_h/fortran_binding.c) converts the indices: for (int i = 0; i < (*outcount); i++) { array_of_indices[i] += 1; } The subroutine MPI_Testsome_f08 (in src/binding/fortran/use_mpi_f08/wrappers_f/f08ts.f90) does no such conversion. The bug is also in MPI_Testany (and potentially other functions I did not test yet). However, without detailed knowledge about internals of MPICH I might not be the best person to fix the issue. Greetings, Gregor On 11.01.22 22:52, Raffenetti, Ken wrote: Gregor, I believe these are test bugs. A fix for the f77 versions was added previously in https://github.com/pmodels/mpich/pull/3962/commits/69b02eaabcdb0008f3879372…, though it does not cover the prsendf test. Perhaps you could add a commit to your branch to fix these tests in a similar way. Ken On 1/11/22, 2:30 AM, "Gregor Corbin" <g.corbin(a)fz-juelich.de><mailto:[email protected]> wrote: Updating the F08 tests to 'use mpi_f08' was mostly straightforward. However, i ran into problems with three of the tests: irsendf08.f90, pssendf08.f90 and prsendf08.f90. With my modified irsendf08 (attached) for example, the test produces these error messages: Nonnull request in irsend and irecv [ 0 ] Unexpected source: 0 in irsend and irecv [ 0 ] Unexpected tag: 0 in irsend and irecv [ 0 ] Unexpected count: 0 in irsend and irecv Invalid data 0.0 at 1 of 666 in irsend and irecv Invalid data 0.0 at 2 of 666 in irsend and irecv ... Invalid data 0.0 at 666 of 666 in irsend and irecv Found 669 errors That is, the last message from process 1 to 0 is not received correctly. When I replace the call to MPI_Waitany with Waitall or Wait there are not errors. Is there maybe a problem with Waitany or did I just do something wrong? Gregor On 07.01.22 17:59, Raffenetti, Ken wrote: We would consider a patch, yes. First, you would need to sign and return the contributors agreement. https://www.mpich.org/documentation/contributor-docs/ As for whether or not automatic conversion is practical, I think if we structured the tests such that the types needing conversion were easily identifiable, then it could be done. It would require some churn of the existing tests. It may also complicate the addition of new, as the author would need to adhere to guidelines that may not be obvious without prior knowledge. I gave myself a task to support automatic conversion of the tests the `use mpi_f08`, but it is not very high priority at the moment. Ken On 1/7/22, 3:10 AM, "Gregor Corbin via discuss" <discuss(a)mpich.org><mailto:[email protected]> <mailto:[email protected]><mailto:[email protected]> wrote: Hi MPICH, I noticed that some of the tests in test/mpi/f08 still work with 'use mpi' instead of 'use mpi_f08', mostly in the pt2pt folder. These seem to be copies of the tests in f90 which in turn have been generated by f77tof90. Shouldn't these tests be converted to 'use mpi_f08'? If so, would you be interested in a PR that fixes this? I would need to do this anyway. Kind regards, Gregor Corbin PS.: The interfaces for 'use mpi' and 'use mpi_f08' are probably too different for an automatic conversion to be practical (how to change all the integers to type(mpi_xxx) for example?).

1 0

Re: [mpich-discuss] Fortran 08 tests with 'use mpi'
by Raffenetti, Ken 13 Jan '22

13 Jan '22

Gregor, Thanks for the update. I suspect you have come across a bug in the binding layer. I'll take a closer look and let you know what I find. Ken On 1/12/22, 5:19 AM, "Gregor Corbin" <g.corbin(a)fz-juelich.de> wrote: Ken, while updating the F08 tests with this bugfix, I may have found another bug inside the 'use mpi_f08' wrappers. The fix removes (superficially) the error in irsendf08, but I still get the same error in pssendf08. This has to do with the array of indices returned by MPI_Testsome: With the 'use mpi_f08' wrappers, the indices in this array are 0-indexed although they should start from 1 according to the Standard (they do start from 1 with the 'use mpi' and 'mpif.h' functions). I have attached a minimal working example to confirm this. Indeed, the function mpi_testsome_ (in src/binding/fortran/mpif_h/fortran_binding.c) converts the indices: for (int i = 0; i < (*outcount); i++) { array_of_indices[i] += 1; } The subroutine MPI_Testsome_f08 (in src/binding/fortran/use_mpi_f08/wrappers_f/f08ts.f90) does no such conversion. The bug is also in MPI_Testany (and potentially other functions I did not test yet). However, without detailed knowledge about internals of MPICH I might not be the best person to fix the issue. Greetings, Gregor On 11.01.22 22:52, Raffenetti, Ken wrote: Gregor, I believe these are test bugs. A fix for the f77 versions was added previously in https://github.com/pmodels/mpich/pull/3962/commits/69b02eaabcdb0008f3879372…, though it does not cover the prsendf test. Perhaps you could add a commit to your branch to fix these tests in a similar way. Ken On 1/11/22, 2:30 AM, "Gregor Corbin" <g.corbin(a)fz-juelich.de> <mailto:[email protected]> wrote: Updating the F08 tests to 'use mpi_f08' was mostly straightforward. However, i ran into problems with three of the tests: irsendf08.f90, pssendf08.f90 and prsendf08.f90. With my modified irsendf08 (attached) for example, the test produces these error messages: Nonnull request in irsend and irecv [ 0 ] Unexpected source: 0 in irsend and irecv [ 0 ] Unexpected tag: 0 in irsend and irecv [ 0 ] Unexpected count: 0 in irsend and irecv Invalid data 0.0 at 1 of 666 in irsend and irecv Invalid data 0.0 at 2 of 666 in irsend and irecv ... Invalid data 0.0 at 666 of 666 in irsend and irecv Found 669 errors That is, the last message from process 1 to 0 is not received correctly. When I replace the call to MPI_Waitany with Waitall or Wait there are not errors. Is there maybe a problem with Waitany or did I just do something wrong? Gregor On 07.01.22 17:59, Raffenetti, Ken wrote: We would consider a patch, yes. First, you would need to sign and return the contributors agreement. https://www.mpich.org/documentation/contributor-docs/ As for whether or not automatic conversion is practical, I think if we structured the tests such that the types needing conversion were easily identifiable, then it could be done. It would require some churn of the existing tests. It may also complicate the addition of new, as the author would need to adhere to guidelines that may not be obvious without prior knowledge. I gave myself a task to support automatic conversion of the tests the `use mpi_f08`, but it is not very high priority at the moment. Ken On 1/7/22, 3:10 AM, "Gregor Corbin via discuss" <discuss(a)mpich.org> <mailto:[email protected]> <mailto:[email protected]> <mailto:[email protected]> wrote: Hi MPICH, I noticed that some of the tests in test/mpi/f08 still work with 'use mpi' instead of 'use mpi_f08', mostly in the pt2pt folder. These seem to be copies of the tests in f90 which in turn have been generated by f77tof90. Shouldn't these tests be converted to 'use mpi_f08'? If so, would you be interested in a PR that fixes this? I would need to do this anyway. Kind regards, Gregor Corbin PS.: The interfaces for 'use mpi' and 'use mpi_f08' are probably too different for an automatic conversion to be practical (how to change all the integers to type(mpi_xxx) for example?).

1 0

Re: [mpich-discuss] Fortran 08 tests with 'use mpi'
by Gregor Corbin 12 Jan '22

12 Jan '22

Ken, while updating the F08 tests with this bugfix, I may have found another bug inside the 'use mpi_f08' wrappers. The fix removes (superficially) the error in irsendf08, but I still get the same error in pssendf08. This has to do with the array of indices returned by MPI_Testsome: With the 'use mpi_f08' wrappers, the indices in this array are 0-indexed although they should start from 1 according to the Standard (they do start from 1 with the 'use mpi' and 'mpif.h' functions). I have attached a minimal working example to confirm this. Indeed, the function mpi_testsome_ (in src/binding/fortran/mpif_h/fortran_binding.c) converts the indices: for (int i = 0; i < (*outcount); i++) { array_of_indices[i] += 1; } The subroutine MPI_Testsome_f08 (in src/binding/fortran/use_mpi_f08/wrappers_f/f08ts.f90) does no such conversion. The bug is also in MPI_Testany (and potentially other functions I did not test yet). However, without detailed knowledge about internals of MPICH I might not be the best person to fix the issue. Greetings, Gregor On 11.01.22 22:52, Raffenetti, Ken wrote: > Gregor, > > I believe these are test bugs. A fix for the f77 versions was added previously in https://github.com/pmodels/mpich/pull/3962/commits/69b02eaabcdb0008f3879372…, though it does not cover the prsendf test. Perhaps you could add a commit to your branch to fix these tests in a similar way. > > Ken > > On 1/11/22, 2:30 AM, "Gregor Corbin" <g.corbin(a)fz-juelich.de> wrote: > > > > > > > Updating the F08 tests to 'use mpi_f08' was mostly > straightforward. However, i ran into problems with three of the > tests: irsendf08.f90, pssendf08.f90 and prsendf08.f90. > With my modified irsendf08 (attached) for example, the test > produces these error messages: > > > Nonnull request in irsend and irecv > [ 0 ] Unexpected source: 0 in irsend and > irecv > [ 0 ] Unexpected tag: 0 in irsend and > irecv > [ 0 ] Unexpected count: 0 in irsend and > irecv > Invalid data 0.0 at 1 of 666 in irsend and irecv > Invalid data 0.0 at 2 of 666 in irsend and irecv > ... > Invalid data 0.0 at 666 of 666 in irsend and irecv > Found 669 errors > > > > That is, the last message from process 1 to 0 is not received > correctly. When I replace the call to MPI_Waitany with Waitall or > Wait there are not errors. > Is there maybe a problem with Waitany or did I just do something > wrong? > Gregor > > > On 07.01.22 17:59, Raffenetti, Ken > wrote: > > > We would consider a patch, yes. First, you would need to sign and return the contributors agreement. https://www.mpich.org/documentation/contributor-docs/ > > As for whether or not automatic conversion is practical, I think if we structured the tests such that the types needing conversion were easily identifiable, then it could be done. It would require some churn of the existing tests. It may also complicate the addition of new, as the author would need to adhere to guidelines that may not be obvious without prior knowledge. > > I gave myself a task to support automatic conversion of the tests the `use mpi_f08`, but it is not very high priority at the moment. > > Ken > > On 1/7/22, 3:10 AM, "Gregor Corbin via discuss" <discuss(a)mpich.org> <mailto:[email protected]> wrote: > > Hi MPICH, > > I noticed that some of the tests in test/mpi/f08 still work with 'use > mpi' instead of 'use mpi_f08', mostly in the pt2pt folder. These seem > to be copies of the tests in f90 which in turn have been generated by > f77tof90. > > Shouldn't these tests be converted to 'use mpi_f08'? If so, would you be > interested in a PR that fixes this? I would need to do this anyway. > > > Kind regards, > > Gregor Corbin > > > PS.: The interfaces for 'use mpi' and 'use mpi_f08' are probably too > different for an automatic conversion to be practical (how to change all > the integers to type(mpi_xxx) for example?). > > > > > > > > >

1 0

Re: [mpich-discuss] Fortran 08 tests with 'use mpi'
by Raffenetti, Ken 11 Jan '22

11 Jan '22

Gregor, I believe these are test bugs. A fix for the f77 versions was added previously in https://github.com/pmodels/mpich/pull/3962/commits/69b02eaabcdb0008f3879372…, though it does not cover the prsendf test. Perhaps you could add a commit to your branch to fix these tests in a similar way. Ken On 1/11/22, 2:30 AM, "Gregor Corbin" <g.corbin(a)fz-juelich.de> wrote: Updating the F08 tests to 'use mpi_f08' was mostly straightforward. However, i ran into problems with three of the tests: irsendf08.f90, pssendf08.f90 and prsendf08.f90. With my modified irsendf08 (attached) for example, the test produces these error messages: Nonnull request in irsend and irecv [ 0 ] Unexpected source: 0 in irsend and irecv [ 0 ] Unexpected tag: 0 in irsend and irecv [ 0 ] Unexpected count: 0 in irsend and irecv Invalid data 0.0 at 1 of 666 in irsend and irecv Invalid data 0.0 at 2 of 666 in irsend and irecv ... Invalid data 0.0 at 666 of 666 in irsend and irecv Found 669 errors That is, the last message from process 1 to 0 is not received correctly. When I replace the call to MPI_Waitany with Waitall or Wait there are not errors. Is there maybe a problem with Waitany or did I just do something wrong? Gregor On 07.01.22 17:59, Raffenetti, Ken wrote: We would consider a patch, yes. First, you would need to sign and return the contributors agreement. https://www.mpich.org/documentation/contributor-docs/ As for whether or not automatic conversion is practical, I think if we structured the tests such that the types needing conversion were easily identifiable, then it could be done. It would require some churn of the existing tests. It may also complicate the addition of new, as the author would need to adhere to guidelines that may not be obvious without prior knowledge. I gave myself a task to support automatic conversion of the tests the `use mpi_f08`, but it is not very high priority at the moment. Ken On 1/7/22, 3:10 AM, "Gregor Corbin via discuss" <discuss(a)mpich.org> <mailto:[email protected]> wrote: Hi MPICH, I noticed that some of the tests in test/mpi/f08 still work with 'use mpi' instead of 'use mpi_f08', mostly in the pt2pt folder. These seem to be copies of the tests in f90 which in turn have been generated by f77tof90. Shouldn't these tests be converted to 'use mpi_f08'? If so, would you be interested in a PR that fixes this? I would need to do this anyway. Kind regards, Gregor Corbin PS.: The interfaces for 'use mpi' and 'use mpi_f08' are probably too different for an automatic conversion to be practical (how to change all the integers to type(mpi_xxx) for example?).

1 0

Re: [mpich-discuss] Fortran 08 tests with 'use mpi'
by Gregor Corbin 11 Jan '22

11 Jan '22

Updating the F08 tests to 'use mpi_f08' was mostly straightforward. However, i ran into problems with three of the tests: irsendf08.f90, pssendf08.f90 and prsendf08.f90. With my modified irsendf08 (attached) for example, the test produces these error messages: Nonnull request in irsend and irecv [ 0 ] Unexpected source: 0 in irsend and irecv [ 0 ] Unexpected tag: 0 in irsend and irecv [ 0 ] Unexpected count: 0 in irsend and irecv Invalid data 0.0 at 1 of 666 in irsend and irecv Invalid data 0.0 at 2 of 666 in irsend and irecv ... Invalid data 0.0 at 666 of 666 in irsend and irecv Found 669 errors That is, the last message from process 1 to 0 is not received correctly. When I replace the call to MPI_Waitany with Waitall or Wait there are not errors. Is there maybe a problem with Waitany or did I just do something wrong? Gregor On 07.01.22 17:59, Raffenetti, Ken wrote: > We would consider a patch, yes. First, you would need to sign and return the contributors agreement. https://www.mpich.org/documentation/contributor-docs/ > > As for whether or not automatic conversion is practical, I think if we structured the tests such that the types needing conversion were easily identifiable, then it could be done. It would require some churn of the existing tests. It may also complicate the addition of new, as the author would need to adhere to guidelines that may not be obvious without prior knowledge. > > I gave myself a task to support automatic conversion of the tests the `use mpi_f08`, but it is not very high priority at the moment. > > Ken > > On 1/7/22, 3:10 AM, "Gregor Corbin via discuss" <discuss(a)mpich.org> wrote: > > Hi MPICH, > > I noticed that some of the tests in test/mpi/f08 still work with 'use > mpi' instead of 'use mpi_f08', mostly in the pt2pt folder. These seem > to be copies of the tests in f90 which in turn have been generated by > f77tof90. > > Shouldn't these tests be converted to 'use mpi_f08'? If so, would you be > interested in a PR that fixes this? I would need to do this anyway. > > > Kind regards, > > Gregor Corbin > > > PS.: The interfaces for 'use mpi' and 'use mpi_f08' are probably too > different for an automatic conversion to be practical (how to change all > the integers to type(mpi_xxx) for example?). > > >

1 0