My Community

Hello,

Is the number of atom types for ML_FF simulations limited to 3?

I have been consistently running ML_FF simulations with the same input files for a while with a system containing 3 atom types. However, when I increase the number of atom types to 4 (INCAR, POTCAR and POSCAR files changed accordingly), the simulation crashes right from the beginning.

From the messages in the standard error, it seems that the error has to do with some FORTRAN loop dealing with the computation of structural (SOAP-like) descriptors in the ml_ff_math.F subroutine. The error is "array index out of bounds".

I have run the very same simulation without performing ML_FF and everything works smoothly.

Please, could you help me to make this simulation run with 4 atom types?

Kind regards,
MCV

P.S.: Please, find enclosed the input-output files in a tar.zip file.

In your POSCAR there are two groups of O atoms with the same label. While VASP works fine with this usually, the machine learning can't handle this because it has to identify datasets via the labels. Having twice the same lable would make the positions indistinguishable among different structures. Unfortunately there is no error message with a proper exit when the same label is encountered for different types in the same structure. There is also no documentation about this in the wiki. So we will put both on our to do list. Thanks for reporting the problem.

Solution for your case:
Name both or one of the two O atoms differently in POSCAR file, like e.g. "O1 O2" or "O O1".


A remark: I saw in the ML_LOGFILE is that you will need 11.5 GB memory per core with the current setup. That looks a lot for ML_MCONF=2000 and ML_MB=5000 on 24 cores. Also the size of CMAT compared to FMAT is much larger at the beginning of the memory consumption output in the ML_LOGFILE. I think you haven't compiled with shared memory "-Duse_shmem" (see also wiki/index.php/Shared_memory). If you haven't I would strongly advice you to do that because practical calculations are almost impossible without shared memory.

Hi,

Thank you very much indeed, both for the solution and for your feedback about our compilation. We'll defenitely have a closer look to that.

Kind regards,
MCV