small demo of new bespokefit CLI | Joshua Horton | Demo of how to setup and use bespokefit from the CLI to optimise the parameters of a small molecule. DC – Any way to see 2D images of which torsions were scanned? JH – Not yet. The information is in there but it’s not shown by default SB – Yeah, you’d need to go to a specific link in the browser to see the 2D structures. This link isn’t currently printed during the run.
JH – This also makes it easier to do multi-stage fits – aiming to do modified seminaio and bonds next SB – yeah, this is great - Each stage is independent so they can be switched out. Eg could go up to RESP charges and other DM – Could I use this for a rotation student generating torsion parameters for hosts? Would they be able to use this to cut out a repeating unit and custom parameters? JH – Should be possible. I tried to run a host before but fragmentation failed due to conformer generation. DM – I’d have them build something that isn’t a macrocycle (like, break up a few units) JH – That should work. I’ll be recapping this demo in my blog post in a few days.
MMackey’s question – If we fit bespoke parameters using a base FF, can we use them in conjunction with another FF? JW – I’d recommend against making any sort of guarantees about this sort of thing. DC – Also, the most expensive parts of doing bespoke fitting will be the QC jobs, and those should be re-usable for different base FFs. So the cost of redoing the ebspoke fitting shouldn’t be too bad SB – Agree. Also agree that we shouldn’t make guarantees about reusability of bespoke terms on different base FFs. Venkat – So, in general should we rerun the forcebalance jobs for every single release?
|
test results of bespokefit with ANI-2x | Venkat | Venkat – I’ve seen considerable improvements in energy RMSE using customFF. Generally things drop from 1-1.5 kcal/mol RMSE in openff-1.3.0 to 0.25-0.5 kcal/mol for Venkat’s customFF. DC – These numbers are larger than I’m used to seeing, and I think we’ve run on these already. JH is running some Venkat – Is there another dataset that would be better? JH – Only other dataset I can think of would be charged, so ANI wouldn’t be suitable. Venkat – I’m getting undefined stereo errors in the early stages of bespoke fitting. SB – There was an issue in fragmenter where, if the molecule gained or lost a stereocenter as a result of fragmentation. This should be fixed in Fragmenter 0.1.2. If this is still happening in 0.1.2, then please open an Issue on the fragmenter repo, or DM me anything you can share DM – Venkat, could we put this data in the JH’s blog post? Venkat – Sure JH – I could put it there, but I’m a little concerned that bespokefit couldn’t reproduce the data. We’re working on supporting ANI and could do something like Venkat’s pre-optimization so that the discontinuity problems doesn’t break things DM – Is the blocker here still the release of twice-differentiable ANI? SB – I’ll bring the email chain with the roitberg lab back to life, CCing DM. This would be one way to get to production, but it’s a deently steep uphill battle. The easier option may be to loosen the convergence criteria in geomeTRIC to be more tolerant of non-smooth hessians from the energy engine. JH – I’m doing a sensitivity analysis of the geomeTRIC parameters to the final output parameters from bespokefit. SB – In benchmarking on the JACS ligand set, we saw near-parity using our default QM method versus smooth-ANI. I’m still interested to see how XTB fits in here, and that would be extra sueful since it can handle charges DC + JH + DM – Agree that XTB results will be great to see. JH – Big blocker right now is my availability - If someone else can analyze the results, then the QCA jobs are done and this should eb straightforward for someone else SB – I can do this – Let’s touch base
DC – Venkat, you mentioned FE calculations. We haven’t started on this yet, so I’d be really interested to hear when you have results on this. Venkat – Sure SB + JH – JH had contacted Dom Rufa in Chodera lab/Perses team to try running FE calcs with new parameters. We could restart this conversation. SB – We could also contact DHahn and Vyutas Gapsys to try bespoke parameters on the same benchmark set as we’ve used before. JW + DM – It wouldn’t hurt to ask, though we don’t know if VG+DH are still in contact/have compute available for that. DM + JW – We’ll eventually have the ability to run on F@H, though timeline for that is unknown SB – Will this support pmx and Perses? DM – MHenry from Perses team said that it may not be ready for automation in current F@H effort. JW – Initial implementation of F@H automation will be pmx/GROMACS only - This will be a prototype implementation. After we’ve learned how to make this prototype (3-9 months?), we expect the Perses team to have concrete input/output specs, and we can re-evalaute how to make a new implementation that works with either pmx or Perses. SB – Could we have OE run this?
DC – We’re planning to discuss new functional forms in FF release call tomorrow. JW – Targeted feedback on roadmap items?
|