2021-05-28 QC meeting notes

Participants

  • @Pavan Behara

  • @Trevor Gokey

  • @Joshua Horton

  • Ben Pritchard

  • @Jeffrey Wagner

Discussion topics

Item

Notes

Item

Notes

Updated from MolSSI

  • BP – Update coming soon, once I merge PR for new version. Should be a minor update (~1 hour). Won’t require upgrade to portal or managers.

  • BP – Are there any simple features that people want to add? Maybe modifying/restarting multiple tasks at once?

    • TG – Multiple restart would be helpful, right now I just do them one at a time.

    • TG – Would be great if, after restarting a task, the count would become accurate. Right now restarted tasks are always set to “0”. Torsiondrive services correctly report nonzero when running modify_service. The problem manifests in the optimizations, where you restart them and they report 0.

  • BP – MolSSI has been focused on writing for renewal

  • BP – Working on the next major release, anticipating major server update in June, then updating clients after that.

User discussion

  • TG – When I restart optimizations in a torsiondrive, should I then restart the torsiondrive?

    • BP – Good question. My first instinct is to restart the optimization.

    • TG – I do this, and I also restart the torsiondrive. A parallel question is whether I should just restart the torsiondrive.

    • BP – I’m working on a refactor of the services now, and will think about ways to make this clearer/easier

  • JH – Re: restarts – Would it be possible to count the total number of restarts in the compute spec, so the server can handle the restarts itself. RIght now we can retry individual claculations, but I’d want to restarts opts and torsiondrives themselves

    • BP – So, like, you’d restart a torsiondrive and it’d restart all the optimizations?

    • BP – This is something I really want to do, since it seems really handy for users. The tricky part is that we want tos ave the output+error for every time the job is attempted, so that people can check the successive outputs and the server logic can make a decision based on the contents. So we’d keep something like an “error/output trajectory”

  •  

Action items

Decisions