foyer icon indicating copy to clipboard operation
foyer copied to clipboard

Multiple definitions for same atom type

Open bkpgh opened this issue 3 years ago • 3 comments

Is it permissible to have multiple definitions (on multiple lines) for a single atom type in a foyer .xml FF file? Will the atom typing work?

As a silly example:

Thanks

bkpgh avatar Jan 12 '21 15:01 bkpgh

Hi @bkpgh, currently I don't think it is possible to have multiple definitions for a single atom type. This is because there are some steps in constructing the force field, we create a dictionary with the key is the atom type and the item is the definitions (SMARTS string). So what will likely happen (I have not confirmed this yet) is one of the (atom type - definition) pair will be overwritten and the atom typing result will not be something you expect. Can you elaborate a bit more about the use case of having multiple definitions for a single atom type? We might be able to add this as a new feature in the future. Thanks!

daico007 avatar Jan 12 '21 16:01 daico007

Thanks; the dictionary implementation is the kind of thing I figured might get in the way. I'm thinking of a few use cases:

  1. Human readability. For example, it might quite transparent to produce a SMARTS that expresses "carbon atom adjacent to an electron withdrawing group" if "electron withdrawing group" is taken as an atom (N,O,F), but a little less transparent if you want to include those plus -CF3, CF2CF3, -SF5 etc. with different, more complex structures. It might be useful to have those definitions on separate lines.
  2. Similar to above, it might be easier for a human to formulate SMARTS for an atom type where an OR operation is implicit by having separate lines.
  3. Apparently different SMARTS coming from different sources, but for the same atom type. What the heck, just throw them all in. One or more sources could be machine-generated. Details left to the future.

Possible "easy" implementation: If atom type names had an optional extension (opls_2001.1) that was stripped off just before any output operation involving the name, there would be unique names in the .xml file and in the dictionary mentioned, but the same intended atom type name available for any simulation. I suppose overrides and atom types defined on other atom types would also need attention.

bkpgh avatar Jan 12 '21 18:01 bkpgh

Thank you for your example @bkpgh! These seems very reasonable and definitely our team can work on to make the XML more accessible and readable by human!

daico007 avatar Jan 13 '21 17:01 daico007