| | |
|---|
Updates from MolSSI | Ben | BP: how’s the server doing? JW: still seeing sporadic failures, or at least have been last couple months BP: have a dedicated(?) firewall that routes traffic to the QCArchive server; used for traffic inbound from outside VT JW: seeing better success than before, but understand this isn’t a permanent solution BP: Long-term options could be renting cloud compute (eg AWS) or building a server in the office. DD: Lots of advantages to AWS BP: Planning a QCFractal release+upgrade tomorrow DD: Thanks for this. And thanks JHorton for opening qcelemental PR. JH: You’re welcome. BP did a lot of the work on the PR. BP: Conda env solve times have been pretty large too. JH: Switching to mamba shaved off 2 hours from 5 hour total test time. BP: Old managers should still work. Change should be backwards-compatible. DD: It’s not hard for us to update workers. BP: I don’t think it will be necessary, but it can’t hurt. I’ll let you know on Slack. Could pin QCEngine 0.20 and QCElemental 0.23(.1?)
BP – Is anyone using Parsl to manage qcf workers? They’re up for renewal and want to report usage stats.
|
Compute status
| David | DD – All the worker jobs on Lilac consumed. Just spun up more QM workers on PRP. PB – I could use more XTB and ANI workers DD – I can spin those up. JH, are you running these? JH – Not ANI since they keep running out of memory. But I can run XTB. DD – I will spin up some ANI workers on PRP
DD – I recall there were issues with single point calcs that required high memory allocation and manual observation. PB, are those still being a problem?
|
New submissions | | CC – Dipeptide set – I’m waiting for QCSubmit #172 to be merged
DD – QCSubmit 172 depends on the new QCF release, should be cut around this weekend. Then we can push out new QCSubmit version. CC – Understood. Once that release happens, I’ll ping you if there are further problems with submitting the dataset
DD – Worked with Willa Wang before I was out last week on qca-dataset-submission #235. Tried to pull down results from dataset. Didn’t see wavefunctions in the results. Not sure what’s going on here. JH – psi4#2242 seemed possibly related, but I haven’t looked closely. DD – I looked at that, seemed to find something similar to what Simon found before (no wavefunction data attached) BP: possible e don’t make it into the QCEngine execution for the gradient DD – I can chase this down – It seems like the store_wavefunction keyword isn’t making it all the way down the stack. BP – We need to be careful that we don’t store the wavefunction for every result record. I did an analysis of what takes up space in the database, and a recent deposition of wavefunction info made the db size shoot up. JW – refresh my memory: we were originally thinking let’s store grids, but that would have been way too large; now we’re thinking orbitals and eigenvalues, which are large but not as bad? BP – Could simplify(?) the process of not recording wavefunction for every step by doing a single point calc only at the end of an optimization. DD +BP – (Some question about where the logic would need to live to record only the wavfunction for the final step) DD – Best thing to do now would be to take the final structures of WWAng’s optimizations and submit single points for all of them
PB – may submit another dataset soon; will be a single point dataset JW – saw that JH had opened a PR for turning an OpenFF topology into SMILES:
might introduce a regression fairly soon, with multi-component topology generation from multiple SMILES JH – I do depend on this, so might need to have a discussion on implementation
|
ML dataset for OpenMM | Pavan | |