Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Current »

Participants

Discussion topics

Item

Notes

General updates

  • JW will be offline Friday

  • MT is working half days East coast time.

  • DD will be offline Thurs+Friday

  • DN will be offline on Monday May 2, until 11 AM Pacific

Individual updates

  • DN

    • Possibility of adding a new item to the Rosemary backlog (virtual sites).

      • Last week at the advisory board meeting, they reaffirmed that they’re interested in having vsites in Rosemary. CBayly was very passionate about this, and he was encouraging us to deprioritize benchmarking in favor of vsites. So I want to hear from you all - Could we add vsites to the backlog? If we’re willing to commit to it, can we not deprioritize any other items?

      • MT – I basically think two things: This is mostly a science team question, and I really liked SB’s response to CBy on the #charge-models channel.

      • SB – This is an interesting question. There’s a couple of frustrating things going on here: CBy seems to think we’re not interested in doing vsites, which is wrong, and that we’re not working on vsites, which is wrong. He should have known this - I asked him the prior week about specific parameterization questions related to vsite fitting. So maybe this is straightened out.

      • SB – He suggested deprioritizing benchmarking because he thought it would speed up work on vsites, and that it would be out of scope for OpenFF. But I think he’s under the misconception that people are interchangable - Pulling DD off of the F@H work will not speed up vsites. I think we need to stress that the benchmarking on F@H isn’t out of scope because the scope is quite limited. We’re not planning to make large changes to pmx and perses, this is almost entirely just to satisfy our narrow benchmarking needs.

      • SB – Re: Can we get vsites into rosemary? It depends on the new science lead and their skills and interests. I can’t commit someone else to do this. There are promising-looking fits and I think we can get them into Rosemary without deprioritizing other stuff. Just some unknown number of little things to fix

      • DD – Do you think CBy is satisfied with this answer?

      • SB – I’m not really sure. What we could do is put together a comprehensive document on what we’re doing, how far we are, what the goalposts are, etc. I think much of this was due to unclear communication, so if we collect this information in a single place we should be in good shape. This page could be a great way to justify the F@H work and show directly how important it is.

      • DD – Should we get JC to weigh in on this? He may be able to convince CBy.

      • SB – I think that could work

      • DN – That was a great response, SB.

      • JW + DD – I’m not sure that a talk specifically between JC and CBy would be helpful.

      • DD – We could distill our WBS on the F@H work into a one-pager if that would help

      • DN – We didn’t get any feedback from the governing board when we presented the vsite tradeoffs at our last meeting. CBy is on the advisory board, not the governing board, so he has no formal decisionmaking power.

      • DD – An executive summary would be great to get everyone on the same side here.

      • SB – DM is usually really good at disentangling hard situations like last Friday.

      • JW DM’ed SB, DN, SM to ask about meeting on this on Wednesday.

  • SB

    • Mostly working on vsites - Getting things together to do fits, doing test fits, looking into the science to figure out why some fits aren’t going how I’d like. But things are moving forward and thanks to MT and JW for quick releases+fixes. So now it seems like something might be fixed since things are looking a bit cleaner - vsites on halogens are looking better.

    • So I’ve been working on the vsite fitting and NN fitting in “gnn-charge-models” under my personal org. I’ll transfer this over to openforcefield org before I go.

    • Once the current bugfix goes in I’ll try to do a quick refit and benchmark set. Hopefully I can do this before the end of the week.

    • My visa got approved and my contract with OpenFF ends at the end of this week, so I may be around a little but my regular work is done and I’ll be heading out.

  • MT

    • Lots of little things surrounding biopolymer release.

    • The 0.11 toolkit units (openff units) are incompatible with old units - Writes things like Å instead of angstrom, which simtk can’t read. So FFs written by new toolkit wouldn’t be readable by old toolkit. Also openff units doesn’t do * between value and unit, which the old toolkit requires.

      • I found a simple solution this morning that writes out Sage from 0.11 in a way that can be read by 0.10.5.

      • Other option could be updating SMIRNOFF spec to explicitly say how units should be written.

      • JW – My only guiding principle is reverse compatibility. I don’t know what a SMIRNOFF spec section on units would even look like - Would we need to proactively define the spelling for every possible unit that we might ever use?

      • PB – Are OFFXMLs the only places where we see this?

      • MT – Kinda. There are two sorts of unit interop situations - In memory conversion and on-disk conversion. OpenFF units already provides in-memory conversion, it’s just the parseability of on-disk sources

      • JW – There’s also serialized molecules (partial charges, conformers) where this will come up.

    • MT – Likely 0.10.6 toolkit release today/tomorrow. This is to fix a loading/unloading problem for vsites from XML.

  • DD

    • Protein-ligand benchmarks

      • working session with Richard Gowers to finish out gufe#13

      • focused on Protocol, and got into what execution looks like

      • tried to hone in on what goes where in Protocol, what a Protocol author needs to write, what objects go where in execution, etc.

      • iterating separately on the ideas we came up with, problems we hit; meeting up again later this week to present our ideas to each other

    • QCArchive

      • now have access to MPI cluster; setting up execution for managers

      • worked with Ben on getting openff-qcsubmit compatible with QCFractal next; making progress but it's a slog

        • uncovering small issues with QCFractal next, which is helpful to Ben

        • Trying to limit scope to compatibility updates, but I keep seeing opportunities to simplify the overall workflow given our more informed scope now and the new structure of qcfractal next. But I’m trying to focus only on compatibility for this release.

      • briefly worked on export pathway for SPICE datasets; better solutions to this must come from next, so prioritizing getting that deployed with Ben

  • PB

    • Less productive last week, worked on looking at chemistries that have bad torsion profiles on non-training sets on QCA and checking whether some of those can be resolved with a parameter split. Working with Trevor to push some valence parameter improvements.

    • Have lot of writing tasks pending, have to work on them this week.

  • JW –

    • Debugged OE chemical environment matches test failure

    • Really strange OE hierarchy metadata assignment when things are undefined - Defaulting all undefined atoms to " ", 1, "UNL". Roundtrippability is now not guaranteed in to/from OE+RDKit, since hierarchy metadata will be added if it wasn’t there before.

    • Expect biopolymer alpha this week

    • Bespokefit working session with Swope and Horton. DD had gotten the benchmarking project to work, could have suggestions? Maybe we should make single file installers. Meeting again this Tuesday.

    • Bit of org stuff, project planning and getting ready for sci lead transition

Action items

  •  

Decisions

  • No labels