Repository navigation
Remove global PathMover.engine #150
Description
Only Shooters need an engine (so far), so we add the engine to the shooter as an option or
add it as a class variable to ShootMover
The first approach would allow to store the engine, but store the engine with each mover separately.
The second approach is simpler because it only need to set the engine once, but we would need to store the used engine somehow separately
Activity
dwhswenson commentedon Feb 7, 2015
Note that this also needs to be added to classes which use the ShootMovers: that makes it a little more complicated to use initialization arguments, since it would require changing
OneWayShootingMover,OneWayShootingMoverSet,MinusMover, and possibly others.On the other hand, I feel weird having it be a class variable. Is it possible to have two Engines at the same time? You could imagine a situation where you want to combine a path sampling approach with temperature replica exchange. In that case, you need a different engine for each T (at least, the way we have engines implemented now).
jhprinz commentedon Feb 7, 2015
Hmmm, it would be kind of cool to allow for multiple engines, although I don't know if our current setting would allow for multiple openmm instances. But in principle we could just program a regular Temperature RepEx algorithm. Interesting. No, wait, we would do Temperature RepEx in Trajectory space. Which could turned into regular RepEx if we only shoot and continue at the old positions.
Just hypothetical. WOuld it make sense to add the temperature and combine TIS trajectories at various temperatures? I don't see why that should not work.
Interesting and easily doable once we have released the first version.
dwhswenson commentedon Feb 7, 2015
When she was here for MolSim, Toni and I talked about the idea of using her TRAM (now xTRAM, if I remember what Frank told me?) in combination with RETIS. If I remember correctly, it was basically a way of handling replica exchange along two axes (by creating sort of "blocks" of one axis within the other? is that right?). So the thought was that there might be some way to do that where one of the axes was RETIS. Not sure if temperature is exactly the right thing to do, which is why I suggest keeping in generic.
In any case, I think that for parallelization we'll eventually take an embarrassingly parallel approach, and farm trajectories out to different nodes. This will probably require a different
DynamicsEngine, and that engine can do the work of making running different instances of OpenMM. So when we really need it, there will probably be a way around it. Just a thing to think about.dwhswenson commentedon Feb 11, 2015
Related note: whether the
engineis associated with instances ofShootMoveror the classShootMoveror the classPathMover, it seems to me that we don't actually need it (in general) forCalculations.Currently it is used in initialization of a calculation, but I don't think anywhere else. Should I remove that?
jhprinz commentedon Feb 12, 2015
Good point, the calculation should be independent of the engine. I think we can savely remove that.
dwhswenson commentedon Feb 28, 2015
How about this:
We make
enginean instance variable for eachShootMover. It defaults to class variablePathMover.default_engine(orShootMover.default_engine?) until it is overridden.There is work using multiple engines for TIS. I hadn't thought about in my earlier posts, but Titus van Erp is developing an approach using ab initio MD for the barrier transition, while doing the minus move using molecular mechanics. It's a clever trick to make the most expensive part of the RETIS calculation a lot cheaper.
Also, we might move
engine.max_length_stopperinto theShootMover: this is a property of the shooting, not of the engine itself (and may be different for different cases of shooting: a minus path may be much longer than a normal shooting move path).jhprinz commentedon Mar 2, 2015
Agreed on all parts.
Using a class variable for the default is probably the best compromise. Especially, since in most cases we will use only one engine.
The multi-engine support should work out of the box. John said that OpenMM supports even multiple instances on one graphics card. So keeping several instances and only run one at a time should be possible without any changes. Also storage can keep several engines already.
For
max_length_stopper, sure that is right now kind of ugly. Adding this to a shooter makes more sense. I would however save this as an integer member variable and not as a real stopper to keep it simple. So each shooter has a number that limits the maximum number of frames. Perhaps we mighthave a
Pathmover.default_max_lengthproperty to change this easily for all shooters.jhprinz commentedon May 15, 2015
For the max_length_ensemble make this a property of each ensemble with a
Ensemble.default_max_lengthproperty. This will be part of the #251.