15 mins | B, P, SI Parameter derivation | Joshua Horton | JH – Could use findings/data/methods from QUBEKit/my thesis Thesis doc: https://theses.ncl.ac.uk/jspui/handle/10443/4876 DM – Fig 6.2 from thesis – Is this WBO dependent? Could we check this? JH – Some systematic issue with fitting H bound to boron that caused LJ radius to get huge (like 2.9 A) and charge to get negative DM – Refitting BCCs could maybe prevent this. DC – These weren’t using BCCs - Chargers were derived from higher-level QM and atoms-in-molecules approach. (D-DECK? approach) DM – There are still pathological cases from density fitting approaches. Hirschfeld? has known issues. Esteban vohringer-martinez has done some work here.
DM – 2 pharma people indicated that boron would be helpful. Nobody asked for silicon. JW – In addition to deriving nonbonded parameters, this could lead to a multiplicative increase in number of torsions. DM – Agree, though the initial parameters don’t have to be great. Because right now there are NO options. JH – Especially if these are introduced first through bespokefit
DM – How should we handle the lack of AM1BCC support for this? Can we use SMARTS-based ChargeIncrementHandler? SB – That should be possible. We can kick off some QM calculations to do this. I’m not optimistic about finding property data of silicon and boron in thermoml. JW – We can easily avoid missing parameter errors up front by putting in all-zero wildcard chargeincrement at top of list.
DC – Where could we find more data on physical properties for these molecules? Pharma datasets?
|
15 mins | Thoughts on using XTB fitting from bespoke-fit for free energy runs | Joshua Horton | JH – QM torsiondrives for JACS set is taking a while. xtb calcs finished quickly. So I’ll start working from xtb results, and will also do QM-based fit once it’s done. DC – I’m interested to see how xtb results in vacuum perform in condensed calcs. DC – Remind me which sets we’re going to run calcs on? SB – For free energy calcs, I think we’d been talking to OE about running these calcs through Orion. DM, can you update? DM – OE has had schedule conflicts for regular meetings where we’d ahve talked about this. But they’re generally excited about this. However they’re quite busy right now preparing for a major software release. So this conversation may restart once they’re done with that. DC – Would this complicate things if we wanted to use these results for the bespokefit paper? Would they expect to be coauthors? DM – I don’t imagine that they’d object to this. DC – So, we should go ahead and start generating FF files? SB – I wonder if we could use lilac for this? I looked over the pmx workflow and I think we could run this without Vyutas. Might need to justify use of pmx vs. perses on MSK resources. pmx results seem to be more comparable to previous results/stable so that would probably be best for now. DC – So, among the attendees of this meeting, we don’t have people with expertise in setting up FE calcs. So this is the unknown that we’re thinking about right now. DM – I have a postdoc (MPitman) who has run pmx locally, so she could help. Some usage tricks like hard-wired file names. SB – DHahn should also have expertise in this. So we should have in-house expertise. DM – We could schedule a quick chat with DHahn and MPitman on setup issues. (General) – Some strategic decisions to make with how we use/fork/fix PMX, where we get compute resources, whether we look to another FE framework DM – One nice thing about pmx is that there’s less scope for uncertainty/implementation chagnes. Once the gromacs topology files are written, they’re written, and the simulations will agree within statistical error.
Action items: JH will make up force field files from XTB results. We’ll coordinate a PMX usage meeting with JH, DH, DD, MPitman, JW, SB, DM.
|