/
2021-09-27 Core Developers meeting notes

2021-09-27 Core Developers meeting notes

Participants

  •  

Goals

  •  

Discussion topics

Item

Notes

Item

Notes

General updates

  • Daylight savings in USA, EU, AUS/NZ will be taking effect at different times for the next month. Plan meetings around possibly missing folks who are confused about the time change.

Updates

  • IP

    • Working on from_pdb – Realized Toolkit already had to_networkx and from_networkx. I’m close on making a PR with functioning prototype.

    • Tried CCTBX (toolbox from Phenix folks) to assign rich chemical information to PDB. Found that it can read PDB and get chains+residues, but it doesn’t have chemical info. They’re also a bit strict about which PDBs can be loaded - For example our T4 lysozyme PDB can’t be loaded because it’s missing expected headers. So in general we may encounter trouble in this direction because of strict input requirements.

    • JW and IP will meet to discuss detailed progress.

  • CC

    • I’ve met with stakeholders on review paper. Lots of good feedback, now I’m waiting on them so I’ll be focused on FF dev for the next for weeks.

    • JW – QCA needs? 2D torsiondrive?

      • CC – Like I said in last in last week’s QC Submission meeting, I’d like to do multidimensional torsiondrived with other dihedral constraints. I’m working with JH on this.

      • CC – Ability to run QM/MM in QCArchive? Not sure how we’d specify which parts of input molecules should be in the QM part of the system, and which should be in the MM. I’m thinking about running benchmark sims, finding the portion of the sims that are causing deviations from the target values, and using those deviating snapshots for future training iterations. Could also do something like ipolq method, where you take the average position of solvent around the molecule being parameterized, and then use the average solvent field to derive FF parameters.

        • DD – Ah, so not combining potentials/forces from both QM and MM, but rather treating different parts of the system as wholly different sims? So this would need to happen at the level of gradient calculations, something like XTB. Do we know engines that can handle this?

        • CC – ORCA can do this. Psi4 can do point charges. Not sure about XTB.

        • DD – So this’d need to be wrapped in QCEngine, and the parameters for what to calculate and how to calculate it would need to go through the QCEngine API/object model.

    • CC – Compiling abstract for BPS meeting, due Friday. Most folks on this call should be authors. Hping to give an overview of FF generation with OpenFF infrastructure – QCArchive, forcebalance, qcsubmit, evaluator, toolkit, and interchange. I’ll make a draft this afternoon and ask for feedback from other stakeholders – Want feedback on drafts to ensure that I cover all the cool, important stuff that we are/will be using.

  • MT

    • CHARMM-GUI

      • Single “OpenFF” entry on website, unclear which version they use

      • Documented that “OpenFF” does not work with CHARMM. CHARMM doesn’t use 1-4 scaling factors, so OpenFF-parameterized mol combined with CHARMM system doesn’t use scaling factors

      • Tried making a AMBER protein + ligand system with their UI and it errors out

    • Psi4 + conda-forge

      • Opened

      • No clear political/legal blockers

      • Many technical hurdles - some deep, some broad

        • Biggest concern is libint – Kinda tangled technical and personal/organizational details.

      • JW – This is a great idea, if we go this route then we’ll want to have someone with a few hours of bandwidth a week to coordinate all the developers and any contractors

        • MT – I can probably do this, but let’s discuss details alter.

        • DD – This overlaps with my role(s) as well and is something I’d like to learn.

    • Started a GROMACS topology file parser. Currently one difficulty is that I have to use a MDTraj topology to hold atom type/topology details until toolkit topology refactor gets a native structure in place. Using intermol a lot at this stage.

    • Beat the drum on SMIRNOFF issues

      • Now a blocker for many Interchange features

      • Not clear who is responsible; issues linger for months

      • Will start opening PRs next week

    • Started a user guide for Interchange

      • Chicken and egg: no users to start a feedback-development loop

    • Met with PB about using Interchange in fitting

      • Replaced create_openmm_system in a torsion scan analysis script

      • Looking into migrating forcebalance (test-only basis)
        Might look into migrating Evaluator - not clear the value add

        • JW – We have to make a choice about whether to polish ForceBalance for another year of use or whether we’ll make a big push to achieve ML nirvana. If we commit a lot to cleanup FB for ease of use we should deprioritize ML, if we pick ML then we can let FB kinda fall out of good repair.

        • MT – Will Rosemary be fit using FB?

          • CC – That seems like the current path.

          • JW – I think so

        •  

  • DD

    • QCArchive

      • put together proposal with Jeff this week on QCArchive advancement scope;
        we have a new grant to work with to execute on this

      • worked on adjusting our PRP deployments to reduce eviction rate. Was probably due to filling up temporary disk space, working on resolving.

      • tried to address issue with ConnectionRefusedErrors on error cycling for basic datasets;
        have not succeeded; requires action on the server to fix

      • worked with Josh to get production QCArchive managers up on Newcastle

      • worked with Pavan to get his own QCFractal server + managers working on UCI HPC3 for experimental/exploratory work

      • need to push for QCEngine release this week; SB’s torsiondrive executor will be active in the next release

    • Protein-Ligand Benchmarks

      • carved out time for protein-ligand benchmarks last week

      • a new iteration of the design document

      • aiming to spend half to 2/3 my OpenFF time on this area for the next two months

      • DD – Parts of this design will require an AWS root account – How can we get one of these started for OpenFF/OMSF?

        • JW – I’ll ping Karmen and CC you on this – Should be much easier now that we have freestanding OMSF. Can begin a low testing budget initially and increase as needed.

        • IP – We’re looking at benchmarking Perses as well – Will this be re-usable for perses benchmark?

          • DD – Yes, we’re actually using Perses for the F@H PL benchmarking project.

          • IP – Our major interest is in ensuring stability of outcomes between Perses releases, so we can ensure that our software changes don’t affect calculated values too much.

          • DD – This should work well – Part of the task/job specification will include the software versions, so a submitting a job when there’s been a new Perses release will make the submission distinct.

    • Partner Benchmarking

      • Lorenzo has put out announcements to rally Sage results from partners;
        coaching him on how to do this messaging effectively

        • he is also coordinating the effort to get blanket approval for public benchmark with Schrodinger,
          and also will be coordinating compute across a few partners

      • going to put together a retrospective survey for partners

      • JW – I’ve been doing effort planning for 2022, it looks like I won’t have bandwidth for benchmarking refactor until Feb 2022 at the earliest.

        • DD – That sounds good, we can check in with benchmarking team and update partners in Decemberish.

  • PB

    • Last week got back on to the wbo saddle and it occupied most of the time, a bit of dataset generation for biaryls-without-ortho-substituents, thanks to David for helping me setup a local qcfractal instance. And then some fitting experiments with the generated data. It's still in works, got some feedback from Chris Bayly & Mobley in my update meeting, have to work on that this week. Will be meeting simon tomorrow for planning some more fitting experiments.

      • JW – I wonder if random noise from conformer dependence are making WBO torsion work harder than it needs to be. This could overlap with Connor Davel’s

      • PB – We’re selecting molecules that are small/rigid enough to not have a ton of conformer dependence.

      • PB – Is there a faster way to do bond order calculations?

        • JW – Maybe espaloma? Or using the bond_orders_from_molecules kwarg to create_openmm_system to keep from having to repeatedly recalculate?

        • JW – Could use maxcyc=0 setting with antechamber/sqm – I can show you how to do this.

    • PB – I’d discussed periodic boxes + PME with MT last week. I’ve tested it and I’m seeing differences on the order of 1e-4 kcal/mol due to different settings here.

      • MT – For context: For small molecule topologies we don’t assign periodic boxes because there’s no point. So this causes OpenMM to use “NoCutoff” nonbonded, but the Parsley/Sage FFs say to use cutoff vdW. I’ve written up an issue on this conflict here:

    • PB – Will the “SMIRNOFF-correct” answer for these energies be in the reference energies package? Or “What the Toolkit does” answers?

      • MT – In reference energies, I plan to publish SMIRNOFF-correct numbers.

  • LW

    • Mostly worked on Australian PhD stuff.

    • Putting together framework for Boltzmann-weighted conformer RESP/2 using MolSSI stack

      • Looked into putting QCSchema => GRID_ESP computation somewhere upstream into QCengine or Psi4 – not sure I’m familiar enough with either package to do a robust/good implementation.

        • Would be really handy to just call {“properties”: [“GRID_ESP”], “keywords”: {“grid”: my_grid}}

        • Psi4: has a schema_wrappers.py that runs a very small selection of potential jobs encoded by QCSchema

        • QCEngine: makes a json file of the schema and calls psi4 on it

        • DD – Downside of making this part of the calculation spec is that specifying grid with job description is that we’d have to redo the QM every time we change the grid resolution/points. Also, once we start storing whole grids, the space requirements get much larger. We’re not sure that we have a QCEngine implementation (or the expertise to make a QCEngine implementation) that’s broad enough to cover all the different ways that different packages handle grids. But if it doesn’t go there, then the implementation will have to go in psi4, but I don’t know how to specify the details of what is needed. Could you open an issue on Psi4?

          • LW – Can do. I saw that WWang at last week’s QCSubmission meeting was going down the path of writing yet-another-implementation so I figured it would be good to have a single well-supported implementation.

      • Adapted some toolkit methods for selecting low-energy diverse conformers; now putting some improvements back into toolkit with

  •  

  • JW –

    • Botched FB 1.9.1 release, made a hopefully-not-botched 1.9.2 release. Considering whether it’d be worth it to embark on a great polishing/refactor next year.

      • MT – Agree with this concern. We should consider this as a precedent when we’re looking at taking on new dependencies from different orgs with different levels of funding/reliability.

    • Possible parmed fire – MT, can I delegate to you?

      • MT – Yes

    • Worked on roadmap revision – Trying to collect tasks that will take >= 2 weeks.

    • HierarchyElements+Schemes merged into topology refactor branch. Will be working on deprecating TopologyMolecule this week. Next will work on AtomTypedMolecule.

 

 

Action items

Decisions

Related content