- Chimera-users - RBVI Mailing Lists

Chimera to visualize MOLDEN-generated VRML2.0 files
by Kalju Kahn 01 Feb '07

01 Feb '07

Dear Chimera users, I am looking for advice on how to make chimera work with VRML 2.0 files generated by MOLDEN. MOLDEN seems to generate valid VRML files (octagaplayer reads these in all right) but chimera crashes with Segmentation fault (core dumped) This happens both on 32-bit Suse 9 system and 64-bit recent Ubuntu system. Any ideas are appreciated! Kalju ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dr. Kalju Kahn Department of Chemistry and Biochemistry University of California, Santa Barbara

2 1

anyone using chimera on a an IBM T43p
by Jeff 01 Feb '07

01 Feb '07

hello, I have an IBM T43p (June '05 or so release) which has an ATI FireGL v3200 (Mobility). In XP, it isn't possible to try out drivers from the vendor, I am limited to drivers from IBM. In Linux, I have been able to install proprietary drivers from ATI, but there is no selection for the 'Mobility' version of the v3200 on ATI's website; the install has not complained though, and basic stuff appears to be fine (GUI is ok, glxgears, etc). In both XP and Linux, chimera will crash when attempting to use volume maps. It appears fine with pdb files, although I typically work with volume data so haven't rigorously tested that. I have been assuming that the FireGL v3200 (Mobility) is the same logic as the v3200, at least documentation I have been able to find seems to imply that. Does anyone know (or suggest) a chimera-stable driver version from ATI that I might test? I might at least be able to get it to work in Linux, as the driver suite downloaded from ATI appears to cover most late-generation cards. thanks for any suggestions, -Jeff

3 2

Re: [Chimera-users] access to pdb parser
by Jean Didier Pie Marechal 01 Feb '07

01 Feb '07

Hi Eric, Well, the truth is that these are two good news. Most likely I didn't explain myself correctly. In reality, for practical reasons, I'd like to use only chimera for the teaching. So, I am planning to only use its internal python shell for python applications. Therefore the tips you gave me are perfect. Thanks a lot for the help! Cheers JD Dr. Jean-Didier Maréchal Professor Lector Unitat de Química Física Departament de Química Universitat Autònoma de Barcelona Edifici C.n. 08193 Cerdonyola (Barcelona) Tel: +34.935814988 e-mail: JeanDidier.Marechal(a)uab.es ----- Missatge original ----- De: Eric Pettersen <pett(a)cgl.ucsf.edu> Data: Dimecres, Gener 31, 2007 10:31 pm Assumpte: Re: [Chimera-users] access to pdb parser > Hi JD, > I have good news and I have bad news. The good news it that using > > PDBio to do what you want is pretty easy. The bad news is that you > > can't use it in a generic Python shell, only in Chimera's own > Python > shell. This is because we use a modified version of Python so that > > the types we define in the C++ layer (Molecule, etc.) can have > attributes added to them in the Python layer -- otherwise they > would > behave like the built-in Python types (dict, list. etc.) that can't > > have arbitrary attributes added to them. We intend to improve our > own code to make modifying Python unnecessary, but haven't gotten > to > it so far. > Nonetheless, you can basically use Chimera in place of a Python > interpreter. "chimera --nogui script.py" will execute the Python > script named script.py without bringing up the Chimera interface. > Also, you can start Chimera normally and bring up the graphical > interface to its interactive Python shell, IDLE (under Tools- > >General > Controls) and type Python commands to that. > Here's a session of me using PDBio in IDLE. I've added some > comments. > >>> from chimera import PDBio # import PDBio > >>> pdbio = PDBio() # create a PDBio instance > >>> mols = pdbio.readPDBfile("/mol/pdb/gc/pdb1gcn.ent") # read a > PDB file given its file name > >>> m = mols[0] # readPDBfile() returned a list of models (NMR > can > have many) so get the model itself > >>> m.pdbHeaders["HEADER"] # each model will have a pdbHeaders > dictionary, keyed by the record type, the values will be a list of > strings -- the PDB records > ['HEADER HORMONE 17-OCT-77 > 1GCN 1GCN 3'] > >>> > > --Eric > > On Jan 31, 2007, at 12:42 PM, Jean Didier Pie Marechal wrote: > > > Hi Eric, > > > > Yes, that would be better to explain more what I'd like to do. > > > > I am planning to give a practical on computational (bio)chemistry > > > in my department next year. I'd stongly like to have the students > > > using chimera and python as their main tools (though both are > tools > > I am in process of learning :-)). > > > > One of the "simple things" I have in mind, is to obtain pdb infos > > > directly from the shell e.g list the SEQRES entry or access to > the > > resolution (REMARK 2), the crystallization conditions etc. The > > students will be chemists and I think that from a didactic point > of > > view, obtaining infos from the python shell would be better that > > reading the pdb files, especially if we want to compare different > > > structures e.g. Writing a comand that gives you ALL the > resolutions > > of the 10 structures you loaded would be interesting. I looked at > > > the PDBio, but I can see how to catch REMARKS infos. > > > > I'd really like to have this work going on, but as you can see, I > > > am a bit lost in where to begin. > > > > Any help to tell me where to start would be fantastic! > > > > Cheers > > > > JD > > > > > > > > > > Dr. Jean-Didier Maréchal > > Professor Lector > > Unitat de Química Física > > Departament de Química > > Universitat Autònoma de Barcelona > > Edifici C.n. > > 08193 Cerdonyola (Barcelona) > > Tel: +34.935814988 > > e-mail: JeanDidier.Marechal(a)uab.es > > > > ----- Missatge original ----- > > De: Eric Pettersen <pett(a)cgl.ucsf.edu> > > Data: Dimarts, Gener 30, 2007 1:25 am > > Assumpte: Re: [Chimera-users] access to pdb parser > > > >> Hi JD, > >> Chimera does its PDB parsing in the C++ layer (the PDBio class in > >> > >> the Python layer). There is a file named PDB.py in the mmCIF- > >> parsing > >> module, but it's not for parsing PDB files. Perhaps if you > >> described > >> why you need Python PDB parsing I could suggest options -- using > >> PDBio possibly being one of them. > >> > >> --Eric > >> > >> Eric Pettersen > >> UCSF Computer Graphics Lab > >> pett(a)cgl.ucsf.edu > >> http://www.cgl.ucsf.edu > >> > >> On Jan 29, 2007, at 1:49 PM, Jean Didier Pie Marechal wrote: > >> > >>> Hello everyone, > >>> > >>> a short question. What is the right call for importing the > >>> pdbparser module in the chimera python shell? I found the PDB.py > >> > >>> module in the site-package mmlib, but I don't know how to import > >> it...> > >>> Thanks a lot, > >>> > >>> JD > >>> > >>> > >>> Dr. Jean-Didier Maréchal > >>> Professor Lector > >>> Unitat de Química Física > >>> Departament de Química > >>> Universitat Autònoma de Barcelona > >>> Edifici C.n. > >>> 08193 Cerdonyola (Barcelona) > >>> Tel: +34.935814988 > >>> e-mail: JeanDidier.Marechal(a)uab.es > >>> > >>> > >>> _______________________________________________ > >>> Chimera-users mailing list > >>> Chimera-users(a)cgl.ucsf.edu > >>> http://www.cgl.ucsf.edu/mailman/listinfo/chimera-users > >> > >> > > > > > >

2 1

TER Cards and Rainbow Colors
by Albion Baucom 31 Jan '07

31 Jan '07

Is there any way to introduce TER records between breaks in a chain, and still have N->C coloring continuous through a single chain? I have for instance a structure with missing loops that were not observed in density. Therefore there are breaks in the main chain. This is a very common occurrence. To prevent spuriously long bonds I have introduced TER records between the breaks. Then when I apply rainbow coloring from N->C terminus I get the spectral coloring between TER records rather than from the beginning of the chain to the end. I tried the card BREAK, but evidently that is not interpreted by Chimera. Coloring by chain, or by model in the Rainbow panel does not produce the desired effect. Thanks Albion

2 1

Re: [Chimera-users] access to pdb parser
by Eric Pettersen 31 Jan '07

31 Jan '07

Hi JD, I have good news and I have bad news. The good news it that using PDBio to do what you want is pretty easy. The bad news is that you can't use it in a generic Python shell, only in Chimera's own Python shell. This is because we use a modified version of Python so that the types we define in the C++ layer (Molecule, etc.) can have attributes added to them in the Python layer -- otherwise they would behave like the built-in Python types (dict, list. etc.) that can't have arbitrary attributes added to them. We intend to improve our own code to make modifying Python unnecessary, but haven't gotten to it so far. Nonetheless, you can basically use Chimera in place of a Python interpreter. "chimera --nogui script.py" will execute the Python script named script.py without bringing up the Chimera interface. Also, you can start Chimera normally and bring up the graphical interface to its interactive Python shell, IDLE (under Tools->General Controls) and type Python commands to that. Here's a session of me using PDBio in IDLE. I've added some comments. >>> from chimera import PDBio # import PDBio >>> pdbio = PDBio() # create a PDBio instance >>> mols = pdbio.readPDBfile("/mol/pdb/gc/pdb1gcn.ent") # read a PDB file given its file name >>> m = mols[0] # readPDBfile() returned a list of models (NMR can have many) so get the model itself >>> m.pdbHeaders["HEADER"] # each model will have a pdbHeaders dictionary, keyed by the record type, the values will be a list of strings -- the PDB records ['HEADER HORMONE 17-OCT-77 1GCN 1GCN 3'] >>> --Eric On Jan 31, 2007, at 12:42 PM, Jean Didier Pie Marechal wrote: > Hi Eric, > > Yes, that would be better to explain more what I'd like to do. > > I am planning to give a practical on computational (bio)chemistry > in my department next year. I'd stongly like to have the students > using chimera and python as their main tools (though both are tools > I am in process of learning :-)). > > One of the "simple things" I have in mind, is to obtain pdb infos > directly from the shell e.g list the SEQRES entry or access to the > resolution (REMARK 2), the crystallization conditions etc. The > students will be chemists and I think that from a didactic point of > view, obtaining infos from the python shell would be better that > reading the pdb files, especially if we want to compare different > structures e.g. Writing a comand that gives you ALL the resolutions > of the 10 structures you loaded would be interesting. I looked at > the PDBio, but I can see how to catch REMARKS infos. > > I'd really like to have this work going on, but as you can see, I > am a bit lost in where to begin. > > Any help to tell me where to start would be fantastic! > > Cheers > > JD > > > > > Dr. Jean-Didier Maréchal > Professor Lector > Unitat de Química Física > Departament de Química > Universitat Autònoma de Barcelona > Edifici C.n. > 08193 Cerdonyola (Barcelona) > Tel: +34.935814988 > e-mail: JeanDidier.Marechal(a)uab.es > > ----- Missatge original ----- > De: Eric Pettersen <pett(a)cgl.ucsf.edu> > Data: Dimarts, Gener 30, 2007 1:25 am > Assumpte: Re: [Chimera-users] access to pdb parser > >> Hi JD, >> Chimera does its PDB parsing in the C++ layer (the PDBio class in >> >> the Python layer). There is a file named PDB.py in the mmCIF- >> parsing >> module, but it's not for parsing PDB files. Perhaps if you >> described >> why you need Python PDB parsing I could suggest options -- using >> PDBio possibly being one of them. >> >> --Eric >> >> Eric Pettersen >> UCSF Computer Graphics Lab >> pett(a)cgl.ucsf.edu >> http://www.cgl.ucsf.edu >> >> On Jan 29, 2007, at 1:49 PM, Jean Didier Pie Marechal wrote: >> >>> Hello everyone, >>> >>> a short question. What is the right call for importing the >>> pdbparser module in the chimera python shell? I found the PDB.py >> >>> module in the site-package mmlib, but I don't know how to import >> it...> >>> Thanks a lot, >>> >>> JD >>> >>> >>> Dr. Jean-Didier Maréchal >>> Professor Lector >>> Unitat de Química Física >>> Departament de Química >>> Universitat Autònoma de Barcelona >>> Edifici C.n. >>> 08193 Cerdonyola (Barcelona) >>> Tel: +34.935814988 >>> e-mail: JeanDidier.Marechal(a)uab.es >>> >>> >>> _______________________________________________ >>> Chimera-users mailing list >>> Chimera-users(a)cgl.ucsf.edu >>> http://www.cgl.ucsf.edu/mailman/listinfo/chimera-users >> >> > >

1 0

Re: [Chimera-users] Update volume display without pressing show
by Thomas Goddard 31 Jan '07

31 Jan '07

Hi Jeff, I also wasn't able to reproduce this problem. There is probably a real problem but some step that causes it is missing. If you figure out that step let me know. Tom Jeff wrote: > sorry about the confusion, > > what I meant by 'does not work', is that once I have loaded the volume > planes tool, it appears to not allow me to select 'update display > without pressing show'. (the button is depressed in the dialog box, or > i unclick/reclick it, but it no longer toggles 'update....w/o press > show' on and off). 2318 build. > > sequence: > > 1) load map; display with solid rendering. default is 'update w/o > press show', and you can see the effect of playing with histogram > update in realtime. > > 2) start volume planes. now requires me to press 'show' to update the > display. this also includes other volumes that vol planes is not used > on, and 'update w/o show' no longer works in surface or solid mode. > > 3) close volume planes, or close session. problem persists. > > 4) restart chimera, now it allows 'update..w/o press show' again. > > so, this happened to me twice, and i figured it was just something to > do with the volume planes tool. As I am writing this, I just re-did > the sequence above, and now it works (volume plane tool updates, can > switch to surface). Because I can no longer replicate this, I should > probably be ignored. Also, I just loaded one of the sessions I was > having a problem with into a new launch of chimera, thinking there > might be some sort of 'system/state snapshot' I could send you, but > now it is working too. So, it appears to have been fixed by a restart > of chimera. Again, please ignore. > > -Jeff

1 0

Re: [Chimera-users] Update volume display without pressing show
by Thomas Goddard 31 Jan '07

31 Jan '07

Hi Jeff, I tried the volume "update show" option in combination with volume planes and did not find an problem. Can you give me step by step instructions to produce the problem? Also I don't know what you mean by "does not work". Does it always update automatically, or never update automatically? What Chimera version? With the volume planes tool, the full map is still opened -- it is just display a subregion that is 1 plane high. Use Features / Region Bounds to see and change the subregion. Or use Features / Subregion Selection and press the Full button to get back to the full map. Also the volume planes dialog always acts on the volume displayed in the volume dialog. Perhaps it should have its own menu to choose the volume you want to show planes for. Tom Jeff wrote: > even if I close the volume planes tool, > > 'update display without pressing Show' no longer works (for instance, > adjusting the volume rendering histogram, or clicking 'surface' > rendering). if I close, then re-open the volume, it still doesn't > work. bug, or my version maybe? > > also, once you start 'volume planes tool', it only keeps track of the > plane it has pulled from the volume map - what used to be a > 100x100x100 volume is now 100x100x1; the volume viewer 'renames' the > map but does not save it out that way (which is good). is there a way > to be able to keep the full volume around, but not displayed? there > are reasons you might want to do that (well, I found myself trying to > do that), without having to re-open the volume. > > i did check to see if i could open 2 copies - one first to run 'volume > planes' on, and then one to subsample but have as a volume rendering, > for example. this works, as long as i don't accidentally touch the > 'volume planes' dialog when fooling with the second opened copy of the > volume. > > mainly just curious, not asking for additional functionality, just > wanted to let you know what I was trying and why. > > -Jeff > > > > Thomas Goddard wrote: >> Hi Jeff, >> >> The volume dialog data display option "Update display without >> pressing Show" only effect volume dialog features. It does not have >> any effect on the Volume Planes tool. The Volume Planes tool does >> not allow adjusting the plane number without updating the display. >> >> Tom >> >> >> Jeff wrote: >>> hi Tom, >>> >>> I have volume planes and precomputed subsamplings going, and the >>> 'update display without pressing Show' no longer works (keep >>> toggling on and off, but it doesn't have an effect) >>> >>> is there a way for me to 'refresh' the state of buttons like that? >>> >>> -Jeff >>

1 0

Watershed segmentation of volumes
by Thomas Goddard 31 Jan '07

31 Jan '07

Hi Jeff, There is no watershed or flood-fill type of method in Chimera for segmenting volume data. This is on our (very long) list of features to develop though. Tom Jeff wrote: > tom, > > i hate to keep piling on questions, but how hard would it be to have a > feature where one places a chimera marker, and then has some sort of > algorithm expand to 'fill' the space, kind of an isosurface problem > (or does this already exist) > > i have 'voids' in some of my maps (stained sections) which i think > correspond to protein, like one sees in negative stain (the positive > values/density in the map correspond to stain; an enclosed void > (density more or less = 0 or close to it) is thought to represent the > actual protein, which was covered in stain, kind of like 'magic shell' > on ice cream - or think of dairy queen cone, dipped in chocolate that > then solidifies), and would like some way to 'grow' a blob in the void > (or at least try) > > does this already exist? i have a buddy who does level set methods who > is often looking for ways to use his library, but i thought i should > ask you first if there is some functionality like this > > -jeff

1 0

Quadro FX 1400/3450 performance
by Thomas Goddard 31 Jan '07

31 Jan '07

Hi Maya, It must be exciting and alot of work to get your lab running. Glad to hear you are making Chimera converts. Graphics benchmark scores using Chimera with the quadro fx 1400 and quadro fx 3400 are shown here http://www.cgl.ucsf.edu/chimera/benchmarks.html We don't have any numbers for the fx 3450 and I don't know if it is similar to the 3400. The 1400 and 3400 have very similar Chimera scores. The Chimera scores indicate how big a test volume can be handled at 10 frames per second. Both these cards are very fast. The one difference I see is that on the Nvidia web site they say the 1400 has 128 Mbytes of memory while the 3450 has 256 Mbytes. http://www.nvidia.com/page/qfx_mr.html http://www.nvidia.com/page/quadrofx.html (fx 3400) Maybe that info is out of date -- maybe there is a choice of memory size. On the Chimera page the fx 1400 had 256 Mb. And 128 Mbytes is small by today's standards. 256 Mbytes is common, and 512 Mbytes is available with some cards. The amount of graphics memory is most noticable if you use the Chimera "solid" rendering mode because it tries to put red,green,blue 8-bit values for the entire volume on the card. For 256^3 volume that is 48 Mbytes, or if you use Chimera 2-D textures mode (the default) it take 3 times that (144 Mbytes). It can also make a difference for very large contour surfaces -- ones you might use for making a figure but would be too slow for interactive rotating (e.g. 10 million triangles at about 18 bytes per triangle = 180 Mbytes). Regarding stereo, I'm not sure if there are any flat panel displays that can work with the LCD glasses. They don't refresh fast enough so there is too much flicker. So you either need a CRT display or maybe some special high-end flat panel. See you at the EMAN workshop. Maya Topf wrote: > Hi Tom, > > How are you? > I am slowly settling down in the UK. Lots of work and collaborations. > A few people from the EM group at birkbeck started using chimera and > they really like it! > > I have a question about graphics cards and maybe you can help me. > I am thinking about buying either NVIDIA QUADRO FX 1400 (stereo) or FX > 3450 (stereo). > Do you think that there is a big difference when I want > to visualise large maps with chimera for example? > > thanks, > Maya > > I saw that you are coming to the eman workshop so I guess I will see > you there! > Tom

1 0

ViewDock descriptors problem
by "Воронков андрей" 31 Jan '07

31 Jan '07

Dear Chimera users, I have ranked database from DOCK. I need to see energies of these structures and their ranking. I open them by View Dock, but in the field Column menu I can see only name field. Why I don't have energy field there and how can I get it? Respectively yours, Andrew PS "Descriptors can be shown in or removed from the upper panel using the Column menu." -this is from manual, but I can;t make shown any descriptos but the name of the structure

2 1

Re: [Chimera-users] using a marker file to zone a volume from python prompt
by Thomas Goddard 30 Jan '07

30 Jan '07

Hi Jeff, I added a user interface dialog for rotating and translating atom coordinates. Markers in Chimera are equivalent to atoms so it works on those. The rotation is specified in Euler angles. The new dialog, called Transform Molecule Coordinates, is available on the experimental features web page: http://www.cgl.ucsf.edu/chimera/experimental/experimental.html Tom Jeff wrote: > thanks Tom, > > much appreciated. how hard is it for me to write a dialog GUI to provide > 3 numerical inputs to the rotation script you forwarded me? (is it more > involved than a few lines? I am not familiar with Tkinter). > > don't want to bother you too much, if it is not a quick thing/response > feel free to punt, please. > > -jeff >

1 0

Update volume display without pressing show
by Thomas Goddard 30 Jan '07

30 Jan '07

Hi Jeff, The volume dialog data display option "Update display without pressing Show" only effect volume dialog features. It does not have any effect on the Volume Planes tool. The Volume Planes tool does not allow adjusting the plane number without updating the display. Tom Jeff wrote: > hi Tom, > > I have volume planes and precomputed subsamplings going, and the 'update > display without pressing Show' no longer works (keep toggling on and > off, but it doesn't have an effect) > > is there a way for me to 'refresh' the state of buttons like that? > > -Jeff

1 0

Re: [Chimera-users] Representation of volume data in memory
by Thomas Goddard 30 Jan '07

30 Jan '07

Hi Jeff, I suspect 2-byte integers are not faster to access or compute with then 4-byte floats on modern CPUs. But more of the map will fit into the CPUs cache which could improve bandwidth and could make computing a contour surface faster. But I don't think that will be significant. You would need to test it to know. Chimera keeps the native data type of the map to conserve memory when reading large maps. Tom Jeff wrote: > does this mean that a 2-byte integer format of a file will display > faster / render triangles faster than the equivalent sized 4-byte float > map? > > Thomas Goddard wrote: >> Hi Jeff, >> >> Chimera keeps volume data in memory using the same numeric value >> types that are present in the file, for example, 32-bit float, 16-bit >> integer, 8-bit integer. >> >> Volume data is copied only when necessary -- for instance, using the >> Gaussian Filter tool creates a floating point copy of the data since >> Gaussian convolution of integer data produces a floating point result. >> >> Tom >> >> >> Jeff wrote: >>> does chimera store all values as float internally (even if the >>> original map is in 2 byte integers), making the mode of the MRC file >>> irrelevant to chimera's performance? >>> >>> -jeff >>

1 0

Re: [Chimera-users] zone tool and volume rendering
by Thomas Goddard 30 Jan '07

30 Jan '07

Hi Jeff, The Chimera handling of the MRC file origin position is done in Python code chimera/share/VolumeData/mrc/mrc_format.py In summary, if it is an MRC2000 file (ie has xorigin, yorigin, and zorigin header values) then (xorigin, yorigin, zorigin) is used as the xyz coordinates of the volume index (0,0,0) unless xorigin, yorigin and zorigin are all zero in which case the xyz position of the map index (0,0,0) is calculated using integer (ncstart, nrstart, nsstart) header values times the grid spacing (defined by (xlen/mx,ylen/my,zlen/mz)). It is never the case that both (ncstart,nrstart,nsstart) and (xorigin,yorigin,zorigin) are used in positioning the map. Tom Jeff wrote: > > I often use another tool to cut out subregions, that I then load into > chimera - until you told me recently, I did not know I could pre-load > subsampled maps, or be able to keep a 'subsampled overview' present > while selecting various regions > > when using other tools to cut out these smaller areas (either IMOD or > Priism), some tools record displacements, and some don't. the Priism > 'CopyRegion' tool appears to do this by adjusting the 'start pixel' > field in the MRC header. IMOD doesn't do this. the 'copyRegion' tool > also doesn't appear to transfer well to chimera, at least in my test > case the original and subvolume do not register properly. (I don't have > any expectation that it would work properly, but I would adapt if I knew > what chimera expects.) > > I am also not sure what entries chimera uses to keep track of > displacements when it cuts out volumes (I could do that experiment right > now), whether it uses 'start pixel' or 'origin', if 'origin' is recorded > in Angstroms or pixels, etc. Also, I don't know what chimera considers > the origin of a density map - if 'start pixel' is 10,10,10, the map is > 20x20x20 pixels in dim, and the origin is (0,0,0), is the origin at the > center of the map, or at the 0,0,0 pixel coordinate of the map? I have > been assuming that 'origin' has to refer to the map's origin location in > space, but this requires defining where the origin is in the volume map > (I think). if there is a 'start pixel' entry, does this effectively > shift the origin? As an example, if the pixel res is 10 A, will the map > example above now display starting at (10 A, 10 A, 10 A)? Or, is one > (or both) of these entries ignored? Finally, if there is already an > entry in one of these fields, does chimera respect that and just > increment, or does it clobber it with the relative displacement > calculated when excising a subvolume? (this slew of questions is > probably covered by a single answer, but I thought it would be good to > elaborate) > > If I knew, I could more appropriately jump between programs. As I am > writing this, I just got an email from David at Boulder telling me that > IMOD uses the origin entries in the header (but don't know yet what it > considers to be the origin, 'far left' corner or center or something else). > > -Jeff

1 0

Precomputing subsampled map sizes
by Thomas Goddard 30 Jan '07

30 Jan '07

Hi Jeff, Yes, Chimera will complain and not allow precomputed volume subsamples if the size of the subsample grid is not what is expected. In the case you give (1434,1434,110) with subsample grid of size (358,358,26) the subsample grid size is not acceptable. Notice that 4 times the subsample size is (1432, 1432, 104) So a half size bins in the first two dimensions are left off (1434 - 1432 = 2) -- that is fine. But the third dimension is missing 1.5 bins (110 - 104 = 6). The subsample file should have size 27 in the third dimension, ie (358,358,27). I don't know why squeezevol from IMOD dropped off more than a whole bin in the third dimension. Chimera allows fractional bins to be dropped off, but does not allow whole bins to be missing. Tom Jeff wrote: > hi again, > > is there a problem with the precomputed subsamplings needing even > dimensions (I pre-cut my volume to even dimensions so that a binning of > 2 would result in a whole number for the subsampled dimensions, but it > can be hard to do this for a factor of 8 in advance). > > chimera is complaining to me about bad dimensions ('Data foo.mrc of size > (358,358,26) not a valid size for dubsamples of foo.mrc of size > (1434,1434,110). > > is there a program you use to bin / get around this problem? I use > 'squeezevol' from IMOD, I am not sure if it is completely transparent in > its output for what chimera would expect > > -j

1 0

Representation of volume data in memory
by Thomas Goddard 30 Jan '07

30 Jan '07

Hi Jeff, Chimera keeps volume data in memory using the same numeric value types that are present in the file, for example, 32-bit float, 16-bit integer, 8-bit integer. Volume data is copied only when necessary -- for instance, using the Gaussian Filter tool creates a floating point copy of the data since Gaussian convolution of integer data produces a floating point result. Tom Jeff wrote: > does chimera store all values as float internally (even if the original > map is in 2 byte integers), making the mode of the MRC file irrelevant > to chimera's performance? > > -jeff

1 0

Re: [Chimera-users] zone tool and volume rendering
by Thomas Goddard 30 Jan '07

30 Jan '07

Hi Jeff, I'll tell you my experience looking at a tomogram (2048 x 2048 x 76) of an immune synapse for a demonstration I gave last month at a cell tomography workshop. The file (mrc) is too large to conveninently display at full resolution. So I made binned versions 2x and 4x smaller along each axis (file size 8x or 64x smaller). Then I used the precomputed subsamples feature I described before. For some added convenience I then saved the map to a NetCDF file using Chimera because this saves the full matrix and binned versions in a single file (new in Chimera 1.2318). I use the volume dialog data display options to "Adjust step size to show at most 1 Mvoxels", or however many million voxels my computer can handle without getting too slow. Then I use the full view of the data to find regions I'm interested in, then use the subregion selection feature and Crop button to look at a smaller piece and the step size automatically is reduced. If I choose a small region I get full resolution. When doing this you have to keep in mind that once you manually change the step size at the top of the volume dialog it turns off the automatic step size adjustment. So I try to avoid that. Of course I also use the volume planes tool. I think you know all this and probably are using Chimera to the best of its current capabilities. You want to push it to use better compression (like resampling to have better aligned boxes) so you can see more data at full resolution. We don't have that yet. It is not hard to envision much fancier compression implementations that improve performance. Chandra Bajaj at U. Texas is very interested in this and may have software you can use. You might want to try his VolumeRover program. The Chimera EM capabilities were developed for single particle reconstructions. We have done little in Chimera to support work with EM tomograms which are very different in size and content (non-axis aligned structures, membranes, ...). We plan to develop tomogram capabilities and my volume planes tool created last month is a tiny step. But it will take years to implement the obvious stuff we can think of now. Your comments are helpful in guiding the priorities. I don't understand why you are "jotting down displacements" when saving subregions. Chimera puts that info into the MRC header. So why do you need to write it down? Tom Jeff wrote: > thanks Tom, > > with regards to the rotation/resampling, I was thinking mainly in > terms of visualizing large #'s of filaments and membrane, which in > themselves only constitute a small fraction of the actual volume they > traverse. even if re-sampling were done by cubic interpolation onto a > the same dimensioned grid, in some cases the loss in resolution would > be acceptable (definitely would be acceptable for some of my current > needs). i have problems with visualizing my whole maps unbinned but > was thinking that the savings such an approach would represent could > allow me to do that. for instance, this is already a problem for me > with trying to volume render a slab of membrane, which I think might > contain interesting features but I can't get the whole thing to go > unbinned; if it were rotated into the minimal enclosing volume, > interpolation artifacts or otherwise, my feeling was that I might > overcome that (there are also a bunch of filaments attached to the > membrane, and running underneath the membrane, so it is a real > difficulty for me to go back and forth between cutting out subvolumes > and binning them to be manageable, segment out filaments, or membrane, > etc, then try to put all the segmented items back into the same volume > and have a look-see). > > the volume planes tool has proven very helpful in segmenting out the > membranes, though. to get at the filaments that are attached to the > membrane, I was zoning out a region around the membrane (placed a > bunch of markers on the membrane using volume planes tool) about 400 A > in radius, but this proved difficult to render in the entire tomogram > b/c the zoned membrane still encompassed most of the original volume, > etc. so I was back to having to cut regions out of that segmented > membrane map to look further. (thus necessitating me jotting down the > displacements of each subregion, etc.) > > -jeff

1 0

Re: [Chimera-users] using a marker file to zone a volume from python prompt
by Thomas Goddard 29 Jan '07

29 Jan '07

Hi Jeff, I forgot to mention that to run the volumezone.py script without display the Chimera user interface you would invoke it from a shell: % chimera --nogui volumezone.py The --nogui flag tells Chimera not to start any graphical user interface. Tom

1 0

Re: [Chimera-users] zone tool and volume rendering
by Thomas Goddard 29 Jan '07

29 Jan '07

Hi Jeff, You are right that masking a filament that runs along the long diagonal of a box does not reduce the disk space or memory use any. (If you compressed the file then it would make a big difference. But you need to uncompress it to use it so that is of limited value.) So to achieve a space savings you need to resample the volume using a grid aligned with the axes of the filament. The resampling will degrade the data resolution some and it might be reasonable to do it on a grid with half the spacing (making the file 8x bigger). With such a resampled map the rotation and shift could be stored so that it can be placed in the original location in the full map. We don't support that now but when we add resampling we will store those rotation parameters in the map file header (maybe in the "labels" field for an MRC file). The time for Chimera to display a map depends on how large the volume grid is because it scans the entire grid in one pass when using the marching cubes algorithm to compute a contour surface. It also depends on how many triangles make up the contour surface. By eliminating the 99% of a masked file that is zeros using a new orientation and resampling it could compute contour surfaces faster. And the solid (volumetric) rendering should be faster directly proportional to the file size. That may be the more important case for your EM tomograms. I plan on supporting resampling on a rotated grid. But I think in many real uses it will not save much space because you will want to resample with finer grid spacing. But it could be convenient for exporting to analysis or visualization software that is limited to xy-planes. Tom Jeff wrote: > got it, > > what you say makes sense, I can definitely workaround, especially given > that the zone tool does a mask upon saving. > > I have been thinking about the problem I have with filaments (or > surfaces) spanning non-orthogonal regions of a volume, which means that > zoning out a long filament (or surface) that might take a much smaller > amount of space/memory once zoned actually takes up almost the same > amount currently, if I am thinking right. > > as an example, say you have a volume that is 100x100x100. inside the > volume, you have a filament, that takes up 10x10x244 voxels (effectively > spanning from one corner to the mirror/opposite corner of the volume). > in theory, zoning out that filament could take up ~1/40th the space, if > rotated to line up with one of the cartesian axes. I don't know how much > logic it would take to do this; I also don't know how chimera reads > origin information from an MRC file, or how much work it would take to > enable it to read (and use) an euler convention from an MRC file, for > displaying later. This would enable cutting a whole bunch of filaments > out of a volume, and then displaying them all concurrently without > running into the problem of loading in large rectangular prisms of space > that are mainly zeros (if this is currently happening, I don't know). I > guess at that point it makes sense to consider the geometric center of > such a rotated object at its origin, to reduce re-displaying the > object/filament properly in the original orientation to just storing a > shift and the rotation angles (6 parameters). > > the same holds true for membranes - right now, I have an entire membrane > that I segmented with markers, but it essentially runs along a hypotenuse. > > one question that probably negates the above paragraph would be 'does > the masked volume (with mostly zeros) display any faster / take less > resources than an equivalent volume without the zeros'? I have been > assuming this is not the case, that the zoned/masked volume still > entails reading in / accounting for that full rectangular prism, despite > the fact that it is mostly empty / full of zeros. > > thanks for you help, > > -Jeff

1 0

Re: [Chimera-users] using a marker file to zone a volume from python prompt
by Thomas Goddard 29 Jan '07

29 Jan '07

Hi Jeff, I've attached a script that opens a density map and a Chimera marker file and writes a new volume corresponding to a zone around the markers. It does not require showing the Chimera user interface to do this. Perhaps you don't need this now (I just got your follow-up email.) but perhaps you will find it useful in writing other scripts. Karin Gross at Max Planck Institute of Biochemistry has written a Chimera extension to slice tomograms at arbitrary angles. I saw it when I visited Munich in December. They also were planning on allowing marker placement on those planes. The volume planes tool could be made to average neighboring planes. Currently it simply displays a NxMx1 subvolume in solid rendering mode. Since there is no existing code in Chimera to support averaging adjacent planes that would have to be added. Probably the easiest solution is to add the adjacent planes in Python and create a new single plane volume on the fly. Tom Jeff wrote: > thanks Tom, > > I will try that. alongside that, is there a way for me to run a 'zone' > function and save a subregion from a python command line (no chimera > launched, just import a library?)? > > I have used the volume planes tool to generate a marker set of a > membrane, it was handy. But, it only handles orthogonal directions, it > can't provide an arbitrary interpolant (which is a large reason I rely > heavily on IMOD's slicer tool); this functionality would be very useful. > A second addition to the volume planes tool would simply be allowing > averaging several slices together (reduces noise) in the direction > normal to the planes, which may already be there (the documentation > online said something about this feature, but it wasn't clear to me) > > it the volume planes tool were able to handle an arbitrary > view/interpolant, then I wouldn't have to depend on the slicer tool, and > the previous request about rotating markers that was related to that > requirement (different features available in different slicer > orientations in IMOD, necessitating a rotation prior to visualization > with the volume planes tool in chimera, thus requiring old marker set > from original volume to be rotated to be used in new volume, etc) would > effectively be voided > > > -Jeff # ---------------------------------------------------------------------------- # Save a volume zone around a given set of markers as a new volume file. # def save_zone(volume_path, markers_path, radius, volume_out_path): # Read zone points atoms, bonds = marker_set_atoms_and_bonds(markers_path) from chimera import Xform xform = Xform() # Identity transform for marker points from SurfaceZone import path_points points = path_points(atoms, bonds, xform) from VolumeData import open_file_type vol = open_file_type(volume_path, 'mrc') # Get containing volume subregion ijk_min, ijk_max = containing_subregion(vol, points, radius) from VolumeData import Grid_Subregion subvol = Grid_Subregion(vol, ijk_min, ijk_max) # Make new volume with zeros outside radius from VolumeViewer import zone_masked_grid_data masked_vol = zone_masked_grid_data(subvol, points, radius) # Write new volume from VolumeData.mrc import write_mrc2000_grid_data write_mrc2000_grid_data(masked_vol, volume_out_path) # ---------------------------------------------------------------------------- # def marker_set_atoms_and_bonds(markers_path): from VolumePath.markerset import load_marker_set_xml msets = load_marker_set_xml(markers_path) atoms = [] bonds = [] for mset in msets: atoms.extend(map(lambda m: m.atom, mset.markers())) bonds.extend(map(lambda l: l.bond, mset.links())) return atoms, bonds # ---------------------------------------------------------------------------- # def containing_subregion(vol, points, radius): from VolumeViewer import points_ijk_bounds, clamp_region ijk_min, ijk_max = points_ijk_bounds(points, radius, vol) ijk_min, ijk_max = clamp_region((ijk_min, ijk_max, None), vol.size)[:2] from math import floor, ceil ijk_min = map(lambda x: int(floor(x)), ijk_min) ijk_max = map(lambda x: int(ceil(x)), ijk_max) return ijk_min, ijk_max # ---------------------------------------------------------------------------- # volume_path = '/usr/local/src/chimera-demos/volume/examples/tricorn_map.mrc' markers_path = '/usr/local/src/staff/goddard/chimera/devel/ZoneScript/test.cmm' radius = 5 volume_out_path = '/usr/local/src/staff/goddard/chimera/devel/ZoneScript/test.mrc' save_zone(volume_path, markers_path, radius, volume_out_path)

1 0

access to pdb parser
by Jean Didier Pie Marechal 29 Jan '07

29 Jan '07

2 1

Re: [Chimera-users] zone tool and volume rendering
by Thomas Goddard 29 Jan '07

29 Jan '07

Hi Jeff, The volume dialog "zone" feature does not work with solid (volumetric) rendering. The current implementation just hides surface triangles having vertices outside the given range so it only works on surfaces. When you use volume dialog File / Save map as... it makes a copy of the data with grid values set to zero outside the radius. Creating a copy of the map in memory or masking the map for use with solid rendering are not currently supported. We wish to add this in the future and it should not be hard to achieve although performance when changing the radius will be significantly worse than with the current surface zoning. The documentation does not mention this limitation and I will update the volume dialog description to describe it. Tom Jeff wrote: > hi Tom, > > is there a way to get the zone tool to operate when doing a solid/volume > rendering - in surface mode, if you set a zone radius, let's say 40 A, > you'll get a region that extends 40 A around the selected marker(s); > however, in 'solid' mode, it appears I get the entire orthogonal region > in the volume that encloses the markers plus that radius. thiis is > problematic if the markers span the hypotenuse of the volume; in that > case, zone with volume/'solid' appears to more or less display the > entire volume rather than just the surrounding region as in 'surface mode' > > do I have a buggy version? this is a recent release, but I've had this > happen with previous releases > > -jeff

1 0

Re: [Chimera-users] chimera startup problem
by Greg Couch 29 Jan '07

29 Jan '07

Just a FYI to the list, the problem here was an ancient OpenGL graphics driver. Upgrading it made the problem disappear. I'll be adding an entry to our Graphics Driver bugs web page, <http://www.cgl.ucsf.edu/chimera/graphicsbugs.html> with a few more details. - Greg ---------- Forwarded message ---------- Date: Tue, 23 Jan 2007 12:25:41 -0500 From: Chen Xu <xuchen66(a)gmail.com> To: chimera-users(a)cgl.ucsf.edu Subject: [Chimera-users] chimera startup problem Dear List, after upgrading to 1.2304 (1.2303 freeze the computer after several minute loaded with a volume pdb file) , I have problem to start it up on (RedHat): agnieszka@raptor ~]$ chimera Error starting chimera: ValueError: attempt to create string with null pointer (see reply log for Python traceback info) Traceback (most recent call last): File "/sware/chimera/chimera-1.2304/share/__main__.py", line 59, in ? value = chimeraInit.init(sys.argv) File "CHIMERA/share/chimeraInit.py", line 255, in init tkgui.initializeGUI(exitonquit) File "CHIMERA/share/chimera/tkgui.py", line 2407, in initializeGUI File "CHIMERA/share/chimera/tkgui.py", line 2368, in createApp File "CHIMERA/share/chimera/tkgui.py", line 1784, in __init__ File "CHIMERA/share/chimera/tkgui.py", line 1811, in makeGraphicsWindow ValueError: attempt to create string with null pointer any help?

1 0

Slow rendering in FC6
by Thomas Goddard 29 Jan '07

29 Jan '07

On Yifan's linux system a large molecule takes a second to redraw and gradually renders from one side to the other. Turned out he did not have the NVIDIA graphics driver installed, so MESA software rendering was being used. Determined this using linux "glxinfo" command. Solution was to install graphics driver. -------- Original Message -------- Subject: problem of running Chimera in FC6 Date: Sun, 28 Jan 2007 13:05:20 -0800 From: Yifan Cheng To: goddard(a)cgl.ucsf.edu Hi Tom, I have a question about running Chimera in Linux FC6 system and wondering if you could help me out? I have Linux boxes running FC6, with a Gigabyte GV-NX76G256D-RH Geforce 7600GS 256MB video card. But somehow the Chimera keep refreshing with any movement in the model or map I loaded into it. It runs this way in both thousands color mode as well as in millions color mode. This video card is not Quadro type and has no stereo function, but I thought this shouldn't matter. Do you have any idea what might be the problem? Thanks a lot for your help. best, Yifan

1 0

Re: [Chimera-users] align different scale models
by Thomas Goddard 29 Jan '07

29 Jan '07

Hi Pu, The PDB file uses units of Angstroms. To specify the spacing between grid planes of your EM map, open it in Chimera, then use menu entry Features / Origin and Scale from the volume dialog. The "voxel size" values listed indicate the size of one grid cell in the density map which is equivalent to the grid spacing. You can change the values and press Return (or Enter) key and the map will be shown at the new scale. Enter the values in Angstroms. (Chimera does not know what units you are using but all data sets must use the same units if you want them to be displayed at the correct relative scales.) The map file is not modified. To save the new scale you either can save a Chimera session (File / Save session as... on the main Chimera window) or save a new copy of the map (File / Save map as... on the volume dialog). Tom P Qian wrote: > Hi Tom, > > I have question to ask you about alignment of PDB model and EM density map. > > When I open both EM density map and its corresponding PDB model, I found they > have different size. I think that is due to different scale they are using. My > question is: Is it possible for me to re-scale them individually so that they > can match each other. I cannot do it at the momemt because zoom function will > affect all data loaded, not only active data but also unactive one. I'm trying > to produce a EM density map which has same scale with PDB model to solve it, > but if Chimera could do it as well, it will be helpful. Thanks > > Best regards > > P. Qian > > Dr. Pu Qian > Physics Department > The University of Sheffield > Hicks Building > Hounsfield Road, S3 7RH > UK >

1 0