You're probably right that the fix nvt isn't being applied to the newly-inserted molecules, but I haven't verified this and this is the first I've heard of the issue. Nice that you've found a good work-around in the meanwhile. If you'd like to send me complete input that clearly illustrates the issue, I can take a closer look.
Note that the reservoir is completely notional as far as LAMMPS's fix gcmc is concerned, so the molecules/atoms don't exist yet, and it is not possible to reference, thermostat, or manipulate molecules or atoms in the reservoir. But when they are inserted, they should be inserted at the set point temperature you specify in the fix gcmc command (in your case 303.0 K).
There are not currently any bond, angle, or dihedral MC moves in LAMMPS. The only MC moves are exchanges (insert/delete), translations, and rotations.
Paul
Thanks Paul for the information there. Is there any other section of LAMMPS source that relies on two systems? I’m just wondering if I could implement a little reservoir here for GCMC, and it would be the best if I could have a whole separate system so that I could turn this into the Gibbs ensemble method or some other algorithm that relies on exchanges between systems, because “fix nvt” should work with that as well! For GCMC it could just be one single molecule that I keep changing, but in more complex algorithms the reservoir is a whole separate system of interacting molecules.
I’m not sure if anyone has ever implemented something like this, perhaps in some other part of the LAMMPS code? Or is the system always just one system with one set of pair styles like lj/cut coul/cut that always has to apply to everything?
Thanks,
Luke
Sounds like you’re asking about a GEMC (Gibbs ensemble Monte Carlo) capability for LAMMPS. It has been considered, but AFAIK, no one has implemented one. I think it would be nice to have, but non-trivial to properly implement and support.
The other part of your question has to do with multiple separate simulations being run by LAMMPS simultaneously, with possible periodic interactions or exchange of particles or information between them. Take a look at the temper command: http://lammps.sandia.gov/doc/temper.html Also, see the partition command line option: http://lammps.sandia.gov/doc/Section_start.html#start_7 and the multi-replica simulations section here: http://lammps.sandia.gov/doc/Section_howto.html#howto_5 So the short answer is yes, LAMMPS can run more than one separate system at once, and they can interact.
Paul
Thanks Paul. I got a new dump command working by implementing a new DumpVis class with DumpVis::write() to send the data, and I use this in the interpreter to run it:
dump 1 all vis 1000 localhost port 7000
I wrote the DumpVis::modify_param() function pasted below, but it doesn’t seem to call it in the execution of my LAMMPS script (I see the constructor and init_style executed only):
int DumpVis::modify_param(int narg, char **arg)
{
printf(“modify_param\n”);
if (strcmp(arg[0],“port”) == 0) {
if (narg < 2) error->all(FLERR, “Illegal dump_modify”);
if (sscanf(arg[1], “%d”, &port) != 1) error->all(FLERR, “Illegal dump_modify port number”);
printf(“Done, port = %d\n”, port);
return 2;
}
return 0;
}
It draws the system in my other little program (the dump could be modified to work with other programs like VMD) and I can look at the evolution.
I was also wondering about the atom styles data. If I have the atom style as Full, can I add the radius to that or do I need to select a different style? I was just going to use the radius to Dump to the output and I could use a bunch of extra fields.
Thanks,
Luke
Thanks Paul. I got a new dump command working by implementing a new
DumpVis class with DumpVis::write() to send the data, and I use this in the
interpreter to run it:
dump 1 all vis 1000 localhost port 7000
I wrote the DumpVis::modify_param() function pasted below, but it doesn't
seem to call it in the execution of my LAMMPS script (I see the constructor
and init_style executed only):
modify_param() is called when you use the dump_modify command.
int DumpVis::modify_param(int narg, char **arg)
{
printf("modify_param\n");
if (strcmp(arg[0],"port") == 0) {
if (narg < 2) error->all(FLERR, "Illegal dump_modify");
if (sscanf(arg[1], "%d", &port) != 1) error->all(FLERR, "Illegal
dump_modify port number");
printf("Done, port = %d\n", port);
return 2;
}
return 0;
}
It draws the system in my other little program (the dump could be modified
to work with other programs like VMD) and I can look at the evolution.
there is already fix imd to hook up simulations to VMD without having
either the simulation slowed down by VMD or vice versa.
I was also wondering about the atom styles data. If I have the atom style
as Full, can I add the radius to that or do I need to select a different
style? I was just going to use the radius to Dump to the output and I could
use a bunch of extra fields.
you can add properties using a hybrid atom style.
axel.
I believe I found the solution here for “fix gcmc” with “fix nvt”:
fix 1 all nvt temp 303.0 303.0 100.0
compute_modify 1_temp dynamic yes
fix 2 mol gcmc 2000 1 0 1 29494 303.0 -1.5 0.1 molecule yes
run 1000000
That’s the compute ID the fix nvt is using to compute the temperature in the fix_nvt.cpp source file so now it is updating the nlocal atoms.
-Luke
Thanks Axel, I was wondering about IMD and VMD. This visualizer here just does two things:
-
Renders w/ the box vectors (similar to “pbc box_draw” i suppose) straight from LAMMPS and with the given radius (I’ll try the hybrid style and set it to default to 2 if its just Full style, because it looks like then the radius is totally unallocated).
-
Can easily handle the changing number of particles in the GCMC.
So I like VMD a lot but I was wondering if there are any specific features for reading in variable particle number trajectories? VMD doesn’t like to load these things but perhaps there is some advanced methods or workarounds?
Luke
Thanks Paul. I got a new dump command working by implementing a new
DumpVis class with DumpVis::write() to send the data, and I use this in the
interpreter to run it:
dump 1 all vis 1000 localhost port 7000
I wrote the DumpVis::modify_param() function pasted below, but it doesn’t
seem to call it in the execution of my LAMMPS script (I see the constructor
and init_style executed only):
modify_param() is called when you use the dump_modify command.
int DumpVis::modify_param(int narg, char **arg)
{
printf(“modify_param\n”);
if (strcmp(arg[0],“port”) == 0) {
if (narg < 2) error->all(FLERR, “Illegal dump_modify”);
if (sscanf(arg[1], “%d”, &port) != 1) error->all(FLERR, “Illegal
dump_modify port number”);
printf(“Done, port = %d\n”, port);
return 2;
}
return 0;
}
It draws the system in my other little program (the dump could be modified
to work with other programs like VMD) and I can look at the evolution.
there is already fix imd to hook up simulations to VMD without having
either the simulation slowed down by VMD or vice versa.
I was also wondering about the atom styles data. If I have the atom style
as Full, can I add the radius to that or do I need to select a different
style? I was just going to use the radius to Dump to the output and I could
use a bunch of extra fields.
you can add properties using a hybrid atom style.
axel.
Thanks Axel, I was wondering about IMD and VMD. This visualizer here just
does two things:
1) Renders w/ the box vectors (similar to "pbc box_draw" i suppose) straight
from LAMMPS and with the given radius (I'll try the hybrid style and set it
to default to 2 if its just Full style, because it looks like then the
radius is totally unallocated).
what have box vectors to do with "radius" (of atoms?). pbc box has
different options
what it lacks is the location of the box origin, since that is not
stored in VMD.
2) Can easily handle the changing number of particles in the GCMC.
not really. there are several workarounds that have been developed
over the years (i have been involved in at least 3 of them). the all
come down to two strategies: each frame is a different "molecule" and
then only one of them is shown, or there are additional dummy atoms
created/allocated and then shown or hidden as needed. what changes is
how this is organized and where in the process the workaround becomes
active.
it cannot easily be changed since VMD in many places assume that the
topology and identity of atoms doesn't change and uses that fact for
many optimizations. for the common case where VMD is used, this is a
very valid assumption and the performance gains and savings in
resources are large.
So I like VMD a lot but I was wondering if there are any specific features
for reading in variable particle number trajectories? VMD doesn't like to
load these things but perhaps there is some advanced methods or workarounds?
the workarounds that i wrote are the multiple molecule animation
plugin, the variable frame size xyz file reader in the topotools
plugin, and the LAMMPSMAXATOMS hack in the lammps trajectory reader
molfile plugin. they all have advantages and shortcomings.
axel.
Thanks for the information there. I’m mainly debugging code and looking at the behavior of the system with new potentials and within the GCMC so it’s a quick way to view the system evolution. The radius is just to render the view quickly (for spheres and shapes like slabs that I’m using for DNA models) and I’m also using the radius as a parameter in my new potential, so it’s unrelated to the box (besides for relative scaling I suppose).
I have a MC version of this potential to compute the burial of groups and so I’m trying to use the available LAMMPS facilities to load these parameters into… I’ll let you know if I have any problems with using the existing hybrid styles.
thanks
-Luke
Thanks Axel, I was wondering about IMD and VMD. This visualizer here just
does two things:
- Renders w/ the box vectors (similar to “pbc box_draw” i suppose) straight
from LAMMPS and with the given radius (I’ll try the hybrid style and set it
to default to 2 if its just Full style, because it looks like then the
radius is totally unallocated).
what have box vectors to do with “radius” (of atoms?). pbc box has
different options
what it lacks is the location of the box origin, since that is not
stored in VMD.
- Can easily handle the changing number of particles in the GCMC.
not really. there are several workarounds that have been developed
over the years (i have been involved in at least 3 of them). the all
come down to two strategies: each frame is a different “molecule” and
then only one of them is shown, or there are additional dummy atoms
created/allocated and then shown or hidden as needed. what changes is
how this is organized and where in the process the workaround becomes
active.
it cannot easily be changed since VMD in many places assume that the
topology and identity of atoms doesn’t change and uses that fact for
many optimizations. for the common case where VMD is used, this is a
very valid assumption and the performance gains and savings in
resources are large.
So I like VMD a lot but I was wondering if there are any specific features
for reading in variable particle number trajectories? VMD doesn’t like to
load these things but perhaps there is some advanced methods or workarounds?
the workarounds that i wrote are the multiple molecule animation
plugin, the variable frame size xyz file reader in the topotools
plugin, and the LAMMPSMAXATOMS hack in the lammps trajectory reader
molfile plugin. they all have advantages and shortcomings.
axel.