libera/#clasp - IRC Chatlog
Search
12:36:10
drmeister
scymtym: 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:45
drmeister
There are a couple of SMARTS strings that are causing problems - they look like this...
12:39:51
scymtym
if i recall correctly, i went by a specification that is hopefully linked somewhere in the repository
12:40:16
scymtym
but i understand those new strings include extensions to the original specification?
12:46:05
drmeister
There's also this... https://www.daylight.com/dayhtml/doc/theory/theory.smarts.html
12:46:51
drmeister
Next I'll contact the Open Force Field people and try and find someone who can explain what this means.
12:47:09
drmeister
I fear that it's generated by the OpenEye software and it's buried in their code somewhere.
12:58:08
drmeister
I’ll try. My question is does this look like a chiral test or bond test from the parser side.
13:16:57
scymtym
"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:35:21
scymtym
i traced the parser with (esrap:trace-rule 'language.smarts.parser::smarts :recursive t)
13:36:04
scymtym
that revealed LANGUAGE.SMARTS.PARSER::ACYCLIC-ATOM-PATTERN trying LANGUAGE.SMARTS.PARSER::MODIFIED-ATOM-PATTERN and LANGUAGE.SMILES.PARSER:ATOM-SYMBOL
13:37:45
drmeister
There's an openff (open force field) slack channel somewhere - I'm going to get on it.
13:37:46
scymtym
the 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:41
drmeister
A chirality test within these force-field type specifiers would be strange. Force-fields don't care about chirality.
13:44:05
scymtym
when 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:46:43
scymtym
right, 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:26
drmeister
It will be a few hours/days before I can hope to get an answer from the Open Force Field people.
13:55:53
scymtym
yes, 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
14:36:17
drmeister
Hang on - I'm at ThirdLaw and it's not a smoking hole in the ground - so something must be up with zeus.