Fix smd behaviour

Hi All,

I’m trying to understand how the “fix smd” functions in terms of the force and velocity direction.

I tried to test on a very simple case which is basically a sphere carved out of a regular fcc crystal lattice. I also set the cut off so small ( = 0.1) so the atoms of the sphere have no interaction. I try to pull or push this sphere with “fix smd” to understand its behaviour. I have attached the input files and the log files for two cases:

a. Tether point is below the centre of mass of the sphere and cvel is positive.

b. Tether point is below the center of mass of the sphere and cvel is negative.

For case a the sphere moves upward (in the direction of the velocity) uniformly which make sense but:

— Why in case b while the spring is moving down the sphere just goes down to up to the initial tether point of the spring and just oscillates around that point while the spring is still moving downward? Shouldn’t it show a behaviour as case a except that its going down?

Note: For spring constant I chose a large value to make very strong; and for cvel I chose a value to move sphere in few timesteps. Dt = 0.005 (default value) in the both cases.

I’ve also browsed most of the posts on “fix smd” and saw a similar discussion and a reference to this part of the documentation there:
"In cvel mode the distance R is incremented or decremented monotonously according to the pulling (or pushing) velocity."

but I couldn’t figure out how to justify the behaviour of case a and b.

I appreciate your time a help in advance.

Cheers,
Kasra.

in.a (815 Bytes)

in.b (816 Bytes)

log.b (113 KB)

log.a (113 KB)

Hi All,

I'm trying to understand how the "fix smd" functions in terms of the force
and velocity direction.
I tried to test on a very simple case which is basically a sphere carved out
of a regular fcc crystal lattice. I also set the cut off so small ( = 0.1)
so the atoms of the sphere have no interaction. I try to pull or push this
sphere with "fix smd" to understand its behaviour. I have attached the input
files and the log files for two cases:

   a. Tether point is below the centre of mass of the sphere and cvel is
positive.
   b. Tether point is below the center of mass of the sphere and cvel is
negative.

For case a the sphere moves upward (in the direction of the velocity)
uniformly which make sense but:

    --- Why in case b while the spring is moving down the sphere just goes
down to up to the initial tether point of the spring and just oscillates
around that point while the spring is still moving downward? Shouldn't it
show a behaviour as case a except that its going down?

Note: For spring constant I chose a large value to make very strong; and for
cvel I chose a value to move sphere in few timesteps. Dt = 0.005 (default
value) in the both cases.

I've also browsed most of the posts on "fix smd" and saw a similar
discussion and a reference to this part of the documentation there:
"In cvel mode the distance R is incremented or decremented monotonously
according to the pulling (or pushing) velocity."
but I couldn't figure out how to justify the behaviour of case a and b.

there are two "design choices" in fix smd that are or will be causing
trouble with your setup.

- fix smd uses the group functions of LAMMPS to compute the center of
mass of a group.
  this will ignore image flags and thus creates problems when you are
pushing too far. you can see this at the end of the run with in.a.

- fix smd will recompute the push direction relative to the target
coordinate when you go past it. this explains the behavior of in.b

the code in fix smd has been due for a rewrite for quite a while, but
there never has a sufficient incentive to do it, since it works well
for most cases that people have been using it for. a lot of the
complications come from being a hacked version of fix spring and a lot
of things that make sense in the context of fix spring are less
meaningful for fix smd. also, by the time it was written, i knew much
less about the inner workings of lammps than what i know now. for a
new implementation several things would be done differently.

i would like to point out that there is an alternate implementation of
steered MD in the user-colvars package, which can handle - after the
last update - unwrapped coordinates. the downside of fix colvars is,
that it currently has no access to "groups" and is not parallel (which
usually isn't much of a problem).

HTH,
    axel.

Thanks for the clarification, it sure helped a lot. A couple of questions here:

  1. For what you said about behaviour of case a: do you mean that the problem is ensued when either the spring or the object past beyond a periodic bc? So such situations should be avoided, right?

  2. Are the following arguments true based on what I got from your description for case b?

a. The target (initial tether point) is just to define a direction as in the code it’s been defined as dy/r (for my cases) and it’s either +1 or -1.
b. The tether point should be chosen such that it’s not crossed during the term of simulation otherwise the expected behaviour of the tethered object will be missed because of the combined effect of cvel direction and the calculated direction, dy/r.

1
No atom of the fix group should leave the box.

2
Case b applies. The point you provide is the target coordinate that should not be crossed. It is best chosen as far away as possible and the fix group on the opposite side of the box.

as mentioned before, the smd implementation in the colvars package makes other choices.

Axel

Hi,

I’m trying to apply “fix smd” on a single particle I can make it work properly here is the cases that I’m running:

a. With “atom_style sphere”, using “pair_style colloid” and using fix smd (cvel = 0 to compare with fix spring) the simulation crashes with:

"MPI process terminated unexpectedly
Exit code -5 signaled from ‘computername’ "

However, fix spring works fine. Different cvel values also cause crash and show the same message as above

b. With “atom_style atomic”, using “pair_style lj/cut” and using fix smd (cvel = 0 to cmpare with fix spring) the simulation runs but showing zero force for all x, y and z direction while at the same situation “fix spring” is showing nonzero spring forces in y direction. However, I can see force values for cvel not be zero. But shouldn’t cvel = 0 show the same behaviour as fix spring?

I have attached the input file for both cases and I’d really appreciate it if you can help me with solving this issue.

Cheers,
Kasra.

in.a (962 Bytes)

in.b (940 Bytes)

Hi,

I'm trying to apply "fix smd" on a single particle I can make it work
properly here is the cases that I'm running:

a. With "atom_style sphere", using "pair_style colloid" and using fix smd
(cvel = 0 to compare with fix spring) the simulation crashes with:

"MPI process terminated unexpectedly
  Exit code -5 signaled from 'computername' "

However, fix spring works fine. Different cvel values also cause crash and
show the same message as above

this has nothing to do with the cvel, but the fact, that fix smd (in
its current form) does not support atom styles that only provide per
atom masses.

you have two options to handle this case:

1) use "atom_style hybrid atomic sphere" and add the line "mass 1
200.0" after setting the per atom mass. this should give the correct
result, since now you will have a per atom _type_ mass as expected,
but also the condition of a per atom mass of the sphere style is
satisfied.

2) download the updated version of fix_smd.cpp from LAMMPS-ICMS that
adds support for per atom masses (it is a very straightforward and
simple change).

b. With "atom_style atomic", using "pair_style lj/cut" and using fix smd
(cvel = 0 to cmpare with fix spring) the simulation runs but showing zero
force for all x, y and z direction while at the same situation "fix spring"
is showing nonzero spring forces in y direction. However, I can see force
values for cvel not be zero. But shouldn't cvel = 0 show the same behaviour
as fix spring?

yes and no. the problem is that your tether point for fix spring is
different from fix smd. for fix smd the initial tether point is
exactly the location of the COM of the fix group, so the fix group is
in the minimum of the potential and there should be no force. if you
do the same thing with fix spring you get the same result, however in
your example you set the tether point to the smd *target* location, so
the COM of the fix group is far away from the minimum and thus you do
see a force.

I have attached the input file for both cases and I'd really appreciate it
if you can help me with solving this issue.

thanks for the inputs. i cannot express how incredibly helpful it is
for these kinds of discussions to have simple inputs that reproduce
the expected or unexpected behavior. i wish more people would
understand this and not just quote a few random lines from their
inputs or post needlessly large and complex inputs.

cheers,
     axel.

Much appreciation for your complete and thorough answer.

— option 1: I applied option 1 and it’s working fine now.

— option 2: I replaced the fix smd files in my current version of lammps “lammps-14May13/src/USER-MISC/fix_smd.cpp” and “lammps-14May13/src/USER-MISC/fix_smd.h” with those from “lammps-icms/src/USER-MISC/fix_smd.cpp” and “lammps-icms/src/USER-MISC/fix_smd.h” and complied and made it again. But using the new generated executable I still get the same error with in.a.

"MPI process terminated unexpectedly
Exit code -5 signaled ‘computername’ "

Am I missing something in what you suggested as the second option?

Cheers,
Kasra.

Much appreciation for your complete and thorough answer.

--- option 1: I applied option 1 and it's working fine now.

--- option 2: I replaced the fix smd files in my current version of lammps
"lammps-14May13/src/USER-MISC/fix_smd.cpp" and
"lammps-14May13/src/USER-MISC/fix_smd.h" with those from
"lammps-icms/src/USER-MISC/fix_smd.cpp" and
"lammps-icms/src/USER-MISC/fix_smd.h" and complied and made it again. But
using the new generated executable I still get the same error with in.a.

"MPI process terminated unexpectedly
Exit code -5 signaled 'computername' "

Am I missing something in what you suggested as the second option?

yes. the updated code is in *LAMMPS-ICMS*, that is "my" branch of
LAMMPS where i try out new features.
you need to get this file:
http://git.icms.temple.edu/git/?p=lammps-icms.git;a=blob_plain;f=src/USER-MISC/fix_smd.cpp;hb=HEAD

the code is already integrated into the upstream LAMMPS version and
will be in the *next* patch that steve releases.

axel.

I’m using the same file as the file in the link you sent. Basically, I downloaded the lammps-icms (as mentioned in your homepage) via :

  • git clone [http://git.icms.temple.edu/lammps-icms.git](http://git.icms.temple.edu/lammps-icms.git) lammps-icms
    
    

And diff command on the file that I’m using and the one that you sent the link shows no difference. But I still get the same error with this updated file.

Kasra.

``

I'm using the same file as the file in the link you sent. Basically, I
downloaded the lammps-icms (as mentioned in your homepage) via :

git clone http://git.icms.temple.edu/lammps-icms.git lammps-icms

And diff command on the file that I'm using and the one that you sent the
link shows no difference. But I still get the same error with this updated
file.

that is impossible. there must be a mistake when you build your executable.
where did you copy the new file? to src/USER-MISC/? or to src/ ?
did you run 'make package-update'?

the patch is in the repository:
http://git.icms.temple.edu/git/?p=lammps-icms.git;a=commitdiff;h=f2e9c170d57df91570af834486a56d0c048614fb
and i ran your original test input without a problem. as i wrote earlier,
the necessary change is straightforward.

axel.

Sorry My bad, I didn’t run ‘make package-update’. I know I had to RTFM better. Now it works like a charm.

Much appreciation for your time and patience.

Cheers,

Kasra.