Dear developers and users,
I would like to do energy minimization and equilibration of a charged polymeric ionic liquids system. after the energy minimization, the potential energy is positive. I divided the equilibration into first: a nvt, and second: a npt one. during the nvt equilibration, the total energy of the system is decreased but not decreased to negative number, in the npt equilibration, the box is squeezed and atoms start crossing the periodic box. The equilibration was terminated with an error:
ERROR on proc 2: Out of range atoms - cannot compute PPPM (src/KSPACE/pppm.cpp:1887)
(kspace_style pppm 1.0e-4)
How am I supposed to solve this out of range problem? I think my initial configuration is quite right, and it seems like there is nothing wrong with the force field parameters definitions. Time step is 1 fs. Is it possibly because my system is not neutral that caused this error?
merging.in (3.8 KB)
PolyBMIM.data (86.2 KB)
TFSI.data (4.8 KB)
modeling.out (7.8 MB)
log.lammps (7.8 MB)
The issue of non charge neutral system has been discussed many times here, see for instance this older post.
My opinion is that if you use a non neutral system on purpose, you better have a really good reason to do it, as well as some solid proof that what you do makes sense.
In most cases, MD systems using Ewald/PPPM methods must be neutral. It could be that non charge neutrality is the reason behind the “out of range” error you have, but it could also be that the rest of your simulation is wrong. With almost no information on your system and input, it is impossible to say, and ionic liquid can be tricky systems to simulate.
This is usually a secondary symptom that indicates some more serious problem.
The cause is that atoms move too far in a single MD step. This can typically be avoided by reducing the time step. A timestep of 1fs may be too large of you have very light atoms.
But it can also be due to bad dynamics due to unsuitable Tdamp/Pdamp settings for fix npt.
Another possible cause could be that your initial geometry is meta-stable and only only when you allow the box dimensions to change, can the system drop into a lower potential energy state.
And also using unsuitable potential parameters can trigger this error when atoms of opposite charge can get too close, experience excessively large forces because of that, and then move too fast.
With the very minimal information provided, it is not possible to make a specific assessment of the situation.
Thank you very much for your reply. I manually assigned the charges for different atom types in the system. I did not mean it to make the system not neutral, I think I the values of the partial charges for some atom types are wrong, or my initial configuration is wrong so that the total charge is not 0. I will revised my structure and the values of the charges to see what’s gonna happen. Really appreciate your help. The data files and input/output log files were provided for any further discussion. Thanks a lot!
Hi there! You are right, if I reduced my timestep to 0.1 fs, the simulation completes with no ‘cannot compute pppm’ error. (I tried it just now) For the initial configuration, I basically read two data files and put them together in a periodic box, modified their positions to let them stay close, but without any overlapping. The potential energy during my equilibration kept on decreasing, but the kinetic energy is so high that the total energy is still positive. I am using opls-aa in my case to do the simulation. When visualizing the trajectory, I noticed the fast movement of my mobile anions. The data files and input/output log files were provided for any further discussion. Much appreciated!
At this point, your problem is no longer a LAMMPS specific issue, but rather a question of how to set up and equilibrate a system for proper simulation. This makes it a topic for discussion with your adviser / supervisor / mentor / tutor / etc. and rather off-topic for this forum.
Yeah I got it, but thank you very much for your advice and suggestions. I’m quite new to this, sorry for any inconvenience caused by this post.