Page Comparison

Updates from MolSSI

• MolSSI site review went well

Manager maintenance

• Queue is empty while we work on automation. Remaining incompletes probably won’t be fixed by restarts.

• Working on lifecycle automation, validation, etc.

• Protein fragment dataset

  • JW – Could this be submitted soonish? It would be useful to push this through to see whether the outputs will also work in our fitting pipeline

  • DD – Yes, could do this in the next week or two

• Conda channel access

  • BP – We need to update the psi4 version with some recent changes

  • DD – Need to have access to MolSSI conda channel to pull this in

  • BP – I got access last week.

  • DD – Will update PR with a psi4 dev version

User questions

• HJ – ESP generation process? I was asked to compare Psi4’s grid generation and FCC grid definition

  • simple cubic lattice vs fcc lattice

    • General – FCC lattice is more accurate, and is recommended by several people for our use case.

  • Timeline for implementation:

    • Decide on default settings for grid generation

      • Want to make sure that we ask for MORE grid points, if anything, than we need, so that we can keep the same settings for a long time.

    • Release FCC grid gen package

      • Hyesu’s code?

      • Simon’s code?

        Github link macro
        link https://github.com/openforcefield/openff-recharge/tree/master/openff/recharge/grids

    • Incorporate ESP calculation into QCEngine

      • ESP would be something like a property calculation, where a molecule is submitted, grid is generated, and charges are assigned

    • Incorporate grid generation (keywords?) into QCSubmit

  • Process for implementation

    • (immediate) HJ will propose and gain consensus on grid gen settings and exposed API (what values can we tweak, what values remain constant?)

      • We will revisit this at each QCF and charge model meeting

      • Likely timeline: 6 weeks (August 30)

    • (pending above) JW will Make sure a python (conda) package is available that has the above API

      • Will need to modify Simon’s implementation to use radius from QCElemental rather than OpenEye.

        Github link macro
        link https://github.com/openforcefield/openff-recharge/blob/master/openff/recharge/grids/grids.py#L66

      • Likely timeline: 3 weeks.

    • (pending above) DD + BP will Merge functionality into QCEngine – Pass in whole grid, or pass in grid generation keywords?

      • JW – Would vote for the job accepting the grid gen keywords, and having the generation run on the worker. Passing in whole grid would be irreproducible.

      • JH – The way Simon’s made it, it’s already based on pytantic. So a dictionary of grid settings could be passed directly as arguments to Simon’s function.

      • We will discuss this more in future meetings, JW will try to find more point for/against

      • Likely timeline: Implementation difficulty dependent on where grid gen happens (on worker or grid passed in during submission)

    • (immediate) DD + BP will Establish version record/provenance for grid gen algorithm in QCArchive

      • We can assume that grid gen is accessed via a python method that eats a qcelemental molecule and produces a grid as a numpy array

      • Likely timeline: This will depend on whether grid gen happens IN QCEngine, in which case the grid gen package version needs to be recorded, or outside, in which case the grid IS the provenance.

    • (immediate) DD + BP will Decide on where grid pts and final ESP values will be stored in QCA

      • Likely 250 pts per heavy atom – for (x, y z, esp, E_x, E,_y, E_z) → 1750 * 8 bytes per heavy atom –> 14,000 bytes per heavy atom. For a 20 heavy-atom molecule this is 280 kB.

      • Likely timeline: Dependent on above

    • (pending above) DD + BP will Coordinate a QCEngine release and update worker recipe/docker image

      • Likely timeline: 2ish weeks