Dear LAMMPS users,
I am new lammps user, and I trying to simulate a system of Poly-Vinyl Alcohol with 40% hydration. I am repeatedly running into the error "ERROR on proc 51: Out of range atoms - cannot compute PPPM (…/pppm.cpp:1839)". This error has been posted multiple times in this forum before and after reading the those discussions I made the following changes to my system-
Increased the neighbourlist frequency to “neigh_modify delay 0 every 1 check yes” and increased the skin distance to 2.0 Angstorm.
Increased the box size
Reduced time step from 1fs to 0.5 fs
Despite the above changes I was still running into the error, so I removed the water from my system and simulated anhydrous PVA and still ran into the same error.
The error always occurs around the same time- at 167000 timesteps for 1fs and 325000 fs for 0.5 fs. I also included a dump command right before the run where this error usually occur but that did’nt help.
I am using the august 2023 version of LAMMPS on a cluster with 80 processors. I have attached my input files below for reference. Any suggestion would be very much appreciated. PVA Anhydrous.tar.gz (3.3 MB)
Hello Simon,
Thank you for your response. The net charge of 10 was due to the end of chain H atoms of PVA. I had assigned charges for the H atoms (except the ones in the OH bond) such that each monomer unit was neutral hence the tail atoms added a net charge to the system.
However, I changed the charge on the H atoms such that the net charge of the system is almost zero and ran the simulation again. It has given the same error after 167000 time steps again. I have attached the files for your reference.
Best Regards,
Anushka PVA_Anhydrous_0_charge.tar.gz (3.3 MB)
It is not very likely that somebody will inspect your files in detail and specifically will want to invest the resources to run for ~200000 MD steps. So, you will have to debug it yourself. The first step is always to carefully observe what happens when your system crashes. Since you can reliably reproduce the crash around a specific timestep number, you can define a dump that will write out a detailed trajectory and make it start only a short time before the crash. Please have a look at the dump_modify delay keyword. Then you can do a detailed visualization.
The second step would then be to build a (much) smaller system and see if you can reproduce this issue. The most common reasons for this error are subtle and related to force field parameters.
The only specific suggestion I can add is that X-O-H angles can often a little unstable – you may have to SHAKE them to maintain stability.
Please verify your system’s overall physical reasonability before making single changes to force fields. You do not want to “stabilise” your simulation by cancelling one error with another.
Please verify that the problem, if it is that, is truly related to this one angle or bond.
Use both restart and write_data commands to troubleshoot the crash. If your system runs OK from a data file, but not from a restart, that may help you narrow down significantly what issues may be happening.