Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Date

Participants

Discussion topics

Item

Notes

TYK2 torsion refits

  • /wiki/spaces/~102144901/pages/786628747

  • JH – Sometimes the same torsion is assigned multiple times around the same bond. Two problems: (1) ForceBalance ends up only changing one of the Chemper-defined torsions (2) optimization takes a LONG time

    • DM – May be

    • JA – This particular case deals with aromatic rings, where the torsion angles are strongly correlated. In something like cyclohexane there could be more of a case for keeping the parameters separate.

    • DM – Could just fit one torsion about each rotatable bond

  • JH – Tried improving computational speed by reducing the number of parameters I’m optimizing. Calculated quality vs. performance for various simplifications (like just using Parsley types)

  • (General) – The computational cost is much lower if we don’t reoptimize the geometry. But it’s important that we refit the geometry.

  • JA – Would there be a way to prune parameters to reduce the search space?

    • JH – Using Parsley as a guide has helped with this. And I do agree that it would be helpful to prune early on

    • DM – This may be premature optimization

    • JW – Is it always the case that the important k values will be visible early on? Or do we risk pruning important terms early on?

    • JA – It would probably still be safe

  • HX – What we do to validate the set, in addition to the torsion scan, we also generate local minima, and ensure that we minimize to those.

    • JH – Could consider adding these as a validation step

  • JW – So, is the big limiting step the speed of MM minimization?

    • JH – Yes, and also the number of optimizations that are needed due to the large number of parameters

  • JH – Would be interested in an intermediate benchmark before full FEP calculations

    • DM – Agree that testing against optimized geometries is a good idea here.

    • JH – So, is the idea to generate random confs that aren’t in the torsion drive?

    • DM – I think that would work.

    • HX – That’s one of our validation steps. We also look at Hvap and other physical properties. But internal energies are the most concrete thing to test against.

    • DM – If we don’t want to generate new QM data, would the optimization trajectories be a good source of confs+energies?

    • HX – Yes

    • JH – a bit concerned about this, since those structures will also have identical torsion angle values

    • DM – Could also do single point calcs on random/omega geometries.

    • JH – Should I do this on the fragments or the whole molecule?

    • DM – Both?

    • JH – Sure

  • There’s one case where the fragment fit gets WORSE, but the whole molecule fit gets BETTER.

    • (General) – So maybe we don’t want to prioritize benchmarking against fragments

  • DR +JH – How will we feed the new files into openmmforcefields?

    • (General) – We’ll make a new FF for each molecule, which is a concatenation of Parsley and the bespoke terms for one molecule.

    • JW will provide JH and DR a code snippet for adding the current directory to the FF-loading entrypoint

  •  Jeffrey Wagner will provide a code snippet to Josh Horton and Dominic Rufa to show how to load a FF from the current directory in openmmforcefields
  • DM – What are our plans for optimizing the phase?

    • JH – Have we ever fit phases using ForceBalance?

    • JW – Do we want to ensure that phases are always physically reasonable? Or will we accept “optimal” numbers even if they’re physically unreasonable/overfit?

    • HX – Our phases are almost always 0 and pi. It turns out that the phase can be factored out and absorbed into the linear coefficients (if there are enough cosine terms available). But we haven’t experimented much here. But if you did refit phase, I’d trust the output.

    • DM – So for now let’s not refit phase.



Action items

  •  

Decisions