[mpich-devel] binding a new MPI type with fortran

[Tatiana V. Martsinkevich]

hello,

Dave, thank you for the brief explanation and links. I still didn't managed
to make fortran programs recognize MPIX_Pattern type so as a temporary
solution we just pass an integer type variable.

Larry, do you mean that we might have problems when passing integer pointer
to a function that takes void* as an argument? We've changed the interfaces
too so we operate with integers and integer pointers everywhere.

best regards,
Tatiana


2013/3/29 Dave Goodell <goodell at mcs.anl.gov>

> The "@FOO@" snippets in a file named "BAR.in" are replaced by "configure"
> (by "config.status", technically) when it is run.  The replacement string
> is taken from a shell environment variable in the configure script by the
> same name.  Valid substitution values are designated by "AC_SUBST" macro
> invocations in "configure.ac".
>
> There are a lot of moving parts here which would take a lot of time to
> explain in detail.  You will probably help yourself out by learning a bit
> about the autotools:
>
> http://www.gnu.org/software/autoconf/manual/autoconf.html
> http://www.gnu.org/software/automake/manual/automake.html
> http://www.flameeyes.eu/autotools-mythbuster/
>
> Grep will also help you answer many of these questions.
>
> -Dave
>
> On Mar 29, 2013, at 3:11 PM CDT, Tatiana V. Martsinkevich <
> tanya.manekineko at gmail.com> wrote:
>
> > Hello,
> >
> > Thanks again for your help Dave.
> >
> > So we went the other way around and changed the type of MPI_Pattern from
> void* to integer and now fortran interfaces are being generated correctly.
> However, now the question is how to register the new type MPI_Pattern so
> that we could use it in fortran programs. This also doesn't seem to be
> trivial...
> >
> > In buildface there are this kind of code sections:
> >
> >     # Datatypes
> >     # These are determined and set at configure time
> >     foreach $key (COMPLEX, DOUBLE_COMPLEX, LOGICAL, REAL,
> DOUBLE_PRECISION, INTEGER, '2INTEGER', '2DOUBLE_PRECISION', '2REAL',
> CHARACTER) {
> >     print MPIFFD "       INTEGER MPI_$key\n";
> >     print MPIFFD "       PARAMETER (MPI_$key=\@MPI_$key\@)\n";
> >     }
> >
> > this looks like where I should start digging but apparently, simply
> adding PATTERN to the key set doesn't work:
> >
> >        Included at src/binding/f90/mpi_constants.f90:6:
> >
> >        PARAMETER (MPI_PATTERN=@MPI_PATTERN@)
> >                               1
> >        Error: Expected expression at (1) in PARAMETER statement
> >
> > Also, could someone please explain what does this notion - @MPI_COMPLEX at - in
> mpi.h.in mean
> >
> > /* Fortran types */
> > #define MPI_COMPLEX           ((MPI_Datatype)@MPI_COMPLEX@)
> >
> >
> > regards,
> > Tatiana
> >
> >
> > 2013/3/28 Dave Goodell <goodell at mcs.anl.gov>
> > You almost certainly will also need some modifications in
> "src/binding/f77/buildiface".  Whenever I need to modify this script I have
> to stare at it for a while before I'm sure where the modifications need to
> go.
> >
> > I don't think we have any existing types which map to pointers under the
> hood.  So there isn't a good example for you to use here.  The "MPI_Fint *"
> changes in particular do not seem correct to me in general.  They *might*
> work in a pinch on a platform with where INTEGER and (void*) are the same
> size.  They might also work on little endian platforms like x86/x86_64, but
> it will be purely by luck if they do.
> >
> > You may be better writing your own Fortran bindings by hand in the short
> term.
> >
> > Bill may have something to add on this subject, since he's the primary
> maintainer for these scripts.
> >
> > -Dave
> >
> > On Mar 28, 2013, at 3:04 PM CDT, Tatiana V. Martsinkevich <
> tanya.manekineko at gmail.com> wrote:
> >
> > > Thanks for reply.
> > >
> > > Yes, unfortunately we need fortran interfaces because most of the
> > > applications that we use for testing are written in fortran.
> > > Will it be enough if I just add a conversion rule to %parmc2f in
> > > ./src/binding/f90/buildface? Something like:
> > >
> > > 'MPI_Pattern' => 'INTEGER(KIND=MPI_ADDRESS_KIND)',
> > > 'MPI_Pattern*'  => 'INTEGER(KIND=MPI_ADDRESS_KIND)',
> > >
> > > And for f77 it will be:
> > >
> > > 'MPI_Pattern' => 'MPI_Fint *'
> > > 'MPI_Pattern*'  => 'MPI_Fint *'
> > >
> > >
> > >> Also, as a side note, please use "MPIX_" for nonstandard MPI
> extensions.  It makes nonstandard interfaces very obvious to users and will
> help prevent potential issues with standardization in the future.
> > >
> > > Duly noted.
> > >
> > > Tatiana
> > >
> > > 2013/3/28 Dave Goodell <goodell at mcs.anl.gov>:
> > >> On Mar 28, 2013, at 2:16 PM CDT, Tatiana V. Martsinkevich <
> tanya.manekineko at gmail.com> wrote:
> > >>
> > >>> We are implementing some fault tolerance related functionality in
> > >>> MPICH-3.0.2. We define a new MPI type in
> > >>> ~/mpich-3.0.2/src/include/mpi.h.in as:
> > >>>
> > >>> typedef void* MPI_Pattern;
> > >>>
> > >>> then in the same file we define:
> > >>>
> > >>> int MPI_Pattern_declare(char* name, MPI_Pattern* handler);
> > >>>
> > >>> However, when I run autogen.sh and fortran binding script executes it
> > >>> gives out:
> > >>>
> > >>> Pattern_declare: No parm type for MPI_Pattern* (MPI_Pattern*)
> > >>> Use of uninitialized value $fparm in pattern match (m//) at
> > >>> ./buildiface line 1289, <FD> line 1710.
> > >>
> > >> Do you want Fortran interfaces at this time or would you be just as
> happy to have C-only bindings right now?  The former will require hacking
> on one or more of the "buildiface" scripts in the "src/binding/LANGUAGE"
> directories.  The latter can be accomplished by moving your prototypes and
> types near the end of mpi.h.in, near the prototypes for
> "MPIX_Mutex_unlock" and "PMPIX_Mutex_unlock".
> > >>
> > >> Also, as a side note, please use "MPIX_" for nonstandard MPI
> extensions.  It makes nonstandard interfaces very obvious to users and will
> help prevent potential issues with standardization in the future.
> > >>
> > >> -Dave
> > >>
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpich.org/pipermail/devel/attachments/20130401/71605077/attachment-0001.html>