[MPI3 Fortran] Results of San Jose Forum meeting
rabenseifner at hlrs.de
Fri Mar 12 17:51:36 CST 2010
I want to cite
"By default, no storage sequence is implied by the order of the component definitions.
However, if you specify the SEQUENCE statement, the derived type becomes a sequence derived type.
For a sequence derived type, the order of the components specifies a storage sequence
for objects declared with this derived type.
If a component of a sequence derived type is of a derived type,
that derived type must also be a sequence derived type.
The size of a sequence derived type declared using a s
tandard derived type declaration is equal to the sum of
the number of bytes required to hold all of its components."
I hope, that this text is based on the Fortran standard.
Other text from the Fortran 95/2003 book
"A sequence type is a numeric sequence type if it has no type parameters,
no component is a pointer or allocatable, and each component is of type
default integer, default real, double precision real, default complex,
or default logical. A component may also be of a previously defined numeric
sequence type. This implies that the ultimate components occupy numeric
storage units and the type itself has numeric storage association."
I hope that these citations are correct in relation to the official
Fortran 2003 standard.
Based on this, the original INTEGER handles and the proposed
derived sequence type with default integer and without any bind(c)
have exactly the same content and storage association.
Based on this, for use mpi and use mpi3, only one identical
backend (written in C) should be necessary.
Of course, this backend must handle Fortran INTEGER and not
These Fortran derived sequence types have been chosen
- to allow strong typing and argument checking that detects
interchanges of count or tag values with datatype and communicator
- witout the need of additional handle value conversion routines.
Convertion, if needed, can be done very simple
INTEGER :: comm_mpi22
TYPE(MPI_Comm) :: comm_mpi30
comm_mpi22 = comm_mpi30%val
comm_mpi30%val = comm_mpi22
- And only one backend for use mpi and use mpi3
----- "Aleksandar Donev" <adonev at lbl.gov> wrote:
> You guys have been busy but unfortunately I do not see much progress,
> On Thursday 11 March 2010, Bill Long wrote:
> > type,bind(c) :: MPI_Comm
> > integer(c_int) :: val
> > end type MPI_Comm
> If indeed someone insists on specifying the internals, use:
> INTEGER(MPI_COMM) :: handle
> What on earth is wrong with that?
> Striving for type-safety and striving to:
> > One advantage of the integer flag values is that it avoids
> > issues when we change the pointer size.
> are at odds with one another. It is like saying a typealias provides
> type safety. It does not, only *subtyping* does, which Fortran does
> have. A derived type with one integer component is, in Fortran, and
> almost in C, soo different from an integer that it is not worth trying
> to pretend they are the same thing. Sticking SEQUENCE will do nothing
> for a type of only one single component, either in practice or in
> theory. BIND(C), as Bill proposes, is infinitely better, if someone
> insists on a derived type (for type safety or whatever reasons).
> Aleksandar Donev, Ph.D.
> Luis W. Alvarez Postdoctoral Fellow
> Center for Computational Sciences and Engineering
> Lawrence Berkeley National Laboratory (http://www.lbl.gov)
> E-mail: adonev at lbl.gov
> Phone: (510) 486-5782 Fax: (510) 486-6900
> Address: MS 50A-1148, LBL, 1 Cyclotron Rd., Berkeley, CA 94720
> Web: http://cims.nyu.edu/~donev/
> mpi3-fortran mailing list
> mpi3-fortran at lists.mpi-forum.org
Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner at hlrs.de
High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530
University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832
Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner
Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)
More information about the mpiwg-fortran