Force field composition

[scmartin]

I have a force field which is an extension of another force field. The new force field is in it's own .lt file. Both force fields use 'Data XXX By Type', but I believe I found a bug. As an example if my new forcefield lt file is something like

import "forcefield1.lt" 

FF2 inherits FF1 {
write_once('Data Masses') {
...
}

write_once('Data Bonds By Type'){
@bond:ab @atom:a @atom:b
@bond:bc @atom:b @atom:c
}

write_once('Data Angles By Type') {
@angle:A @atom:a @atom:b @atom:c @bond:* @bond:*
...
}

}

then moltemplate fails to find the angles. After messing around with it for a bit, I found that it seems to be checking in the first forcefield file. The output from Moltemplate for generating 3-body interactions by atom/bond type looks similar to

checking @/angle:FF2/A type requirements:
['@atom:FF2/a', '@atom:FF2/b', '@atom:FF2/c', '@bond:FF1/ab '@bond:FF1/bc']

If I remove the @bond:* variables from the data angles by type lines, it works correctly.

[hothello]

Can you provide a complete input deck that reproduces this issue?

As a general comment: it only makes sense to use the bond terms constraints if you need to distinguish a specific triplet using something other than the atom types. But I agree that the behaviour of nbody_by_type.py with the @bond:* @bond:* terms added should match that without them.

[jewettaij]

I admit I don't have time to develop new features for moltemplate right now. But I will fix a bug if you can share an example. As Otello said, please send an example of this problem with a complete list of .lt files by posting here (or send them to jewett.aij@gmail.com). I will fix this. (I hate to see your efforts go to waste.)