make and make test

[lma]

Hi there,

1st - I have installed a OpenSUSE 13.2-Gnome-Live-x86_64, but i am not very familiar with, i.e., i'm a newbie with linux...
2nd - I also installed with zypper the gcc, mpi, liblapack, lapack, blas, libblas3
3rd - I followed (i guess!) all the steps in the http://dalton-installation.readthedocs. ... tml#basics

4th - I run the make command and i get the result below:
mg@linux:~/dalton/DALTON-Source/build> make
[ 0%] Built target check_external_timestamp_qfitlib
[ 0%] Built target check_external_timestamp_gen1int
[ 1%] Built target gen1int
[ 2%] Built target gen1int_interface
[ 3%] Built target qfitlib
[ 3%] Built target generate_binary_info
[ 3%] Built target check_external_timestamp_pelib
[ 4%] Built target pelib
Scanning dependencies of target dalton
[ 4%] Building Fortran object CMakeFiles/dalton.dir/binary_info.F90.o
Linking Fortran static library lib/libdalton.a
[ 99%] Built target dalton
Linking Fortran executable dalton.x
[ 99%] Built target dalton.x
[ 99%] Built target peter_utils_blocks
[ 99%] Built target tools/FChk2HES
[ 99%] Built target tools/aces2dalton
[ 99%] Built target tools/distances
[ 99%] Built target tools/labread
[100%] Built target tools/xyz2dalton

5th - When I run the command make test, i got all the tests failed:

mg@linux:~/dalton/DALTON-Source/build> make test
Running tests...
Test project /home/mg/dalton/DALTON-Source/build
Start 1: dft_ac_grac
1/457 Test #1: dft_ac_grac ......................***Failed 0.08 sec
Start 2: dft_b3lyp_cart
2/457 Test #2: dft_b3lyp_cart ...................***Failed 0.11 sec
.
.
.
456/457 Test #456: molden ...........................***Failed 0.05 sec
Start 457: single_input
457/457 Test #457: single_input .....................***Failed 0.09 sec

0% tests passed, 456 tests failed out of 457

>>>> and the final output of the command was:

Errors while running CTest
Makefile:117: recipe for target 'test' failed
make: *** [test] Error 8

---------------------------------------------------------------------------------------

1st Question:
>> Can anyone tell me what i'm doing wrong?

2nd Question:
>> I edit the .bashrc file with the following export commands, save it and make a source command:
#Dalton
export DALTON_TMPDIR=/home/mg/dalton/DALTON-Source/DALTON/scratch/
export DALTON_LAUNCHER="mpirun -np 4"
>> Do i need more commands in the bashrc?

3rd Question:
>> How do I make the dalton command be available in all directorys? like a path in MS-DOS?

Thank you,

Luis

[taylor]

All tests failing most likely indicates a problem with your setup. What more detailed information is in the logfile from the "make test" step? It will be difficult to help without more information.

A couple of comments, however. You are building (it would seem) and running with MPI. I am not asserting that this is the cause of problems, but it is a complicating factor. You should I think try to build the simplest (that is, serial rather than parallel) version of the code first. Second, you are using as a scratch directory something under your home filesystem. This is unwise. If possible you should make a dedicated separate /scratch directory (or similar name) and ideally on a different physical disk. This reduces performance penalties if you are trying to run Dalton and at the same time use your machine for something else, and it avoids issues of parts of your home filesystem being removed as jobs terminate.

Making dalton available "across directories" can be done by adding the directory containing the dalton script to your PATH environment variable. However, I question whether this is a good idea. Most likely at some point you will build a different version of the code (say, using a different BLAS library or something --- I'm not sure about OpenSUSE but certainly with some other distros the BLAS/LAPACK is rarely optimum and also the version of OpenMPI is often not the most stable version) and then you have to remember to change PATH and what order directories should be specified, etc. I find it safer to specify the explicit pathname in my runscripts so that I can see which version I'm getting.

Best regards
Pete

[xiongyan21]

On my MAC, in order to let the last two commands effective and the tests go smoothly, a restart should be performed, which may be nonfeasible for your case, a workstation cluster, or a supercomputer. Thus, Dr. Taylor's comment is enlightening.

[taylor]

A change to one's bash environment (or any other UNIX shell I'm familiar with) should not require a restart. One has to "source" the new environment with, e.g.,

Code: Select all

. .bashrc

I am a Mac user for my "work", although not for running calculations, and I have never had a problem with this. I can see that a restart would work, but it seems drastic!

Best regards
Pete

[lma]

All tests failing most likely indicates a problem with your setup. What more detailed information is in the logfile from the "make test" step? It will be difficult to help without more information.

A couple of comments, however. You are building (it would seem) and running with MPI. I am not asserting that this is the cause of problems, but it is a complicating factor. You should I think try to build the simplest (that is, serial rather than parallel) version of the code first. Second, you are using as a scratch directory something under your home filesystem. This is unwise. If possible you should make a dedicated separate /scratch directory (or similar name) and ideally on a different physical disk. This reduces performance penalties if you are trying to run Dalton and at the same time use your machine for something else, and it avoids issues of parts of your home filesystem being removed as jobs terminate.

>> OK!
>> a) I will rmdir the build directory
>> b) ./setup --fc=gfortran --cc=gcc --cxx=g++ (this is the correct installation command to run dalton with sequentional compilation, right?)
>> c) This machine is only to run Gaussian09 and Dalton, not simultaneously, so i keep my scratch directory under my /home. (the main problem to keep it under my /home is just performance, correct?)
>> d) Which .logs should I send to the forum, to give the much possible information about my "new" installation?


Making dalton available "across directories" can be done by adding the directory containing the dalton script to your PATH environment variable. However, I question whether this is a good idea. Most likely at some point you will build a different version of the code (say, using a different BLAS library or something --- I'm not sure about OpenSUSE but certainly with some other distros the BLAS/LAPACK is rarely optimum and also the version of OpenMPI is often not the most stable version) and then you have to remember to change PATH and what order directories should be specified, etc. I find it safer to specify the explicit pathname in my runscripts so that I can see which version I'm getting.
>> OK! I will not make dalton available across directories.
>> About the BLAS/LAPACK information... i'm sorry, but i didn't follow...

Thank you very much for all your patience,

Luis


Best regards
Pete

[taylor]

My point about BLAS/LAPACK etc, is that very often these are neither the latest version, nor are they optimized for a particular architecture (see for example my posting about Dalton on Raspberry Pi where the installed ATLAS is a pathetic fraction of what the chip is capable of, because the build version is for an earlier generation of the hardware). For people at academic institutions the best solution for mathematical libraries is to download and use (free!) the Intel MKL library, at least for machines that use any version of the "x86_64" architecture, which means anything from Intel or AMD based on their standard laptop/desktop/server chipset. The MKL library is compiler-agnostic, if you don't have the Intel compilers you can still link against the library after compiling with gfortran/gcc. Well, at least this is what people tell me, I admit I don't actually do this myself... The MKL library that one pays for comes with support also for Intel's Xeon Phi, but I have not explored whether this is so for the free version because the machines I have the free version on do not have Phi's, and conversely the machines I can access that do have Phi's have full Intel licences.

In general I would make the following points. First, if you are using a fairly standard distro, compare the version numbers of compilers (like gfortran and gcc) and libraries (like ATLAS) against the current "release number" for the original software sources. Second, do not assume that the current release number is the "best" version! But... if the distro version of a compiler is very different from the current version (or the same for versions of a library) there is some reason for concern. It is a good rule of thumb to never go with version X.0 of anything, nor with the first incarnation of even Intel's compilers, like when Composer 2016 is released. But if your distro has (say) gfortran version 4.6.2 and the GNU compiler website says the current version is gfortran 5.3.1, well, there might be a bit of a problem there and one should think about updating. Similarly, for Raspberry Pi the ATLAS version as distributed is (as for many distros) something like 3.6.0. The current ATLAS version is actually 3.10.2, which is why most "standard" precompiled ATLAS installations give you crap performance, because they were likely built on single-core nodes with no chipset-specific optimization.

Best regards
Pete

[lma]

My point about BLAS/LAPACK etc, is that very often these are neither the latest version, nor are they optimized for a particular architecture (see for example my posting about Dalton on Raspberry Pi where the installed ATLAS is a pathetic fraction of what the chip is capable of, because the build version is for an earlier generation of the hardware). For people at academic institutions the best solution for mathematical libraries is to download and use (free!) the Intel MKL library, at least for machines that use any version of the "x86_64" architecture, which means anything from Intel or AMD based on their standard laptop/desktop/server chipset. The MKL library is compiler-agnostic, if you don't have the Intel compilers you can still link against the library after compiling with gfortran/gcc. Well, at least this is what people tell me, I admit I don't actually do this myself... The MKL library that one pays for comes with support also for Intel's Xeon Phi, but I have not explored whether this is so for the free version because the machines I have the free version on do not have Phi's, and conversely the machines I can access that do have Phi's have full Intel licences.

In general I would make the following points. First, if you are using a fairly standard distro, compare the version numbers of compilers (like gfortran and gcc) and libraries (like ATLAS) against the current "release number" for the original software sources. Second, do not assume that the current release number is the "best" version! But... if the distro version of a compiler is very different from the current version (or the same for versions of a library) there is some reason for concern. It is a good rule of thumb to never go with version X.0 of anything, nor with the first incarnation of even Intel's compilers, like when Composer 2016 is released. But if your distro has (say) gfortran version 4.6.2 and the GNU compiler website says the current version is gfortran 5.3.1, well, there might be a bit of a problem there and one should think about updating. Similarly, for Raspberry Pi the ATLAS version as distributed is (as for many distros) something like 3.6.0. The current ATLAS version is actually 3.10.2, which is why most "standard" precompiled ATLAS installations give you crap performance, because they were likely built on single-core nodes with no chipset-specific optimization.

Best regards
Pete

Hello Pete,

First of all, thank you very much for your detailed explanation about the packages.

Second, i will reinstall in a few minutes Dalton with "sequentional compilation" and i will post here the result, and also the version of the packages that i'm using.

Thank you very much and best regards,

Luis

[lma]

Dear Pete,

>>I execute some commands to check the linux version that i'm using:
mg@linux:~> uname -a
Linux linux.site 3.16.6-2-desktop #1 SMP PREEMPT Mon Oct 20 13:47:22 UTC 2014 (feb42ea) x86_64 x86_64 x86_64 GNU/Linux
mg@linux:~> uname -r
3.16.6-2-desktop
mg@linux:~> cat /etc/issue
Welcome to openSUSE 13.2 "Harlequin" - Kernel \r (\l).

>>The packages and versions that i'm using are:
liblapack3-3.5.0-4.1.3.x86_64
gcc-4.8-7.1.2.x86_64
blas-devel-3.5.0-4.1.3.x86_64
libblas3-3.5.0-4.1.3.x86_64
libatlas3-3.10.1-7.1.5.x86_64

>>I remove the build directory and executed three commands:
1st >> ./setup --fc=gfortran --cc=gcc --cxx=g++; **
2nd >> mg@linux:~/dalton/DALTON-Source/build> make **
3rd >> mg@linux:~/dalton/DALTON-Source/build> make test ** (451 tests that failed... )
** (please check the attached file to see output of the executed commands )

>>Can you please tell me:
a) Which version of Linux you have or recommend?
b) The packages that will work with the Linux version of a) ?

Thank you very much... and please help me...

[taylor]

I think you make some progress here because your "make test" output indicates some tests have passed! I am still of the opinion that the problem is more likely related to how you are running the code than with your setup (see below). In the meantime, when I have failed tests, they each produce a directory under the "build" directory, with a name like "test_something_something" and this directory in turn contains various files from the failed test including a "log" file that should have messages that give some pointer to the cause of the failure. Do you get such directories and files when you run the tests? And if so, do they not give some sort of clue as to the problem?

Your system setup seems a little old but I cannot see anything that would cause problems. We (the Dalton mob) hesitate to tell people "you need such-and-such a version of Linux etc." because Linux is such a moving target, and so are the compilers. For what it's worth my main experience is with Red Hat-derived systems: at home we run CentOS 6 as our production system although we keep an eye on CentOS 7, and we use virtual machines (VM) to further keep an eye on other distros. Our OpenSUSE test VM is "Leap 42", in typical computer science fashion (look at Mozilla/Firefox) the developers have invented a completely different, new, numbering system so I have no idea how this connects to your version 13.3. It is version 4 of the kernel, and has version 5.x of the compilers, but I emphasize I do not believe this is the source of your problems. On CentOS 6 all of our software versions, including the kernel itself, are older than your OpenSUSE versions (although we use the MKL libraries) and things work fine.

Please look to see if you have any log files from the failed tests, and maybe post a couple?

Best regards
Pete

[bast]

Please have a look at build/Testing/Temporary/LastTest.log and search for "failed". I suspect all tests fail for the same reason. Please post here the error message.

[taylor]

Thanks, Radovan, I knew there was a particular file to look at it, but I blush to admit I couldn't remember the name, and on a quick look at a recent build I couldn't find it.

But note that it's interesting that while the original build failed everything, this user's new simplified build actually passes some tests. So I think the original poster is getting closer to a solution.

Best regards
Pete

[lyzhao]

Dear lma,
which version are your python?
maybe you should update the python.

Lan

[taylor]

I think at this point the best thing would be to let the original poster come back to us with any logs that show why the tests fail, rather than changing the software stack. Note that I'm not saying that the software shouldn't be updated: I'm just trying to avoid changing multiple variables at once.

Best regards
Pete

[lma]

Dear Pete and Rodovan,

Thanks for your time answering me, and please check the attached which i had to compress to upload: LastTest.log.tar.gz

I checked that the error written below appears a lot of times:
Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation.

Once again, thank you very much and I will be waiting for your expert advices to solve my problem.

Best regards,

Luis

[taylor]

One should not be misled by the SIGFPE error: this is generated by the Fortran "CALL ABORT" that is used within Dalton to terminate the program when an error condition of some sort is recognized. If I look at the first part of your posted file, I see lots of I/O errors. The very first test fails because it cannot open a file. Later tests fail because they cannot read files, or they cannot find labels on files, or they read past the end-of-file. Are you certain your "job", that is, the "Make test" has the necessary permissions to create and remove files in the desired scratch directory? Are you sure you do not have old, failed test directories present (this will confuse the program because if there are old files there the program will think this is some sort of restart run, which it should not be).

Some of your tests say "mpirun" exited --- if this is your sequential (i.e., non-MPI) build why are you invoking mpirun?

Best regards
Pete

[lma]

Ok!
a) I will delete the scratch directory and create a new one.
b) I will check my user permissions to run the make test

After that i will send the "new" .log file.

Thanks,

Luis

[bast]

To me the error looks like you are testing a sequential binary launched with mpirun
(probably you have incorrectly exported DALTON_LAUNCHER). It looks like several
sequential jobs are launched in parallel and they step on each other's toes and one
process deletes/overwrites a file and the other processes get confused.

[taylor]

Very acute observation, Radovan, I did not put 2 + 2 together but I can see that this is a very likely source of the problem: an attempt to run parallel tests that are then stepping on each other.

Luis, please make sure that you test your non-parallel build with only sequential commands. A sequential build/test should not be using mpirun at all, and certainly not with the number of processes set to other than one.

I think if you can verify your sequential build is OK, you (possibly with some more input from forum posters) will be able subsequently to get a parallel version going. But it is imperative to have the simple, sequential, baseline version running first.

Best regards
Pete

[lma]

Very acute observation, Radovan, I did not put 2 + 2 together but I can see that this is a very likely source of the problem: an attempt to run parallel tests that are then stepping on each other.

Luis, please make sure that you test your non-parallel build with only sequential commands. A sequential build/test should not be using mpirun at all, and certainly not with the number of processes set to other than one.

I think if you can verify your sequential build is OK, you (possibly with some more input from forum posters) will be able subsequently to get a parallel version going. But it is imperative to have the simple, sequential, baseline version running first.

Best regards
Pete

Dear Pete and Radovan,

Thank you for your suggestions. I didn't have the time yet to test it... Probably I will have the time only on Wednesday, but after the test I will keep you informed.

Best regards,

Luis

[lma]

Dear Pete and Radovan,

Thank you very much for you help, you were right when you mentioned the "mpirun", because i forgot to comment the following line in the .bashrc:
export DALTON_LAUNCHER="mpirun -np 4"

I had place a # in that bashrc line and executed the command make test, i only had 1 failed test:
>>100:prop_newtramcscf

Now... i need some help how to calculate the 2PA and the 1st Hyperpolarizability... Should I post a new topic in a different root?

Thank you very very very much!

Luis

[taylor]

So what sort of 2PA and hyperpolarizability calculation do you want to run that is not documented in the manual, and/or given as an example in the test suite? It is a bit difficult (not being telepathic, as I have observed more than once on this forum not only about myself but about all the other Dalton developers...) to know what people are asking and especially to know what is wrong with the existing documentation? This is not being defensive: we really want to know what we can do to improve the documentation but it is difficult to understand what the deficiencies are unless people are more specific about how what they want to do is not already described in the manual and in the test suite? There are certainly test jobs as examples that do 2PA and hyperpolarizabilities, so what is missing?

Best regards
Pete

[bast]

dear Luis,
it's good that you got it debugged.
And please open a new thread for a new problem.
This is because when 2PA experts
see the subject "make and make test" they may click "delete"
and vice versa.
thank you,
radovan

[lma]

So what sort of 2PA and hyperpolarizability calculation do you want to run that is not documented in the manual, and/or given as an example in the test suite? It is a bit difficult (not being telepathic, as I have observed more than once on this forum not only about myself but about all the other Dalton developers...) to know what people are asking and especially to know what is wrong with the existing documentation? This is not being defensive: we really want to know what we can do to improve the documentation but it is difficult to understand what the deficiencies are unless people are more specific about how what they want to do is not already described in the manual and in the test suite? There are certainly test jobs as examples that do 2PA and hyperpolarizabilities, so what is missing?

Best regards
Pete

Dear Pete,

Probably I didn't expressed myself in the correct manner, about the 2PA and 1st Hyper, I am very sorry for that.

I was trying to say that I am going to use Dalton for 2PA and 1st Hyper calculations, and of course, that i will study the manual, search for examples, but probably i will need some help! And if that it will be the case, the best solution was to open a new topic, right?

I want, again, to thank you for all the assistance in the installation and I want to assure you that i will try to run that calculations by myself. If I have any question, I will try to provide all the information that you need to assist me, but please, accept my apologies in advance in the case that i couldn't give you all the information to solve my future problem/question.

Best,

Luis

[lma]

dear Luis,
it's good that you got it debugged.
And please open a new thread for a new problem.
This is because when 2PA experts
see the subject "make and make test" they may click "delete"
and vice versa.
thank you,
radovan

Dear Radovan,

Thank you for all the support.

I will study first the Dalton syntax and methods, and if I will have any question I will open a new topic.

Thank you very much,

Luis