basis set error

[xjamesmao]

Hello,
I just tried tests (ctest -j8) after compiling dalton2013. However, all tests with basis set name with * (such as 6-31G*, 6-311g**, ...) failed with error message such as: Basis "6-31G**" does not exist. It seems the program cannot translate * to d,p,..correctly. I am wondering, what can be the reason for this error during compilation?
Thanks!
jm

[bast]

dear James,
what operating system or distribution are you on?
best wishes,
radovan

[hjaaj]

Hello,
I just tried tests (ctest -j8) after compiling dalton2013. However, all tests with basis set name with * (such as 6-31G*, 6-311g**, ...) failed with error message such as: Basis "6-31G**" does not exist. It seems the program cannot translate * to d,p,..correctly. I am wondering, what can be the reason for this error during compilation?
Thanks!
jm

As far as I know, this is only a problem on native Windows, because '*' is not valid in Windows file names. I have successfully installed Dalton with Windows Cygwin, which silently internally changes the '*' to something else so the files can be saved in the windows file system. We have no plans of making a native Windows version, because Windows Cygwin works fine.

-- Hans Jørgen.

[xjamesmao]

Thanks for all kind help~ Problem solved,

[xjamesmao]

I thought it was done but not...

All tests passed! After that I "make install". However, the installed dalton.x is giving the error code:
" error while loading shared libraries: libmkl_gf_lp64.so: cannot open shared object file: No such file or directory"

The "make" version dalton.x in /build works without the error.

The "prefix" was assigned when I ./setup.

libmkl_gf_lp64.so is located in the $MATH_ROOT.

What did I do wrong for the "make install"?

Many thanks!

[taylor]

You have already been asked what system you are building on and what your "setup" is. Hans Joergen deduced (as did I, but thanks to timezones he posted first!) that at the very least you had unpacked the source or manipulated it on a Windows system, where the use of a '*' in a filename is unacceptable. But otherwise you are simply posting error messages from the Intel compiler stack.

The Dalton developers are an extraordinarily able and talented group of people, but to the best of my knowledge none of us is telepathic... Please tell us exactly what platform you are building the code on, operating system and compiler versions, etc., and what setup parameters you chose. It is very difficult to help anyone without knowing their environment!

Best regards
Pete

[xjamesmao]

Hi Pete,

My sincerely apology to all. I should post these information first:

x86_64 GNU/Linux openSUSE

what I exactly did:

export MATH_ROOT='/opt/intel/mkl'
./setup --mpi --prefix=/home/
cd build
make -j8
export DALTON_NUM_MPI_PROCS=8
ctest
make install

I do not have intel compiler installed.

Thank you again.

jm

[taylor]

Thanks for this. So you are using gfortran as the compiler and then linking to the MKL library, given that you don't have the Intel compiler? Hmmm. I know this is supposed to work, after the gnu compiler people adopted the Intel standards for binaries and address lists. Nevertheless, I am still a bit nervous about how all this plays together (and I can tell you that there is a base-level incompatibility between routines in OpenMPI compiled with gnu and compiled with Intel, and they do not interoperate properly, despite the OpenMPI authors' claims to the contrary, although that is not the problem here).

Given that you don't have the Intel compiler, have you tried not using MKL? Unless you have ATLAS (or something similar) the performance will be crap, but at least it would tell you whether the problem is some gfortran/MKL incompatibility. I do not use gfortran on Linux because we have the Intel compiler suite, so I've never tried what you're doing, although I guess a number of other people have (and they may then have a better response than mine). But as I say, to eliminate (or perhaps identify) some gnu/Intel incompatibility here you could try just building with gfortran and not using MKL, and at least see whether the test suite runs.

Best regards
Pete

[bast]

it is surprising to me that the "make install"ed version
behaves differently. "make install" basically just copies
it. is it possible that you run them in different terminals
which possibly have different environment settings?
i am thinking here about the LD_LIBRARY_PATH which
should contain your MKL libs.
radovan

[taylor]

Ha! A dimension I hadn't seen: very good point, Radovan! There should be no difference, as you say: if the dynamic library is found in one case but not the other, it must be a difference in the runtime environment. This of course is what "module" was invented for --- while it's great for letting geeks flip between different software versions, its biggest benefit is setting up a consistent environment.

Best regards
Pete

[xjamesmao]

Thank you so much Radovan! Yes it is the problem of LD_LIBRARY_PATH. I added my MKL libs path to it and it works fine now.

Thank you very much as well Peter. I learned from your kind reply. Will try a different build for a different math library to compare.

Thanks again.