- Chimera-users - RBVI Mailing Lists

64-bit Linux chimera snapshot available
by Greg Couch 28 Feb '07

28 Feb '07

If you are running a 64-bit version of Linux with an AMD64, Opteron, or Intel Xeon processors, then please try out our new snapshot at <http://www.cgl.ucsf.edu/chimera/download.html>. This platform is now supported and will have future snapshot and production releases. Greg Couch UCSF Computer Graphics Lab

1 0

Re: [Chimera-users] Saving model positions
by Tom Goddard 27 Feb '07

27 Feb '07

Hi Christopher, If you have 10 models open in a Chimera session and you close model number 7, the session should still save correctly. If it doesn't please report it as a bug. Unfortunately restoring the session file uses different model numbers for the density maps (the lowest available numbers). That is a bug that I need to fix. It should use all of the original model numbers even if there are gaps. Even though the model numbers will change, the orientations of all the models 1-6 and 8-10 will all be correct in the restored session. I sent your earlier email to our Chimera users mailing list. That is why your reply to me went to that mailing list. I like to post the questions to the mailing list so others can benefit from the answer and I remove any confidential information (email, phone, signature line, research details). Let me know if you want to keep your questions off of the Chimera mailing list. Here's the message where I posted your original question and my reply. http://www.cgl.ucsf.edu/pipermail/chimera-users/2007-February/001366.html Tom Christopher Akey wrote: > > Thomas - > > This went via reply to some kinda list, sorry. > > I will try some of these approaches. However, there is a question. If > you have 10 objects in a session, and decide to delete number 7, then > sometimes you cannot get the session to save properly with a missing > number. > > In theory, if one could get the session to save, then a matrix for the > first 6 objects would still work? > > > cheers C Akey

1 0

New chimera development snapshot available
by Greg Couch 27 Feb '07

27 Feb '07

See <http://www.cgl.ucsf.edu/chimera/docs/relnotes/snapshot.html> for details (this will be accurate for the next few days, after that read the release notes that are bundled into the chimera snapshot). The snapshot uses NumPy instead of Numeric python, so some third-party extensions may break (eg., parts of EMAN). Other highlights include intial support for PDB 3.0 (remediated PDB) format and built-in POV-Ray raytraced image support. Enjoy, Greg Couch UCSF Computer Graphics Lab

1 0

Saving model positions
by Thomas Goddard 26 Feb '07

26 Feb '07

Hi Christopher, The problem you have with the Chimera matrixget and matrixset commands is that the matrix file lists the model number (0.0, 1.0, 2.0, ...) with each matrix. For example, Model 0.0 -0.0635922 -0.740419 0.66913 247.807 -0.979146 -0.0833402 -0.185275 540.192 0.192946 -0.666958 -0.719679 472.752 Model 1.0 0.233245 -0.923975 -0.303095 418.621 0.970522 0.201738 0.131868 -125.304 -0.0606967 -0.324918 0.943792 100.98 When you open maps and PDB files in a different order they get different numbers. Chimera assigns the lowest available number (starting at 0) each time you open a data set. Then when you use matrixset <filename> to get your standard orientation it applies the matrices to the wrong models because of the different numbering. The easiest remedy for this is to open your data sets in a fixed order (first large ribosomal map (#0), then small ribosomal map (#1), ...). This can be inconvenient. If you save a single positioning matrix in a file there is no current command to say to apply that matrix to a model that you specify as a command argument (e.g. no command like "matrixset <matrix-file> <model-number>" exists). There are some other approaches to the problem of getting standard orientations. One method is to save your ribosome large and small subunit map positions in a Chimera session. Then if you want to use different maps, open the reference session, then open the new maps and use the "matrixcopy" command http://www.cgl.ucsf.edu/chimera/docs/UsersGuide/midas/matrixcopy.html to position the new maps to match the reference map positions. Instead of using matrixcopy you could use the equivalent Model Panel dialog "Transform As" button to apply the positioning matrix of one map to a second map. Another command that may be helpful is "savepos <name>". http://www.cgl.ucsf.edu/chimera/docs/UsersGuide/midas/savepos.html It remembers the positions of all currently opened data sets and gives a name to that set of positions. You can later restore those positions with the command "reset <name>". These named positions are saved in Chimera session files. The trouble is that there is not an immediate way to apply those positioning matrices to different maps or PDB models. But that could be achieved with the matrixcopy command or Model Panel / Transform As button. If this set of capabilities does not let you easily do what you want could you describe an exact scenario (how many maps, how many models, how are they related) and if possible propose a new command that would help you. I think it would be great if density map file formats supported saving multiple named positioning matrices in their header. For example, you might want to save how a piece of a map is positioned in the full source map, and also how a piece of a map fits into different map (e.g. at various locations in a tomogram), and your case of just a standard orientation ("front view", "top view"). I do not believe any of the commonly used density map formats allow this although it may be possible to put that info into header comment fields in some map files. Tom Christopher Akey wrote: > Tom - > > ... > > Chimera is very good, but there are still problems. A new workstation > will help and will be here in a few weeks. > > However, one thing is really annoying. It is important to set a > particular view for your structure, for example a side-by-side frontal > view of the ribosome with regards to the small and large subunits. > > Once you have this in one session it would be useful to be able to > recreate this easily in other sessions. (For logistical reasons, it is > ofter easier to keep a session for each Figure so that they don't get to > crowded.) > > Right now, if you save a matrix (matrixget) and then make a change in > the session, ie delete or add a file, you get unpredictable results, but > usually, the matrix no longer works or it only works for one volume in > the session. This is not good when you have separate vols for the small > and large subunits in proper registration, you get a matrix for the > front view, and then at a later time, only one subunit will be realigned > properly! > > It would be great if you could set a matrix for a particular map as a > benchmark, then when you read that map into any other session, you could > recreate this orientation using the matrix. I don't understand why this > won't work. > > The feature of being able to bring in other maps and align them in > CHimera is great and works very well (its in our older test version that > we are using, and its very useful as we often have 3 or more structures > of the same basic object with minor diffs). > > I hope this makes sense. > > cheers C Akey >

1 0

many days after...another question Re: Select atom by serial number.
by Jean Didier Pie Marechal 26 Feb '07

26 Feb '07

Hi everybody, I'd like to select a series of atoms by their serial number (again!!!) (e.g. from atom number 1 to atom number 10). the sel @/serialNumber=1-10 doesn't seem to be the right syntax. Is it possible to do this kind of selection? If yes, what is the right syntax please. 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.935814936 e-mail: JeanDidier.Marechal(a)uab.es ----- Missatge original ----- De: Elaine Meng <meng(a)cgl.ucsf.edu> Data: Dijous, Gener 11, 2007 8:59 pm Assumpte: Re: [Chimera-users] Select atom by serial number. > > Hi JD, > We also tested Chimera 1.2309 on Windows, and these specifications > > work correctly. Example: > Command: sel @/serialNumber=232 > will select NZ of Lys 27 in chain A of the PDB entry 1zik. The > only > other thing I can think of (besides what was in the previous > message) > is to check if your PDB file is correctly formatted. The > ATOM/HETATM > serial number is supposed to be in columns 7-11 and right-justified. > Best, > Elaine > > On Jan 11, 2007, at 11:39 AM, Elaine Meng wrote: > > > Hi JD, > > You are using the correct specifications - both of your examples > > > should work. I tested both approaches in Chimera 1.2304 on Mac > OSX > > and they worked correctly. We'll have to look into your > specific > > version/platform and get back to you. If you want, you could > send > > me the PDB file you are using so I could test if there is some > > issue specific to that structure. To be clear: the serial > number > > is the number shown in the column after ATOM (or HETATM) in the > PDB > > file, regardless of what order the atoms are really in. That > is, > > if the first ATOM has 2 in that column, its serial number is 2 > and > > not 1. > > Best, > > Elaine > > ----- > > Elaine C. Meng, Ph.D. meng(a)cgl.ucsf.edu > > UCSF Computer Graphics Lab and Babbitt Lab > > Department of Pharmaceutical Chemistry > > University of California, San Francisco > > http://www.cgl.ucsf.edu/home/meng/index.html > > > > > > > > > > On Jan 11, 2007, at 10:47 AM, Jean-Didier Maréchal wrote: > > > >> Hi Everyone, > >> > >> > >> > >> > >> > >> I am desperately trying to select an atom of my pdb by its > serial > >> number. > >> > >> Looking at the archives, it seems that I should put something > like > >> @/serialNumber=525 > >> > >> I tried “sel #0@/serialNumber=525” in the commandl ine and “@/ > >> serialNumber=525” in the Atom Specifier. None of these > selections > >> worked. Can someone tell me the right way to do this, please ? > >> > >> > >> > >> Cheers > >> > >> JD > >> > >> > >> > >> Current running chimera: version 1 build 2309 > >> > >> OS: windows > >> > >> > >> > >> _______________________________________________ > >> Chimera-users mailing list > >> Chimera-users(a)cgl.ucsf.edu > >> http://www.cgl.ucsf.edu/mailman/listinfo/chimera-users > > > >

2 1

Combining 2 electron density maps in 1
by Mazdak Radjainia 23 Feb '07

23 Feb '07

Hi, I would like to open two electron density maps in chimera and save/merge them together in one map. Both maps are activated in the "model panel" but I cannot select/save both at a time using the volume viewer. I appreciate your help! Kind regards Mazdak

3 2

Chimera on 64-bit Windows
by Tom Goddard 21 Feb '07

21 Feb '07

Hi Christopher, I believe the 32-bit Windows Chimera distribution will run on 64-bit versions of Windows, such as Windows XP Pro x64 Edition. But I do not have a machine to try it on. It will certainly run on 32-bit Windows running on a 64-bit processor -- I've tried that with an AMD64 processor. Tom Christopher Akey wrote: > Steve and Tom- > > Will EMAN and Chimera run ok on a 64 bit machine running windows XP, > initially we plan to use it this way, then change over to Linux when > we have time. Or do we just install Linux right away? > > cheers C Akey

1 0

Memory requirements for Chimera
by Tom Goddard 21 Feb '07

21 Feb '07

Hi Christopher, I think it starts making sense to use a 64-bit machine if you are loading data that requires >= 1 Gbyte. In general, 32-bit linux binaries will run on a 64-bit machine. Currently we only provide a 32-bit linux Chimera distribution though we plan on adding 64-bit Linux as a standard Chimera platform in the next 6 months. The 32-bit Chimera runs fine on 64-bit linux. The advantage of a 64-bit version is that it uses memory pointers that are 64 bits so they can address more than 4 Gbytes. On a 32-bit system the operating system and the many libraries that Chimera uses (~50) may occupy a significant portion of the 4 Gbyte address space. Even if you have less than 4 Gbytes of physical memory the operating system can and does use the full 32-bit 4 Gbyte address space and swap data to disk when there is not enough physical memory. But if a program asks for a 512 Mbyte block of memory and there is no available segment of that size in the address space then it will fail. Graphics drivers use the computer's main memory for data that will not fit on the card. Either 256 or 512 Mbytes on the graphics card should give good performance even for large systems. Unless you are using the volume "solid" rendering mode the rendering speed will slow to much less than 1 frame per second before you use up 256 Mbytes. For reference, the machines I currently use for developing Chimera and looking at large volume data sets are: 1) Mac dual G5 desktop with 1.5 Gbyte memory and 128 Mb ATI Radeon 9800 Pro graphics, and 2) MacBook Pro, Intel Core 2 duo, 2 Gbyte memory, 256 Mb ATI X1600 graphics. Thanks for the apoptosome papers -- interesting work. Tom Christopher Akey wrote: > Tom- > ok, I will keep notes on what is not working and send them to you, as > we go through making figures this week. > > Will chimera run fine on a 64 bit Linux box? The other option is 32 > bits, but if I buy a high end workstation it should probably be 64 bit > yes? > > Also, about making Chimera able to handle big sessions: is the rate > limiting factor the RAM or the memory on the Graphics Card. We have a > 512 Mb cache on our current graphics card and still have problems, so > I presume we are RAM limited. > > When buying a new machine, should I invest in a 512 Mb Nvidia card or > is 256 fine, as long as there is enough RAM? > > By the way, I am attaching two pdfs of papers published using Chimera > graphics. > > thanks. > > CWA > > > Tom Goddard wrote: >> Hi Christopher, >> >> I'm not sure what causes crashes in Chimera when you are working >> close to the available memory limit. If a memory allocation fails in >> C++ it should produce an error message in Chimera indicating that >> memory could not be allocated because we catch those exceptions. >> Memory allocations in C (not C++) libraries that Chimera uses are >> likely to cause a crash though. >> >> It would help us to know what Chimera is doing when the crashes >> occur. We may be able to put some safety checks in our C++ where C >> library allocations are known to fail. Do I understand correctly >> that crashes happen while you are saving an image (individual tiles >> being displayed on screen)? Chimera by default makes an image 3 >> times larger then requested to make a smoother image. That can take >> a good bit of memory. Are there other actions that cause crashes? >> >> Tom > >

1 0

An NMR Average Structure
by S W Simon Sham 21 Feb '07

21 Feb '07

Hi, I need to calculate an average structure from an emsembled structures in Chimera. Can we do it it Chimera? If yes, how? Thanks for any helps. Simon ------------------------------------------------------------------------ ----- Simon Sham, Ph.D. NMR Core Facility Comprehensive Cancer Center Univerisity of Alabama 933 South 19th Street CH19 B31 Birmingham, AL 35294 Office: (205) 934-5696 Fax : (205) 934-6475 Email : ssham44(a)uab.edu

2 1

Create surface from markers
by Tom Goddard 20 Feb '07

20 Feb '07

Hi Jeff, Chimera cannot currently create a surface from markers placed with the volume path tracer tool. It would not be so hard to write some Python code to do this. Here is an example of Python code that creates a surface in Chimera: http://www.cgl.ucsf.edu/chimera/docs/ProgrammersGuide/Reference/surface.html Tom Jeff wrote: > hi Tom, > > is there a way to use a marker file just to render a surface (a > series/group of dots, just needing to be connected by a mesh)? for > instance, to represent a membrane. > > -Jeff

1 0