Queue status | DD Managers don’t need updating Queue is running dry for TG, and his workers New PRs are welcome, JC opened PR last night Looking at submitting JH’s corrected dihedral constraint protein fragments. This is ready for submission unless JH has any objections. Looking at unconstrained protein fragments/torsions. Working on JM’s phenyl resubmission
JH – Do we want to submit ANI stuff again? DD – Yes, preparing ANI1 and ANI1cxx jobs, as well as ANI2x with higher maxiter. JH – Would separating this into three submission make error cycling simpler? Probably OK to pair all the ANI1 jobs together.
TG – Do we want to prioritize DFT datasets since we have extra workers ready to handle those? DD – Yes, no specific priority for datasets to submit. TG – Would be good to do unconstrained protein fragments, then JC’s. TG will take a look at submitting unconstrained protein fragments, and prepare it if it’s easy JH – Do we want to fully copy the input data into a separate folder? This would be wasteful DD – I generally just reference the other folder with the original dataset, rather than making a full copy.
|
User questions | TG – Noticed a lot of errors in error cycling, that aren’t fixed by restarts. JH – If they’re the XTB ones, I’ve reported that to the devs TG – This is about the DFT ones. JH – I noticed that we stopped getting error output from psi4 DD – This is likely due to a recent change I made to QCEngine. It meant to fix something else, but the result is that psi4harness now frequently doesn’t have an error message attached. DD – Some errors are consistent, like protein dataset v2, but we’re about to supersede that, so I’m calling those “end of life”. There’s one optimization in particular that’s not clearing. DD – HJ’s dataset “Alrichs…” also has a persistent error which I’m not seeing clearing. DD – BP had added the ability to clear the compute tag on some tasks, which would let us run datasets specifically on our infrastructure.
JH – QCEngine with vsites? I’ve tested locally with geomeTRIC, but QCEngine isn’t made for them. TG – We could do TIP4P or TIP5P, I have those OFFXMLs in the tests. (General) Exclusions will be troublesome DC – Exclusions in AMBER vsites are inherited from single parent atom. This leaves the dangerous cases where a vsite doesn’t clearly “belong” to one parent. So best practices are to keep it closest to one particular parent and label that as the primary. TG – For force redistribution, how does that work? DC – Forces get redistributed according to chain rule on to frame atoms. TG – Hard thing is that OpenMM reports net force on a vsite, but not how it distributes to the parents. What is the “frame”? DC – The atoms that determine the geometry of the vsite. Basically the frame atoms almost always have mass. In special rare cases, vsites can be parents for other vsites. JH – I think the vsite forces are already redistributed, so they’re listed once on the vsite, but also the atoms have the forces already added. TG – For our vsites, we default to exclusion_policy=parents, which is ALL “frame atoms”. Another strategy we will allow is minimal, which will only exclude the parent.
|