BP: No updates from me on hardware side. On software side I dug into qcsubmit to make it compatible with qcf-next, almost done with it except the torsiondrive, need testers. I took caching out of qcsubmit and put that on client side now. Two tests were broken, mostly because of pint dependency
DD: I don’t see any changes now?
BP: I have to push them yet.
DD: Thanks for working on this. Do you need any help with tests?
BP: Let me sort these out a bit more and then I can use your help.
DD: For qcf-next roll out do we need to do mocking exercises like setting up a test server, etc., as before?
BP: I don’t think it would help that much.
DD: I agree.
BP: There is a snowflake instance I am using to test though.
DD: Yeah, I use a similar thing for Fah-alchemy.
BP: Anyways, wait on the tests for a while but I think it is ready for users to give it a go.
DD: Josh Horton reached out to me recently and he can help with this.
JW: Yeah, DD since you are busy with Fah work I think it’s better to use JH and myself for qcsubmit on a timescale of a month or two.
DD: We’re getting close to the release of alchemiscale but it is still uncertain how my workload would be for the near future. But, I can lend a hand when we are close to deploying qcf-next.
JW: Sure, we can figure it out when we get close, Josh Mitchell may also help.
PB: Updated workflow files to use `miniforge-variant: Mambaforge` to resolve GHA failures. Root cause was workflow file, not conda yaml file. Initially I took out the defaults channel, but this didn’t work. Then I found an open issue on the setup_miniconda repo, which recommended using the miniforge-vairant line above and resolved the issue
DD – Was it an out of memory issue?
PB – No, it was a packagenotfounderror for conda=22
JW + DD – details?
PB – setupminiconda/274() notes the issue and workaround.
PB – Should we standardize on what the toolkit does?
JW – Toolkit uses provision-with-micromamba, but qca-dataset-submission may have such a touchy set of deps with the mixed channels that I don’t think we should touch it unless we have more problems.
Throughput status
New dataset
OpenFF Protein Capped 3-mer Omega v1.0
CC – This is a smaller torsiondrive set, focused on omega torsions. Only 26 molecules, 1D torsiondrive. I might anticipate that the torsiondrives may have trouble since the exptl barrier to rotation can be around 20 kcal/mol, so
DD – Want lilac working on this?
CC – Is PRP running?
DD – No, nothing will be running these jobs at the moment.
JW – This dataset is medium/high important to the org - Helps derisk a possible issue with the protein FF so we have something good looking for the NIH submission.
CC – Right, this is the highest-effort avenue of resolution, hopefully one of the simpler two paths I’m checking will work out.
PB – I pushed pepconf dataset to end-of-life, since there are ~2000 persistent errors related to disk space and other repeating issues.
DD – That makes sense, we discussed the size of some of these prior to submission
User issues/questions
PB – PE was asking if there are major differences between Psi4 1.4.1 and 1.6.1. I’m not aware of any.
DD – I’m meeting with PE and JC to discuss SPICE data/project management and stuff.
JW - We’re talking with JC and OpenMM leadership about shared resources and support personnel, but that hasn’t gone far, so at this point if you’re supported by OpenFF consortium resources (industry money) please work on assigned tasks instead of spice.