[Chimera-users] PDB
Eric Pettersen
pett at cgl.ucsf.edu
Wed Jun 23 14:38:56 PDT 2010
Hi Matt,
I can see your motivation. I don't know how you are going about
updating the session file, but I think it's relatively simple. Let's
say your eight (identical) monomers are open as models 0-7. I believe
this would do it:
sel #0-7
open 0 new_monomer.pdb
open 1 new_monomer.pdb
open 2 new_monomer.pdb
open 3 new_monomer.pdb
open 4 new_monomer.pdb
open 5 new_monomer.pdb
open 6 new_monomer.pdb
open 7 new_monomer.pdb
del sel
--Eric
On Jun 23, 2010, at 2:07 PM, Dougherty, Matthew T wrote:
> Hi Eric,
>
> Yes this is closer to the situation, lots of monomers making up a
> complete virus. But the issue is not data/memory size, but rather
> provenance & transformations.
>
> The researchers are constantly tweaking the PDB data prior to
> submission. I might get a dozen intermediate versions (eg, 12x8 PDB
> structures) before doing a final animation on the final PDB data
> sets. They tend to have the same number of residues/atoms, although
> there may be a few additions of side chains or slight changes in
> backbone xyz coordinates.
>
> Meantime, I am evolving these session files, with different savepos
> camera keyframes, so updating the PDB files becomes more convoluted
> as the session file becomes more complicated (e.g., introduction of
> corresponding EM densities, use of dozens of keyframes), plus the
> entanglement of the camera transformations and the model
> transformations.
>
> Matt
> ________________________________________
> From: Eric Pettersen [pett at cgl.ucsf.edu]
> Sent: Wednesday, June 23, 2010 3:51 PM
> To: Dougherty, Matthew T
> Cc: chimera-users at cgl.ucsf.edu BB
> Subject: Re: [Chimera-users] PDB
>
> Perhaps the situation is that you have the same session using dozens
> or hundreds of copies of the same PDB file?
>
> --Eric
>
> On Jun 23, 2010, at 1:47 PM, Eric Pettersen wrote:
>
> On Jun 23, 2010, at 12:48 PM, Dougherty, Matthew T wrote:
>
> Hi,
>
> When PDF files are read by Chimera and the session is written, the
> PDB data becomes part and parcel with the session files. That is,
> Chimera does not go back to the PDB files when it reloads the
> session, it uses the PDB data within the session file instead; as
> contrasted to density volume files, which are referenced by the
> session file, and the density volume files reloaded when the session
> file is read by Chimera.
>
> Is there a way to force the session file not to save the PDB
> internally to the session file, and instead reference and interact
> with it similar to the way volume files are managed?
>
> Hi Matthew,
> Briefly: no. For a variety of reasons:
>
> 1) Structural data didn't necessarily come from PDB files.
> 2) What to do about structure deletions and additions?
> 3) Session is less transportable/publishable (also occurs with
> volume files separate from sessions)
>
> I don't see any upside really. You wouldn't be able to swap in a
> different PDB file because there would structure attributes stored
> in the session file (charges, conservation scores, etc.) that would
> need to be mapped on a 1-for-1 basis with atoms/residues of the
> original PDB file. I guess if your PDB file was huge there would be
> some space savings from having multiple sessions referencing the
> same PDB file. Nonetheless, the space issue is a lot less important
> for structure files than volume files.
>
> --Eric
>
> Eric Pettersen
> UCSF Computer Graphics Lab
> http://www.cgl.ucsf.edu
>
>
> _______________________________________________
> Chimera-users mailing list
> Chimera-users at cgl.ucsf.edu<mailto:Chimera-users at cgl.ucsf.edu>
> http://www.cgl.ucsf.edu/mailman/listinfo/chimera-users
>
>
More information about the Chimera-users
mailing list