[mpich-discuss] Fortran 08 tests with 'use mpi'
Gregor Corbin
g.corbin at fz-juelich.de
Fri Jan 14 06:26:50 CST 2022
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 at mpich.org>
> *Date: *Wednesday, January 12, 2022 at 5:19 AM
> *To: *Raffenetti, Ken <raffenet at anl.gov>, discuss at mpich.org
> <discuss at mpich.org>
> *Cc: *Gregor Corbin <g.corbin at 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/69b02eaabcdb0008f3879372629cfe92f98e8d56 <https://github.com/pmodels/mpich/pull/3962/commits/69b02eaabcdb0008f3879372629cfe92f98e8d56>, 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 at fz-juelich.de> <mailto:g.corbin at 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/ <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 at mpich.org> <mailto:discuss at mpich.org> <mailto:discuss at mpich.org> <mailto:discuss at 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?).
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpich.org/pipermail/discuss/attachments/20220114/43049bb0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: show-gcc-and-mpich-bugs.f90
Type: text/x-fortran
Size: 3597 bytes
Desc: not available
URL: <http://lists.mpich.org/pipermail/discuss/attachments/20220114/43049bb0/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: show-gcc-bug.f90
Type: text/x-fortran
Size: 2146 bytes
Desc: not available
URL: <http://lists.mpich.org/pipermail/discuss/attachments/20220114/43049bb0/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5900 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.mpich.org/pipermail/discuss/attachments/20220114/43049bb0/attachment-0001.p7s>
More information about the discuss
mailing list