Page Comparison

...

\uD83D\uDC65 Participants

\uD83E\uDD45 Goals

Updates from MolSSI
Infrastructure needs/advances
Throughput status
- Openff dipeptides torsiondrives v2.1: 25/26 TD complete
  - can be moved to end-of-life
- OpenFF Protein Capped 1-mer Sidechains v1.0: 29/46 TD
  - stuck at this
- SPICE PubChem Set 1 Single Points Dataset v1.2: almost done, rest all are scf convergence errors except for two runs
- SPICE PubChem Set 2 Single Points Dataset v1.2: 40538 calcs done, making progress
User questions/issues
Science support needs

\uD83D\uDDE3 Discussion topics

...

Time

...

Item

...

Presenter

...

Item
Notes
Updates from MolSSI
BP: No more issues with SSL certificate errors, fully automated.
BP – Tested data migration this weekend - Tried a first version of the porting code. Found some simple problems.
working on iterations for this
BP – for the migration, already have routing worked out based on the API point you’re hitting; going to be based on the new client version
BP – Working on reaction datasets, the worst of them all, forged in secret in the fires of Mordor
refactored it into a `ReactionService`; fixing how data is persisted in tables, since it was using JSON blobs
BP – I’m really interested in when you all start trying out the new version - I’d like feedback on performance issues. Will provide a conda yaml and python setup.py-from-git set of instructions.
DD – So, first you’ll spin up a test server (with a migrated version of some datasets), then that will be suitable for testing new managers. Once we’re satisfied that compute/access/submission works well, you have a pathway to production.
BP+DD – Yes, right now we have a computer “molssi10”. All traffic to the production server goes through molssi10 as a gateway. So at first the test server will live ON molssi10, and it will both act as the old production server gateway (all API queries with `/v1` in their path go to the OLD server) AND the test server (all API queries with `/v2` will be handled by molssi10). Then when we’re happy with the new behavior, we’ll go read-only for both databases for a few days, and migrate the entire old database to the new format. Once the migrated database is good to go, then we can spin up new managers that interface with the new API.

Infrastructure needs/advances
DD – I’m spinning up work on the QCEngine “single points after an optimization” functionality. Should have some time this week to work on it.
PB – Do we still need this? I saw that you have a QCSubmit PR that overlaps with what you’re describing.
DD – They don’t really overlap, the QCSubmit PR exposes the ability to set which kind of optimization to do (about which properties like bond indices to keep on which steps, eg `all`, `first and last`, `last`, etc)
Throughput status
Openff dipeptides torsiondrives v2.1: 25/26 TD complete
PB – can be moved to end-of-life?
CC – I think this is still making a little progress. Could we let this go for another week? The remaining molecule is the largest one in the set.
(General) – There’s something odd here, there’s just one optimization that’s showing up as INCOMPLETE, we should let it run for another week.
OpenFF Protein Capped 1-mer Sidechains v1.0: 29/46 TD
stuck at this
PB – Were these going to be resubmitted?
CC – A few of the inputs had bad geometries, I’m working on validating+fixing the inputs. But many of these are good, so it would be great to let those run through
DD – That sounds good, I’ll reduce error cycling from once per hour to once per 3 hours.
SPICE PubChem Set 1 Single Points Dataset v1.2: almost done, rest all are scf convergence errors except for two runs
PB – 136 calculations are consistently failing, mostly SCF convergence errors. 2 are failing for other reasons seemingly related to host machines, could let it run for a few more days and move to end-of-life.
SPICE PubChem Set 2 Single Points Dataset v1.2: 40538 calcs done, making progress
PB – This seems to be chugging along.
PB – I’ll message Eastman and Chodera (CCing DD) about the SPICE sets and the DES supplement set without MBIIS (3k molecules from the DES submission were failing, PB resubmitted the failing mols)
User questions/issues
Science support needs

✅ Action items

⤴ Decisions

...

Versions Compared

Old Version 1

New Version 2

Key

\uD83D\uDC65 Participants

\uD83E\uDD45 Goals

\uD83D\uDDE3 Discussion topics

✅ Action items

⤴ Decisions

Item	Notes
Updates from MolSSI	BP: No more issues with SSL certificate errors, fully automated. BP – Tested data migration this weekend - Tried a first version of the porting code. Found some simple problems. working on iterations for this BP – for the migration, already have routing worked out based on the API point you’re hitting; going to be based on the new client version BP – Working on reaction datasets, the worst of them all, forged in secret in the fires of Mordor refactored it into a `ReactionService`; fixing how data is persisted in tables, since it was using JSON blobs BP – I’m really interested in when you all start trying out the new version - I’d like feedback on performance issues. Will provide a conda yaml and python setup.py-from-git set of instructions. DD – So, first you’ll spin up a test server (with a migrated version of some datasets), then that will be suitable for testing new managers. Once we’re satisfied that compute/access/submission works well, you have a pathway to production. BP+DD – Yes, right now we have a computer “molssi10”. All traffic to the production server goes through molssi10 as a gateway. So at first the test server will live ON molssi10, and it will both act as the old production server gateway (all API queries with `/v1` in their path go to the OLD server) AND the test server (all API queries with `/v2` will be handled by molssi10). Then when we’re happy with the new behavior, we’ll go read-only for both databases for a few days, and migrate the entire old database to the new format. Once the migrated database is good to go, then we can spin up new managers that interface with the new API.
Infrastructure needs/advances	DD – I’m spinning up work on the QCEngine “single points after an optimization” functionality. Should have some time this week to work on it. PB – Do we still need this? I saw that you have a QCSubmit PR that overlaps with what you’re describing. DD – They don’t really overlap, the QCSubmit PR exposes the ability to set which kind of optimization to do (about which properties like bond indices to keep on which steps, eg `all`, `first and last`, `last`, etc)
Throughput status	Openff dipeptides torsiondrives v2.1: 25/26 TD complete PB – can be moved to end-of-life? CC – I think this is still making a little progress. Could we let this go for another week? The remaining molecule is the largest one in the set. (General) – There’s something odd here, there’s just one optimization that’s showing up as INCOMPLETE, we should let it run for another week. OpenFF Protein Capped 1-mer Sidechains v1.0: 29/46 TD stuck at this PB – Were these going to be resubmitted? CC – A few of the inputs had bad geometries, I’m working on validating+fixing the inputs. But many of these are good, so it would be great to let those run through DD – That sounds good, I’ll reduce error cycling from once per hour to once per 3 hours. SPICE PubChem Set 1 Single Points Dataset v1.2: almost done, rest all are scf convergence errors except for two runs PB – 136 calculations are consistently failing, mostly SCF convergence errors. 2 are failing for other reasons seemingly related to host machines, could let it run for a few more days and move to end-of-life. SPICE PubChem Set 2 Single Points Dataset v1.2: 40538 calcs done, making progress PB – This seems to be chugging along. PB – I’ll message Eastman and Chodera (CCing DD) about the SPICE sets and the DES supplement set without MBIIS (3k molecules from the DES submission were failing, PB resubmitted the failing mols)
User questions/issues
Science support needs