Is it really that expensive compared to the optimization per se??

On 25 sept. 2013, at 20:48, Daniel Russel <drussel@gmail.com> wrote:

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.com> wrote:
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.com> wrote:
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