Dear users,
I using moltemplate to prepare my system. My system has gtlucose and water. I have downloaded the forcefield and structure files from atb server in .lt format. When I run moltemplate.sh it is showing there are no atoms in your system. I am attaching the required files. Please have a look and help me.
Regards
Sasthi
system.lt (271 Bytes)
GROMOS_54A7_ATB.lt (265 KB)
glucose.lt (21.8 KB)
However, I modified these but again get the same error. The modified files are attached.
system.lt (363 Bytes)
glucose_opt_geom.lt (21.8 KB)
GROMOS_54A7_ATB.lt (265 KB)
glucose_box.lt (657 Bytes)
Dear Sasthi
You had the right idea when you modified the files to create the “glucose_box.lt”. (More details below.)
First of all, to other moltemplate users who are also getting this error message, (who arrive here via google), this error occurs whenever you forgot to tell moltemplate how many of each molecule type you want in your simulation. To do that, you must use the “new” command (as explained in pages 18-19 (section 4.2) of the current version of the moltemplate manual. You must use the “new” commands in the global/outermost scope. “new” commands which appear nested within a compound molecule definition will not get rid of this error message, unless you instantiate the molecule in which they appear.) But this is not Sasthi’s problem. Sasthi’s problems are ATB-specific:
----- ATB troubleshooting -----
For ATB users, there appear to be several additional difficulties:
This seems needlessly painful. Perhaps I should send the folks at ATB an email with some suggestions to make it easier for end-users to use ATB with LAMMPS and moltemplate? It seems like it might be worth the effort to offer to coordinate with them.
Details:
glu = new GROMOS_54A7_ATB/_ICT [5].move(0,0,7.0)
[5].move(0,7.0,0)
[5].move(7.0,0,0)
All of this is explained in the “glucose.lt” file (and “glucose_opt_geom.lt” file), however I don’t fault you for not reading this file carefully.
Note: A spacing of 3.45 Angstroms was far too small and was causing numerical explosions. I set it to “7.0”, and I still needed to use minimization (ie the “minimize” command) to avoid explosions. The resulting geometry is still unrealistic. You can often get more efficient packing density using PACKMOL. (A discussion of how to read packmol coordinates is mentioned in section 4.1 of the moltemplate manual, and demonstrated in more detail in these two examples: example1, example2) I updated the example and attached some new files to the end of this post. (See below.)
mass * 1.0
…so you know explicitly what mass LAMMPS is using.
https://lammps.sandia.gov/doc/mass.html
As explained in the instructions, you have to remember to define the “cutoff” variable before you include “system.in.init” in your LAMMPS script (which contains the “pair_style” command). The chose to set it to 14.0, but I would probably have chosen something smaller like “11.0” or “12.0”.
variable cutoff equal 12.0
14.0 seems pretty large and will slow down the simulation. I suspect it’s much larger than what GROMACS uses. Perhaps I should seek clarification from the ATB whether it is necessary to use such a large cutoff.
Unfortunately some of these instructions provided by ATB are incorrect (or at least very poorly chosen), such as telling people to use “boundary f f f”, instead of “boundary p p p”. You should probably use periodic boundary conditions for most of your simulations. (Or at least, use shrink-wrapped boundaries.)
https://lammps.sandia.gov/doc/boundary.html
Also, you should also never use the default “dump” command with molecular systems, for example, don’t use this:
dump 1 all atom 500 dump.lammpstrj
I recommend using this instead:
dump 1 all custom 500 traj_npt.lammpstrj id mol type x y z ix iy iz
Anyway, I’m sorry to learn that using ATB is difficult. I hope this helps get you passed your current impasse.
Incidentally, I attached a corrected version of your system to this message, including “glucose_opt.geom.lt”, and “system.lt” which uses the correct synta. I also attached a LAMMPS input script which works with your system “run.in” (a modified version of “system.in”). (I did not re-send the “GROMOS_54A7_ATB.lt” file you posted earlier in this thread because it’s so large, but you will need that too.)
Instructions:
moltemplate.sh system.lt
#(or moltemplate.sh -vmd system.lt)
lmp_mpi -i run.in
#(or “mpiexec -np 4 lmp_ubuntu -i run.in” etc…)
(Incidentally, the “cutoff” parameter is defined in “run.in” and I arbitrarily set it to 12.0. I don’t know if this is correct.)
Cheers
Andrew
P.S. Comments / Rants:
glu = new _ICT [5].move(0,0,7.0)
[5].move(0,7.0,0)
[5].move(7.0,0,0)
It would also be a bit nicer if they gave users the option to include the entire “GROMOS_54A7” force field with the “GROMOS_54A7_ATB.lt” file, instead of only the parameters for the atoms in your molecule(s). Perhaps I can ask them about this as well.
system.lt (1.15 KB)
glucose_opt_geom.lt (21.8 KB)
run.in (1.7 KB)
Since posting my reply, Thomas Lee (CC'd) has reached out to me, and
we have discussed the difficulties that users might have when using
ATB with moltemplate. I'd also like to clear up some mistakes and
misunderstandings that I had about ATB. Hopefully this will prevent
confusion for ATB users in the future.
Summary: ATB looks like it is an extremely useful resource for LAMMPS
users running all-atom simulations.
Misconception: The ATB is only relevant to users who want to use the
GROMOS force field.
Unlike GROMOS (a united-atom force-field for proteins), the ATB was
designed as a resource to create models of general organic molecules.
(They are working on developing their own general all-atom protein
force-field as well.)
Unlike GROMOS, both united-atom and all-atom versions of molecular
models are provided. For the united-atom models, ATB borrows some of
the atom types, bond types, and angle types used by the GROMOS force
field whenever possible. However, unlike GROMOS, the ATB also offers
all-atom versions of each molecule.
In both cases (all-atom and united-atom), for each molecule the
bond, angle, dihedral and improper force-field parameters for every
interaction in the molecule are calculated directly from
density-functional theory (and replaced by force-field rules only when
the parameters in the force-field do not agree with the DFT
calculations).
Presumably, the resulting molecular models should be more accurate and
have much wider applicability compared to using GROMOS.
A quote from Thomas Lee:
"On the relationship between GROMOS and the ATB:
The GROMOS force field is only defined for proteins and a few solvent,
ions, and small molecules relevant to protein simulations. The ATB is
not GROMOS, but it used GROMOS as a starting point and remains
backwards compatible with GROMOS (i.e. original atom types, bond types
are still available and use the same parameters), so you can use a
GROMOS protein with an ATB ligand. You are correct that GROMOS is
united atom only but the ATB provides both united and all atom
topologies. We are actually in the process of developing an all-atom
ATB protein force field, but this is still in the early stages."
"For bonded force fields, we use QM calculations of the hessian to
calculate the bond and angle force constants. We then check if an
existing bond/angle type exists in the force field (including the
original GROMOS bond and angle types) that is close enough to the QM
calculation (i.e. within expected accuracy of the QM). If not, the
ATB automatically creates a new bond/angle type and adds it to the
force field. My understanding is that we now (after > 100,000
molecules) have enough bond and angle types that new ones are not
often added. Dihedrals, on the other hand, come from the original
GROMOS set and are assigned based on a set of rules. But this will
soon be superseded by a QM approach we have developed."
Dear Sasthi
----- ATB troubleshooting -----
1) It's difficult to figure out how to refer to your molecule in the "new" command.
This might change. (See below)
2) The files downloaded from ATB do not include the atomic masses. (?)
Not true. This was a mistake on my part.
3) As explained in the instructions, you have to remember to define the "cutoff" variable before you include "system.in.init" in your LAMMPS script.
4) Bad instructions in the ".lt" files created by the ATB database.
The instructions are not that bad.
If you run simulations using those suggestions, the simulations will not crash.
(But I suggested some small changes).
Details:
1) To be fair to the people at ATB, every molecule file (".lt" file) downloaded from the ATB database includes a long comment section at the beginning with instructions how to use these files. In your case, the "glucose.lt" file defines a molecule named "_ICT". (...which they decided to have nested within the definition of the "GROMOS_54A7_ATB" force field object. This means that you must refer to that molecule as "GROMOS_54A7_ATB/_ICT", not "_ICT". For example, in your "system.lt" file (or "glucose_box.lt" file), you must refer to it this way:
glu = new GROMOS_54A7_ATB/_ICT [125]
All of this is explained in the "glucose.lt" file (and "glucose_opt_geom.lt" file), however I don't fault you for not reading this file carefully.
I have asked Thomas to change the format of the files created by ATB
slightly, so that in the future users can use this syntax instead:
glu = new _ICT [125]
(Incidentally, in this example "_ICT" was the name given to the
glucose molecule.)
This is the same syntax used in most of the moltemplate examples,.
Perhaps future versions of files created by ATB will work this way.
In my opinion, this was the most important change that would make it
easier for people to use ATB with moltemplate. But perhaps ATB users
might not have such strong opinions about this as I do.
2) I just noticed that the files from the ATB database do not include the masses of any of the atoms in your system.
I was completely wrong about this. (Sorry, I was looking at a
corrupted version "GROMOS_54A7_ATB.lt" which was not the file returned
by the ATB server.) The real "GROMOS_54A7_ATB.lt" does indeed include
all of the masses (and pair_coeffs) for every atom type.
3)
As explained in the instructions, you have to remember to define the "cutoff" variable before you include "system.in.init" in your LAMMPS script (which contains the "pair_style" command). The chose to set it to 14.0, but I would probably have chosen something smaller like "11.0" or "12.0".variable cutoff equal 12.0
14.0 seems pretty large and will slow down the simulation. I suspect it's much larger than what GROMACS uses. Perhaps I should seek clarification from the ATB whether it is necessary to use such a large cutoff.
I was wrong about this too. I read somewhare that the GROMOS force
field use a 14.0 angstrom cutoff by default, so it makes sense that
the ATB would suggest this as a default.
4)
Unfortunately some of these instructions provided by ATB are incorrect (or at least very poorly chosen), such as telling people to use "boundary f f f", instead of "boundary p p p". You should probably use periodic boundary conditions for most of your simulations. (Or at least, use shrink-wrapped boundaries.)
LAMMPS Molecular Dynamics Simulator
Thomas uses "boundary f f f" boundary conditions because in his
example, he was simulating a single molecule. I did not tell him to
remove that example, but I suggested he also include an additional
comment to mention that "p p p" should be used for condensed-phase
simulations. (Simulations of a single molecule are pretty unusual.)
Either way, most LAMMPS users armed with google should be able to
figure this out on their own.
Also, you should also never use the default "dump" command with molecular systems, for example, don't use this:
dump 1 all atom 500 dump.lammpstrjI recommend using this instead:
dump 1 all custom 500 dump.lammpstrj id mol type x y z ix iy iz
My opinion is not relevant. I withdraw this suggestion.
People can use whatever dump style they prefer.
Anyway, I'm sorry to learn that using ATB is difficult. I hope this helps get you passed your current impasse.
Honestly, my comments were all minor quibbles.
Moltemplate has a complicated file format and Thomas has done a great
job creating files that use this format.
The ATB works.
(And at first glance, it seems to be more polished and more consistent
than LibParGen.)
In my opinion, the ATB is currently the best method to get molecules
into LAMMPS (using moltemplate at least).
Cheers
Andrew
Since posting my reply, Thomas Lee (CC'd) has reached out to me, and
we have discussed the difficulties that users might have when using
ATB with moltemplate. I'd also like to clear up some mistakes and
misunderstandings that I had about ATB. Hopefully this will prevent
confusion for ATB users in the future.Summary: ATB looks like it is an extremely useful resource for LAMMPS
users running all-atom simulations.Misconception: The ATB is only relevant to users who want to use the
GROMOS force field.Unlike GROMOS (a united-atom force-field for proteins), the ATB was
designed as a resource to create models of general organic molecules.
(They are working on developing their own general all-atom protein
force-field as well.)Unlike GROMOS, both united-atom and all-atom versions of molecular
models are provided. For the united-atom models, ATB borrows some of
the atom types, bond types, and angle types used by the GROMOS force
field whenever possible. However, unlike GROMOS, the ATB also offers
all-atom versions of each molecule.
In both cases (all-atom and united-atom), for each molecule the
bond, angle, dihedral and improper force-field parameters for every
interaction in the molecule are calculated directly from
density-functional theory (and replaced by force-field rules only when
the parameters in the force-field do not agree with the DFT
calculations).
(Sorry. Typo: That should have been "do agree".)
Presumably, the resulting molecular models should be more accurate and
have much wider applicability compared to using GROMOS.A quote from Thomas Lee:
"On the relationship between GROMOS and the ATB:
The GROMOS force field is only defined for proteins and a few solvent,
ions, and small molecules relevant to protein simulations. The ATB is
not GROMOS, but it used GROMOS as a starting point and remains
backwards compatible with GROMOS (i.e. original atom types, bond types
are still available and use the same parameters), so you can use a
GROMOS protein with an ATB ligand. You are correct that GROMOS is
united atom only but the ATB provides both united and all atom
topologies. We are actually in the process of developing an all-atom
ATB protein force field, but this is still in the early stages."
This quote from Thomas clarifies this. (Perhaps I don't need to post
a correction.)