On Mon, Mar 26, 2018 at 9:41 AM, David A Case <david.case.rutgers.edu> wrote:
>
> 3. Concerning Intel 2017 compilers:
>
> We have two quite different ways of requesting MKL: via the -mkl flag
> and via the MKL_HOME environment variable. The -mkl flag leads to
> simpler FLIBS (etc.) varaibles in config.h.
>
> a. does anyone understand the difference; understand why we might
> want two different options?
So from what I can tell, MKL_HOME triggers the "link line advisor"
style of linking in MKL. The advantage there is that allows MKL to be
used with non-Intel compilers (at least GNU and PGI, not sure about
Cray). The '-mkl' flag triggers the much simpler '-mkl' option for
linking MKL (
https://software.intel.com/en-us/mkl-linux-developer-guide-using-the-mkl-compiler-option)
but this only works for Intel compilers. It seems like '-mkl' for
configure2 also makes PMEMD use the MKL FFT.
> b. It looks to me like Intel now bundles both MKL and intelmpi into
> their compiler suites. Is it possible to have the compilers
> without MKL?
Only the runtime libraries for IntelMPI are bundled with the Intel
compiler suite - the dev libraries cost extra. I think MKL always
comes with it but I'm not sure about that.
>
> 4. The configure2 script is still making decisions based on the Intel
> compilers back to version 10. Is there any need to continue to try
> to support such old compilers? Are we just wasting develper time
> trying to test (let alone benchmark) these things? What is the
> oldest vesion of the Intel compilers we should allow?
I can't speak for everyone, but the oldest Intel compilers I still
have access to are version 12, so I can't even test the older ones. I
say if no devs have access to older compilers we at least print a
warning that this is now unsupported (if not outright disable).
-Dan
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Mon Mar 26 2018 - 08:00:04 PDT