Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Participants

...

tParticipants

Discussion topics

Item

Notes

General updates

  • JW – The “interchange adoption” meeting is right after this (9 AM Pacific)

Individual updates

  • SB

    • Got RESP charges into openff-recharge, got docs up to date. It was a lot to work to collect evidence for HOW to actually do the different steps, since the “canonical” approach appears to be based on several different publications. So now we can do RESP fitting with vsites.

    • Started doing some RESP fitting. Found a few bugs in a few pieces of software.

    • Worked on interchange regression, generalizing software to work on different comparisons. Largely looked at removing hard-coded values so that it could be used in other contexts.

    • DN – What’s the relationship between RESP and vsites?

      • SB – There are a few ways to assign partial charges to molecules. AM1BCC is what we use a lot, it’s fast and generalizable. RESP fitting is another way to derive partial charges that’s more accurate but more complex. RESP charges are important to both the virtual sides project (it will let us calculate the charge values to assign to vsites, and measure the accuracy of the sites that we do assign), and to do graph charges project (It’s as easy to train a graph net on RESP as to AM1BCC, but RESP will give us better/more accurate results)

      • DN – What additional work will be needed to figure out vsites?

      • SB – We need the datasets - both training and tests – and also we need to figure out the SMARTS pattern for the vsites. Then we need to train the whole force field with the vsites added, and then we need to benchmark the accuracy of the resulting FF.

      • DN – Is this something that we can tell the ad board at the next meeting?

      • SB – We could update them. My initial plan is to do the initial test and then put together a project plan that lays out the information and the plans. That may be better to share with the ad board, since anything sooner will have a lot of uncertainty.

    • JW – One thing that came up the other week was whether we plan on using TrivalentLonePair sites.

      • SB – That’s the kind of thing we might use on amines. I’m not sure if tests will show that we need those. I don’t have high certainty in an answer now. CBayly has been arguing for inclusion of vsites on sp2 Ns. And in that case we could probably make do with divalentlonepairs.

      • JW – Different packages have different vsites. AMBER support isn’t totally clear about what they support. GROMACS supports probaly a superset of our types.

      • SB – OMM made the decision to have each vsite define a orthonormal basis, and then you define your vsite position in that.

      • JW – The AMBER vsite interface is a bit troublesome. We may be able to avoid this by effectively making a way to define our own orthonormal basis sets.

  • DN

    • Working on website - Largely focused on a “how to cite” page.

  • CC

    • For a few of the remiining torisondrives on the protein QC jobs, tehre are a few bad input geometries. This is stopping progress on 4 of those. Last week I made a method to screen these usign an energy evaluation in Sage. This didn’t work. So now I’m checking whether a tetravalent atom is not close to a tetrahedral geometry.

      • JW – The connectivity checker didn’t catch these?

      • CC – No, the neighbor atoms are just all on the same side of the center atoms.

    • One big blockers on the protein benchmarks is figuring out how many ns/day we can get on the local clusters (dedicated GPU boxes). This will let us extrapolate how long we need to run the trajectories. Can also use this to figure out our total runtime. I’ve decided to do 2fs normal dynamics instead of 4fs HMR.

      • JW – Do we need to not use HMR?

      • CC – The NMR observables do depend on the H positions, so I don’t want to mess with the H dynamics. We might be able to use it for crystal sims.

  • MT

    • Mostly worked on interchange validation. Last week I worked on getting charges right for vsites - But geometry and exclusions showed large discrepancies. It’s hard to determine what parts of the discrepancies were bugs already in the toolkit. Also, with charges, the trivalentlonepair vsites sometimes mis-assign charges. For exlusion_policy=minimal or parents, the exclusion issue is particularly tricky.

    • JM gave interchange docs a nice overhaul. Things look a lot better, JM added some cool graphics, I’ll probably show these off on slack later.

    • Worked on a bunch of Toolkit PRs - Won’t go into detail but things are getting into shape.

    • Worked on PDB-loading UX testing. Managed to load 18/20 molecules from Hahn PLBenchmarks repo on the first try, in an average of about 1 minute each.

  • PB

    • Last two weeks worked on fitting experiments related to impropers, and general fitting.

    • For i4 improper with a broad range of in-plane and out-of-plane impropers mixed together I tried to separate out chemistries based on cheminformatics, making new smarts patterns by hand, but it didn't work out well, will be working on testing out wbo for impropers this week.

      • JW – Could a single WBO-interpolated improper parameter be used to define whether a center is pyrimidal or planar?

      • PB: From JM’s old work <Improper smirks="[*:1]-[#7X3:2](-[*:3])-[*:4]" id="i5" sqrtk1="2.051309243917e+00" sqrtk2="1.305089015005e-01" k1="4.207869614179e+00" periodicity1="4" phase1="180." k2="-1.703257337088e-02" periodicity2="8.0" phase2="-180." parameterize="sqrtk1, sqrtk2" parameter_eval="k1=PRM['PeriodicTorsionForce/Improper/sqrtk1/[*:1]-[#7X3:2](-[*:3])-[*:4]']**2, k2=-1*PRM['PeriodicTorsionForce/Improper/sqrtk2/[*:1]-[#7X3:2](-[*:3])-[*:4]']**2"/>

        Image Added
    • General fitting wise, modified seminario starting point for angles and bonds worked well on the benchmarks, trying to see if there would be further improvement with adding the hessian targets as well (the new internal coordinate hessian from Hyesu).

    • Reviewing some of the wbo work done last year on biphenyls with no-ortho substituents and trying to document the findings in a better way.

    • Still a bit lagging on Sage paper, will move it this week.

  • JW

    • Coordinating with AMBER devs re: vsites

    • Came up with rough estimates for CPU+GPU total usage for OpenFF. KCJ will reference these numbers when companies offer partnerships or donations of compute resources.

      • PB – Compute-wise, it may be good to keep track of automated chemical perception work as well.

        • JW – Thanks, I’d forgotten about that.

    • Some PR and issue clearance - Thanks SB for the CSP stereo thing in RDKit.

      • SB – Will this be backported to 0.10.X?

      • JW – I think it’s in a grey area for “critical-ness”. So I’ll take your advice

      • SB – I think this is critical - JH is largely using inddustry benchmark set, and some of the molecules there fail due to this bug.

      • JW – I will backport this PR to the 0.10.X series.

    • I think EP0005b is ready? Unclear state, need to push again this week.

...