Creating a reduced version of the "pre yes" option for constantly changing forces.

Dear all,

I have created a C program which carries out an STMD simulation by calling LAMMPS as a library. STMD requires that the forces are changed at every timestep; I use the following sequence of steps:

  1. Create new variables in LAMMPS with the command variable newforce_x atom [force_x] for the x force I wish to impose. I do the same for y and z.
  2. Use fix force_control molecule setforce v_newforce_x v_newforce_y v_newforce_z to impose the forces.
  3. Run the simulation one step with the command run 1 pre yes post no , with pre yes so that LAMMPS will notice the new forces.
  4. Send the command unfix force_control so that I can start fresh next time-step.

Based on reading the documentation and mailing list threads, I believe that the pre yes option which I must use causes a major slowdown in the execution of my code. I would like to delve into the source code and create a reduced version called force yes , which does nothing more than notice the change in force. My attempts to implement this so far have not been successful; blind trial and error in seeing how much of pre I can turn off without things breaking is slow and error-prone.

Could I please have some guidance on what I can safely disable?

Regards,
Gil Rutter

dear gil,

Dear all,

I have created a C program which carries out an STMD simulation by calling
LAMMPS as a library. STMD requires that the forces are changed at every
timestep; I use the following sequence of steps:

1) Create new variables in LAMMPS with the command variable newforce_x
atom [force_x] for the x force I wish to impose. I do the same for y and
z.
2) Use fix force_control molecule setforce v_newforce_x v_newforce_y
v_newforce_z to impose the forces.
3) Run the simulation one step with the command run 1 pre yes post no ,
with pre yes so that LAMMPS will notice the new forces.
4) Send the command unfix force_control so that I can start fresh next
time-step.

o dear. this looks overly complex and convoluted.

Based on reading the documentation and mailing list threads, I believe that
the pre yes option which I must use causes a major slowdown in the
execution of my code. I would like to delve into the source code and create
a reduced version called force yes , which does nothing more than notice

no. that is not a reasonable approach. you shouldn't need
to go through the entire "setup" ordeal simply because of
changing the forces. otherwise fix addforce or fix setforce
would not work by itself.

the change in force. My attempts to implement this so far have not been
successful; blind trial and error in seeing how much of pre I can turn
off without things breaking is slow and error-prone.

Could I please have some guidance on what I can safely disable?

nothing of it. i don't see why you'd need go through this
ordeal. if there is a reason, you can't use the more elegant
method listed below, i'd rather write a few lines of code that
would define and update the variables that you are using in
fix setforce from the library interface. that should be sufficient
to use run with "pre no".

however, i would strongly recommend to look at is the
couple/lammps_quest example. this computes forces from an
external (QM) program and adds them to LAMMPS via the use
of a callback mechanism via fix external. no need to break at
each run step.

the only issue is, do you compute an additional force component
or do you need to replace the forces entirely?

in the first case, you can use fix external as is. in the second you'd
either have to change fix external to replace forces instead of adding,
or define fix setforce 0.0 0.0 0.0 on the same group of atoms before
using fix external to clear out the computed force.

cheers,
    axel.