Problem configuring Molpro2020.2

[Kristian Holten Møller]

Hi everyone, 

I am continuously experiencing problems configuring, compiling and running Molpro2020.2 and I am trying to pinpoint where it currently goes wrong. 

While I know that the exact keywords needed depend on the system, I was hoping that  someone would have a list of commands that they have successfully used to configure (and subsequently compile) Molpro2020.2 that they would be so kind to share? I am especially interested in a "./configure" line with specification of 64-bit (8-byte) LAPACK, as that seems to be the issue, as described in more detail below: 

I have tried the following sequence of commands:

*****

module load intel/20.0.4

module load intelmpi/2020.4.304

scl enable devtoolset-9 bash

PATH=$PATH:/groups/kemi/hzn383/programs/ga-5.8/tools

./configure --prefix=/groups/kemi/hzn383/programs/Molpro_patched_compiled

*****

This seems to work for single-point calculations, but when trying to do optimizations, I get the error message below, which I via this forum tracked to Molpro assuming that the LAPACK library uses 4 byte integers rather than 8 byte integers:

*****

Geometry written to block  1 of record 700

 ? Error     

 ? integer too large to be represented in 4 bytes  

 ? The problem occurs in mint8to4   

*****

To overcome this, I tried configuring Molpro with the following keywords:

*****

./configure --prefix=/groups/kemi/hzn383/programs/Molpro_patched_LAPACK_compiled --with-lapack-path=/software/local/intel/parallel_studio_xe_2020_upd4/mkl/lib/intel64 --with-lapack-int64

*****

However, when I try running the test jobs (make quicktest), I get an error related to insufficient memory as shown below for all the jobs. 

*****

 = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

 Memory manager status, default implementation STACK

 Stack status: Remaining memory=31999956 doubles (44 currently used, 32000000 maximum used), Entries=3

                           Type        Depth            Address      Size  Rank Bounds

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

                          double          38       7F3E32C7A040        38     1  1:38

                          double          41       7F3E32C7A028         3     1  1:3

                          double          44       7F3E32C7A010         3     1  1:3

 = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

 ? Error

 ? Insufficient memory to allocate a new array of length 4294967278 8-byte words

 ? The problem occurs in memory

 GLOBAL ERROR fehler on processor   0

h2o_ano.test: ERRORS DETECTED: non-zero return code ... inspect output

*****

The same error I get if I try to run any calculation specifying memory using "-M", even if I use a large amount of total memory. If instead, I run a calculation using the "-m" keyword to specify memory, I get the error below: 

*****

 ** On entry to DGESVD parameter number 13 had an illegal value

 ? Error

 ? failure from BLAS/LAPACK

 ? The problem occurs in xerbla

 GLOBAL ERROR fehler on processor   0

*****

That's why I think the problem somehow relates to the linking to LAPACK and any insight would be highly welcome. 

Best, 

Kristian H. Møller

Postdoc

University of Copenhagen

[andreas...@gmail.com]

Dear Kristian,

Molpro 2020.x by default actually now uses blas/lapack libraries with 32-bit integers, so please

send your example for the geometry optimisation, it should not happen when you linked

with a 4-byte blas/lapack library (and when this is the origin of the failure of the calculation).

I am using the following configuration settings for MKL:

export MKLROOT=/home/andreas/intel/oneapi/mkl/latest
./configure --with-lapack="-L${MKLROOT}/lib/intel64 -Wl,--no-as-needed -lmkl_gf_lp64 -lmkl_gnu_thread -lmkl_core -lgomp -lpthread -lm -ldl"

which is obtained by using the MKL link advisor (using gnu,openmp):

https://software.intel.com/content/www/us/en/develop/tools/oneapi/components/onemkl/link-line-advisor.html

Maybe you could try out such explicit settings also for your configuration rather than relying on

what the configure script sets internally.

Andreas

[Kristian Holten Møller]

Dear Andreas,

Thanks a lot for looking into this.

I tried compiling with the explicit settings as you suggested
(changing the MKLROOT), but unfortunately I get the same error.
I have attached the input and (one of the) output files of the
calculation resulting in the error.

I have gotten CCSD/aVTZ optimizations to finish for small systems up
to sizes of CH3S and SO2.
So it seems that the error is related to this specific type/size of
calculation. I am currently trying to see what is "required" to invoke
this error message.

Best,
Kristian H. Møller
Postdoc

> --
> You received this message because you are subscribed to the Google Groups "molpro-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to molpro-user...@googlegroups.com.
> To view this discussion on the web, visit https://groups.google.com/d/msgid/molpro-user/f916b551-a57b-42f9-8513-d116b9e2e627n%40googlegroups.com.

[Andy May]

Dear Kristian,

Was this definitely without the --with-lapack-int64 option? This option instructs Molpro that the blas/lapack library contains 8-byte integers, and was really only useful for the case of a genetically named liblapack etc. that one could not determine the size of integers automatically. The option in no way influences the result of --with-lapack-path, so your original configuration would've resulted in the 4-byte integer MKL libraries being linked to Molpro but Molpro code expecting the 8-byte interface. Future versions of Molpro will support only the 4-byte interface since this is needed for Eigen and other things that Molpro will be using.

Please could you send all the relevant configuration files such as CONFIG, config.log, build/molpro_config.h and build/molpro_config.fh for us to look at? Perhaps it is best to send all these attachments to mol...@molpro.net instead of the mailing list.

Best wishes,

Andy

To view this discussion on the web, visit https://groups.google.com/d/msgid/molpro-user/CALaHyMVcTkrDvvshJOpX0GzQzABixugC6RspVuumNXK3Bhm2Gg%40mail.gmail.com.

[andreas...@gmail.com]

Dear Kristian,

from your output I can only speculate that the corresponding BLAS call is one dscal operation inside

a routine that diagonalises the model hessian at the beginning of the optimisation. It fixes the phase when

two coeffs are almost identical, so is not done any time.

I have tested your calculation with my configuration and it runs without problems (using a smaller active space,

though). This indicates that the problem indeed is related to the blas library configuration and it would be good if

you could send the corresponding configuration log+h+fh files to the molpro.net email address as suggested by Andy.

It is strange that the 4-byte-int problem only shows up here, so it would be useful for us to understand

what is going on.

For the time being you can also do the calculation using the corresponding precompiled binary for your system

which you may find on the web page www.molpro.net/download

Best wishes,

Andreas