Hi,
Having mpiifort/mpiicc is very specific I guess.
On my side, if I use "configure_mpich2/openmpi intel" from
AmberTools/src to get a working MPI version with the Intel compiler, I
end up with mpif90/mpicc only. So there are different ways of having
Intel + MPI...
As Dave said, it has "always" been required that the user provides a
working version of mpif90/mpicc. What should this case be so specific?
Is it now standard to have mpiifort for Intel + MPI? In that case,
should configure_mpich/openmpi be modified to automagically link the
correct binaries?
Gerald.
On 04/01/2014 06:12 PM, Jason Swails wrote:
> I just tried the Intel compilers and got the same behavior. The
> relevant code in configure2 makes it seem like it was tested on a
> machine or two that did not have the Intel compilers (line 1014):
>
> mpiifort_version=`mpiifort -v 2>&1`
> mpiifort_version=`echo $mpiifort_version | sed -e 's/mpiifort.*Library //g' -e 's/for Linux.*//g' -e 's/\.0.*//g' -e 's/bash.*found//g' -e 's/mpiifort.*license.*//g'`
>
> I assume the purpose of the 'sed' command is to wipe out any error
> messages and return a blank string. The output of a failed "mpiifort
> -v" command will probably vary from platform to platform, so such an
> approach probably won't work here.
>
> This mechanism can be replaced by using "which" to detect the presence
> of mpiifort or mpiicc in the PATH (akin to what's done for Python around
> line 569) and only grep for the version if it exists.
>
> I'd still say that Intel MPI is sufficiently specialized that we should
> have users request it either via a -intelmpi flag like Dan suggested or
> by setting up symlinks like Dave suggested. Unless mpicc/mpif90 is
> provided by Intel's MPI in addition to mpiifort/mpiicc (which is so
> weird!?), I might cast my vote in with Dave's suggestion for now. If
> mpicc/mpif90 IS provided by IntelMPI, Dan's suggestion is best IMO.
>
> I'm all for making users jump through (trivial) hoops (like setting up
> system symlinks and squelching other MPIs from their PATH variables) to
> support a combination that hasn't been that thoroughly tested yet by the
> wider community. (If Dave's suggestion is not trivial to someone, they
> should probably consider sticking with typical MPIs for now).
>
> Just my 2c...
>
> All the best,
> Jason
>
> On Tue, 2014-04-01 at 08:51 -0700, Ross Walker wrote:
>> Hi Dave,
>>
>> The problem is that with Intel MPI mpif90 and mpicc point to gfortran and
>> gcc while mpiifort and mpiicc point to ifort and icc. VERY annoying!!! -
>> But it means relying on mpif90 and mpicc here doesn't work. That's why the
>> check is in there. I'd have assumed though that Perri would have checked
>> this on a machine that didn't have the intel MPI but did have the Intel
>> compilers. Perri can you fix this today please.
>>
>> All the best
>> Ross
>>
>>
>> On 4/1/14, 8:45 AM, "David A Case" <case.biomaps.rutgers.edu> wrote:
>>
>>> On Tue, Apr 01, 2014, Daniel Roe wrote:
>>>>
>>>> This check can be fixed, but the larger issue I think is configure
>>>> shouldn't assume intel MPI will be used with Intel compilers. Instead, I
>>>> think this should be a separate flag like '-intelmpi' that users can
>>>> specify if they want mpiifort etc used instead of mpif90. Thoughts?
>>>
>>> For the -mpi flag, we have always said that it is up to the user to
>>> make sure that the mpicc and mpif90 commands found in the PATH are the
>>> ones
>>> they really want. We don't try to distinguish (or care) whethere the
>>> user is
>>> using openmpi, or mpich, or mvapich, or some hardware-specific version.
>>>
>>> Why should we not do the same for Intel's mpi? That is, it is up to the
>>> user
>>> to make mpicc point to mpiicc, and mpif90 to point to mpiifort. We can
>>> give
>>> some hand-holding instructions, but it seems like we are going down a
>>> long,
>>> long path to try to support every MPI version's command names that might
>>> come
>>> up.
>>>
>>> This is a pretty tentative recommendation, but it is a simple one!
>>>
>>> ...dac
>>>
>>>
>>> _______________________________________________
>>> AMBER-Developers mailing list
>>> AMBER-Developers.ambermd.org
>>> http://lists.ambermd.org/mailman/listinfo/amber-developers
>>
>>
>>
>> _______________________________________________
>> AMBER-Developers mailing list
>> AMBER-Developers.ambermd.org
>> http://lists.ambermd.org/mailman/listinfo/amber-developers
>
--
____________________________________________________________________________
Prof. Gerald MONARD
SRSMC, Université de Lorraine, CNRS
Boulevard des Aiguillettes B.P. 70239
F-54506 Vandoeuvre-les-Nancy, FRANCE
e-mail : Gerald.Monard.univ-lorraine.fr
tel. : +33 (0)383.684.381
fax : +33 (0)383.684.371
web : http://www.monard.info
____________________________________________________________________________
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Tue Apr 01 2014 - 12:00:03 PDT
