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

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 > >

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

I agree set_is_optimized() is a very intuitive user interface but I appreciate it was hard to maintain for each attribute. Do we really need a different optimization for each attribute? I think it is enough to work at the particle level.

How about we deprecate XYZ::set_coordinates_are_optimized(), and add particle::set_is_optimzed() instead? It seems much easier to implement. I didn't think the coding / computational side through yet, but it might be simpler since it can be applied as a filter on containers. Daniel, I bet for you it might be easier to think how complicated this would be.

On Wed, Sep 25, 2013 at 11:48 AM, 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.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 > >

Thanks Daniel, I will try your suggestion!

Davide

Inviato da Davide. Il giorno 25/set/2013 20:48, "Daniel Russel" drussel@gmail.com ha scritto:

> 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 > >

I was just responding to the claim that other approaches would be computationally more expensive. Overall, I doubt there are many or any circumstances in which the cost of movers matters. But the maintenance cost of keeping code maintained and consistent without any global way of checking it is pretty significant.

On Thu, Sep 26, 2013 at 3:17 AM, Yannick Spill yannick@salilab.org wrote:

> 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.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 > >

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 > >