AlchemicalNonequilibriumLangevinIntegrator acceptance

Copying from the alchemistry Slack channel from @davidlmobley: We’re having some issues with our work on binding mode sampling with NCMC (in BLUES), especially as we try to switch to the AlchemicalNonequilibriumLangevinIntegrator, where we are having large energies/forces that lead to crashes as we are turning back on alchemical interactions between the ligand and the protein. Part of this seems to potentially be due to problems with the alchemical correction factor in certain cases, but we think that actually forces are getting large enough to cause the integrator to lose stability first. Do you have suggestions? We were wondering whether we ought to be checking for forces that exceed some sort of cutoff and automatically rejecting cases where that happens (naively it seems to me there ought to be some sort of force to timestep ratio which determines the largest force that can be tolerated without risking crashes, and that anything exceeding that value by many orders of magnitude should certainly be rejected).

Some notes •For the AlchemicalNonequilibriumLangevinIntegrator we were using R V O H O V R (g-baoab) splitting. •The “alchemical correction factor” is the correction for transform the real system to/from the alchemical system (it was in perses.annihilation.ncmc_switching at one point, https://github.com/choderalab/perses/blob/3c0e672728c0acb87a0efc9fa76bc893f1b5dfed/perses/annihilation/ncmc_switching.py#L162-L182 but glancing over the master branch I don’t see it there now)

[jchodera]

We’ve got a fix for the speed issue in the works: https://github.com/choderalab/openmmtools/pull/218

When I construct AbsoluteAlchemicalFactory with disable_alchemical_dispersion_correction=True, the slowdown is eliminated:

      95 : -319001.077 kJ/mol :    9.914 ms : lambda_sterics   1.00000000 lambda_electrostatics   0.04000000
      96 : -319005.766 kJ/mol :    9.883 ms : lambda_sterics   1.00000000 lambda_electrostatics   0.03000000
      97 : -319047.705 kJ/mol :    9.726 ms : lambda_sterics   1.00000000 lambda_electrostatics   0.02000000
      98 : -319026.067 kJ/mol :   11.732 ms : lambda_sterics   1.00000000 lambda_electrostatics   0.01000000
      99 : -318967.641 kJ/mol :    9.736 ms : lambda_sterics   1.00000000 lambda_electrostatics   0.00000000
     100 : -318978.847 kJ/mol :    9.766 ms : lambda_sterics   0.99333333 lambda_electrostatics   0.00000000
     101 : -319043.797 kJ/mol :    9.910 ms : lambda_sterics   0.98666667 lambda_electrostatics   0.00000000
     102 : -319017.829 kJ/mol :   10.063 ms : lambda_sterics   0.98000000 lambda_electrostatics   0.00000000
     103 : -318845.324 kJ/mol :    9.762 ms : lambda_sterics   0.97333333 lambda_electrostatics   0.00000000
     104 : -318664.833 kJ/mol :   11.491 ms : lambda_sterics   0.96666667 lambda_electrostatics   0.00000000
     105 : -318611.969 kJ/mol :    9.534 ms : lambda_sterics   0.96000000 lambda_electrostatics   0.00000000
     106 : -318625.666 kJ/mol :    9.543 ms : lambda_sterics   0.95333333 lambda_electrostatics   0.00000000

[jchodera]

What about LangevinIntegrator instead inheriting from a base TrotterSplittingIntegrator that would allow velocity Verlet-style integrators?

Alternatively, I like the idea of an override_sanity_checks=False (or maybe sanity_checks=True)?