2021-02-02 QCF Meeting notes

Updates from MolSSI

• BP – No major updates. Still working on refactor. Looking promising but no ETA yet.

• BP – Server is stable, no planned downtime.

Manager/queue status

• DD – Resubmitted PEPCONF with dlc coordinates and reset=True. This makes jobs converge much more quickly.

  • LPW – The reset=True flag makes geomeTRIC completely ignore the hessian from the previous step in some cases. This involves looking at the eigenvalues of the hessian, but if the largest eigenvalues are near 0, then keeping the hessian between steps is unlikely to be helpful.

• DD – Pepconf is running well on all resources (shows plots)

  • LPW – Would it be possible to make a similar histogram of optimization steps required?

  • DD – Pepconf has some of the largest molecules we’ve worked with, and some tricky macrocycles.

  • LPW – GeomeTRIC should be OK with macrocycles

•  

User questions

• LPW – It would be helpful to have access to the final error in these cases, since I don’t know whether they’re due to Psi4 errors, geomeTRIC errors, etc.

  • DD – Unfortunately, if an optimization fails in QCF, we don’t get access to the final structures.

  • BP – This is one the the things I’m going to do in this refactor. Currently if a job fails, the info doesn’t get stored in the database. I’m working on adding this in the refactor.

Infrastructure improvements

• DD: are there pain points in submission that users would like us to address in the next month?

  • JW: Ambertools-psi4 incompatibility - do we know what the problem is, and can we address it?

• DD: are there any scientific questions that are currently hard to answer with the way QCArchive works?

• HP: Since QCEngine can utilize geomeTRIC, is transition-state optimization possible to execute?

  • DD: qcengine.compute_procedure would be entrypoint

  • LPW: interested in getting minimum energy paths along torsion degrees of freedom

    • these are chemical reactions, analogous to a geometry optimization

  • HP: comparing opt perf between geometric and qchem internal coords; wrote code that tracked iterations, wondering whether qcarchive can optimize hundreds of structures with qchem and another hundred with geometric; is there a way to compare each structures iteration number and final energy

  • BP: as long as info is stored, def accessible programmatically

    • QCA will store optimization in a Python data structure

  • LPW: want to be able to compare to other packages to catch cases where geometric may be performing badly.

  • BP: compute_procedure: considering how this should be changed to make distinction between program, procedure (e.g. optimization)

  • LPW: one option is to use QChem style convergence criteria, but this is not sufficient in simulating use of QChem itself, since there are many unpublished details about optimization algorithm

  • DD: is QChem open source? Would like to assess how feasible wrapping with QCEngine as procedure executor

    • LPW: not open source, and would be of interest to community, but for us doesn’t quite rise to level of urgent need

      • can use current approach for running QChem directly; burden is on the user to make comparisons between outputs

  • LPW: long-term interested in being able to run all optimizations of interest in QCArchive

  • DD: possible to use QChem within optimizations for gradient calculations under geomeTRIC

  • HP: this was useful information; thank you!

  • BP: wrapping QChem wouldn’t really be a fundamental problem; wouldn’t be an optimization where you use a metaprogram like geometric with a gradient calculator underneath

    • this is good discussion; fuzzy terminology I’d like to clean up

  • LPW: as I work on installing QCFractal locally, hoping to become more familiar

  • BP: lots will change, but will be an upgrade pathway (for data)

• TG: we talked last time about wavefunction data cooking; what was the conclusion?

  • QCElemental issue #248:

  • DD: I may take this on; could draw from openff-recharge implementation, generalize to QCElemental models