LAMMPS WWW Site - LAMMPS Documentation - LAMMPS Mailing List Archives
Re: [lammps-users] Issues with fix rigid in PRD simulation
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lammps-users] Issues with fix rigid in PRD simulation

From: Axel Kohlmeyer <akohlmey@...24...>
Date: Mon, 28 Aug 2017 07:47:05 -0400

On Sun, Aug 27, 2017 at 6:33 PM, Mohammad Rasool Vazirisereshk <mvazirisereshk@...24...> wrote:

Axel, thanks for your response. The tip does not move with constant velocity, it is connected to a single atom using a spring and the single atom moves with constant speed. What I am trying to do is to reach a lower scanning velocity (velocity of the single atom mentioned above) of the tip by parallelizing the time domain using prd simulation (something similar to this paper:

​there is a significant difference between the process in the paper you quote and your own description. the paper uses a constant load, which is very similar to using steered MD in constant force mode (and equivalent to using fix addforce in LAMMPS), while your setup is equivalent to SMD in constant velocity mode. whether your tip is tethered to an atom moving at constant velocity or whether the tip itself is moving at constant velocity doesn't make a significant difference here. your tip is not experiencing a constant load, but the load will increase as your reference atom moves and it thus will ultimately follow at the speed of that reference atom, even if only in a "jumpy" mode.  this means, that my assessment remains. PRD makes sense for the simulation in the paper, since the progress of the tip depends on activated events, while it doesn't make sense in your case, as it depends on the speed in which you move your reference particle.​ the two setups are not comparable, since in your case the load is changing.

As far as I know, similar setups with fix rigid worked fine in prd simulations with the LAMMPS version of 2012-2013 and I wanted to check if someone else faces some issues in using both packages concurrently in the recent version of the LAMMPS. 

​there has been significant refactoring of the rigid fixes over the years to addresses several shortcomings and fix problems/bugs.
if you believe there is a bug remaining or LAMMPS behaving incorrectly, please provide a minimal test example that clearly demonstrates the issue (best posted with a detailed description to so this can be properly evaluated. your kind of vague and speculative question is not likely to get you an answer. at least i have not seen people respond to the mailing list on such questions.

that said, this does not change my assessment of your simulation being a setup where PRD makes little sense.






On Sat, Aug 26, 2017 at 8:36 AM, Axel Kohlmeyer <akohlmey@...24...> wrote:

On Fri, Aug 25, 2017 at 6:43 PM, Mohammad Rasool Vazirisereshk <mvazirisereshk@...24...> wrote:

Hi everyone,

 I am using the latest stable version of LAMMPS (11 Aug 2017) and have a question about the use of REPLICA and rigid packages, concurrently at a simulation. 

The problem I am working on is simplified as follows: I have a tip moving laterally on a substrate. The top part of the tip is rigid (using fix rigid) and coupled to an atom moving laterally with constant speed (using fix move). This setup works perfectly in regular MD. However, when I use prd command the system shows strange behavior (the tip sometimes either penetrates in the substrate or flies over simulation box). Below you can find a part of my input file: 

​i would say this is because you are trying to do something that makes no sense.

the purpose of PRD is to advance the time line faster by running decorrelated systems in parallel to increase the probability of a rare event to happen within a limited amount of wall time. however, your tip moving at constant speed is defeating that purpose. you don't know in advance, when the rare event happens, so you don't know how far to offset the position of the tip in each replica and the PRD code has no idea that you would need to keep your tip static while decorrelating the replicas, not to mention the unphysical "kick" to your system, when you would let the tip move again.

if you want to get improved statistical sampling, you don't need PRD, but can just run the same type of regular MD input concurrently with the -partition flag while considering two important points:
1) each replica should use different random number seeds to (re-initialize) velocities
2) each replica should run without the tip moving for a sufficiently long time to make sure they are sufficiently decorrelated. using a langevin thermostat (again with different random seeds for each run)

​of course, that can be done even simpler by just generating multiple input files and running them independently.​



# 1 fs time step
timestep 0.001
variable t equal 300


fix 1 lo-mid nvt temp 300.000000 300.000000 1
fix 90 hi-mid nvt temp 300.000000 300.000000 1
fix 91 free nve
fix 2 lo-fixed setforce 0.0 0.0 0.0
fix 10 hi-fixed addforce 0.0 0.0 -0.003613

fix 3 hi-fixed rigid single torque 1 off off off
fix 4 hi-fixed spring couple virtual 4.0 0.0 NULL NULL 0.0

#virtual atom
fix 7 virtual setforce 0.0 0.0 0.0
fix 8 virtual move linear 0.01 0.0 0.0 units box

I guess the problem is due to having fix rigid command in the prd simulation since I ran the prd simulation for a similar setup, which did not have fix rigid, without any problem.

I also tried to use fix aveforce (0 0 0) instead of fix rigid in my prd simulation but it did not work out. 

Is there anyone else who faced irregularities with fix rigid in prd simulation? Any idea or comment will be appreciated. 


Check out the vibrant tech community on one of the world's most
engaging tech sites,!
lammps-users mailing list

Dr. Axel Kohlmeyer  akohlmey@...24...
College of Science & Technology, Temple University, Philadelphia PA, USA
International Centre for Theoretical Physics, Trieste. Italy.

Dr. Axel Kohlmeyer  akohlmey@...24...
College of Science & Technology, Temple University, Philadelphia PA, USA
International Centre for Theoretical Physics, Trieste. Italy.