Hi,
On Mon, 16 Oct 2006, Ross Walker wrote:
> For Amber 10 we will be requiring a Fortran 95 compiler. Will we also be
> requiring an implementation of MPI v2?
On Mon, 27 Mar 2006 11:58:01 -0800 Dave indicated that a Fortran 95
compiler was a requirement for sander. So Amber 9 requires Fortran 95.
We should have put a comment in the Amber 9 manual.
On Mon, 16 Oct 2006, Ross wrote, Dave wrote, then Ross wrote:
> > > There are some functions of MPI 2 that I would like to use
> >
> > what are these functions?
>
> Initially the main ones I would like to use are MPI_IN_PLACE versions of
> many mpi v1 commands.
>
> E.g.
> if (master) then
> call mpi_reduce(MPI_IN_PLACE, sendbuf, 100, MPI_REAL, MPI_SUM, 0,
> else
> call mpi_reduce(sendbuf, 0, 100, MPI_REAL, MPI_SUM, 0, commworld, ier)
> end if
Use of MPI_IN_PLACE may improve efficiency. (I wouldnt be surprised
if some or many MPI v1 implementations already have this optimization
( in particular, I mean with out having to specify MPI_IN_PLACE ),
especially for reduce operations. Furthermore, I wouldnt be surprised
if some or all MPI v2 implementations do not have the MPI_IN_PLACE
optimization for all instances mandated by the standard.)
Thus, I encourage you to share your profiling data and to make a
persuasive case before you optimize.
> While messy this can be worked around with some ifdefs to do both versions.
> However, I would ultimately like to be able to use single sided messaging
> operations (mpi_get and mpi_put) as this makes diagonalization in parallel
> significantly more efficient. However, there is no MPI v1 equivalent of this
> and so it would be very difficult to make both MPI v1 and MPI v2 compliant
> versions of the code.
There are a number of approaches. ifdef-ing is perhaps the most familiar,
but otherwise does not have much going for it.
At the very least use just one ifdef by hiding the mpi v1 or v2 selection
inside the guts of a module. The Trace module is an example of this approach.
But here are some details, eg:
#file.f
call mpi_reduce(sendbuf, 0, 100, MPI_REAL, MPI_SUM, 0, commworld, ier)
->
use ambermpi
...
call ambermpi_mpi_reduce(sendbuf, 0, 100, MPI_REAL, MPI_SUM, 0, commworld, ier)
# ambermpi.f
module ambermpi
#ifdef AMBER_MPI_IN_PLACE
logical :: use_mpi_in_place = true
#else
logical :: use_mpi_in_place = false
#endif
subroutine ambermpi_mpi_reduce(sendbuf, ...
if ( use_mpi_in_place ) then
call mpi_reduce(MPI_IN_PLACE, sendbuf, ...
else
call mpi_reduce(sendbuf, ...
endif
end sub
end mod
Since this is the 21st century, any fortran compiler will optimize away the
if inside ambermpi_mpi_reduce.
Sorry if I have overkilled you on the details, but I agree with Bob Duke
that we can and should do a better job of specifying our interfaces.
The technique above preserves the mpi v1 interface,
hides an implementation detail inside a module,
enables compile time control of the guts,
and does not reduce efficiency.
See my next post with subject
interfaces booklist
for references.
Date: Mon, 27 Mar 2006 11:58:01 -0800
From: Scott Brozell <sbrozell.scripps.edu>
To: amber-developers.scripps.edu
Subject: Re: amber-developers: Re: More sun issues
Hi,
On Mon, 27 Mar 2006, David A. Case wrote:
> On Mon, Mar 27, 2006, Scott Brozell wrote:
>
> > > > integer :: system_coord_id = 0
>
> > Agreed, but is it or is it not Fortran standard compliant ?
>
> It *is* standard-compliant in F95: see p. 139 of Metcalf, Reid and Cohen,
> "Fortran 95/2003 Explained."
>
> This syntax is not required to be supported in Fortran 90. I guess this
> means that an F95-compliant compiler is required for sander. Since we are now
> 11 years past 1995, this seems like a reaonsble requirement. Other compilers
> that are called "F90" (such as from SGI) allow this construct.
Mongan> f90: Sun Fortran 95 8.2 2005/10/13
Wow, ok; thanks for the language lawyering.
Aside: interestingly, this means that every such object is getting
initialized even as a local variable.
Scott
Received on Wed Oct 18 2006 - 06:07:35 PDT
