Compilation of 6.4.2

option, parallelism,...

Moderators: fgoudreault, mcote

Forum rules
Please have a look at ~abinit/doc/config/build-config.ac in the source package for detailed and up-to-date information about the configuration of Abinit 8 builds.
For a video explanation on how to build Abinit 7.x for Linux, please go to: http://www.youtube.com/watch?v=DppLQ-KQA68.
IMPORTANT: when an answer solves your problem, please check the little green V-like button on its upper-right corner to accept it.
Locked
JEJohns
Posts: 55
Joined: Sun May 02, 2010 5:30 pm

Compilation of 6.4.2

Post by JEJohns » Tue Oct 26, 2010 10:38 pm

Dear all,
I'm currently having trouble during the make portion of the abinit-6.4.1 installation. I have previously installed 6.2.2 and other abinit builds on this system. I will attempt to be as specific as possible to avoid wasting anyone's time. I am working on a 4 core Xenon processor machine using Suse10.1, Open Mpi 1.4.1, and the GCC compilers version 4.4.3. These are the same versions I compiled 6.2.2 with many months ago. Just to make sure that it isn't a path problem on my part I did rebuild 6.2.2 today as well.
For compiling...
I make a temporary build directory
cd /builddirectory
/somepath/abinit-6.4.1/configure --enable-mpi FC=mpif90 CXX=mpicxx CC=mpicc --enable-mpi-io
./make

I've attached both config.log files (6.4 & 6.2 each) and have included below the region where they differ. Below is a long series of errors that do not show up when I try to compile the 6.2.2 package
configure:24020: result: yes
configure:24026: checking whether the C++ compiler supports MPI
configure:24271: mpicxx -o conftest -g -O3 -mtune=native -march=native -funroll-loops -ffast-math conftest.cpp >&5
/tmp/ccMFqqlv.s: Assembler messages:
/tmp/ccMFqqlv.s:2147: Error: no such instruction: `pmovzxbw %xmm6,%xmm4'
/tmp/ccMFqqlv.s:2149: Error: no such instruction: `pmovzxwd %xmm4,%xmm5'
/tmp/ccMFqqlv.s:2152: Error: no such instruction: `pmovzxbw %xmm6,%xmm3'
/tmp/ccMFqqlv.s:2154: Error: no such instruction: `pmovzxwd %xmm3,%xmm1'
/tmp/ccMFqqlv.s:2155: Error: no such instruction: `pmovzxwd %xmm4,%xmm2'
/tmp/ccMFqqlv.s:2160: Error: no such instruction: `pmovzxwd %xmm3,%xmm0'
/tmp/ccMFqqlv.s:2174: Error: no such instruction: `pmovzxbw %xmm9,%xmm7'
/tmp/ccMFqqlv.s:2176: Error: no such instruction: `pmovzxwd %xmm7,%xmm8'
/tmp/ccMFqqlv.s:2177: Error: no such instruction: `pmovzxbw %xmm9,%xmm0'
/tmp/ccMFqqlv.s:2179: Error: no such instruction: `pmovzxwd %xmm0,%xmm5'
/tmp/ccMFqqlv.s:2182: Error: no such instruction: `pmovzxwd %xmm7,%xmm6'
/tmp/ccMFqqlv.s:2183: Error: no such instruction: `pmovzxwd %xmm0,%xmm2'
/tmp/ccMFqqlv.s:2191: Error: no such instruction: `pmovzxbw %xmm3,%xmm14'
/tmp/ccMFqqlv.s:2193: Error: no such instruction: `pmovzxwd %xmm14,%xmm15'


and it is during the make that it seems to fail, specifically during the linalg preq routine. I've attached a piped copy of the output of make during the make procedure, and below is a copy of the error messages that pop up during make.
drotmg.f:138.15:

GO TO IGO(120,150,180,210)
1
Warning: Deleted feature: Assigned GOTO statement at (1)
drotmg.f:144.72:

ASSIGN 120 TO IGO
1
Warning: Deleted feature: ASSIGN statement at (1)
drotmg.f:156.72:

ASSIGN 150 TO IGO
1
Warning: Deleted feature: ASSIGN statement at (1)
drotmg.f:169.72:

ASSIGN 180 TO IGO
1
Warning: Deleted feature: ASSIGN statement at (1)
drotmg.f:180.72:

ASSIGN 210 TO IGO
1
Warning: Deleted feature: ASSIGN statement at (1)
srotmg.f:140.15:

GO TO IGO(120,150,180,210)
1
Warning: Deleted feature: Assigned GOTO statement at (1)
srotmg.f:146.72:

ASSIGN 120 TO IGO
1
Warning: Deleted feature: ASSIGN statement at (1)
srotmg.f:158.72:

ASSIGN 150 TO IGO
1
Warning: Deleted feature: ASSIGN statement at (1)
srotmg.f:171.72:

ASSIGN 180 TO IGO
1
Warning: Deleted feature: ASSIGN statement at (1)
srotmg.f:182.72:

ASSIGN 210 TO IGO
1
Warning: Deleted feature: ASSIGN statement at (1)
/tmp/ccWvD4SX.s: Assembler messages:
/tmp/ccWvD4SX.s:196: Error: no such instruction: `pinsrd $0x1,%r10d,%xmm1'
/tmp/ccWvD4SX.s:200: Error: no such instruction: `pinsrd $0x1,%ebx,%xmm0'
make[5]: *** [cgttrf.o] Error 1
make[4]: *** [build-stamp] Error 2
make[3]: *** [package-ready] Error 2
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

Any help you could provide would sincerely be appreciate.
--James
Attachments
config.log
log file for 6.4.1
(120.41 KiB) Downloaded 444 times
config6-2.log
log file for 6.2.2
(108.22 KiB) Downloaded 381 times
make.log
(1.42 KiB) Downloaded 380 times

User avatar
Alain_Jacques
Posts: 279
Joined: Sat Aug 15, 2009 9:34 pm
Location: Université catholique de Louvain - Belgium

Re: Compilation of 6.4.2

Post by Alain_Jacques » Wed Oct 27, 2010 3:49 pm

Hello James,

I don't like too much to mix mpi with FC=, CC=, ... vars .So would you be so kind to test the configuration and compilation again with the following recipe.

Start with a clean /builddirectory. Edit a test.ac file with the following content (or convert it to a configure line by changing the _ with - )

Code: Select all

prefix=/usr/local
enable_64bit_flags="yes"
enable_mpi="yes"
enable_debug="no"
enable_fft="no"
enable_linalg="no"
with_mpi_prefix=/usr
enable_optim="aggressive"


Well enable_optim aggressive is maybe not too safe for the moment as you have compilations difficulties - maybe remove that line for the moment; it should be fine later. Change the prefix and mpi_prefix according to your system preferences (here mpif90 is expected in /usr/bin/mpif90). Invoke the configurator with

Code: Select all

/somepath/abinit/configure --with-config-file=./test.ac
Then if all went fine, go on with a "make" (or "make multi"), "cd tests" and "make tests_acc" (or "make tests_acc4").

Kind regards,

Alain

JEJohns
Posts: 55
Joined: Sun May 02, 2010 5:30 pm

Re: Compilation of 6.4.2

Post by JEJohns » Wed Oct 27, 2010 4:42 pm

Alain,
I made the test.ac file as you suggested, made a new build directory, and changed the prefix and mpi prefix to the appropriate directories. In the config file, it clearly has the flag enable_linalg="no", but the make still seems to dive into the prereqs/linalg directory and fails in there with the same message. Any other suggestions?
Any help is most appreciated,
James
Attachments
config2.log
(120.68 KiB) Downloaded 397 times
make_err2.log
(2.38 KiB) Downloaded 373 times
make_stdout2.log
(34.4 KiB) Downloaded 358 times

User avatar
Alain_Jacques
Posts: 279
Joined: Sat Aug 15, 2009 9:34 pm
Location: Université catholique de Louvain - Belgium

Re: Compilation of 6.4.2

Post by Alain_Jacques » Wed Oct 27, 2010 6:23 pm

For the explanation of the error codes. First of all, don't worry about the warnings - nothing deadly here.
Now for the errors pinsrd and pmovzxbw. Both are SSE4.1 processor instructions. The -mtune/-march="native" option ask the compiler to produce code specific to the processor in your system. It has recognized a "penryn" or Core i7 variant and pushed SSE4.1 enhanced capabilities. But apparently the backend assembler doesn't recognize them - looks like very outdated binutils.

Try to add enable_optim="safe" to the test.ac file; clean the builddirectory with a rm -rf * (don't nuke ypur test.ac file ... or your whole source tree) and redo the configure/make steps. If it fails, show me the last mpif90 invocation line - I would like to check that there is only -O2 and no -mtune/-march anymore. BTW I cannot look at the attached files - it says "not downloaded yet. Are you working with an Abinit distribution file or a CVS copy?

And yes, the enable_linalg=no was there by purpose to force the use of the internal lapack. Otherwise make may pick up some external libblas or liblapack that it finds suitable on your system.

Alain

User avatar
pouillon
Posts: 651
Joined: Wed Aug 19, 2009 10:08 am
Location: Spain
Contact:

Re: Compilation of 6.4.2

Post by pouillon » Wed Oct 27, 2010 7:08 pm

I agree with Alain: you have mismatch between GCC and your assembler.

Try setting FCFLAGS="-g -O3 -funroll-loops -ffast-math" in your test.ac and reconfigure Abinit. This should work.
Yann Pouillon
Simune Atomistics
Donostia-San Sebastián, Spain

User avatar
Alain_Jacques
Posts: 279
Joined: Sat Aug 15, 2009 9:34 pm
Location: Université catholique de Louvain - Belgium

Re: Compilation of 6.4.2

Post by Alain_Jacques » Wed Oct 27, 2010 7:42 pm

Hello Yann,

He'll loose the per-directory optimization flags by forcing an FCFLAG ... libxc will fail its tests with more than -O2 on gcc-4.4. Anyway, James please tell us if it works.

Alain

JEJohns
Posts: 55
Joined: Sun May 02, 2010 5:30 pm

Re: Compilation of 6.4.2

Post by JEJohns » Wed Oct 27, 2010 9:12 pm

I should be able to do it this evening (Central standard time, GMT-5). After the original test.ac file didn't work, I started a convergence test of ecutwfn using icutcoul=2 versus not using it, which looks like it should be finishing up in ~5 hours.
-James

JEJohns
Posts: 55
Joined: Sun May 02, 2010 5:30 pm

Re: Compilation of 6.4.2

Post by JEJohns » Thu Oct 28, 2010 12:36 am

the enable-optim="safe" option seems to have worked. Am I losing anything or any speed by using that flag, and should I still try to recompile with the FC flags suggested above?

loefaas
Posts: 11
Joined: Thu Jul 01, 2010 1:12 pm

Re: Compilation of 6.4.2

Post by loefaas » Thu Oct 28, 2010 11:40 am

Dear all,

I have also some problems with the compilation of abinit 6.4.1 using MPI. I don't know if anything have changed from 6.2.2 which I have compiled with out problems. I am using the suggested test.ac from above, and both configure and make works with out trouble. I am using OpenMPi 1.4.2 + Intel 10.1

But when running a PAW+GW calculation in MPI I get the following error in the start of the Sigma-calculation

Code: Select all

-P-0000  rkdss: will read 2004 states

 k       eigenvalues [eV]
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image              PC                Routine            Line        Source             
abinit             000000000105A307  Unknown               Unknown  Unknown
abinit             00000000010592CA  Unknown               Unknown  Unknown
abinit             0000000000AC9476  Unknown               Unknown  Unknown
abinit             0000000000503269  Unknown               Unknown  Unknown
abinit             000000000045C8F7  Unknown               Unknown  Unknown
abinit             000000000044BE55  Unknown               Unknown  Unknown
abinit             0000000000448162  Unknown               Unknown  Unknown
libc.so.6          000000392BA1D994  Unknown               Unknown  Unknown
abinit             0000000000448089  Unknown               Unknown  Unknown


The same input works with the serial version of abinit 6.4.1 and also with abinit 6.2.2 with MPI. I have attached the config.log also.
Attachments
config.log
(106.04 KiB) Downloaded 378 times
Last edited by loefaas on Thu Oct 28, 2010 1:33 pm, edited 1 time in total.

User avatar
Alain_Jacques
Posts: 279
Joined: Sat Aug 15, 2009 9:34 pm
Location: Université catholique de Louvain - Belgium

Re: Compilation of 6.4.2

Post by Alain_Jacques » Thu Oct 28, 2010 1:11 pm

James,

Well "-O2" optimization is less effective than "-O3" - that's for sure. Now the impact on your calculation is difficult to predict; it could be around 15% slowdown, maybe even less. You may try Yann's FCFLAGS suggestion but be sure to run the full testsuite afterwards (tests_acc - or even tests_acc4 - as you have a multicore CPU to pinpoint errors).
If you want to improve speed, I would suggest to investigate why the assembler rejects the gcc/gfortran compiler output. Did you install a recent compilers toolchain on an old Linux installation? If it is your case, install a new binutils package - they are quite simple to compile; install them in f.e. /usr/local/binutils, add the corresponding directory to $PATH and recompile Abinit in that environment with an aggressive enable_optim.
Another efficient speedup is to use advanced BLAS/LAPACK instead of the "generic" ones included in Abinit. Good candidates are MKL and GotoBLAS(+LAPACK). Same story by adding accelerated FFTW3 - actually MKL included FFT is quite performing.

Alain

User avatar
pouillon
Posts: 651
Joined: Wed Aug 19, 2009 10:08 am
Location: Spain
Contact:

Re: Compilation of 6.4.2

Post by pouillon » Thu Oct 28, 2010 5:25 pm

With this - as well as some similar problems recently encountered on the test farm - I've realized that there is a design flaw in the build system. I'll try to fix it for the upcoming 6.4.2.
Yann Pouillon
Simune Atomistics
Donostia-San Sebastián, Spain

JEJohns
Posts: 55
Joined: Sun May 02, 2010 5:30 pm

Re: Compilation of 6.4.2

Post by JEJohns » Thu Oct 28, 2010 9:04 pm

Thanks Yann & Alain for all the help. I'll try buliding new lapack /blas libraries, and see what the slowdown / speed up is. Now back to the grind of trying to get these 2d GW/icutcoul calculations to work. Thanks again for all the help :)

User avatar
pouillon
Posts: 651
Joined: Wed Aug 19, 2009 10:08 am
Location: Spain
Contact:

Re: Compilation of 6.4.2

Post by pouillon » Fri Oct 29, 2010 4:06 pm

You're welcome. :-)

The design flaw has now been fixed.
Yann Pouillon
Simune Atomistics
Donostia-San Sebastián, Spain

User avatar
Alain_Jacques
Posts: 279
Joined: Sat Aug 15, 2009 9:34 pm
Location: Université catholique de Louvain - Belgium

Re: Compilation of 6.4.2

Post by Alain_Jacques » Sat Nov 06, 2010 5:11 pm

IMHO fp-speculation=safe is not so safe even inherently dangerous; I would recommend =off i.e. stop and issue an error message when a floating point exception occurs.
I am puzzled about how this option popped in the makefiles. I assume you use a development branch. Do you see that option in your <root_of_abinit_source>/config/optim/fc_intel_default-optim.conf file?

Kind regards,

Alain

JEJohns
Posts: 55
Joined: Sun May 02, 2010 5:30 pm

Re: Compilation of 6.4.2

Post by JEJohns » Sat Nov 06, 2010 6:45 pm

Alain,
That option just popped up when I used the flag enable_optim="safe". When I turned off that flag, it compiled and built just fine on the Quest system. That's why I deleted the original post. Apparently though I should have deleted it faster, as you were lightening fast to respond! Sorry for the trouble
--James

Locked