Yutong Zhao just mentioned more numerically stable version
To do:
Change vector notation
mention there could be numerical stability issues around 0 and pi
JC – IJKL vs …
LW – I’m 99% sure that it doesn’t make a difference.
JC – So matching direction doesn’t make a difference. Other cases that are dangerous?
LW – Cases where torsion profile itself isn’t symmetric around 0
JC approved PR + left remaining to dos as comments
PR #63
JW
JW + JC + LW – We should invite Tom to begin a formal spec change proposal, which we will likely approve.
DM – Agree
JW will write to tom to invite formal change proposal
JW – General framework for considering vsites other than brute-forcing all edge cases? Something like symmetry groups in inorganic chem (c2v etc?)
MT – I think SMIRNOFF vsites are a genuinely new question
LW – re the particular question in the EP regarding the instability for fitting (multiple vsites wiht 1 spec vs one type with multiple capabilities) I doubt there’s an xisting general solution for this
DM – I’m thinking more carefully about some things - eg the nitrogen planarity thing was another edge case. I don’t see a general solution. So we probably want to do relatively narrow expansions of the spec instead of trying to make things highly general (since then we’ll hit cases/geometries that nobody’s thought of yet).
JW – Re the restrictions on monovalent and divalentlonepairs, I’ll look into adidng a named argument to skip emitting an error if they’re applied to an unexpected valence.
DM – Ok
(discussion about how to apply multiple vsites to same parent atom)
(currently implementation does this using name field to decide collisions, DM suggests alternatively using a field like “group” where all members of a group could coexist on a parent atom but if a vsite from another group is added the previous group would be removed. DM thinks it’s more imporant to document the current behavior in the spec than to document a new behavior and also implement it)
MT – Big problem with current implementation is that the logicthat toolkit uses to decide whether vsites are different are a tuple of (type, orientation atoms, name) and the existing behavior may be “surprising” to scientists, even if it’s “correct”.
JW – Any objection to me starting the process to EP the vsites page from OFFTK?
DM + LW – Agree
MT – Might be good to do it in steps.
JW – Ok, I’ll start this.
.
General forum
MT – JW has been working on a PR to allow multiple parameters with identical SMIRKS in the Toolkit.
JW – I think this is a good idea. JC has indicated as much
LW – It’d be helpful to have a warning if multiple parameters ahve ientical SMIRKS
MT – Two qs: should this be allowed? (seems to be yes) and which parameter wins (should be later). And should both decisions be upstreamed into the spec?
LW – Last parameter wins should be in the spec.
MT – I think I looked a year ago and couldn’t find it clearly stated.
LW – If we do merge this behavior PR, I’d be in favor of explicitly saying that later match wins even if SMIRKS are identical.
MT – Agree, should be a small change.
JW – Current planned behavior change is to have last parameter win if there are identical smirks, and to allow duplicate SMIRKS in (so avoid raising DuplicateParameterError) in ParameterHAndler.add_parameter.
MT – Right now users can silene specific warnings, or turn warnings into errors, so I don’t think we should add a new argument to the add_parameter API.
LW – Right now the add_parameter API raises an error that you can catch with try/except, but then the parameter isn’t added.
Mt – I don’t want downstream warnings to be something that the toolkit takes the responsibility for handling.
…
MT – So right now duplicate parameters can come in via file loading and FF concatenation. So I’d assumed thatthis was also allowed when using the API to add parameters. But I see that the current state of the API is that duyplicate paramters aren’t allowed at all, and this change would optionally allow them.