2021-01-19 QCF Users Meeting notes

Date

Jan 19, 2021

Participants

  • @Jeffrey Wagner

  • @David Dotson

  • @Pavan Behara

  • Heejune Park

  • @Trevor Gokey

  • Ben Pritchard

  • @Joshua Horton

Discussion topics

Item

Notes

Item

Notes

Meeting frequency

  • JW – Would like to move to every-other-week unless there are items to discuss

  • (General) – No disagreement

Updates from MolSSI

  • BP – No news (is good news). Some small developments going on WRT dependency graphs.

Manager status

  • DD – Planning on rolling out updated conda environments with newest OpenFF Toolkit (will require restarts of existing managers). Hoping to submit PB’s reindexed submission.

  • DD – No need to spin up lots of managers at this time.

  • DD – Want to refactor local debugging so that other people can do it. Will require giving HJ and PB some QCA manager credentials. Should make distinct tokens from those that are being used for bulk compute at UCI and UCD. BP, could you make new manager tokens for Hyesu Jang and Pavan Behara?

    • DD – Is PB’s client credential the same as a manager credential?

      • BP – Maybe, I’d need to look. We’d also want to think about how the use would look (directly querying the task queue)

  • (Decision) BP will make new manager credentials/tokens for Pavan Behara, Hyesu Jang, and Josh Horton.

User questions

  • DD – During benchmarking, we found that long-running optimizations converge better when we use DLC coordinates instead of TRIC. Bill Swope is finding that, with TRIC (translation-rotation-internal coordinates(?), our default), 15-20% of optimizations fail to converge. Instead we can use DLC, which doesn’t consider translations and rotations.

    • TG – Agree, I’ve seen molecules fully rotate during TRIC optimizations

    • JH – This makes sense, we also accidentally had the reset flag set to False

    • DD – Based on conversations with LPW, the results of these calculations won’t be any less “correct”, but there will be edge cases where DLC takes longer than TRIC.

    • TG – I’ve only ever seen the whole-molecule-rotation with MM, not QM. Though I would expect to see it with QM as well (maybe I just didn’t observe it).

    • DD – It’s worth noting that we see this problem with QM engines other than Psi4 as well.

    • JW – So, root cause is unknown, but switching to DLC should fix it?

    • DD – Yes, we can explain as far as “molecule rotation causes some convergence criteria to not be met”

    • DD – We’re going to re-submit pepconf with these settings (with dlc and reset=True), and this will be a test run to see whether this really works. If so, we can look into changing our submission defaults.

    • TG – In an issue on qcsubmit, I also posted some keywords for grid spacing and DIIS settings. If we get a lot of SCF errors then tweaking these may help.

    • DD – Do we have any examples of representative pepconf failures that we can run locally to test the effects of these settings?

    • TG – I can work with PB on running this at UCI.

      • DD – We want to run with dlc, and reset=True, different settings per TG’s post.

      • TG – Would this mean new compute keywords? So instead of default, should we call this default-v2?

      • DD – I think so, but in QCSubmit, keyword handling is under the hood.

      • JH – In QCSubmit, you’d want to make somethinng like default-v2

      • JH – Could just treat this as a compute expansion.

@David Dotson I will resubmit all of pepconf with dlc and reset=True
@Trevor Gokey and @Pavan Behara will rerun a few SCF convergence failures from pepconf locally using different SCF keywords to see effect on convergence
  • HP – Working on development and refinement of reaction pathways from MD trajectories. My earlier work was converting it from Py2 to Py3. The previous version relies heavily on QChem, I have to make it agnostic to QChem. So, first, I replaced optimizations using GeomeTRIC. In the long run I’d like to refactor the whole workflow to use the QC* ecosystem.

  • JW – BP, are there options for improve Psi4 speed? What would a model look like where we give money to make Psi4 faster for our use cases?

    • BP – MolSSI might have to be neutral among QC packages, so we would have some trouble brokering contracts specirfically to improve Psi4. We’d need someone who’s quite skilled in low-level coding – Most of the low-hanging fruit has been picked.

    • JH – At PsiCon, I saw that there was a paid option to get GPU-accelerated Qchem (which is a standalone module that may be able to accelerate psi4). https://www.brianqc.com/

    • BP – This is surprising, because QM doesn’t map well to GPUs.

    • TG – Another thing we could try is relaxing the convergence criteria. Though we’d want to validate that this doesn’t significantly change energies/FF fits.

    • DD – LPW also mentioned that another step would be to use QChem convergence criteria (which has fewer metrics of convergence)

    • JH – QCSubmit supports relaxes/reduced convergence criteria (keyword QCCNV=True will use “GAU” convergence set, but reduce how many criteria must be met.

    • TG – Changing SCF settings could also speed things up.

    • BP – A big win would be to have GeomeTRIC store the wavefunction from the previous step and use it as the initial guess for the next step. Then you could see convergence within 2 or 3 iterations.

    • (General) This would involve storing the wavefunciton on the local machine/file system between QCNg calls. The change would need to be in GeomeTRIC. It would need to be an if clause in geomeTRIC that sees whether it’s using Psi4 and stores the wavefunction if so.

    • DD – Does psi4Harness have the machinery to accept a wavefunction as an initial guess?

    • BP – Unsure

    • DD – Would there be any performance/accuracy downside to this approach?

    • BP – I don’t think there would be anything major.

@David Dotson will open an issue in geomeTRIC describing the approach for storing the psi4 wavefunction between steps.

Action items

Decisions