× If you run into troubles, it is always a good habit to report the following information:
  • the way build.mrcc was invoked
  • the output of build.mrcc
  • compiler version (for example: ifort -V, gfortran -v)
  • blas/lapack versions
  • as well as gcc and glibc versions

as well as the value of the relevant environmental variables, such OMP_NUM_THREADS, etc.

This information helps us a lot when figuring out what is going on with your compilation :)

MRCC with GNU + OpenMPI + PCM + XC

3 years 2 months ago #945 by phillipseeber
Dear Peter,

in principle this solution is available to everyone and i would love to see that it is also helpful to others. In principle the idea of Nix is to have deterministic environments, that always work on the target as they must be independent from distribution packages/libraries. In the end i hope to be able to get rid of the hazzle of environment modules on our cluster and at the same time have an easy solution to install the software also on a local workstation without teaching the whole group how to compile e.g. OpenMolcas from scratch.
We also have programs like Pysisyphus , that wraps QC software to perform tasks and that heavily relies on sane installations of those packages. Nix provides nice tools to integrate all the stuff and simplify wrappers and configuration files for such programs.
If you are interested, i have tried to describe in the readme of my nix repo how to use it. So far it seems to work on our Debian, OpenSuse and CentOS systems without trouble.
Using programs like Gaussian, ORCA, MRCC, etc just requires the user to obtain the license and tarballs themselves. Nix is only providing an installer.

Regarding the permission problem, i have some idea what is going on there:
The problem is indeed in this part, starting with the "do" loop in line 8306 of integ.f, where you loop over the atoms in the molecule, i guess.
In this loop for every unique element the density is generated by performing an atomic calculation, which copies the basis of the element to "mrccjunk/" (lines 8526 and 8529-8530), correct?
Now this works fine for the first element in a calculation and without any problems for inputs with just one element. For example, the MINP_3He_cc-pVTZ-RPAX2 test runs fine, as it only has a single element. MINP_Benzene2+_cc-pVDZ_DF-ROHF crashes as it has two elements. C is first in the input and the density for it is just generated without problems. When reaching the hydrogens, MRCC crashes with the error from the last post. Now in "mrccjunk/" there is the following:
insgesamt 916K
drwxrwxrwx 1 phillip phillip  306 Jul  2 11:50 .
drwxr-xr-x 1 phillip phillip  162 Jul  2 11:50 ..
-rw-rw-rw- 1 phillip phillip   78 Jul  2 11:50 COORD.xyz
-rw-rw-rw- 1 phillip phillip    0 Jul  2 11:50 DAO
-rw-rw-rw- 1 phillip phillip   38 Jul  2 11:50 EXIT
-rw-rw-rw- 1 phillip phillip 1,2K Jul  2 11:50 FOCK
-rw-rw-rw- 1 phillip phillip  240 Jul  2 11:50 fort.11
-rw-rw-rw- 1 phillip phillip  127 Jul  2 11:50 fort.55
-r--r--r-- 1 phillip phillip 331K Jul  2 11:50 GENBAS
-rw-rw-rw- 1 phillip phillip  261 Jul  2 11:50 iface
-rwxrwxrwx 1 phillip phillip 1,6K Jul  2 11:50 junkscript
-rw-rw-rw- 1 phillip phillip 2,2K Jul  2 11:50 KEYWD
-rw-rw-rw- 1 phillip phillip  322 Jul  2 11:50 MINP
-rw-rw-rw- 1 phillip phillip 1,2K Jul  2 11:50 MOCOEF
-rw-rw-rw- 1 phillip phillip  12K Jul  2 11:50 MOLDEN
-rw-rw-rw- 1 phillip phillip   99 Jul  2 11:50 MOLDEN.perm
-rw-rw-rw- 1 phillip phillip   27 Jul  2 11:50 OCCUP
-rw-rw-rw- 1 phillip phillip  672 Jul  2 11:50 OEINT
-rw-rw-rw- 1 phillip phillip    0 Jul  2 11:50 pids
-rw-rw-rw- 1 phillip phillip  336 Jul  2 11:50 PRINT
-rw-rw-rw- 1 phillip phillip    5 Jul  2 11:50 ROUTE
-rw-rw-rw- 1 phillip phillip  608 Jul  2 11:50 SCFDENSITIES
-rw-rw-rw- 1 phillip phillip  272 Jul  2 11:50 SCHOL
-rw-rw-rw- 1 phillip phillip  672 Jul  2 11:50 SROOT
-rw-rw-rw- 1 phillip phillip  240 Jul  2 11:50 SYMTRA
-rw-rw-rw- 1 phillip phillip 2,5K Jul  2 11:50 TEDAT
-rw-rw-rw- 1 phillip phillip 2,4K Jul  2 11:50 TEINT
-rw-rw-rw- 1 phillip phillip 487K Jul  2 11:50 VARS
So "GENBAS" is the only file, which has only read permissions, as they are probably inherited from the original read only permissions of nix-store. Now, when the second loop iterations for H atoms come, "integ" tries to copy "$mrccpath/BASIS/H" to "mrccjunk/GENBAS", which fails as the old "GENBAS" has no write permissions. I have tried to work around this, by applying the sledgehammer and execute
umask 0000
alias cp="cp --no-preserve=all"'
before invocation of any mrcc executable, but unfortunately this does not work. I guess "ishell" is not picking up the alias.

Regarding the "~/.nix-profile/bin/BASIS" and location of the BASIS directory:
this "~/.nix-profile directory" is actually the place where all nix stuff is being installed. It contains symlinks for the installed programs to the nix-store, where the actual files live.
"~/.nix-profile/bin/" looks like:
insgesamt 224K
dr-xr-xr-x 1 root root 996 Jan  1  1970 .
dr-xr-xr-x 1 root root  80 Jan  1  1970 ..
lrwxrwxrwx 1 root root  69 Jan  1  1970 BASIS -> /nix/store/8824imlk8gpgxn4nm1d12vqm1f4w3z0w-mrcc-2020.02.22/bin/BASIS
lrwxrwxrwx 1 root root  68 Jan  1  1970 ccsd -> /nix/store/8824imlk8gpgxn4nm1d12vqm1f4w3z0w-mrcc-2020.02.22/bin/ccsd
lrwxrwxrwx 1 root root  72 Jan  1  1970 ccsd_mpi -> /nix/store/8824imlk8gpgxn4nm1d12vqm1f4w3z0w-mrcc-2020.02.22/bin/ccsd_mpi
lrwxrwxrwx 1 root root  67 Jan  1  1970 cis -> /nix/store/8824imlk8gpgxn4nm1d12vqm1f4w3z0w-mrcc-2020.02.22/bin/cis

So i guess my last resort would be to copy more or less the entire mrcc installation directory with a wrapper script to the directory from which mrcc was called, set correct permissions on it and call these files then, which can have write permissions for the user. But this is even more extreme. If you see another solution, this would be very nice.

Sorry for the long post and thank you again. Best wishes

Please Log in or Create an account to join the conversation.

3 years 2 months ago #946 by phillipseeber
Dear Peter,
i found a working solution now, which is a little bit more complex than i wish it would have been, but it is working.

To solve this permission problem my solution is now the following:

Move the original mrcc entry points "dmrcc" and "dmrcc_mpi" to "dmrcc-original" and "dmrcc_mpi-original"

Create wrapper scripts "dmrcc" and "dmrcc_mpi" that are linking the MRCC executables from their original installation location ("/nix/store/...mrcc/bin/") to the directory from which they were called and that contains the input file "MINP"

Then set a umask with write permissions for the calling user. The "BASIS" directory is being copied to the local mrcc directory.

The script replaces all PATHs to the original MRCC installation directory with those from the temporarily created new installation directory and then calls "dmrcc-original" or "dmrcc_mpi-original" from this local installation directory.

All MRCC executables are then happy regarding file permissions and the overhead is quite small as the only thing that is being copied is the "BASIS" directory, while all the large executables are just symlinks. Works without any problems as far as i can tell. Here is my final setup: gitlab.com/theoretical-chemistry-jena/ni...pps/mrcc/default.nix

Thank you again for your help! Best wishes

Please Log in or Create an account to join the conversation.

3 years 2 months ago #953 by nagypeter
Dear Phillip,

thank you for explaining more about your Nix setup, sounds very useful. It is great that you made it available for everyone! If you do not mind, I might recommend it for users who cannot solve their MRCC install issues in the future as an alternative solution.

Thanks also for figuring out the permission problem. Your solution seems to work fine, but indeed a bit uncomfortable.
Alternatively, you can replace the cp on line 8529 of integ.f to
call ishell('cp --no-preserve=all ' //
so that there is permisson to overwrite GENBAS with the basis file of the 2nd atom.

Pending on Mihaly's approval this could go to the next release and you can modify your copy if you like.

Sorry for the late reply!
Best wishes,

Please Log in or Create an account to join the conversation.

Time to create page: 0.026 seconds
Powered by Kunena Forum