corrupted size vs. prev_size while consolidating

job314

I suppose I have to report this here even though I have been interacting with CRYSTAL support directly. most if not all EOS cases just stop/abort with cryptic messages at the end of all of the iterations, sometimes already into EOS calculation.

TOTAL ENERGY(DFT)(AU)(  2) -1.0219660133484E+04 DE 2.2E-09 tester 2.1E-13
TTTTTTTTTTTTTTTTTTTTTTTTTTTTTT EDFT        TELAPSE   143507.65 TCPU   142271.40
corrupted size vs. prev_size while consolidating
corrupted double-linked list

or

SORTING VOLUMES/ENERGIES

    VOLUME (A^3)    ENERGY (a.u.)

    810.125802   -1.023662022986E+04
    829.558185   -1.023663933122E+04
    849.094033   -1.023665162912E+04
    868.935234   -1.023665780851E+04
    880.846516   -1.023665872507E+04
    889.065728   -1.023665819061E+04
    909.486571   -1.023665312286E+04
    930.215794   -1.023664308419E+04
    951.267331   -1.023662850026E+04
corrupted size vs. prev_size
corrupted size vs. prev_size
munmap_chunk(): invalid pointer
corrupted double-linked list
corrupted size vs. prev_size
munmap_chunk(): invalid pointer
munmap_chunk(): invalid pointer
munmap_chunk(): invalid pointer
munmap_chunk(): invalid pointer
munmap_chunk(): invalid pointer
munmap_chunk(): invalid pointer
munmap_chunk(): invalid pointer
munmap_chunk(): invalid pointer
munmap_chunk(): invalid pointer
munmap_chunk(): invalid pointer
munmap_chunk(): invalid pointer
munmap_chunk(): invalid pointer
munmap_chunk(): invalid pointer
munmap_chunk(): invalid pointer
munmap_chunk(): invalid pointer

GiacomoAmbrogio

Hi job314,
I moved the topic in bug reports category.

Could you kindly provide the input and output files for an example of these errors?

I assume you are using the parallel version of CRYSTAL23. Could you also specify the environment in which you are running the code? Specifically, which version of MPI you are using and whether you are using libraries such as intel MKL. If so, please include their versions as well.

job314

Sure, see attached typical input and output. It is method independent. It appears to originate by the end of EOS optimization, some of them as you see in the example in the first post literally during the EOS calculations
EOSerror.out
INPUT.d12

I emailed the admins to provide system information

job314

Another one. I emailed separately CRYSTAL support some time ago about these, Alessandro is aware of these
INPUT.d12
EOSerror.out

job314

CRYSTAL uses Intel MPI and MKL

load("intel-oneapi-compilers/2024.1.0")
load("intel-oneapi-mkl/2024.1.0")
load("intel-oneapi-mpi/2021.12.0")
$ ldd crystal
linux-vdso.so.1 (0x00007ffce0991000)
libm.so.6 => /usr/lib64/libm.so.6 (0x00007f635deef000)
libmpifort.so.12 => /apps/spack-managed/gcc-11.3.1/intel-oneapi-mpi-2021.12.0-pdx4nzpz6ei3vtjndfrp25fsmkms6x6n/mpi/2021.12/lib/libmpifort.so.12 (0x00007f635db58000)
libmpi.so.12 => /apps/spack-managed/gcc-11.3.1/intel-oneapi-mpi-2021.12.0-pdx4nzpz6ei3vtjndfrp25fsmkms6x6n/mpi/2021.12/lib/libmpi.so.12 (0x00007f635c3be000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f635c195000)
libgcc_s.so.1 => /usr/lib64/libgcc_s.so.1 (0x00007f635c17a000)
libc.so.6 => /usr/lib64/libc.so.6 (0x00007f635bf71000)
/lib64/ld-linux-x86-64.so.2 (0x00007f635dfcc000)
librt.so.1 => /usr/lib64/librt.so.1 (0x00007f635bf6c000)
libdl.so.2 => /usr/lib64/libdl.so.2 (0x00007f635bf67000)
–

aerba

We are running some tests and I think we are close to identifying the problem. We’ll probably have a solution by the beginning of next week.

job314

aerba much appreciated, hopefully I will not need to completely rerun those almost finished EOS jobs

aerba

job314 I wouldn't be THAT optimistic

aerba

Hi,

After running a few tests, we found a bug towards the end of the EOS module due to the size mismatch of different arrays (specifically, in the full list of direct lattice vectors of the equilibrium configuration and maximally compressed configuration). While this requires an actual fix to the code, we also found a workaround solution for you. Indeed, if the maximally compressed configuration has the same list as for the equilibrium configuration, everything is fine. Thus, in your case, it was enough to explore a maximum compression of 5% (rather than 8%) to be able to run smoothly the job.

Please, find here a working input file (where we have also reduced the number of explored volumes to 4+1 to speed up the calculation without resulting in any significant loss of accuracy).

job314

thank you