Re: Error on Settle.C when compiling NAMD with Intel Compiler

From: Florian Blanc (blanc.flori_at_gmail.com)
Date: Thu Nov 09 2017 - 11:00:09 CST

Dear Giacomo,

Thanks a lot for your suggestions. We managed to compile the NAMD build
using GCC (still not ICC though, but it is not critical as the GCC build
has good performances).

Something odd happened during the first attempt to compile with gcc.
When we compiled charm++, we explicitly declared the compilers:

  ./build charm++ verbs-linux-x86_64 gcc gfortran -j16 --with-production

Doing so, charmrun compiles, but then when compiling NAMD the same
"undefined references" error pop up at the end of the compilation.
Finally, we found out that removing the explicit declaration of the
compilers to build charmrun ( ./build charm++ verbs-linux-x86_64 -j16
--with-production) also worked fine and allowed us to compile NAMD at
the end. I do not know whether this is the intended/expected behavior,
but we lost enough time trying to solve this that I felt it was worth
sharing the solution.

All the best,

Florian

On 10/26/2017 08:56 PM, Giacomo Fiorin wrote:
> Hi Florian, since you refer to having compiled charm++ as well, did
> you use the same Intel version for both Charm++ and NAMD?  Mixing
> versions might work, but it's certainly safer not to.
>
> The error says that it's not able to locate the function
> __builtin_ia32_loadupd, which is a compiler builtin.  Without knowing
> more, this points to a mismatch between the generated code and the
> compiler that is supposed to link it (which is just wrapped around by
> charmc).
>
> Try also GCC, if you can.  You may lose a bit on those sections of the
> code that haven't been flagged explicitly for vectorization, but the
> most compute-intensive parts will be still taken care of.
>
> Giacomo
>
> On Thu, Oct 26, 2017 at 1:34 PM, Florian Blanc <blanc.flori_at_gmail.com
> <mailto:blanc.flori_at_gmail.com>> wrote:
>
> Dear Victor and Josh,
>
> Thank you for your replies. As per Victor's advice I commented out
> the "simd assert" line in the Settle.C file. As expected, the
> "loop was not vectorized" error does not appear anymore during
> compilation. However, compilation is still unsuccessful as I get a
> "Fatal Error by charmc" at the very last stage of NAMD
> compilation. Before this, several "undefined reference to
> `__builtin_ia32_loadupd' " (or similar) are printed, referring to
> Settle.C and also to ComputeNonbondedTabEnergies.C,
> ComputeNonbondedPProf.C, ComputeNonbondedLES.C,
> ComputeNonbondedTI.C, ComputeNonbondedGo.C, ComputeNonbondedFEP.C,
> ComputeNonbondedStd.C and ComputeMsm.C.
>
> Although it is not a KNL system, I also tried several versions of
> the compiler as suggested by Josh (2016 and 2014) but got the same
> error. I have no idea what's going on. I don't know if the problem
> can come from an imperfect compilation of charmrun, but if so note
> that the compilation and run of the "megatest" program for
> charmrun were successful. Any leads ?
>
> Thanks again,
>
> Florian
>
>
> On 10/25/2017 11:01 PM, Vermaas, Joshua wrote:
>
> This wouldn't happen to be a KNL system, would it? Here is
> some text from the release notes that went along with 2.12:
>
> There appears to be a bug in the Intel 17.0 compiler that
> breaks the
> non-KNL-optimized NAMD kernels (used for alchemical free
> energy, etc.)
> on KNL.  Therefore the Intel 16.0 compilers are recommended on
> KNL.
>
> -Josh
>
> On 10/25/2017 02:31 PM, Florian Blanc wrote:
>
> Dear NAMD users,
>
> I am trying to compile the most recent (nightly of 25th of
> October) version of NAMD on the French supercomputer Curie
> using the Intel Compiler version 17.0.2; I want a
> verbs-linux-x86_64 build. Although the compilation of charm++
> works fine, the following error interrupts the compilation of
> NAMD:
>
> src/Settle.C(332): (col. 3) error #13378: loop was not
> vectorized with "simd assert"
>
> compilation aborted for src/Settle.C (code 1)
>
>
> I find only one reference to this error on the Internet, on
> the Intel Forum:
>
> https://software.intel.com/en-us/articles/cdiag13378
> <https://software.intel.com/en-us/articles/cdiag13378><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsoftware.intel.com%2Fen-us%2Farticles%2Fcdiag13378&data=02%7C01%7CJoshua.Vermaas%40nrel.gov%7C5e016e76178f45b3564b08d51be755db%7Ca0f29d7e28cd4f5484427885aee7c080%7C0%7C0%7C636445602755688587&sdata=DL2DER03K54%2ByvZLgT60RIznPNK1Jec%2FVJBs%2BchwVJ8%3D&reserved=0
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsoftware.intel.com%2Fen-us%2Farticles%2Fcdiag13378&data=02%7C01%7CJoshua.Vermaas%40nrel.gov%7C5e016e76178f45b3564b08d51be755db%7Ca0f29d7e28cd4f5484427885aee7c080%7C0%7C0%7C636445602755688587&sdata=DL2DER03K54%2ByvZLgT60RIznPNK1Jec%2FVJBs%2BchwVJ8%3D&reserved=0>>
>
> but no further information is given. Does anyone know this
> problem and a way to solve it? I can provide more details on
> the architecture and/or the compilation options I used if it
> is relevant.
>
> Thank you very much in advance,
>
> Florian Blanc
>
>
>
>
>
>
> --
> Giacomo Fiorin
> Associate Professor of Research, Temple University, Philadelphia, PA
> Contractor, National Institutes of Health, Bethesda, MD
> http://goo.gl/Q3TBQU
> https://github.com/giacomofiorin <https://github.com/giacomofiorin>

This archive was generated by hypermail 2.1.6 : Sun Dec 31 2017 - 23:21:46 CST