I found a type in the "oplsaa.lt" file I posted last week, and have
attached a corrected version.
There's also a warning later on in the body of this email message.
(Avoid using "*" characters within "pair_coeff" commands in moltemplate.)
Sorry to keep this thread alive. Hopefully this will be the last message.
Cheers
Andrew
Dear Andrew,
I am using your software (moltemplate) to build a system with two kind
of molecules (hexadecane and pentane). I have departed from the
hexadecane example and I am using the OPLS potential given. I am
building both hexadecane and pentane using CH2 and CH3 monomers which
define inside 3 different types of atoms (H, C(CH3) and C(CH2)). The
problem is that after generating lammps input obviously only 3 types of
atoms are present but I would like to have 6 (3 for the hexadecane and 3
for pentane). That is because I have a wall that interacts with
different lj epsilon depending wether it is methane or hexane and I need
to differentiate between them.Eduardo
Dear Eduardo
Interesting example. I think the cleanest way to handle this
issue is to modify the oplsaa.lt file storing the force-field
parameters. (In other words, use oplsaa_moltemplate.py to generate a
new "oplsaa.lt" file, and modify it.) Edit the new "oplsaa.lt" file
so that it now has two kinds of CH3 and CH2 carbon atoms with a
similar text pattern. (You can use whichever names you like, but in
the attached file, I use "@atom:80_a", and "@atom:80_b" to denote CH3
carbon in hexadecane and pentane, respectively. Both match the
text-pattern "@atom:80_*".)Later on, in the "Data Bonds By Type", "Data Angles By Type", "Data
Dihedrals By Type", and (if applicable) "Data Impropers By Type"
sections, I would replace the corresponding atom type names (eg
"@atom:80"), with "@atom:80_*", where "*" is a wildcard. This will
pattern-match both @atom:80_a and @atom:80_b. (This tells moltemplate
not to distinguish between these two different types of CH3 atoms when
generating bonded-interactions, and looking up force-field parameters
for them).
Warning:
This wildcard expansion feature ONLY works inside the "BY TYPE" sections.
It does NOT work inside the write_once("In Settings") sections, in
"coeff" commands, or anywhere else. So, for example, do not attempt
to use wildcards elsewhere, as in:
write_once("In Settings") {
pair_coeff @atom:80_* @atom:80_* lj/cut/coul/long 0.066 3.5
...
}
write_once("Data Masses") {
@atom:80_* 12.011
...
}
write_once("In Charges"){
set type @atom:80_* charge -0.18
...
}
Instead, you must write the name of each atom type explicitly, here.
write_once("In Settings") {
pair_coeff @atom:80_a @atom:80_a lj/cut/coul/long 0.066 3.5
pair_coeff @atom:80_b @atom:80_b lj/cut/coul/long 0.066 3.5
...
}
write_once("Data Masses") {
@atom:80_a 12.011
@atom:80_b 12.011
...
}
write_once("In Charges"){
set type @atom:80_a charge -0.18
set type @atom:80_b charge -0.18
...
}
Sorry. I did not realize how confusing this is until after I posted
the original message. The inconsistent use of wildcard characters is
a limitation mentioned in chapter 10 of the manual, but I don't expect
people to read that far. (This problem difficult to fix within
moltemplate, because LAMMPS also allows wildcard characters * inside
input script commands, for example "3*6". When used that way, it
means something quite different, and I did not want to interfere with
that. You actually CAN use "pair_coeff" commands with LAMMPS-style
wildcards (ie "3*6"), but you must use bracket notation as in:
"pair_coeff @{atom:80_a}*@{atom:80_b} ..." to prevent the * from being
interpreted as part of the variable name.. I avoid using LAMMPS-style
wildcards in moltemplate files as much as possible.)
oplsaa.lt (8.46 KB)