Versions Compared

Key

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

...

Participants

Goals

  • New advancements

  • New submissions

    • PEPCONF compute expansion submission failure

  • Upcoming infrastructure improvements

    • STANDARDSv3 submission machinery in QCSubmit

    • STANDARDSv3 submission machinery in qca-dataset-submission

    • Github link macro
      linkhttps://github.com/openforcefield/qca-dataset-submission/issues/179

    • Multiple PR templates

      • New submission

      • Compute expansion

      • Infrastructure modification

    • psi4 1.4 release?

  • Upcoming science support

  • Larger advances

    • Automated FF coverage gap identification, torsion prioritization, submission generation

    • Benchmarking (dashboard, etc.)

Discussion topics

Item

Presenter

Notes

PEPCONF compute expansion

David

  • DD:

  • JH: expanding compute has no new ids, no tasks passed to threads

    • could be a quick fix, but also considering a rework of how to structure compute expansions

      • would allow selective adding of compute to certain ids

  • DD: can we get a quick fix for now (to get PEPCONF rolling), then add in more nuanced pathways later?

  • JH: sounds good, can do

Torsiondrive benchmark update

David

  • DD: will give a review, launch; can relaunch if we hit failure similar to PEPCONF

Compute expansions

Josh

  • JH: would like feedback on qcsubmit#93

    • TG: will do

    • DD: will do

Multiple PR templates

David

  • DD: would like multiple PR templates for different use cases

  • TG: can we start to template out some notebooks? Like an OptimizationDataset template with current best-practices.

    • Should it live in qca-dataset-submission or qcsubmit?

      • qcsubmit makes the most sense; is a starting point for documentation (how-tos)

  • SB: are notebooks the most effective way to convey this? How do we avoid copypasta on many of these? Is a CLI perhaps a better approach?

    • JH: been on the todo list for a while; considering ways to do this

    • TG: definitely for CLIs, and makes sense for the usual pathways for submission

    • DD: there are weird custom cases where you can’t avoid doing Python-fu directly with QCSubmit components; complementary to the CLI approach

  • DD: any initial step we can take to set us down a path?

    • TG: let’s PR into QCSubmit notebooks that capture current practices, then can evolve these into a CLI form over time

Any gaps for FF fitting?

David

  • SB: nothing at this time; current process meets needs of fitting

Should we make this call every two weeks?

David

  • TG: this meeting functions as a nice pressure to make sure we keep datasets rolling

  • PB: still keep every week, perhaps fine if it’s sometimes short

  • TG: perhaps double-dip with the User meeting (every other Tuesday)? Could piggy-back on that one to address our issues there

    • would we add the agenda items for this call to the user meeting (at the end)

Action items

  •  Joshua Hortonwill add quick fix to allow compute expansions to work as before in openff-qcsubmit
  •  David Dotson will review qca-dataset-submission#173, merge
  •  Trevor Gokey will provide feedback on openff-qcsubmit#93
  •  David Dotson will provide feedback on openff-qcsubmit#93
  •  David Dotson will PR template an OptimizationDataset submission notebook into QCSubmit, function as initial docs
  •  David Dotson will set this meeting as once every two weeks, but we’ll shift to using the user meeting as an opportunity to meet and discuss on the off-weeks

Decisions