2022-08-09 Meeting notes

Updates from MolSSI

• BP – Had problems with the gateway server. It seems to be fixed again now. Had to contact the server manufacturer, told us to “reseat the memory and clean the contacts” and it worked. We’ll see in a few months whether this crops up again.

• BP – Hoping to get funding from somewhere for a new server. We’d put this in our supercomputing center.

• BP – We should hear next month about the CZI grant.

• DD – With our current rate of storage use, we’re not under huge time pressure, right?

• BP – Right, but it’s still going to be necessary eventually.

• BP – No planned improvements to code since I’m still teaching

• DD – Did the test fixtures end up getting exposed? We could use that for our testing.

  • BP – I’m pretty sure those got in, maybe they just needed to get exposed via setup.py. It’s current form should be pretty much final

  • DD – And what’s the release timeline for the next branch?

  • BP – If we know that we’re getting new hardware, I’ll wait until that. But otherwise we’ll go ahead with it when I’m done teaching. Was thinking about a change where we’d use spec instead of specification at some places in the API.

• BP – Still looking for more folks that would be interested to beta test

  • DD – I met some folks from treeline biosciences that were interested in getting help deploying QCF on their environments.

  • BP – I’d love to talk to them. Deployment is still a weakness and we need a better strategy. Maybe I could draw on the system of hosting it for academics, to host it for other paying folks as well.

  • PB – I also met Treeline folks at CUP last march, they were also interested in internally hosting QCF. One of them is Brian Cole.

    • BP – The most important thing is that they should use the next branch, since the current master branch will be deprecated soon.

• BP – Mentioned this last week as well, but as a reminder: we have two postdocs coming. Neither will be working directly on QCA. One will be working on ML. The other (Reza) will be working on applications of MOPAC to biological problems.

Infrastructure advances

Throughput status

• OpenFF Protein Capped 3-mer Backbones v1.0

  • Opts: 247185 → 251942 (4757)

  • TDs: 4 → 4

• RNA Single Point Dataset v1.0

  • default: 8864 → 8868 (100 error)

  • wb97m-d3bj/def2-tzvppd: 1603 → 2538

User questions/issues

• PB: Can we have just status reports and not rerun errored calculations for selected PRs, if we know the failures from heavy calculations would be consistent viz., SCF failures redoing them over and over again would give us the same error and waste compute. ( )

  • DD – So, for those, you’d want status reports but no error cycling at all?

  • PB – Yes

  • DD – So, the thing to do here would be to make a new “State” (corresponding to a column on the project board), which generates reports instead of error cycling.

  • PB – I was thinking of instead selectively error cycling based on the data about the error. So SCF errors wouldn’t get cycled, and geometric failures would get rerun.

  • DD – I see, so we’d still want to add a column, but then the list of allowed and disallowed errors would be hard-coded. I don’t anticipate that there will be a very elegant way to do this. And I’d note that I think I’ve seen SCF errors clear and geometric errors be deterministic. But these may be fleetingly rare.

  • PB – We say SCF errors in the RNA dataset drop from 114 to 100. BP, do you know whether changes in the initial guess would affect convergence? Does SAD(?) have a random component?

  • BP – Yeah, changes in initial guess could affect SCF convergence.

  • DD – I suspect that the times we’ve seen SCF convergences recover and finish have been due to machine differences. But again, this is pretty rare.

  • BP – Yeah, in theory this shouldn’t happen, but in practice it does.

Science support needs