From: Giacomo Fiorin (giacomo.fiorin_at_gmail.com)
Date: Thu Nov 09 2017 - 16:12:41 CST
Thanks for posting this feedback. I would pay attention to whether there
are multiple versions of GCC installed, because in many supercomputers
multiple versions are installed simultaneously. Typically, the native
compiler for many server Linux operating systems is gcc 4.something, but
gcc 6 or later is also installed after the fact to support recent language
constructs.
Because we technically have to use one compiler (e.g. g++) to compile the
NAMD objects and *another* compiler (i.e. the charmc wrapper) to link them,
there is some risk involved.
Giacomo
On Thu, Nov 9, 2017 at 12:00 PM, Florian Blanc <blanc.flori_at_gmail.com>
wrote:
> 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>
> 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
>>> /na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fso
>>> ftware.intel.com%2Fen-us%2Farticles%2Fcdiag13378&data=02%7C0
>>> 1%7CJoshua.Vermaas%40nrel.gov%7C5e016e76178f45b3564b08d51be7
>>> 55db%7Ca0f29d7e28cd4f5484427885aee7c080%7C0%7C0%7C6364456027
>>> 55688587&sdata=DL2DER03K54%2ByvZLgT60RIznPNK1Jec%2FVJBs%2Bch
>>> wVJ8%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
>
>
>
-- 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
This archive was generated by hypermail 2.1.6 : Mon Dec 31 2018 - 23:20:42 CST