[Bug Report] forrtl: severe (64) input conversion error in autoset_available (ini.F) during dielectric_funct calculation

[liang-wen_pi]

Hello，Everyone！
I am encountering a persistent runtime error when performing GW/TDHF calculations on my local workstation, while the exact same set of input files runs successfully on a large-scale HPC cluster. I referred to the steps on the official website and the zip file it provided.

https://www.vasp.at/wiki/index.php/Impr ... c_function

The DFT step alaways did well. But the error occurs at the beginning of the execution (initialization phase). The stack trace points to an "input conversion error" (unit -5) originating from autoset_available in ini.F.

Error Message:

reading WAVECAR
the WAVECAR file was read successfully
initial charge from wavefunction
forrtl: severe (64): input conversion error, unit -5, file Internal List-Directed Read
Image PC Routine Line Source
vasp_std 00000000025C91C0 Unknown Unknown Unknown
vasp_std 00000000025C872D Unknown Unknown Unknown
vasp_std 000000000053B3CB autoset_available 822 ini.F
vasp_std 000000000053A463 autoset_available 706 ini.F
vasp_std 0000000001E6AC02 xi_mp_calculate_x 448 chi.F
vasp_std 0000000002579F7A vamp_IP_do_rpa_ 6006 main.F
vasp_std 000000000254DB25 MAIN__ 3320 main.F
vasp_std 000000000040981D Unknown Unknown Unknown
libc.so.6 000014F728033CA8 Unknown Unknown Unknown
libc.so.6 000014F728033D65 __libc_start_main Unknown Unknown
vasp_std 0000000000409731 Unknown Unknown Unknown

Environment of the failing system:

VASP Version: 6.5.0 (CPU standard version)
OS: Debian GNU/Linux 12 (bookworm)
Compiler: Intel(R) Fortran Compiler Classic 2021.13.1 (ifort) via mpiifort
Math Library: Intel MKL 2024.0.2
MPI: Intel MPI (part of oneAPI 2024.2)

[andreas.singraber]

Hello!

Thanks a lot for the detailed bug report! In particular, the stack trace was very helpful as it already pinpoints to the issue here: VASP tries to determine the available memory in a subroutine FIND_FREE_MEMORY_ENTRY in ini.F by reading the system file /proc/meminfo (if it is available). Parsing the information in this file has been working without issues so far, the source code for this feature was introduced already with the first release of VASP 6. However, it seems some unexpected string was processed on your local workstation which ultimately messed up the conversion into an integer number and lead to the runtime error. Can you please run the following command on your workstation and post the output here:

Code: Select all

cat /proc/meminfo

This will help us to harden the routine in such way that it will not trip over this issue again.

In order to circumvent the issue on your local workstation you can set the available memory manually in the INCAR file via the MAXMEM tag. This should disable the automatic memory estimation and hence VASP should not stop at the problematic code any more.

Hope this helps!

All the best,
Andreas Singraber

[liang-wen_pi]

This is the information.

(base) ~$ cat /proc/meminfo
MemTotal: 3169359964 kB
MemFree: 500520684 kB
MemAvailable: 3075539296 kB
Buffers: 3524692 kB
Cached: 2507049504 kB
SwapCached: 396852 kB
Active: 126493760 kB
Inactive: 2445582768 kB
Active(anon): 61664040 kB
Inactive(anon): 348808 kB
Active(file): 64829720 kB
Inactive(file): 2445233960 kB
Unevictable: 18248 kB
Mlocked: 7448 kB
SwapTotal: 492831740 kB
SwapFree: 488621188 kB
Zswap: 0 kB
Zswapped: 0 kB
Dirty: 180 kB
Writeback: 20 kB
AnonPages: 61415680 kB
Mapped: 1910872 kB
Shmem: 541408 kB
KReclaimable: 79955312 kB
Slab: 91494328 kB
SReclaimable: 79955312 kB
SUnreclaim: 11539016 kB
KernelStack: 101088 kB
PageTables: 335000 kB
SecPageTables: 40756 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 2077511720 kB
Committed_AS: 108818216 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 1291044 kB
VmallocChunk: 0 kB
Percpu: 973440 kB
HardwareCorrupted: 0 kB
AnonHugePages: 31782912 kB
ShmemHugePages: 0 kB
ShmemPmdMapped: 0 kB
FileHugePages: 0 kB
FilePmdMapped: 0 kB
Unaccepted: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
Hugetlb: 0 kB
DirectMap4k: 62033916 kB
DirectMap2M: 3069710336 kB
DirectMap1G: 88080384 kB

I found that this might be caused by the physical memory being too large on that node. I am not sure if this is the reason?
thanks！

[andreas.singraber]

Hello!

Thanks a lot for the meminfo output, it is now very clear what is happening: your machine has 3TB of RAM which corresponds to the displayed 3075539296 kB of available memory. Unfortunately, the number corresponding to the string "3075539296" is larger than the maximum representable 4-byte integer 2147483647 and hence the conversion to an integer fails.

We have had similar issues before at other places in the code but unfortunately the fix was not incorporated in this particular routine yet. Thanks for making us aware of this issue, I will make sure that this will be fixed in the upcoming releases.

All the best,
Andreas Singraber

[liang-wen_pi]

Thank you for your reply.
Now, using the new parameters, I can run the VASP.

Yours,
liangwen Pi