Add contribution where we perturb from unmodified System objects to alchemical versions about perses HOT 4 CLOSED

It looks like this will require a change in the interface.

We currently have run_example.py call code like this (which will presumably be moved into a Sampler class):

# Initialization
alchemical_engine = alchemical_engine_library.AlchemicalEliminationEngine(alchemical_metadata)
ncmc_engine = ncmc_switching.NCMCEngine(temperature=temperature, timestep=switching_timestep, nsteps=switching_nsteps, functions=switching_functions)
...
# annihilation of old atoms
old_alchemical_system = alchemical_engine.make_alchemical_system(system, top_proposal, direction='delete')
[ncmc_old_positions, ncmc_elimination_logp] = ncmc_engine.integrate(old_alchemical_system, positions, direction='delete')
...
# creation of new atoms
new_alchemical_system = alchemical_engine.make_alchemical_system(top_proposal.new_system, top_proposal, direction='create')
[ncmc_new_positions, ncmc_introduction_logp] = ncmc_engine.integrate(new_alchemical_system, geometry_proposal.new_positions, direction='create')

Here are some possibilities:

• Option 1. Have AlchemicalEngine.make_alchemical_system() also return the logP for changing the system from real to alchemical. This would require additional arguments (temperature).
• Option 2. Have NCMCEngine.integrate() also incorporate the logP for changing the system from real to alchemical. This would require additional arguments (real_system).
• Option 3. Combine AlchemicalEngine with NCMCEngine and merge these calls into a single call:

# Initialization
ncmc_engine = AlchemicalNCMCEngine(temperature=temperature, timestep=switching_timestep, nsteps=switching_nsteps, functions=switching_functions)
...
# annihilation of old atoms
[ncmc_old_positions, ncmc_elimination_logp] = ncmc_engine.integrate(top_proposal, positions, direction='delete')
...
# creation of new atoms
[ncmc_new_positions, ncmc_introduction_logp] = ncmc_engine.integrate(top_proposal, geometry_proposal.new_positions, direction='create')

I actually like Option 3 even if it means a bit more refactoring, since it reduces the number of arguments that must be specified multiple times and eliminates some intermediate variables (old_alchemical_system, new_alchemical_system) that are never used again. I'm not sure if there are really any disadvantages to this.

from perses.

Options 2 and 3 are both fine, IMO.

Re: option 2, I think that now that we have a convenience class for topology proposals that include both new and old systems, requiring real_system is not really a burden at all.

Re: option 3, I think this is probably the best option. Modular code is great, though as you've noted before, the AlchemicalEliminationEngine is just a thin bit of code around AbsoluteAlchemicalFactory anyway, so it might be less error-prone and more straightforward to just combine the two--especially since we'll always be starting and ending at "real" states.

I'm +1 on option 3.

from perses.

Great. I'll try implementing option 3 and see if I run into any showstoppers.

from perses.

Looks like this is resolved.

from perses.