speed up sampling - Call graph about torsionfit HOT 2 CLOSED

Hm. Collectively, get_value takes up 370 s (75%) of the runtime, but it seems like this might be a lazy function that masks the actual compute time.

compute_energy claims to take up 75% of the runtime, but the OpenMM energy computation routine getState() is only 2.5%---the rest of the time is new_fcn(), with a cyclic (?) call to createSystem and omm_nonbonded_force, but collectively these supposedly only account for ~10%. Where the time is actually being spent is a mystery to me.

It seems like things could be sped up by two things:

1. Minimizing the number of unit conversions required by setting up the whole PyMC model in a standard unit system. You can convert everything to compatible units by calling quantity.value_in_unit_system(simtk.unit.md_unit_system). Once you strip the units when setting up the PyMC model and functions, you avoid the cost of converting back/forth from units every step, though you still have to worry about stripping units from calls to context.getState(getEnergy=True).getPotentialEnergy().
2. There are a lot of calls to createSystem because you separately create an OpenMM System object, instantiate a Context, compute the energy, and delete everything for each configuration of each fragment. There are many ways to speed this up, but even caching the System object for a given param inside of TorsionScanSet would probably speed things up immensely.

I would suggest first merging your fragments branch with the main repo via a PR and then trying to do some optimization, making sure tests still pass for each optimization. Sine we are using nose-timer, you can easily see if you are improving speed during the nosetests.

from torsionfit.

Addressed in #25

1. system was cached
2. removed deep copy in ParmEd
3. switched to sqlite backend

This resulted in a 100x speedup.

from torsionfit.