DALTON 2016 on x86_64

Problems with Dalton installation? Find answers or ask for help here
Post Reply
RikaK
Posts: 9
Joined: 09 Jun 2014, 03:40
First name(s): Rika
Last name(s): Kobayashi
Affiliation: Australian National University
Country: Australia

DALTON 2016 on x86_64

Post by RikaK » 05 Jan 2016, 03:13

Hello world,
Re: "Many tests fail using Intel 2015. Therefore we currently do not recommend to compile Dalton 2016.0 using Intel 2015."
FWIW Dalton 2016 successfully built on our x86_64 system running CentOS release 6.7:
http://nci.org.au/systems-services/nati ... iguration/
using openmpi/1.8.8 intel-fc/16.0.1.150 intel-cc/16.0.1.150 intel-mkl/16.0.1.150 cmake/3.4.0
100% tests passed, 0 tests failed out of 457

This combination not so lucky on LSDALTON:
73% tests passed, 80 tests failed out of 292
(will follow that up separately).
Rika

arnfinn
Posts: 232
Joined: 28 Aug 2013, 08:02
First name(s): Arnfinn
Middle name(s): Hykkerud
Last name(s): Steindal
Location: UiT The Arctic University of Norway
Contact:

Re: DALTON 2016 on x86_64

Post by arnfinn » 05 Jan 2016, 15:22

Thank you very much for letting us know!

Concerning DALTON: AFAIK, there are several (CC) tests that fails when compiled with Intel 14.0.2. This is the newest Intel compiler I have access to, so I am not sure if it works with newer 14.0.X compilers (or 15.0.X compilers).

Update: It seems like one DALTON test is failing with Intel 15.0.2 (rsp_esr2).

taylor
Posts: 525
Joined: 15 Oct 2013, 05:37
First name(s): Peter
Middle name(s): Robert
Last name(s): Taylor
Affiliation: Tianjin University
Country: China

Re: DALTON 2016 on x86_64

Post by taylor » 05 Jan 2016, 18:43

It's perhaps not entirely surprising that LSDalton shows more failed tests than Dalton (although I admit I'm astounded that every test passes for the latter!). Dalton is almost entirely Fortran77: there's a bit of Fortran90 but not a lot, and so Dalton places only modest demands on the compiler. Most of the steps related to turning Fortran source into intermediate language for ultimate optimization and translation into machine instructions will be pretty pedestrian and similar to that in older compiler versions (the main problems, particularly in compiler versions 20xx.0, come from the Friday night post-pub "I've had a great idea about code optimization: here, hold my beer while I just tweak the compiler source"...). So setting aside major blunders, one would hope that the Dalton source is so old-school and simple-minded that a compiler should be able to handle it, absent such post-pub tweaks to the compiler...

LSDalton is much more recent, and much more sophisticated in its use of Fortran90 and later-version features. I would expect it to put a lot more demand on the compiler to do the job properly, a lot more demand on the compiler's ability/capability to optimize, and a lot more demand on the compiler to genuinely implement functionality as specified in the standard. So the fact that some tests fail is not a great surprise. As I said in another posting a year ago, and incorporating here some very valuable comment from Radovan Bast: if you turn off all optimization, build, and the code runs all tests, then your code fulfils the Fortran standard. It may not be good code, and it may still violate good practice that is not explicitly forbidden by the standard, but within the definitions of the standard it is compliant. If you now allow the compiler to do some/quite a bit/a lot/huge amounts of optimization and the code no longer works, then there is a problem with the compiler. Certainly you the programmer could have done things differently and perhaps avoided such problems, but the primary difficulty is with the compiler.

Best regards
Pete

RikaK
Posts: 9
Joined: 09 Jun 2014, 03:40
First name(s): Rika
Last name(s): Kobayashi
Affiliation: Australian National University
Country: Australia

Re: DALTON 2016 on x86_64

Post by RikaK » 05 Jan 2016, 23:36

>
> It's perhaps not entirely surprising that LSDalton shows more failed tests than Dalton (although I admit I'm astounded that every test passes for the latter!).
>
Yes, exactly. That was my main motivation for posting. And also because for an earlier Dalton build I found the note "Tested on CentOS 6.3, Intel 13.1.3, MKL 11.0.5, OpenMPI 1.6.3" which I always find very helpful - avoids searching for the Holy Grail of Compiler Version. I couldn't immediately find an equivalent note for this release, just the intel15 warning so thought I'd provide my own.
>
The LSDalton comment was more of an aside, hence saying I would follow that up separately, mainly because we've just had Patrick visiting us working with his LSDalton coupled cluster development copy on our machines and that was the Intel version decided on. Patrick is working at O0 but if we want to go production ... hence the warning.

tkjaer
Posts: 300
Joined: 27 Aug 2013, 20:35
First name(s): Thomas
Last name(s): Kjaergaard

Re: DALTON 2016 on x86_64

Post by tkjaer » 06 Jan 2016, 10:35

Concerning the LSDalton test cases

If the failing testcases are the ones with "decmp2", "decccsd", "decrimp2", "fullccsd" etc. Then this could be because the DEC code, compiled with MPI, expects atleast 2 MPI processors for proper testing.

did you export the DALTON_NUM_MPI_PROCS enviromental variable to something bigger than 1 ? Or set the LSDALTON_LAUNCHER to something like "mpirun -np 3" ?

But yes the LSDalton code are using an increasing amount of features from Fortran90, Fortran2003, and beyond.

We do try to write code that the compile can translate, but the compiles are not very stable with respect to these features.

RikaK
Posts: 9
Joined: 09 Jun 2014, 03:40
First name(s): Rika
Last name(s): Kobayashi
Affiliation: Australian National University
Country: Australia

Re: DALTON 2016 on x86_64

Post by RikaK » 06 Jan 2016, 11:19

tkjaer wrote:Concerning the LSDalton test cases

If the failing testcases are the ones with "decmp2", "decccsd", "decrimp2", "fullccsd" etc. Then this could be because the DEC code, compiled with MPI, expects at least 2 MPI processors for proper testing.

did you export the DALTON_NUM_MPI_PROCS enviromental variable to something bigger than 1 ? Or set the LSDALTON_LAUNCHER to something like "mpirun -np 3" ?
I haven't looked into this in depth (it really wasn't intended to be more than a remark) but I had the test suite on "setenv DALTON_NUM_MPI_PROCS 4" and a job I had lying around on 32 processors (to test across nodes). Didn't really look much into the failures except to note they were a mixture of segfaults and numerical discrepancies (factors of 2 or 3 in some cases which made me think it might be a race condition).
And yes a lot of the failures are DEC:
$ grep "(Failed)" make_tests.log | grep dectests | wc
41 164 1630

tkjaer
Posts: 300
Joined: 27 Aug 2013, 20:35
First name(s): Thomas
Last name(s): Kjaergaard

Re: DALTON 2016 on x86_64

Post by tkjaer » 06 Jan 2016, 11:21

OK thanks.

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests