hi guys,
i discovered the MD optimizer in imp and i am interested in using it. when studying the input, i am missing something: how is the temperature equilibrated? there is no parameter for that in the input (equil in dodgy old modeller). also in the source code i did not figure out where the temperature is actually used... is the function safe to be used now? or should i rather not?
thanks
frido
Friedrich Foerster wrote: > i discovered the MD optimizer in imp and i am interested in using it. > when studying the input, i am missing something: how is the > temperature equilibrated? there is no parameter for that in the input > (equil in dodgy old modeller). also in the source code i did not > figure out where the temperature is actually used... > is the function safe to be used now? or should i rather not?
MD is currently a very simple implementation, and doesn't do much beyond moving the atoms around. You should come talk to me (or hash it out on the mailing list or wiki) about your specific needs. Equilibration in particular isn't implemented in the way you might expect, because to do it the Modeller Way (temperature and equil arguments to the optimizer) isn't very general. I instead propose something similar to:
1. An abstract DynamicsAction class from which concrete classes such as VelocityScalingThermostat (which is what Modeller's MD does), NoseHooverThermostat, etc. derive.
2. The MD class maintains a list of DynamicsAction objects and calls an evaluate() method on each one at each dynamics step.
Any comments? I don't think using OptimizerStates for this is appropriate, since they generally are optimizer-agnostic, and probably shouldn't be tinkering with the optimization state, whereas a DynamicsAction would be expected to actually go in and mess with the velocities etc.
Ben
On Feb 22, 2008, at 2:45 PM, Ben Webb wrote:
> Friedrich Foerster wrote: >> i discovered the MD optimizer in imp and i am interested in using it. >> when studying the input, i am missing something: how is the >> temperature equilibrated? there is no parameter for that in the input >> (equil in dodgy old modeller). also in the source code i did not >> figure out where the temperature is actually used... >> is the function safe to be used now? or should i rather not? > > MD is currently a very simple implementation, and doesn't do much > beyond > moving the atoms around. You should come talk to me (or hash it out on > the mailing list or wiki) about your specific needs. i am currently not in the lab and therefore miss the opportunity to earn a fortune on ebay with old harddisks. do you have an old mac around? previous lab members dealt pretty antique machines for significant amounts;) > Equilibration in > particular isn't implemented in the way you might expect, because to > do > it the Modeller Way (temperature and equil arguments to the optimizer) > isn't very general. I instead propose something similar to: > > 1. An abstract DynamicsAction class from which concrete classes such > as > VelocityScalingThermostat (which is what Modeller's MD does), > NoseHooverThermostat, etc. derive. sounds good to me. for my purpose, the crude modeller way is probably sufficient, but more flexibility is certainly good. > > > 2. The MD class maintains a list of DynamicsAction objects and calls > an > evaluate() method on each one at each dynamics step. > > Any comments? I don't think using OptimizerStates for this is > appropriate, since they generally are optimizer-agnostic, and probably > shouldn't be tinkering with the optimization state, whereas a > DynamicsAction would be expected to actually go in and mess with the > velocities etc. > > Ben > -- > ben@salilab.org http://salilab.org/~ben/ > "It is a capital mistake to theorize before one has data." > - Sir Arthur Conan Doyle > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
> Any comments? I don't think using OptimizerStates for this is > appropriate, since they generally are optimizer-agnostic, and probably > shouldn't be tinkering with the optimization state, whereas a > DynamicsAction would be expected to actually go in and mess with the > velocities etc. I think it should be considered OK for OptimizerStates to mess with the state. It does introduce ordering issues but these will be complicated any time we have objects messing with the state, whatever we call them. And they are executed at the right time.
Also if we want to outlaw it, we should change various pointers to const.
hi,
I would like to iterate over all restraints. To my understating the way to do that today is using model.get_restraints(), although the restraints I get might also be of type RestraintSet. It seems that today one basically needs to know which restraint sets the model contains. I suggest to add a function Flat() in class Restraint that returns a flat list of all restraint in that instance ( will be called recursively with RestraintSet).
thoughts?
Keren.
So in C++ you can just do something like
template <class C> void visit_restraints(C *m) for (typename C::RestraintIterator rit= m->restraints_begin(); rit != m->restraints_end(); ++rit) { RestraintSet *rs= dynamic_cast<RestraintSet>(*rit); if (rs) { visit_restraints(rs); } else { do something to the restraint } } }
In python I would imagine you can do something similar, but I don't really know how. Ben?
I don't like the idea of a Flat method (first, because the name is all wrong). More importantly, in most cases, whether a restraint contains others (like Bret's do) is really just an implementation detail and is something that should not be exposed.
What are you trying to accomplish? If it is getting a dependency graph, you will have all sorts of problems with nonbonded lists and other sorts of indirect relationships.
How about requiring that Restraint::get_particles() always returns all the particles that affect the Restraint? It would be horribly expensive in the worst case, but....
We may need to introduce some lower level mechanism. For example, a method on Object which returns a list of all pointers contained to other objects. I may be able to implement that in a clean way with only the overhead of one extra int per pointer.
On Feb 23, 2008, at 5:19 PM, Keren Lasker wrote:
> hi, > > I would like to iterate over all restraints. > To my understating the way to do that today is using > model.get_restraints(), although the restraints I get might also be > of type RestraintSet. > It seems that today one basically needs to know which restraint sets > the > model contains. > I suggest to add a function Flat() in class Restraint that returns a > flat list of all restraint in that instance ( will be called > recursively with RestraintSet). > > thoughts? > > Keren. > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
> What are you trying to accomplish? If it is getting a dependency graph, you > will have all sorts of problems with nonbonded lists and other sorts of > indirect relationships.
It is for generating the dependency graph. The idea is to generate the graph and then run inference on it. I am not really interested in all the restraints that build one logic restraint, but Frido and I have for example a restraint set of all the Y2H restraints. I would like to be able to go over it.
> How about requiring that Restraint::get_particles() always returns all the > particles that affect the Restraint? It would be horribly expensive in the > worst case, but.... Maybe we can specific the level of particles we are intersted in, for example if we are working on the protein level, I will not be intersted in getting all the atom particles but just the protein ones.
> We may need to introduce some lower level mechanism. For example, a method on > Object which returns a list of all pointers contained to other objects. I may > be able to implement that in a clean way with only the overhead of one extra > int per pointer. great :) - but we'll have to decide what the list should contain ... :) > > On Feb 23, 2008, at 5:19 PM, Keren Lasker wrote: > >> hi, >> >> I would like to iterate over all restraints. >> To my understating the way to do that today is using >> model.get_restraints(), although the restraints I get might also be >> of type RestraintSet. >> It seems that today one basically needs to know which restraint sets the >> model contains. >> I suggest to add a function Flat() in class Restraint that returns a flat >> list of all restraint in that instance ( will be called >> recursively with RestraintSet). >> >> thoughts? >> >> Keren. >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev@salilab.org >> https://salilab.org/mailman/listinfo/imp-dev
Keren Lasker wrote: > I would like to iterate over all restraints. > To my understating the way to do that today is using > model.get_restraints(), although the restraints I get might also be > of type RestraintSet. > It seems that today one basically needs to know which restraint sets the > model contains. > I suggest to add a function Flat() in class Restraint that returns a flat list of all restraint in that instance ( will be called > recursively with RestraintSet).
I think we need to keep the number of virtual methods in Restraint to a minimum. As Daniel points out, you can certainly try to dynamic cast each restraint to a RestraintSet if you want to enumerate them in C++. I don't know of any way to do this at the Python level, so I asked on the SWIG mailing list for suggestions. I'll report back what I hear from those guys. (It would be straightforward to write a SWIG helper function that did the dynamic cast though, if there's no way of doing it automatically.)
Your other option is to do what Frido is currently doing - keep a reference in Python to the RestraintSets you're interested in looking at later. Since everything is dynamic typed at the Python level, it's very easy to build all sorts of useful hierarchies there at runtime.
Ben
On Feb 23, 2008, at 9:57 PM, Ben Webb wrote:
> Keren Lasker wrote: >> I would like to iterate over all restraints. >> To my understating the way to do that today is using >> model.get_restraints(), although the restraints I get might also be >> of type RestraintSet. >> It seems that today one basically needs to know which restraint >> sets the >> model contains. >> I suggest to add a function Flat() in class Restraint that returns >> a flat list of all restraint in that instance ( will be called >> recursively with RestraintSet). > > > Your other option is to do what Frido is currently doing - keep a > reference in Python to the RestraintSets you're interested in > looking at > later. Since everything is dynamic typed at the Python level, it's > very > easy to build all sorts of useful hierarchies there at runtime. that is my current solution, but I think that we should have a more general solution ( probably the dynamic casting is good enough for now). > > > Ben > -- > ben@salilab.org http://salilab.org/~ben/ > "It is a capital mistake to theorize before one has data." > - Sir Arthur Conan Doyle > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
Friedrich Foerster wrote: > i discovered the MD optimizer in imp and i am interested in using it. > when studying the input, i am missing something: how is the > temperature equilibrated? there is no parameter for that in the input > (equil in dodgy old modeller). also in the source code i did not > figure out where the temperature is actually used... > is the function safe to be used now? or should i rather not?
As of last night's build, IMP.MolecularDynamics should be usable - it can at least do everything that Modeller's MD does (with the exception of rigid bodies and self-guided or Langevin dynamics[*]). A simple checklist for the Modeller people:
1. Velocities by default are NOT initialized - they are kept from any previous run (or they are zero for the first run). To initialize them to a given temperature, call the assign_velocities method. 2. Atom shifts are NOT capped by default (Modeller's cap_atom_shift parameter). But you can cap the velocity component with the set_velocity_cap method (with the default Modeller shift of 0.2A and timestep of 4.0fs, the equivalent velocity cap would be 0.05A/fs). 3. No equilibration is done (Modeller's equilibrate parameter). But you can get something similar by creating a VelocityScalingOptimizerState and adding it to the optimizer. That has a rescale_velocities method, which you can whenever you like (otherwise it will rescale the velocities every skip_steps). 4. Unlike Modeller, IMP uses 'real' masses in MD. Each particle to be optimized must be given a 'mass' parameter, which is the mass in AMU (g/mol). I suppose if you wanted to be perverse you could emulate the Modeller behavior by giving every particle a mass of 12.011.
[*] Guided Langevin dynamics should be simple, however (just override the virtual step method in a derived class). I need this for my refinement anyway, so it will appear in the near future.
See also https://salilab.org/imp/doc/doxygen/classIMP_1_1MolecularDynamics.html and https://salilab.org/imp/doc/doxygen/classIMP_1_1VelocityScalingOptimizerStat...
Ben
-
Ben Webb -
Daniel Russel -
Friedrich Foerster -
Keren Lasker