Hi,
On Mon, Mar 26, 2018 at 07:41:24AM -0600, David A Case wrote:
> This email is primarily for Scott and Gerald, but I'm posting to the
> whole list in case others (Dan?) have useful input:
>
> 1. Concerning Intel 2018 compilers: can you do this:
>
> cd $AMBERHOME/test/dhfr
> ./Run.dhfr
> mv mdout.dhfr mdout.dhfr.sander (assuming some failure occured)
> TESTsander=../../bin/pmemd ./Run.dhfr
>
> And send me the mdout.dhfr files plus info that comes to stdout/stderr?
> I'm trying to see if there are hints in the mdout file about what is
> going on.
>
> I think there is no point for anyone to continue to report hundreds of
> errors with Intel 18. But if you see ideas (e.g. compiler flags) that
> help, plese send that information along.
I blew away my 18.0.0 build. I now have access to 18.0.2 and will
build with and report dhfr.
> 2. In the configure2 script, we already create cc_version_major and
> fc_version_major variables. I think we just need to check them in the
> intel compiler section, and output an error message ("Sorry: we have not
> yet had time to get Amber to work with the 2018 versions of Intel
> compilers") if one finds version 18.
Ok.
> 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?
Yes, i added -mkl for two reasons: -mkl is a vastly superior interface
to MKL for intel compilers and MKL_HOME is problematic on systems with
multiple compiler and mkl versions (ie, i had link errors using
MKL_HOME and got tired of inspecting a zillion libmkl_* files).
Other replies have addressed how MKL_HOME might be useful
and why it doesn't seem that anyone is using it w/o intel compilers.
> 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?
The answer from OSC's intel installer is probably yes, but it would require
extra effort and probably creativity.
> c. Hence, do we need either option? Can we assume that the Intel compiler
> will have MKL and just use it?
We probably don't need either for intel, but the careful approach would be
to add a -nomkl option and not to do all this right before release.
> d. Is there any need to still allow MKL to be used with GNU
> compilers? Does anyone have an example where there is a
> significant speed improvement using this option?
>
> 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?
No; i don't think anyone is spending such time; we still have
intel/12.1.4.319 at OSC because a lot of software was built with it
and it was a solid version as far as quality control.
But intel 16 would be a more recent reasonable cutoff.
As usual, the question of when to retire something is relative.
The last time this came up for gnu compilers someone wanted a really
early 4 version. It's easy to say/write "install bla bla" but as we know
this doesn't always work for developers, let alone inexperienced users.
scott
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Mon Mar 26 2018 - 10:30:05 PDT
