12:36:10drmeisterscymtym: Are you online? I am returning to force fields now and the Open Force Field people have made some changes to the SMARTS strings they allow in their force field.
12:36:45drmeisterThere are a couple of SMARTS strings that are causing problems - they look like this...
13:16:57scymtym"our" smarts parser expects atom patterns that are not literally naming an element only within […]. in a […] context, *@1 would be "any atom AND chirality of unspecified class with count 1""
13:37:45drmeisterThere's an openff (open force field) slack channel somewhere - I'm going to get on it.
13:37:46scymtymthe first (MODIFIED-ATOM-PATTERN) requires […] and eventually reaches ATOM-PATTERN/NON-LITERAL, one of which is "*". the second (ATOM-SYMBOL) does not require […] and allows only literal element names
13:40:41drmeisterA chirality test within these force-field type specifiers would be strange. Force-fields don't care about chirality.
13:41:02drmeisterThe universe at the atomic level doesn't have a preference for handedness.
13:44:05scymtymwhen i change the grammar so that it behaves as if the surrounding […] were there, i get (:CHAIN (:ELEMENT (((:ATOM NIL :KIND :WILDCARD :BOUNDS (0 . 1))) ((:BOND (:ATOM ((1))) :KIND :SAME-RING :BOUNDS (1 . 3))))) :BOUNDS (0 . 3)) which may or may not make more sense
13:44:22drmeisterThat makes me think this is a cyclic bond test.
13:45:23drmeisterSo it interprets it as a :SAME-RING test?
13:46:43scymtymright, but that's just the result of me forcing the parser to accept this input. i don't think we can derive the true semantics from this result
13:54:26drmeisterIt will be a few hours/days before I can hope to get an answer from the Open Force Field people.
13:55:53scymtymyes, the unmodified grammar fails at position 4. the hacked grammar gets to position 10 but fails there. i assume the hack messes up operator precedence