fix colvars in parallel tempering simulation

Hi All,

Can I use the “fix colvars” package during a parallel tempering simulation?

When I use the following input file to perform parallel tempering, the probability distribution of the collective variable I got is different from the one simulated at a single temperature.

In the example provided in the lammps manual, only “fix nvt” is used in parallel tempering. So I’m wondering whether it is designed to not work with other “fixes” that I included here.

Thanks,
Bin

++++++++++++++++++++++++++++++++++++++++++++++++++

units real
timestep 2
dimension 3

boundary s s s
variable T world 350 365

neighbor 10 bin
neigh_modify delay 5
atom_modify sort 0 0.0
special_bonds fene
atom_style peptide

bond_style harmonic
pair_style vexcluded 2 3.5 3.5

read_data data.restart

pair_coeff * * 0.0
pair_coeff 1 1 20.0 3.5 4.5
pair_coeff 1 4 20.0 3.5 4.5
pair_coeff 4 4 20.0 3.5 4.5
pair_coeff 3 3 20.0 3.5 3.5

velocity all create ${T} 2349852

group2ndx groups.ndx

fix 2 alpha_carbons backbone beta_atoms oxygens fix_backbone_coeff.data 1ubqA.seq

fix 4 all colvars protCont.colvars output out_temp${T}
fix_modify 4 energy yes

thermo 1000
dump 1 all atom 10000 dump_temp${T}.lammpstrj

dump_modify 1 sort id

Hi All,

Can I use the "fix colvars" package during a parallel tempering simulation?

When I use the following input file to perform parallel tempering, the
probability distribution of the collective variable I got is different from
the one simulated at a single temperature.

sure. that is what i would expect.

In the example provided in the lammps manual, only "fix nvt" is used in
parallel tempering. So I'm wondering whether it is designed to not work with
other "fixes" that I included here.

this is more of a conceptual question. in parallel tempering, you swap
temperatures between simulations. thus a single trajectory will
"visit" different temperatures over the course of time. to get the
single temperature distribution, you would have to break the
collective variable data into segments between swap attempts and then
assemble your distribution from all of the segments at the same
temperature. and strictly speaking, you'd even have to drop a segment
of data after a successful swap, since that would represent
equilibration at the new temperature. for the latter reason, people
often set up parallel tempering so that the time between swap attempts
is chosen so that the system is just reasonably equilibrated and then
you only keep the frame where you swap (and attribute it to the "old"
temperature).

axel.

Hi Axel,

Thanks a lot for your nice explanation.

Parallel tempering in principle should correctly sample Boltzmann distribution for each single temperature. However, as you pointed out, that is based on the assumption that the simulation at each given temperature is sufficiently relaxed before the swap attempt.

The swap frequency 100 I used in my simulation is certainly not sufficient for that purpose. I will try the scheme you suggested—keep the frame where you swap—with a larger swap frequency.

Best regards,
Bin

P.S. Thanks for contributing such a nice colvars package to LAMMPS.

Hi Axel,

Thanks a lot for your nice explanation.

Parallel tempering in principle should correctly sample Boltzmann
distribution for each single temperature. However, as you pointed out, that
is based on the assumption that the simulation at each given temperature is
sufficiently relaxed before the swap attempt.

The swap frequency 100 I used in my simulation is certainly not sufficient
for that purpose. I will try the scheme you suggested---keep the frame where
you swap---with a larger swap frequency.

well, you'll also have to write a tool that takes the replica vs.
temperature map from the log file and reassembles the colvars
trajectory files accordingly. i am certain that other users would
appreciate it, if you contribute it to the LAMMPS distribution.

Best regards,
Bin

P.S. Thanks for contributing such a nice colvars package to LAMMPS.

the credit for colvars goes to jerome henin and giacomo fiorin that
worked (and argued) for a long time to build it. i only wrote the
wrapper to interfaces it to LAMMPS (which was easy, because the
colvars library is so well designed).

axel.

this is more of a conceptual question. in parallel tempering, you swap
temperatures between simulations. thus a single trajectory will
“visit” different temperatures over the course of time.

Sorry, perhaps I did not read your email as carefully as I thought.

Suppose I use the following line in the Lammps input file,
“variable T world 350 365
fix 4 all colvars protCont.colvars output out_temp${T}”
and I am running the simulation with two cpus 1 and 2.

Before the swap is attempted, cpu1 will be running at temperature 350 and write the collective variable to out_temp350.traj.
After a successful swap, cpu1 will be running at temperature 365, but continue write to out_temp350.traj. This happens because Lammps actually exchanges the temperature but not the configuration.

Is this what happens in the simulation? I did not fully understand this previously.

Thanks for your help.
Bin

>> this is more of a conceptual question. in parallel tempering, you swap
>> temperatures between simulations. thus a single trajectory will
>> "visit" different temperatures over the course of time.

Sorry, perhaps I did not read your email as carefully as I thought.

Suppose I use the following line in the Lammps input file,
"variable T world 350 365
fix 4 all colvars protCont.colvars output out_temp${T}"
and I am running the simulation with two cpus 1 and 2.

Before the swap is attempted, cpu1 will be running at temperature 350 and
write the collective variable to out_temp350.traj.
After a successful swap, cpu1 will be running at temperature 365, but
continue write to out_temp350.traj. This happens because Lammps actually
exchanges the temperature but not the configuration.

yes. all parallel tempering implementations i know operate like that.
swapping configurations would be silly, since it is a lot of
communication, while swapping temperatures achieves the same thing by
communicating a single number. in some MD codes, the whole thing is
grafted onto the MD code with some scripting without even modifying
the MD code itself.

axel.