2023-07-25 OpenFF QCA Working Group Meeting Notes

Participants

Goals

PortalClient Training
- BP will link slides here
- PB – Are we still splitting dispersion calculation from functional?
  - BP – Good question. It’s all together in the new version. So if you’re running a lot of different functionals with dispersion correction, it may make sense to add a new specification for the dispersion correction.
- PB – Can we access the new datasets in the new server?
  - BP – Yes, the new hardware is running a copy of the old server and the new server, and you can use either the old or new client to access it. We also have an ML version - Splitting out the old OpenFF instance, now have an OpenFF instance, a MolSSI instance, and an ML instance.
- DD – And to emphasize - We should only be submitting using the NEW client to the NEW server, right?
  - BP – yes
MolSSI QCArchive user group
- user questions / issues / feature request
  - QCSubmit constraints question
- server instance statuses
  - QCArchive Legacy
  - QCArchive OpenFF
    - currently retains everything from Legacy
  - QCArchive ML
  - QCArchive Validation
- compute resources statuses
- call for new users
- trainings
  - upcoming PortalClient trainings
  - upcoming compute manager trainings
- deployed stack versions:
  - QCArchive Legacy
    - 0.15.8.1
  - QCArchive OpenFF
    - 0.50.0b11
  - QCArchive ML
    - 0.50.0b12
  - QCArchive Validation
    - 0.50.0b12
New datasets
- SPICE 2.0
- OpenFF Optimization Diverse Fragments with Iodine (w/ ESPs)
- OpenFF Optimization Hypervalent Sulfurs (w/ ESPs)
- OpenFF DNA
Updates from stakeholders
- OpenFF
- Genentech
- MolSSI
QCFractal development : sprint begins …
- QCFractal v0.50.0 - imminent
- v0.70.0 milestone:
Additional business
- MolSSI QCArchive Working Group start date: 8/29

Discussion topics

Item

Notes

PortalClient Training : slides

Next major version is v0.50
Hardware backing servers is now sufficiently provisioned to handle load from users, compute, storage needs
Software stack changes:
- web api: flask + gunicorn
- auth: password + jwt
- compute manager: just parsl
now features consistent terminology
- database more relational than previous; db-constraint-based consistency
- more done server-side
  - dataset submission, status checking; improves performance
- emphasis on iterative fetching: can iterate over records instead of pulling everything down at once as a big blob
- web API is more accessible; technically doesn’t need QCPortal client
- ownership tracking: records belong to identities and groups; not yet used to enforce permission boundaries
Raw web API
- browser can access records in a far more standard way
All calculations are records
Some records are services
- e.g. TorsionDrive, GridOptimization, etc.
One dataset type per record type; all behave similarly
May bring back idea of collection as some kind of heterogeneous dataset, but not present as a concept right now
entry - typically the molecule input : the rows in a dataset
specification - method/basis/keywords : the columns in a dataset
in a dataset, the combination of an entry (row) and specification (column) refer to a record
primary object you work with is records, don’t directy work with tasks and services (though accessible as properties on records)
more usage of properties in records with automatic fetching (e.g. wavefunctions)
getting and querying
- get_records(ids) returns list of records in same order as ids
- query_records(...) returns an iterator, no guaranteed order of results
submit with add_*
only metadata, specifications and names of entries downloaded at first
- full records only downloaded as requested
BP : have an old instance of QCFractal server running that serves requests from the old FractalClient; have an equivalent new QCFractal server running that serves requests from the new PortalClient

PortalClient Training : interactive

mamba create -n qcportal_tutorial -c qcarchive/label/next qcportal nglview jupyter

Participants

Goals

Discussion topics

Action items

Decisions