On Fri, Jan 18, 2013 at 10:55 AM, David A Case <case.biomaps.rutgers.edu>wrote:
> On Fri, Jan 18, 2013, Josh Berryman wrote:
>
> > Yes. It seems like there are two separate use-cases, which is leading
> > configure to have a bit of an inconsistent approach
> >
> >
> > 1) ./configure -mpi intel:
> > Require that all the paths are set up: mpicc points to mpiicc, with all
> the
> > libs and paths set up correctly, and mpiicc pointing to icc. This is
>
> I don't think this is correct. I don't see any references to mpiicc (never
> knew that existed.) I think it is better to say that this option assumes
> that mpicc and mpif90 are correctly installed, and know how to find the
> proper
> libraries.
I agree here. configure is now fairly robust to most MPIs. The Cray
compiler wrappers are notable exceptions, although there's a flag for that.
Expecting an MPI to be properly installed is not a heavy requirement,
especially with configure_mpich2 and configure_openmpi around.
> For me, mpicc/mpif90 are always in $AMBERHOME/bin, but I've not
> been able to ever convince anyone else that this is a desirable option.
The only reason I don't suggest this is because then PATH ordering becomes
an issue. This is one of the biggest shortcomings of our configure script,
IMO -- to change versions of MPIs, compilers, etc., you have to change your
PATH environment so `which <thing>` will give you the right version of
<thing>. I also don't like the idea of requiring AMBERHOME/bin to be
prepended to the PATH (I'm not singling out Amber here), since it can
introduce hard-to-isolate bugs (Gaussian's "install" program caused me
hours of grief because of this).
I think we should expand the flexibility of choosing compilers that are
_not_ the head of the PATH.
> >
> > Despite requiring all this prior setup, it still (currently, pulled from
> > dev tree about a week ago) has a kludgey look around for the intel
> library
> > path, sometimes breaking if it turns out that the path is not what was
> > expected.
>
> It's true that configure2 tests the (serial) intel compiler even when -mpi
> is set, which is probably not what it should be doing.
>
> >
> > 2) ./configure intel:
> > Doesn't require scripts to be sourced, sets fc=ifort, etc, itself, and
> also
> > has a kludgey look around for the intel library path.
>
> Well, ifort still has to be in the users' PATH; I suppose we could also
> assume
> that the user's LD_LIBRARY_PATH is also correct.(?)
>
I think this is the correct assumption. We shouldn't try to guess library
locations in a kludgey way and force compilers that aren't set up properly
to compile Amber. If users have trouble setting up the Intel compilers
correctly (which suggests that they're running on their own machine, not a
cluster where this should have been done for them), there's a simple
solution: use gnu. They come ready-to-go with every distribution and make
little-to-no difference in desktop performance (and NO difference in
pmemd.cuda performance).
My 2c,
Jason
--
Jason M. Swails
Quantum Theory Project,
University of Florida
Ph.D. Candidate
352-392-4032
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Fri Jan 18 2013 - 11:00:02 PST
