[AMBER-Developers] Intel compilers and Amber18

From: David A Case <david.case.rutgers.edu>
Date: Mon, 26 Mar 2018 07:41:24 -0600

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.

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.

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?

   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?

   c. Hence, do we need either option? Can we assume that the Intel compiler
      will have MKL and just use it?

   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?


...thanks!....dac


_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Mon Mar 26 2018 - 07:00:03 PDT
Custom Search