Hi All,
I'm trying to use the Martini force field with a 10 fs timestep. However, I
keep losing atoms (bonds, angles, dihedrals). I've attached the most recent
simulation input file (General_Sim.in), the force field parameters
(ASA_Sheet.ff), a restart file, and the stdout that I get after the
restart files are not portable between platforms and setups and thus
most of the time useless. as i mentioned before, you need to provide a
suitable data file.
Hi All,
I’m having trouble getting a 10 fs timestep to work with the Martini CG force field. I’m losing bonds, angles, dihedrals…signs that I have bad particle communication.
I’ve attached the force field params, the simulation input, a data file and the error log.
I’m running the simulation on a dual octacore. I’ve tried to modify the skin distance, neigh_modify and communicate parameters but still can’t get a stable run. Suggestions on why the instability or a possible fix would be greatly appreciated.
Thanks
A5S20A5-equi.data (2.68 MB)
ASA_Sheet.ff (1.1 KB)
General_Sim.in (1.14 KB)
stdout (17.4 KB)
A5-S30-A5_sheet_group.pdb (1.24 MB)
Hi All,
I'm having trouble getting a 10 fs timestep to work with the Martini CG
force field. I'm losing bonds, angles, dihedrals...signs that I have bad
particle communication.I've attached the force field params, the simulation input, a data file and
the error log.I'm running the simulation on a dual octacore. I've tried to modify the
skin distance, neigh_modify and communicate parameters but still can't get a
stable run. Suggestions on why the instability or a possible fix would be
greatly appreciated.
your neighbor list and communication settings are *very* unusual.
i don't see much of a problem using a 20fs timestep with the default
settings for
neighbor 2.5 bin
neigh_modify delay 1 every 1 check yes
communicate single 0.0 # default
this will also run about twice as fast.
axel.
Hi Axel,
I used the default params you suggested:
neighbor 2.5 bin
neigh_modify delay 1 every 1 check yes
communicate single 0.0 # default
with a 20 fs timestep and the run crashed after 10000 steps.
I used the “unusual” neighbor list and communication settings because of the larger timestep and the softer spring constants. I thought things might be drifting to processors a bit faster.
Martini is implemented in Gromacs, using a neighbor list build ever 10 iterations, and a neighbor cutoff of 1.2 nm with a grid style algorithm. I’m assuming Gromacs handles neighbor list and atom migration differently than LAMMPS so this is likely the problem? Unfortunately, I don’t have adequate time to learn Gromacs so I’m trying to give it a try with LAMMPS.
Thank you again for the help.
Hi Axel,
I used the default params you suggested:
neighbor 2.5 bin
neigh_modify delay 1 every 1 check yes
communicate single 0.0 # defaultwith a 20 fs timestep and the run crashed after 10000 steps.
I used the "unusual" neighbor list and communication settings because of the
larger timestep and the softer spring constants. I thought things might be
drifting to processors a bit faster.Martini is implemented in Gromacs, using a neighbor list build ever 10
iterations, and a neighbor cutoff of 1.2 nm with a grid style algorithm.
I'm assuming Gromacs handles neighbor list and atom migration differently
than LAMMPS so this is likely the problem? Unfortunately, I don't have
adequate time to learn Gromacs so I'm trying to give it a try with LAMMPS.
you cannot easily translate the parameters. but honestly, if you
figured out how to use LAMMPS, learning how to run gromacs is not that
much of a jump. other MD codes are much quirkier and - same as LAMMPS
- gromacs has a decent documentation and plenty of tutorials
(including martini specific tutorials).
at this point, i would rather suspect that there is something less
than perfect with your topology or it is simply not possible to push
more in LAMMPS. if you cannot reach 20fs perhaps 15.fs will work ok.
if you have some freak fluctuations due to some jammed initial
configuration, it might help to run for a while with fix nve+langevin
and a comparative short time constant (which can be increased as the
system relaxes).
i don't know what else to recommend. perhaps trying to run a known
good system, i.e. take one of the martini demo examples and translate
them for LAMMPS and see how that behaves.
axel.
In a shorter (stable) run are you getting any “dangerous”
reneighborings listed at the end-of-the-run output?
If so, it means you are not letting LAMMPS reneighbor
when it might choose to.
So long as you are allowing LAMMPS to reneighbor every
timestep if it thinks it needs to, you should be able
to choose any skin distance you want. Of course some
choices may be faster than others.
Steve