Page Comparison

Scheduling

MT

• JC: conflict will not be an issue in future

EP 10

LW/JC

• 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

• Github link macro
  link https://github.com/openforcefield/standards/pull/63 extended false

• 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

• Github link macro
  link https://github.com/openforcefield/standards/issues/64

• (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.

  • DM – We should double check.

  • https://openforcefield.github.io/standards/standards/smirnoff/#smirnoff-parameter-specification-is-hierarchical

  • 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.