[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


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