I am running a (generation) simulation with version lammps-30Oct14. There are 100 linear chains with 20 beads each–18 nonsticky beads making up the bulk of the chain and 1 sticky bead at each end. I want the terminal beads of each chain to get “stickier” with each timestep (100000 timesteps total). Thus, I am trying to use the fix_adapt command to ramp epsilon for the sticky-sticky interaction with each timestep. The terminal (sticky) beads have been assigned a group ID of type 2, while nonsticky beads are of type 1. The goal of the simulation is to observe domain formation (sticky bead aggregates). To promote aggregation, epsilon 2 2 is ramped and sticky-nonsticky interactions (epsilon 1 2) are designed to be purely repulsive. Here are the relevent lines of my input script (bolded):
fix 3 sticky adapt 1 pair lj/cut epsilon 2 2 v_EPS scale no reset no
In case of format adjustment when this email is sent, let me clarify that all data in the fix command is contained on a single line.
The simulation finished without any errors, but when I use the visualization tool, VMD, I am not convinced that the fix_adapt command is actually ramping epsilon. I would expect to see gradual aggregation of the sticky beads as epsilon increases, but there is no noticeable formation of these domains as the frames progress. This leads me to believe that epsilon 2 2 stays at its initial value of 1.0 rather than being ramped to 9.0. I included v_EPS in the thermo_style command in order to monitor epsilon values in the log/screen files, and I am seeing a steady increase in epsilon as the time progresses. However, it appears that this increase is entirely absent in VMD as the sticky beads do not show any increased affinity for each other. I have scrubbed the fix_adapt page on the lammps site and cannot find any syntax errors in my input. Any suggestions would be greatly appreciated.
I am running a (generation) simulation with version lammps-30Oct14. There are 100 linear chains with 20 beads each–18 nonsticky beads making up the bulk of the chain and 1 sticky bead at each end. I want the terminal beads of each chain to get “stickier” with each timestep (100000 timesteps total). Thus, I am trying to use the fix_adapt command to ramp epsilon for the sticky-sticky interaction with each timestep. The terminal (sticky) beads have been assigned a group ID of type 2, while nonsticky beads are of type 1. The goal of the simulation is to observe domain formation (sticky bead aggregates). To promote aggregation, epsilon 2 2 is ramped and sticky-nonsticky interactions (epsilon 1 2) are designed to be purely repulsive. Here are the relevent lines of my input script (bolded):
fix 3 sticky adapt 1 pair lj/cut epsilon 2 2 v_EPS scale no reset no
In case of format adjustment when this email is sent, let me clarify that all data in the fix command is contained on a single line.
The simulation finished without any errors, but when I use the visualization tool, VMD, I am not convinced that the fix_adapt command is actually ramping epsilon. I would expect to see gradual aggregation of the sticky beads as epsilon increases, but there is no noticeable formation of these domains as the frames progress. This leads me to believe that epsilon 2 2 stays at its initial value of 1.0 rather than being ramped to 9.0. I included v_EPS in the thermo_style command in order to monitor epsilon values in the log/screen files, and I am seeing a steady increase in epsilon as the time progresses. However, it appears that this increase is entirely absent in VMD as the sticky beads do not show any increased affinity for each other. I have scrubbed the fix_adapt page on the lammps site and cannot find any syntax errors in my input. Any suggestions would be greatly appreciated.
Did you consider, that you have a cutoff on your lj interactions?
I suggest you add a print line at the top of the compute() method
in pair_lj_cut.cpp and every N timesteps, print out the value
of epsilon[2][2], and likewise the lj1234[2][2] variables that contain
it. That is the best way to check if epsilon is indeed being
ramped. You could also put a check inside the double
loop to see how many 2/2 interactions are actually being computed.
As Axel indicated, it could be nearly none.
Thank you for the recompiling instructions, and my apologies for replying to the wrong address.
I modified the cpp file to print epsilon [2][2] at each timestep, and found that it is not being ramped at all. Unfortunately, epsilon [2][2] is staying at 1.0 throughout the simulation despite the fix_adapt command in place.
I am using pair_style lj cut 2.5. I ran the in.chain script with the fix_adapt modifications and the epsilon ramp was successful. I went back through my input script and added my commands (line by line) to the in.chain script and discovered that run_style respa is not compatible with fix_adapt. After removing respa, I ran the simulation and observed both epsilon increasing (the printf modification in the cpp file was very helpful) and aggregation in VMD. I will have to find a close alternative to respa but I am satisfied for now. Thank you, Axel and Steve, for your prompt responses.
I am using pair_style lj cut 2.5. I ran the in.chain script with the
fix_adapt modifications and the epsilon ramp was successful. I went back
through my input script and added my commands (line by line) to the in.chain
script and discovered that run_style respa is not compatible with fix_adapt.
After removing respa, I ran the simulation and observed both epsilon
increasing (the printf modification in the cpp file was very helpful) and
aggregation in VMD. I will have to find a close alternative to respa but I
am satisfied for now. Thank you, Axel and Steve, for your prompt responses.
adding support for r-RESPA to a fix is often a pretty straightforward
affair. please try out the attached patch. to stay consistent with the
r-RESPA formalism, fix adapt should only be called on the outmost
timesteps. in order for that to work properly, the frequency (N) of
when fix adapt is called has to be commensurate with that or else it
will be called less frequently, e.g. every 10th step when the outer
respa step is on every other step and N is chosen to be 5.
please make some tests (i've only tested if it compiles) and let us
know if it works correctly.
thanks Axel - this update will be in the next patch.
Note that when running rRESPA the timestep counter
is for the outermost rRESPA level. Hence if you
use N = 1 in fix adapt (as you had before), it will
update every outer step, as desired.
then you should removed/adapt the the corresponding text in the doc
files that are based on me misunderstanding the RESPA implementation.
The “timestep”_timestep.html command sets the timestep for the
outermost rRESPA level. Thus if the example command above for a
4-level rRESPA had an outer timestep of 4.0 fmsec, the inner timestep
would be 8x smaller or 0.5 fmsec. All other LAMMPS commands that
specify number of timesteps (e.g. “neigh_modify”_neigh_modify.html
parameters, “dump”_dump.html every N timesteps, etc) refer to the
outermost timesteps.
Are you referring to some other part of the doc pages?
I followed the steps on the LAMMPS site for applying patches:
-save patch file in my top-level LAMMPS directory (this directory contains LICENSE and README)
-within that directory, type “patch -bp1 < filename” into the terminal
-a list of updated files prints to the screen
-within the src directory, type “make package-update”
-while still in src, rebuild LAMMPS with “make alex” command
I ran a simulation and observed an inactive fix_adapt command (I kept the modified cpp file to print epsilon throughout the simulation, and epsilon did not ramp). It is possible that the patch was ineffective, but I also question whether or not LAMMPS was patched successfully. I am using LAMMPS-30Oct14.
It’s iffy to apply a current patch to an old version of LAMMPS.
If the patch didn’t complain it should have been OK, but no
guarantees. As the bug page states:
Apply individual patch files to your copy of LAMMPS and do an
incremental re-build, as described on the “download
page”_download.html#patches. This requires you to apply patches in
chronological order, starting from the date of your copy of LAMMPS, to
stay up-to-date.
Note that it should generally be possible to apply a specific patch
below to the preceeding stable version, assuming the patch command is
able to do its magic. E.g. patches that minmally touch just a file or
two.
Failing all that, just download the current version.
it looks like the patch was applied correctly. however, my changes
were incomplete and had a bug, which explains why it had no effect. i
have now reviewed and tested the changes and added the missing pieces
and fixed the bugs i could find.
if you apply the attached patch on top of this, it should work now. at
least it worked for me with the latest development version. since this
only add code or modifies what was added in the previous patch, it
should not matter whether you have a current or somewhat older version
of LAMMPS.
I upgraded to the latest version of lammps, 9Dec14, to avoid any headaches. After applying both patches, it appears that fix_adapt and respa are cooperating. Many thanks to both of you.