file qcg_tmp/tmp_MTD/crest_conformers_0.xyz gets corrupt and fills all available disk space

[matteo-maria-tommasini]

Dear Developers,
as described by the title of this issue, the xyz file generated during one of the MTD steps of a CREST run blows up. This of course breaks the calculation after the whole available disk space is used. The inspection of the head and tail of the file (> 100 GB) reveals garbage instead of regular xyz coordinates. The two xyz input files of the calculation are attached and the command line used to run CREST is the following:

crest rr.xyz --qcg chloroform.xyz --T 10 --nsolv 20 --ensemble --mdtime 100 --alpb chloroform --wscal 1.0 --nofix

The log file is also attached (run.out).
Thank you for your help and the great code!

crest-issue.tgz

Matteo Tommasini
(Dipartimento di Chimica, Materiali e Ingegneria Chimica "G. Natta" -- Politecnico di Milano)

[cplett]

Hi, thank you for the bug report.
It seems that the MTDs restart way too often even though this should not happen. I will check on this and see if I can find the problem.

[matteo-maria-tommasini]

Thank you!

[cplett]

Hi,
I couldn't reproduce the problem yet, but I've noticed that the GFN-FF in combination with the wall potential cannot handle the chloroform or bromoform solvents and leads to missing output files which might cause the problem.
A possible solution to get reliable results is either to increase the wall potential with the --wscal flag, to use gfn2-xTB for the ensemble mode (which might be computationally too expensive), or to run a single MD instead of the NCI-MTD for the ensemble generation with the --md flag.

[matteo-maria-tommasini]

Dear Christoph,
Thank you for your helpful suggestions. We ran a simulation changing the --wscal factor to 1.34 (calculated from the volumetric ratio between chloroform and water) and the above mentioned issue did not occur. This is the command line we used for running CREST:

crest ss-c1.xyz --qcg chloroform.xyz --T 10 --nsolv 40 --ensemble --mdtime 100 --alpb chloroform --wscal 1.34 --nofix

Unfortunately, this time we encountered the following Fortran runtime error:

[##################################################] 100.00% finished.At line 1146 of file ../src/strucreader.f90
Fortran runtime error: Sequential READ or WRITE not allowed after EOF marker, possibly use REWIND or BACKSPACE

Error termination. Backtrace:
#0 0x7fe2a486ebfa
#1 0x7fe2a486f685
#2 0x7fe2a487025b
#3 0x7fe2a4aa7dcd
#4 0x563b2a26ee87
#5 0x563b2a1356ec
#6 0x563b2a14ae4f
#7 0x563b2a2a96aa
#8 0x563b2a129a5e
#9 0x7fe2a44d1d09
#10 0x563b2a129a99
#11 0xffffffffffffffff

When the calculation stopped CREST was working on the xyz ensembles files (full_ensamble.xyz, final_ensemble.xyz, here attached), which were then located in the /qcg_tmp/tmp_MTD directory, and were containing just one set of coordinates each. At the moment of the runtime error the largest file in the working directory was the file qcg_tmp/tmp_MTD/crest_rotamers_0.xyz with a size of 432 MB. The file was not corrupt as in the previous crash and could be examined. Apparently it contains several hundreds of solvated conformers.
Thank you in advance for your help.
Cheers,
Matteo

crest-issue.zip

[cplett]

Dear Matteo,
Thank you for the report.
I will try to check on what happened there. This is a strange behavior and should not occur.
Could you please try to use the --md flag to employ only a single MD for generating the ensemble? This will help me to narrow down the problem further.

[github-actions]

This issue had no activity for 6 months. It will be closed in 1 week unless there is some new activity.