ML_IERR vs ML_ESTBLOCK

[rwindiks]

Dear Developers,

again, let me express my sincere gratitude for everyone in your team who developed and is developing and improving MLFF. MLFF is essential to simulate rare events such as reaction mechanisms and degradation processes on the atomic scale with DFT accuracy. Developing and applying MLFF is like a child's game, Also very helpful are the advanced MD techniques such as steered MD and metadynamics. Please keep on doing this excellent job!

From the post https://vasp.at/forum/viewtopic.php?p=3 ... ERR#p31594 I learned that in the upcoming release the flag ML_IERR will be deprecated and the new flag ML_ESTBLOCK will be used instead. In VASP 6.5.1 both flags can be already used but let VASP behave differently. If ML_IERR used then the SFF is continuously written to the file ML_LOGFILE while an MLFF is applied. Hence, users have the chance to examine whether the MLFF is extrapolating or interpolating. That should be the preferred behavior. However, if ML_ESTBLOCK is set instead of ML_IERR, only the header of ML_LOGFILE is written and not updated during a calculation. Only at the very end, a complete version of ML_LOGFILE is created that contains values of SFF for the entire simulation. With the latter behavior users cannot examine during a running simulation how the MLFF "behaves".

Is it possible that also with using ML_ESTBLOCK SFF is continuously written to the file ML_LOGFILE while an MLFF is applied?

Thanks.

VASP MLFF rocks!

René

[andreas.singraber]

Dear René,

thanks a lot for your kind words, it is great to hear that you enjoy using MLFFs in VASP :) !

Indeed the new tag name for controlling the frequency of error estimates is ML_ESTBLOCK instead of ML_IERR (both should work in VASP 6.5.1). I am sorry we have not updated the Wiki accordingly! However, there should be no difference between the two INCAR tags because in the source code one is merely an alternative INCAR tag "spelling" to the other one. Once the value is read in (to the same variable!) there is no difference in the code flow. I wonder whether the behavior you observe is reproducible? Could you maybe also try this on another machine/file system?

So my guess is that there is I/O buffering responsible for the ML_LOGFILE being written only partially. The operating system (in particular on larger clusters) can buffer the output to files in memory for a very long time, so it looks to the user as if the program itself would not try to write anything to disk. Only when the program exits (or the file is closed in the program) the OS is actually forced to write to disk. We can try to include some "flush" statements but this may still be ignored by the OS. So, unfortunately, there is no (easy and portable) way of circumventing I/O buffering... anyway, I will ask my colleagues if there is some method that "usually works".

Thanks for bringing this up, it is indeed not very helpful if there are error estimates but one cannot actually see them at runtime .

All the best,
Andreas