2020-10-23 QCA Submission Meeting notes

GeomeTRIC and ANI2x

Trevor

• TG: Increasing iterations should solve many (perhaps all)

  • what’s the level of dedup that will happen with results?

• BP: Optimizations are all-or-nothing; if they don’t complete, no trajectory is stored

• JH: what if I overwrote the spec, say the ANI2x spec, would that cause restarts to use the new geomeTRIC maxiter?

• BP: if you deleted the spec, the Optimizations would exist, but would have a pointer to something that doesn’t exist.

  • we’re still debating here what parameters constitute changes to compute

• TG: why don’t we filter out the molecules we know will work for ANI and just do a new submission?

  • perhaps a new submission is the best approach, with appropriate molecules

• JH: Is the memory increase a symptom of geomeTRIC’s or QCEngine handling of e.g. the ANI models?

  • DD: if geomeTRIC is creating a new harness instance every time it needs to do a calculation, this would likely do this; need to verify

• JH: Is the whole Optimization is done in one go on the worker? Has to hold onto a lot of stuff.

• TG: Geometric just calls QCEngine, doesn’t deal with the harnesses directly, so singleton class instances would need to be handled by QCEngine or made explicit in geomeTRIC

• DD: paths forward?

  • ANI1, ANI1cxx added to ligand benchmark

  • A maxiter=3000 ANI2xv2 spec added to ligand benchmark

  • JH: WB97 would be of interest, because this is the DFT ANI is trained on; will ask Adrian and others if this is desired in #qcfractal

Bugfixes in QCFractal

Ben

• BP: worked with Trevor to find this bug that shows up in ~600 Optimizations

  • fairly serious, though rare; working on it

• PR for output of TorsionDrive logs

• Service limit is strange; doesn’t appear to have a strict effect

  • restarts on services don’t check the limit at all, so this is probably why

• There’s a rare case where the TorsionDrive’s reference to the minimum points to a value that doesn’t exist in its data structure

  • DD: should we ignore the possible inconsistency of the minimum energy stored in the TorsionDrive and just calculate the minimum client-side, or do one-time remediation?

    • probably remediation/scrubber, since doesn’t seem to be happening on newer datasets

• A lot of managers pulling down duplicate tasks; have a solution via semaphoring coming

Wavefunctions

Trevor

• We do support wavefunctions, no good way to reconstruct them after the fact

  • can specify wavefunctions in protocol, will store in QCArchive

  • need to get back the wavefunction client side, then get back orbitals so we can calculate ESPs

    • Like Wfn object in psi4?

• Reconsituting psi4 wavefunction from what is stored is the key barrier right now

  • roundtripping on the wavefunction data that gets shoved into QCSchema

  • we think this should live in the psi4 Python layer

  • we need someone with sufficient expertise to implement this roundtripping in psi4

• Trevor will discuss with Mobley the state of the problem, assess options for unblocking (who, when)

QCFractal torsiondrive debugging

David+Josh

• Spent some time debugging the one-shot torsiondrive issues

  • solved errors DD was getting from the script being named torsiondrive.py; causes the torsiondrive package to fail if running from same dir 🤦‍♂️

• Intermittent SQL error observed by JH, DD, Xavier Lucas; still trying to assess the root issue; hard to debug due to intermittent appearance