Hello,
I am doing simulations of a water droplet on a feldspar slab to estimate contact angle.
When I run the simulation at a low timestep, (for example at 0.01), the simulation runs normally but it is taking a long time to see the spreading of the droplet. When I increase timestep to 0.1 or 1, it runs a couple of steps and I get the following error: Lost Atoms.
I read in the LAMMPS user mailing list about this kind of problem, and tried everything that was suggested. For example, I tried to increase the simulation box in the z direction, but it did not solve my problem. I also tried running at low timesteps first and then increasing it, it works in the beginning and after some steps I lose some atoms.
Anybody has a suggestion of why it happens and how I can avoid it?
I am sending my log file attached to this email.
Thank you.
My script. :
log.lammps (5.07 KB)
For a system like yours you should be able to use a timestep of 0.25fs to 0.5 fs (with some luck) but not 1.0fs. if you use a rigid water model even larger (up to 2fs).
so if that is not possible, that is usually an indication that there is something not quite right with your force field parameters. what is the water potential and are parameters consistent?
what is also worrisome is that you have increased the neighbor list sizes for page and one. why is that?
axel.
Hello Dr. Axel,
Thank you very much for your email
The water potential I am using is the SPC and the force field used for feldspar is the ClayFF. The parameters are consistent. All of the parameters I am using are the ones reported in papers. I also checked the parameters in the original paper that introduces the CLAYFF model (Cygan,2004).
The neighbor list sizes are high because I am trying to avoid some errors such as neighbor list overflow or bond atoms missing on proc. I tried different values for the neighbor list, but I still have the lost atoms at timestep 0.1 or higher.
Any suggestions of what can be causing this problem and how to avoid it?
Thank you.
Isa
Hello Dr. Axel,
Thank you very much for your email
The water potential I am using is the SPC and the force field used for feldspar is the ClayFF. The parameters are consistent. All of the parameters I am using are the ones reported in papers. I also checked the parameters in the original paper that introduces the CLAYFF model (Cygan,2004).
if this is supposed to be SPC, then where is fix shake? or is this supposed to be a flexible SPC variant? was CLAYFF use with SPC water?
The neighbor list sizes are high because I am trying to avoid some errors such as neighbor list overflow or bond atoms missing on proc.
neighbor list overflow should only happen if you have an unusual (local) density or an unusually large cutoff. you have neither, that means if you have an error with a neighbor list overflow, there is something wrong in your force field parameters and atoms get too close.
I tried different values for the neighbor list, but I still have the lost atoms at timestep 0.1 or higher.
those parameters have nothing to do with list atoms or bond atoms missing.
Any suggestions of what can be causing this problem and how to avoid it?
the most likely cause remains that the force field parameters are not correct or suitable for your system, or some incorrect related settings.
you may believe that you have double/triple checked everything, but there may be an error in unit conversion or the paper using different conventions for how to describe parameters, or incorrect/inconsistent assignment of charges. your confidence only identifies you as someone with limited experience. had you more experience, you would worry more.
there is not much else that can be done outside of careful visualizing your simulation with very frequent output and then identifying where you have atoms getting too close and what kind of atoms and whether that is consistent with the model.
one thing you can do is to model both parts separately and determine what are the optimal settings for each individually. that could narrow down the issue to either component or the interactions between the two components.
axel.