On Aug 19, 2016, at 6:32 PM, Matt Thompson <fort...@gmail.com> wrote:
>
> 2. The second one is a run-time assignment. You can do that between any
> compatible entities, and so that works.
>
> Okay. This makes sense. I guess I was surprised that MPI_COMM_NULL wasn't a
> constant (or parameter, I guess). But maybe a type() cannot be constant...
Maybe...? I don't know enough Deep Fortran to know...
> > that the comm == MPI_COMM_WORLD evaluates to .TRUE.? I discovered that once
> > when I was printing some stuff.
>
> That might well be a coincidence. type(MPI_Comm) is not a boolean type, so
> I'm not sure how you compared it to .true.
>
> Well, I made a program like:
>
> (208) $ cat test2.F90
> program whoami
> use mpi_f08
> implicit none
> type(MPI_Comm) :: comm
> if (comm == MPI_COMM_WORLD) write (*,*) "I am MPI_COMM_WORLD"
> if (comm == MPI_COMM_NULL) write (*,*) "I am MPI_COMM_NULL"
> end program whoami
> (209) $ mpifort test2.F90
> (210) $ mpirun -np 4 ./a.out
> I am MPI_COMM_WORLD
> I am MPI_COMM_WORLD
> I am MPI_COMM_WORLD
> I am MPI_COMM_WORLD
>
> I think if you print comm, you get 0 and MPI_COMM_WORLD=0 and MPI_COMM_NULL=2
> so...I guess I'm surprised. I'd have thought MPI_Comm would have been
> undefined until defined.
I don't know the rules here for what happens in Fortran when comparing an
uninitialized derived type. The results could be undefined...?
> Instead you can write a program like this:
>
> (226) $ cat helloWorld.mpi3.F90
> program hello_world
>
> use mpi_f08
>
> implicit none
>
> type(MPI_Comm) :: comm
> integer :: myid, npes, ierror
> integer :: name_length
>
> character(len=MPI_MAX_PROCESSOR_NAME) :: processor_name
>
> call mpi_init(ierror)
>
> call MPI_Comm_Rank(comm,myid,ierror)
> write (*,*) 'ierror: ', ierror
> call MPI_Comm_Size(comm,npes,ierror)
> call MPI_Get_Processor_Name(processor_name,name_length,ierror)
>
> write (*,'(A,X,I4,X,A,X,I4,X,A,X,A)') "Process", myid, "of", npes, "is
> on", trim(processor_name)
>
> call MPI_Finalize(ierror)
>
> end program hello_world
> (227) $ mpifort helloWorld.mpi3.F90
> (228) $ mpirun -np 4 ./a.out
> ierror: 0
> ierror: 0
> ierror: 0
> ierror: 0
> Process 2 of 4 is on compy
> Process 1 of 4 is on compy
> Process 3 of 4 is on compy
> Process 0 of 4 is on copy
That does seem to be odd output. What is the hostname on your machine? FWIW,
I changed your write statement to:
print *, "Process", myid, "of", npes, "is on", trim(processor_name)
and after I added a "comm = MPI_COMM_WORLD" before the call to MPI_COMM_RANK,
the output prints properly for me (i.e., I see my hostname).
> This seems odd to me. I haven't passed in MPI_COMM_WORLD as the communicator
> to MPI_Comm_Rank, and yet, it worked and the error code was 0 (which I'd take
> as success). Even if you couldn't detect this at compile time, I'm surprised
> it doesn't trigger a run-time error. Is this the correct behavior according
> to the Standard?
I think you're passing an undefined value, so the results will be undefined.
It's quite possible that the comm%mpi_val inside the comm is (randomly?)
assigned to 0, which is the same value as mpif.f's MPI_COMM_WORLD, and
therefore your comm is effectively the same as mpi_f08's MPI_COMM_WORLD --
which is why MPI_COMM_RANK and MPI_COMM_SIZE worked for you.
Indeed, when I run your program, I get:
-----
$ ./foo
[savbu-usnic-a:31774] *** An error occurred in MPI_Comm_rank
[savbu-usnic-a:31774] *** reported by process [756088833,0]
[savbu-usnic-a:31774] *** on communicator MPI_COMM_WORLD
[savbu-usnic-a:31774] *** MPI_ERR_COMM: invalid communicator
[savbu-usnic-a:31774] *** MPI_ERRORS_ARE_FATAL (processes in this communicator
will now abort,
[savbu-usnic-a:31774] *** and potentially your MPI job)
-----
I.e., MPI_COMM_RANK is aborting because the communicator being passed in is
invalid.
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
_______________________________________________
users mailing list
users@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/users
