MT – Want to take Friday Apr 4 off Getting more involved in science team/fitting work MuPT (Big grant led by Shirts and some materials folks) is considering contracting skilled developer-time from OMSF to help with interop and packaging. OpenFF is considering it. What would your feelings be about working with them for some fraction of your time? MT – Not interested. Anticipate there being a lot of friction on leveling up software quality given where it’s started. Also agree there will be friction on CG. Atomistic modeling should work fine once we get our infrastructure smoothed out, even though it’s not currently (also not sure whether RDKit/OE are suitable for molecules at these scales). So I’m not super excited about this but could be talked into if it there are changes. JW – I figure atom replacement is completely out of bounds for the openff namespace. Atomistic stuff is in bounds, either using real or simple molecules. I’m not sure about funcitonal form of CG or if it would fit in via from_openmm MT – There are some CG representaitons that use our funcitonal form (basically with huge atoms). But the realistic ones use altnerative funcitonal forms, and often get nonbonded terms pairwise from lookups (NBFIX style). From a birds-eye view, the existing molecule class would be completely incompatible. The Topology class might need significant changes to work well. Parameter assignment would need to be defined from scratch - Would it use atom types for the beads? Or somehow thread into SMIRNOFF typing some other way? JW – I think parameter assignment is out of the question. Wasn’t sure about externally-parameterized components: if they had Sage-looking functional forms maybe we could squeeze them in, but if it’s weird stuff I’m not sure MT – Idea of fitting in coarse grained reps in interchange isn’t impossible, but interfaces with Toolkit Molecule+Topology will be tough. The SimpleMolecule stuff is still a bit of a kludge and that will need to be rethought.
Up to volunteer to be joint demo presenter+coordinator for 2025 symposium? MT – Yes. I’d told ZB I was interested to do this. JW – Perfect - I think ZB is in charge of this, but I’ll be the OpenFF stakeholder.
We’re considering having one person to be the presenter+coordinator for all the projects, instead of switching off presenters mid-talk. The projects would still need to make the outline, and each would need to supply the bulk of the material for their part of the demo. But the presenter would:
* ensure consistent formatting/pacing, and delegate revisions to the projects
* decide on the technical format (eg: repo vs. gist, RISE vs vanilla notebooks vs. something else, conda env yaml vs. lockfile)
* be responsible for setting up the repo so the audience can install+run everything
* generally “own” all the day-of details (laptop, wifi, adaptors, A/V checks)
* rehearse a lot and iterate with projects to give them feedback about material, and get feedback on the script
|