Something is confused here. MC only moves things through movers. CG will move any attribute that is optimized, so if you are using that then you also need to make sure coordinates are not optimized.
On Fri, Sep 27, 2013 at 2:11 AM, Davide Baù davide.bau@gmail.com wrote:
> Hi, > > not adding particles to the movers has not effect > unless set_coordinates_are_optimized(false) is set, i.e. > if set_coordinates_are_optimized == True, particles will move even though > they have not been added to the mover. > > Davide > > > The cheaper way to keep them from moving is just to not add them to the > movers. The set_coordinates_are_optimized(false) approach was expensive > both computational (since the movers had to check each time they were > requested to move the particle whether it could actually be moved) and in > terms of code since the checks had to be consistently done in many places > (and weren't). > > > On Wed, Sep 25, 2013 at 1:44 AM, Davide Baù davide.bau@gmail.com wrote: > >> I still think that was a convenient way of keeping particles "untouched". >> It can be done in other ways, but I guess it will be computationally more >> expensive. >> >> Davide >> >> >> >> On Sep 24, 2013, at 9:06 PM, Yannick Spill wrote: >> >> I agree that this is the right way to go. Only MD needs to be changed in >> that respect i believe. >> >> On 24 sept. 2013, at 20:57, Daniel Russel drussel@gmail.com wrote: >> >> There hasn't been any systematic pass through things to make them >> consistent. That said, I think at this point most (all?) movers move the >> particles they are told to move. >> >> *Marking an attribute as not optimized has never meant that the attribute >> will not change during optimization and, similarly, marking it as optimized >> has never meant that it will necessarily be optimized*. For example the >> global coordinates of all members of rigid bodies are set as non-optimized, >> but change. And, marking the z coordinate of something as non-optimized is >> unlikely to ever make it not change (it may trigger an exception though). >> >> Going the a three state `constant` (changes are dropped on the floor), >> `computed` (value is the result of a score state, so changes outside of >> that trigger an error), `variable` (the optimizer can change it if it >> wants) might make the most sense. I'm not sure how expensive adding a check >> if things are constant before setting would be in practice. >> >> >> On Tue, Sep 24, 2013 at 9:43 AM, Barak.raveh barak.raveh@gmail.comwrote: >> >>> I read the issue thread again - so, how does it work right now? >>> >>> On Sep 24, 2013, at 9:37 AM, Daniel Russel drussel@gmail.com wrote: >>> >>> See issue https://github.com/salilab/imp/issues/255. There was (and to >>> some extent is) a lot of ambiguity about how setting individual coordinates >>> to be optimized interactions with telling MC to move them. >>> >>> >>> On Tue, Sep 24, 2013 at 7:24 AM, Davide Baù davide.bau@gmail.comwrote: >>> >>>> Hi all, >>>> >>>> I have a question about the "set_coordinates_are_optimized" function in >>>> IMP 2.0.1. >>>> >>>> In the IMP versions < 2.0, to set the coordinates of a given particle, >>>> e.g., P1 to (0,0,0), I would use the following code: >>>> >>>> > fixedP = "1" >>>> > p = ps.get_particle(index) >>>> > p.set_name(pname) >>>> > if pname == fixedP: >>>> > d = IMP.core.XYZ(p) >>>> > d.set_coordinates(IMP.algebra.Vector3D(0,0,0)) >>>> > d.set_coordinates_are_optimized(False) >>>> >>>> In IMP 2.0.1, even though, at this point, the coordinates of the >>>> particle "fixedP" are set to (0,0,0), the "set_coordinates_are_optimized" >>>> does not seem to work anymore (the coordinates of "fixedP" change during >>>> the optimization). Has this function beed replaced with a new one in the >>>> latest IMP version? >>>> >>>> Thanks, >>>> Davide >>>> _______________________________________________ >>>> IMP-dev mailing list >>>> IMP-dev@salilab.org >>>> https://salilab.org/mailman/listinfo/imp-dev >>>> >>> >>> _______________________________________________ >>> IMP-dev mailing list >>> IMP-dev@salilab.org >>> https://salilab.org/mailman/listinfo/imp-dev >>> >>> >>> _______________________________________________ >>> IMP-dev mailing list >>> IMP-dev@salilab.org >>> https://salilab.org/mailman/listinfo/imp-dev >>> >>> >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev@salilab.org >> https://salilab.org/mailman/listinfo/imp-dev >> >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev@salilab.org >> https://salilab.org/mailman/listinfo/imp-dev >> >> >> >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev@salilab.org >> https://salilab.org/mailman/listinfo/imp-dev >> >> > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev > > > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev > >