Hi Nicolas,
It sounds like you have the "all_states" option set. So, to only have
one object state shown at a time, try
unset all_states
Also, deleting anything in PyMOL is easy:
delete objName
or through the cmd API:
cmd.delete("objName")
Cheers,
-- Jason
On Mon, Mar 7, 2011 at 9:11 PM, Nicolas Bigaouette
<nbigaoue...@gmail.com> wrote:
> Hi Jason,
>
> Thanks for your reply. No, I'm not deleting the cgo objects after the
> relevant frames. Actualy, I don't know how. This what I wanted to do though.
>
> I was able to achieve a workaround. Each time load_cgo() is called to create
> a box, a loop will go through all later time steps adding an empty cgo
> object of the same name. But it seems to be really slow, as expected.
>
> So my error was thinking that giving an object a state would draw the object
> only at that frame: it seems it is drawn for all later frames.
>
> Thus, how can I add an object only for a given state/frame? Should I delete
> the object at the next state/frame? What would be the command to delete a
> cgo object?
>
> Should I store what load_cgo() returns and issue a "delete" over that
> object?
>
> Thanks!
>
>
> On Mon, Mar 7, 2011 at 9:03 PM, Jason Vertrees
> <jason.vertr...@schrodinger.com> wrote:
>>
>> Hi Nicolas,
>>
>> Are you hiding or deleting the boxes after the relevant frame passes?
>> This is hard to debug without seeing sample code.
>>
>> Cheers,
>>
>> -- Jason
>>
>> On Mon, Mar 7, 2011 at 8:39 PM, Nicolas Bigaouette
>> <nbigaoue...@gmail.com> wrote:
>> > Hi all,
>> >
>> > I'm usin pymol to vizualize my molecular dynamics code. Particle
>> > positions
>> > is saved in a single .xyz file. An example is:
>> > 2
>> > 0.00000 fs -- MD of 2 particles (position in Angstrom)
>> > A 0.000 0.000 0.000
>> > E 13.020 0.000 0.000
>> > 2
>> > 0.00050 fs -- MD of 2 particles (position in Angstrom)
>> > A 0.000 0.000 0.000
>> > E 10.520 0.000 0.000
>> > [...]
>> > The number "2" (appearing twice) gives the number of particles to be
>> > read
>> > for that time step.
>> >
>> > I want to add some boxes around some of the particles, so I wrote a a
>> > function that creates a CGO object and add it to a frame/timestep using
>> > "cmd.load_cgo(my_cjo_obj,boxname,timestep)".
>> >
>> > For each time step of my simulation, I load the box informations from a
>> > file
>> > and call my cgo-creating function for the boxes present in the file. For
>> > some time steps, a single box is drawn, for other time steps I can have
>> > many
>> > of them. Some boxes can disappear and also re-appear at a later time
>> > step.
>> >
>> > This means I have "duplicates" boxes. If a box is present at two
>> > different
>> > time steps (with the same "boxname" when calling load_cgo()), it will be
>> > created in pymol multiple times, but the "timestep" option of the
>> > "load_cgo()" command should make it appear at the right time step.
>> >
>> > Unfortunately, it is not working as expected. All the boxes are drawn
>> > correctly and they appear at the righ time. BUT, some of them are not
>> > "hidden" (or deleted) when they should.
>> >
>> > As an example, I'm attaching a webm video of a particle travelling from
>> > right to left (white ball). The initial frame is correct: the boxes are
>> > correctly drawn where I want them. As the particle travels, boxes should
>> > adapt to its location. New boxes are created fine: as the particle is
>> > traveling, we can see boxes adjusting around it. But the two smallest
>> > boxes
>> > are always shown while they should not appear starting from half of the
>> > movie.
>> >
>> > In the loop which creates the CGO objects, I print the box properties to
>> > verify that I don't add the two small boxes when they shouldn't appear.
>> > Except from that, I don't know what else could be wrong. Maybe I'm
>> > abusing
>> > the "state" argument to load_cgo() or not using it correctly?
>> >
>> > Thank you for any help!
>> >
>> > Nicolas
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > What You Don't Know About Data Connectivity CAN Hurt You
>> > This paper provides an overview of data connectivity, details
>> > its effect on application quality, and explores various alternative
>> > solutions. http://p.sf.net/sfu/progress-d2d
>> > _______________________________________________
>> > PyMOL-users mailing list (PyMOL-users@lists.sourceforge.net)
>> > Info Page: https://lists.sourceforge.net/lists/listinfo/pymol-users
>> > Archives: http://www.mail-archive.com/pymol-users@lists.sourceforge.net
>> >
>>
>>
>>
>> --
>> Jason Vertrees, PhD
>> PyMOL Product Manager
>> Schrodinger, LLC
>>
>> (e) jason.vertr...@schrodinger.com
>> (o) +1 (603) 374-7120
>
>
> ------------------------------------------------------------------------------
> What You Don't Know About Data Connectivity CAN Hurt You
> This paper provides an overview of data connectivity, details
> its effect on application quality, and explores various alternative
> solutions. http://p.sf.net/sfu/progress-d2d
> _______________________________________________
> PyMOL-users mailing list (PyMOL-users@lists.sourceforge.net)
> Info Page: https://lists.sourceforge.net/lists/listinfo/pymol-users
> Archives: http://www.mail-archive.com/pymol-users@lists.sourceforge.net
>
--
Jason Vertrees, PhD
PyMOL Product Manager
Schrodinger, LLC
(e) jason.vertr...@schrodinger.com
(o) +1 (603) 374-7120
------------------------------------------------------------------------------
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d
_______________________________________________
PyMOL-users mailing list (PyMOL-users@lists.sourceforge.net)
Info Page: https://lists.sourceforge.net/lists/listinfo/pymol-users
Archives: http://www.mail-archive.com/pymol-users@lists.sourceforge.net
