December 2015 - Chimera-users - RBVI Mailing Lists

Re: [Chimera-users] multi GPU rendering
by Tom Goddard 18 Dec '15

18 Dec '15

Hi Ben, One more bit of useful info regarding rendering large maps with solid style. The “perpendicular to view” projection mode is not the same as the mode “x, y, or z planes”. The perpendicular mode uses an OpenGL graphics 3d texture and slices the map perpendicular to the viewing direction and uses trilinear interpolation on the graphics card. The x,y,z planes mode uses OpenGL 2d textures perpendicular to one of the x, y, or z axes. While the perpendicular mode seems better the trouble is that 3d textures are generally not used in video games, so this is a very obscure graphics feature that may not be well optimized in the graphics driver, it may be slow (e.g. be done with no hardware acceleration), it may have limits to the size of the volume. On the other hand 2d textures are used in every video game and are optimized to the hilt — they are what is used to put color patterns on any surface. With some graphics cards and drivers the 3d textures will work as well as 2d textures, particularly the high-end cards, but you will only find this out by trial and error. The default “auto” projection mode never uses perpendicular to view because it is a bad choice on many low-end graphics cards. Tom > On Dec 18, 2015, at 1:38 AM, Benoît Zuber <benoit.zuber(a)ana.unibe.ch> wrote: > > Hi Tom > > Thanks for the additional info. I didn't know about the projection mode option. I was wondering before why under some conditions z planes were super thin when viewed perpendicular to z axis and why sometimes the gaps were filled. This was a bit problematic for some data sets where we actually mainly look in this orientation. Now using projection mode "perpendicular to view" instead of auto forces the planes to be rendered thick. great. > > watching nvidia-smi outputs confirms that only one GPU is used for rendering. Watching is also very useful to know how much the volume must be cropped before switching to the next step size without saturating the GPU memory. > Now I got it, if we want to watch bigger volumes, we just need to get a top geforce with 12 Gb instead of 3 Gb (Santa if you can hear me) > > Cheers > Ben > On 18.12.2015 01:02, Tom Goddard wrote: >> Hi Ben, >> >> From what I read both Nvidia SLI and AMD CrossFire for using multiple graphics cards both require hardware jumpers between the cards. >> >> The Chimera solid benchmark makes a cube shaped volume and times rendering it. A 1024 cubed volume takes 2 Gbytes on the graphics card because each grid point takes two bytes, one for the gray level and one for the transparency. An important thing to know about the solid rendering with really big volumes is that by default when you rotate it will make up to 3 full copies of the data — so up to 6 Gbytes in the benchmark example. It makes a copy when you rotate to viewing a different face of the cube. It then treats it as slices parallel to that face. So for a cube shaped map you will see a freeze when you rotate beyond 45 degrees. For non-cube maps I think the rule is it uses the face of the box that is showing the most area. For big volumes if you don’t care so much about looking at it along x and y directions then you might change projection mode the Features / Solid Rendering Options from “auto” to “z planes”. You probably want to know what auto does — it uses z planes if the volume is a thin slab, but "x, y, or z planes” if it is not a thin slab. Thin means x or y at least 4 times larger than z (I pressed Help on Volume Viewer dialog to learn that bit, even though I wrote the code). Once “projection mode” is “z plane” then you won’t get any of the extra copies. >> >> For really big volumes I could probably the transparency and use one byte per grid point. I could just scale transparency with intensity (which is what volume viewer does anyways). That makes the data of the graphics card half as big so it would be possible to show larger maps. I’ll try that in our next generation ChimeraX software — would be a nice improvement. >> >> Back to using multiple graphics cards — I don’t think the driver can possibly split the volume solid rendering data (2d OpenGL textures) — it will try to put all of it on both graphics cards — so you won’t get more memory by using more cards. >> >> Tom >> >> >>> On Dec 17, 2015, at 2:39 PM, < <mailto:benoit.zuber@ana.unibe.ch>benoit.zuber(a)ana.unibe.ch <mailto:benoit.zuber@ana.unibe.ch>> <benoit.zuber(a)ana.unibe.ch <mailto:benoit.zuber@ana.unibe.ch>> wrote: >>> >>> Hi Tom >>> >>> Thanks for your thorough reply. I am not in front of the workstation but I’ll use the gpu activity monitor to guess if chimera is using the three GPUs. I have some doubts that the OS / openGL driver is distributing rendering work on each gpu in our configuration. I think that for the SLI to work you need to wire both cards together, which is not the case in our workstation. But anyway, I’ll check activity. >>> >>> The rendering case I was referring to consists of solid rendering. I never try to render the full dataset at full resolution as we are talking about datasets of around 50 Gb. I use a very high step to select a sub region, then I gradually decrease step size and fine tune the contrast transfer function. When I am happy I render at step 2 or step 1, depending on the sub region size. Clearly there is time needed to read data from disk; when reading is done the program still computes stuff for a few seconds. Then I can rotate, zoom, …, the volume. If the sub region is not too large then it is super smooth. But if I select a too large sub volume, then I can rotate some degrees, then it freezes for a while, then it is smooth again, etc. So I guess it corresponds to your description of the problem. >>> >>> I took a look at the benchmark. That’s very useful! Obviously I am not going to get better performance with a quadro (at least one in the benchmark: All quadro except K4000 get worse scores for solid rendering than the GTX 780 Ti. K4000 actually got the same score as the 780 Ti. Only with a GTX Titan would I get a nearly 2x improvement, which makes sense since this card has 2x the memory of the 780 Ti (6Gb vs 3Gb). The GTX Titan X is not in the benchmark yet but it should be even better as it has 12 Gb Ram. Possibly the quadro k6000, which is not in the benchmark either, could have similar or better performance as this one (it also has 12 Gb RAM) but … it costs about 4 times more than a Titan X. Sad that only the quadro work for stereo under linux (but for that we bought a once state of the art quadro on eBay for 150$ and installed it on another PC :-) >>> >>> Cheers >>> Ben >>> >>> De : Tom Goddard <goddard(a)sonic.net <mailto:goddard@sonic.net>> >>> Date : jeudi, 17 décembre 2015 19:22 >>> À : Benoit Zuber <benoit.zuber(a)ana.unibe.ch <mailto:benoit.zuber@ana.unibe.ch>> >>> Cc : chimera users list <chimera-users(a)cgl.ucsf.edu <mailto:chimera-users@cgl.ucsf.edu>> >>> Objet : Re: [Chimera-users] multi GPU rendering >>> >>>> Hi Ben, >>>> >>>> I haven’t tried Chimera with 2 or more graphics cards working together. I don’t know if it is likely to improve rendering speed. I don’t think applications need any special support to use multiple cards — the system graphics driver distributes the work across 2 or more cards. With Nvidia cards this technology is called SLI and with AMD cards it is called CrossFire. From what I understand they do thing like have each of 2 cards render every other frame — since the graphics are pipelined the current frame and next frame could be rendered simultaneously possibly doubling the speed. I have my doubts that this will improve Chimera rendering speed for large density maps. I think slow rendering of maps in solid (grayscale) style typically happens in Chimera when the map data doesn’t fit on the graphics card, so every frame it has to transfer all the data to the card — the performance plummets once you get a map that big. If the data does fit on the graphics card, it usually renders at full frame rate (60 frames per second), although that isn’t true of all graphics cards. This all relates to the speed rotating the model. When you first load a big map it can take a long time because disk drive speed is slow — a solid state drive helps speed this up. If you explain exactly the case where you see slow rendering I can perhaps advise. >>>> >>>> In general I think the Geforce cards perform better (fewer bugs, faster speed) than the Quadro cards, and would only recommend Quadro if you use stereoscopic display with shutter glasses. Here are Chimera benchmarks for a range of graphics cards: >>>> >>>> <http://plato.cgl.ucsf.edu/trac/chimera/wiki/benchmarks>http://plato.cgl.ucsf.edu/trac/chimera/wiki/benchmarks <http://plato.cgl.ucsf.edu/trac/chimera/wiki/benchmarks> >>>> >>>> Tom >>>> >>>> >>>> >>>>> On Dec 17, 2015, at 5:28 AM, wrote: >>>>> >>>>> Hi >>>>> >>>>> Can chimera make use of more than one GPU for 3D rendering? We have 3 Geforce GTX 780 Ti (mainly used for number crunching) on a particular workstation and would be interested to make full use of them for rendering tomograms or serial block face imaging data. >>>>> >>>>> Another question: has anyone done benchmark comparison for 3D rendering in Chimera between a top of the line Geforce GTX card and a top Quadro card? Is there a strong improvement with the Quadro, which might justify the price gap? >>>>> >>>>> Thanks >>>>> Ben >>>>> -- >>>>> Prof. Benoît Zuber >>>>> Institute of Anatomy >>>>> University of Bern >>>>> Baltzerstrasse 2 >>>>> Postfach 922 >>>>> 3000 Bern 9 >>>>> Switzerland >>>>> <mailto:benoit.zuber@ana.unibe.ch>benoit.zuber(a)ana.unibe.ch <mailto:benoit.zuber@ana.unibe.ch> >>>>> +41 31 631 84 40 >>>>> <http://www.ana.unibe.ch/research/experimental_morphology/index_eng.html>http://www.ana.unibe.ch/research/experimental_morphology/index_eng.html <http://www.ana.unibe.ch/research/experimental_morphology/index_eng.html>_______________________________________________ >>>>> Chimera-users mailing list >>>>> Chimera-users(a)cgl.ucsf.edu <mailto:Chimera-users@cgl.ucsf.edu> >>>>> http://plato.cgl.ucsf.edu/mailman/listinfo/chimera-users <http://plato.cgl.ucsf.edu/mailman/listinfo/chimera-users> >>>> >> >

1 0

[MGMS-DS]: Molecular Modelling Workshop April 4-6, 2016 in Erlangen, Germany
by Harald Lanig 18 Dec '15

18 Dec '15

Dear list subscribers, I am very happy to announce that the 30th Molecular Modelling Workshop in Erlangen takes place on April, Monday 4th to Wednesday 6th, 2016. Starting on Monday after lunch should allow to avoid travelling on weekend and keeping the expenses at a minimum. This time, the scientific program of the meeting is conducted by Prof. Tim Clark, Technical Director of the Computer-Chemistry-Center in Erlangen, Germany. As usual, the workshop is organised by the German Section of the Molecular Graphics and Modelling Society. ####### Plenary Speakers ####### Over the last few decades computational chemistry, molecular modelling, and chemoinformatics became more and more an integral part of research in various areas of the chemical industry and at universities. A lot of new tools and new approaches together with a huge increase in computer power facilitate this development. We are very pleased to announce Prof. Brian Shoichet University of California, San Francisco, USA and Dr. Marcus A. Neumann Avant-Garde Materials Simulation Deutschland GmbH giving plenary presentations as leading experts their respective fields. ####### Poster and Lecture Awards ####### As in the past years, there will be two poster awards of EUR 100 each and three lecture awards for the best oral presentations: 1st Winner: Travel bursary to attend the Young Modeller's Forum in London, UK, plus a speaker slot option at YMF 2016 (travel expenses are reimbursed up to EUR 500) 2nd Winner: EUR 200 travel expenses reimbursement 3rd Winner: EUR 100 travel expenses reimbursement Only undergraduate and graduate research students qualify for the poster and lecture awards. ####### Registration ####### As every year, an interesting and successful workshop depends on your contributions! Therefore let me invite you to submit talks and/or poster titles via the registration form accessible on the workshop website http://mmws2016.mgms-ds.de/index.php?m=register This website will provide all necessary information about the meeting! The deadline for all submissions is February 26th, 2016. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Please note that the week before the 30th Molecular Modelling Workshop, on Wednesday March 30th to Friday April 1st 2016, a Symposium Commemorating the Life and Work of Paul von Ragué Schleyer will take place at the same venue. If you are interested in this meeting, please follow the link http://schleyersymposium.mgms-ds.de for further information. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ We are looking forward to meeting you in Erlangen soon! -Harald Lanig Chairman of the MGMS-DS e.V. http://www.mgms-ds.de -- ------------------------------------------------------------------------ PD Dr. Harald Lanig Universitaet Erlangen/Nuernberg Zentralinstitut fuer Scientific Computing (ZISC) Geschaeftsfuehrer Martensstrasse 5a, 91058 Erlangen Fon +49 9131-85 20781 harald.lanig(a)fau.de Fax +49 9131-85 20785 http://www.zisc.uni-erlangen.de ------------------------------------------------------------------------

1 0

Fit to segments
by Luca Pellegrini 18 Dec '15

18 Dec '15

Hi, I am using ‘Fit to Segments’ to fit a crystal structure into the appropriate segment of an 18A EM map of a larger protein complex. The structure is one subunit of the complex. After initial manual alignment of the structure, fitting to the selected segment works well and produces what I believe is the correct orientation of the structure in the map. However, the fitting stats (Corr/At. Incl.) for the wrong hits are almost as good (within a few percent points), even though for some of them the structure is clearly misplaced in the segment. Can anyone please comment/advise on this? It looks like fitting and relative statistics are calculated relative to the entire map rather than the selected segment. I am using Chimera 1.10.1, build 40415. Best wishes, Luca Luca Pellegrini Department of Biochemistry University of Cambridge 80 Tennis Court Road Cambridge CB2 1GA UK Email: lp212(a)cam.ac.uk Phone: 0044-1223-760469

1 0

multi GPU rendering
by benoit.zuber＠ana.unibe.ch 17 Dec '15

17 Dec '15

Hi Can chimera make use of more than one GPU for 3D rendering? We have 3 Geforce GTX 780 Ti (mainly used for number crunching) on a particular workstation and would be interested to make full use of them for rendering tomograms or serial block face imaging data. Another question: has anyone done benchmark comparison for 3D rendering in Chimera between a top of the line Geforce GTX card and a top Quadro card? Is there a strong improvement with the Quadro, which might justify the price gap? Thanks Ben -- Prof. Benoît Zuber Institute of Anatomy University of Bern Baltzerstrasse 2 Postfach 922 3000 Bern 9 Switzerland benoit.zuber(a)ana.unibe.ch +41 31 631 84 40 http://www.ana.unibe.ch/research/experimental_morphology/index_eng.html

2 1

dashed distance line
by A G Szabo 16 Dec '15

16 Dec '15

I recently used the distance feature to determine the distance between two alpha carbons in a protein. The view on the image showed a dashed line and the distance in Angstroms. I had managed to change the color of the line and numbers to a dark green, and thicker line. So I then snipped the image and put it in power point. Figure below: As you can see the line and numbers are there. Now look at the Jpeg file that is attached. The dashed line does not show up. No big deal but perhaps there is a setting that I missed when I saved the image. Thank you. Arthur G. Szabo Professor Emeritus Chemistry and Biochemistry Wilfrid Laurier University Waterloo Canada

2 1

solid threshold in a python script
by benoit.zuber＠ana.unibe.ch 14 Dec '15

14 Dec '15

Hello I would like to add several threshold markers for volume solid rendering. I would like to do it in a script. I guess the only way is to do it through a python script. I tried modifying the solid_levels and solid_colors attributes of the active volume but I could not find how I can then get the depending volume attributes, such as transfer_function and the gui (both rendered volume and the volume viewer dialog) to be correctly updated. Could anyone please give me a few pointers? Thanks in advance Ben -- Prof. Benoît Zuber Institute of Anatomy University of Bern Baltzerstrasse 2<x-apple-data-detectors://1> Postfach 922<x-apple-data-detectors://2/0> 3000 Bern<x-apple-data-detectors://2/0> 9 Switzerland benoit.zuber(a)ana.unibe.ch<mailto:benoit.zuber@ana.unibe.ch> +41 31 631 84 40<tel:+41%2031%20631%2084%2040> http://www.ana.unibe.ch/research/experimental_morphology/index_eng.html

2 2

on preset interactive 1 color
by Smith Liu 12 Dec '15

12 Dec '15

Dear All, If by chimera we select preset interactive 1 for a protein complex, each chain will take a different color. As for when we describe the corresponding colors in a paper we need to know the names of each color by the chimera preset interactive 1 function, and the colors by this function are usualy very close to each other, will you please introduce to me the color names colored by the function preset interactive 1? Smith

2 3

Movie Making in Chimera
by Florian Drechsler 10 Dec '15

10 Dec '15

Dear Chimera Support Team, I have a question regarding movie making in Chimera: I would like to be able to record a movie, based on a chimera script, and have exact frame-wise control over what is recorded. Chimera seems to make a funny distinction between "internal trajectory frames" and "movie frames" which I don't get. I would like a one-to-one correspondence between these, no interpolation or anything like that. More precisely, I would like to be able to do the following, in strict sequential order: - Load some models, - rotate one of the models, - move one of the models, - capture a movie frame of the resulting configuration, and again - rotate one of the models, - move one of the models, - capture a movie frame of the resulting configuration, etc. I have tried using "perframe" commands, where each perframe operation comprises a "move" and a "turn" command, and has the option "frames 1". Still, I don't get exactly what I want: the resulting movie doesn't consist of the number of frames I'd expect - movie encoding seems to start before all commands have actually been executed. I can see a message saying that the movie has been finished, while things are still moving. I've provided a code snippet below. Moreover, rather than using "perframe", surely there must be a more elegant and natural way of enforcing sequential execution of commands, as one would expect from any normal programming language. Thank you very much in advance for your help, Best regards, Florian Drechsler -------------------------- Florian Drechsler Universität Ulm Institut für Biophysik Albert-Einstein-Allee 11 D-89081 Ulm ------------------------ ============================================================== # This is a command file to be opened from UCSF Chimera. # It loads several molecules from PDB files, and arranges them in docked conformations. # These conformations are the result of a Bayesian inference carried out by FastNPS. # Upon execution of this file, Chimera will generate a movie clip showing a set of docked # conformations, in the manner of a flip-book. # This file can be edited if any particular colour or lighting options etc. are desired. # --- load PDBs --- open ./2waq.pdb open ./1D3U_movedtoCentrePol_noTFB.pdb ################################################################################## ##### E d i t a b l e s e c t i o n for custom viewing preferences ##### ##### (colour, lighting, background, etc.) ##### ################################################################################## set bg_color white color dark slate gray #0:.A-Q 2dlabel create title text "Samples of configurations of docking scenario, 2WAQ vs. 1D3U" xpos 0.04 ypos 0.92 color black 2dlabel create sub text "Motion does not represent dynamics" size 12 xpos 0.04 ypos 0.88 color black ################################################################################## ##### E n d o f e d i t a b l e s e c t i o n ##### ################################################################################## move x 14.5577 model #1 move y 10.7525 model #1 move z 13.1320 model #1 windowsize 800 600 scale 0.8 movie record supersample 3 move 0.9432,3.3367,-3.9733 model #1 wait move -3.1264,-2.5812,5.6072 model #1 wait move -2.9523,2.8959,-3.9907 model #1 wait move -14.0968,0.5720,-12.9560 model #1 perframe "move -14.0968,0.5720,-12.9560 model #1; turn y 1 model #0;" frames 1 ~perframeperframe "move -14.0968,0.5720,-12.9560 model #1; turn y 1 model #0;" frames 1 ~perframe perframe "move -14.0968,0.5720,-12.9560 model #1; turn y 1 model #0;" frames 1 ~perframe perframe "move -14.0968,0.5720,-12.9560 model #1; turn y 1 model #0;" frames 1 ~perframe perframe "move -14.0968,0.5720,-12.9560 model #1; turn y 1 model #0;" frames 1 ~perframe wait move 8.4475,0.1,0.1 model #1 perframe "move 2.0968,0.5720,-12.9560 model #1; turn y 1 model #0;" frames 1 ~perframe perframe "move 2.0968,0.5720,-12.9560 model #1; turn y 1 model #0;" frames 1 ~perframe perframe "move 2.0968,0.5720,-12.9560 model #1; turn y 1 model #0;" frames 1 ~perframe perframe "move 2.0968,0.5720,-12.9560 model #1; turn y 1 model #0;" frames 1 ~perframe perframe "move 2.0968,0.5720,-12.9560 model #1; turn y 1 model #0;" frames 1 ~perframe perframe "move 2.0968,0.5720,-12.9560 model #1; turn y 1 model #0;" frames 1 ~perframe perframe "move 2.0968,0.5720,-12.9560 model #1; turn y 1 model #0;" frames 1 ~perframe perframe "move 2.0968,0.5720,-12.9560 model #1; turn y 1 model #0;" frames 1 ~perframe perframe "move 2.0968,0.5720,-12.9560 model #1; turn y 1 model #0;" frames 1 ~perframe wait move 8.4475,4.5142,16.4771 model #1 turn z 2 wait move -12.9187,-0.7126,-7.8443 model #1 turn z 2 wait move 9.5982,-3.2342,8.4843 model #1 turn z 2 wait move 3.2604,3.3466,-4.2558 model #1 turn z 2 wait move 0.5383,-1.8787,5.0346 model #1 turn z 2 wait move -0.6887,1.1472,-2.6070 model #1 turn z 2 wait move -0.0759,-1.7268,1.1365 model #1 turn z 2 wait move -3.1444,0.7922,-1.0015 model #1 turn z 2 wait move 5.2841,0.0361,0.6118 model #1 turn z 2 wait movie encode docking.mp4 bitrate 10000 framerate 60

3 5

multi protein complexes
by A G Szabo 09 Dec '15

09 Dec '15

I am working with a protein PDB 4KHZ. It is a recent PDB deposition of the maltose transporter system. It is a multisubunit protein complex. There are five separate chains that come together. I know how to select and visualize each of them or in pairs or whatever. Two of the subunits have a maltose substrate bound within their interior. I know how to visualize the maltose molecules using the Select menu. When I go to the Select menu, open Residues - click on GLC (Glucose) all of the maltose molecules become visible in both proteins. Is it possible somehow to visualize only one of the maltose molecules in one of the proteins in this case the maltose in chain E. - and not have the maltose in G or F visualized. Thank you Arthur G. Szabo Professor Emeritus Chemistry and Biochemistry. Wilfrid Laurier University.

2 1

Re: [Chimera-users] Save the map after hide dust
by Tom Goddard 08 Dec '15

08 Dec '15

Hi Gary, Good to hear from you. The hide dust feature does not change the density map, it only hides the small connected surface pieces. You could set the map grid points to zero inside the dust blobs with the mask command. But first you need to be able to show only the dust and there is no command to do that. I've attached a Python script that does that. You select the map surface (ctrl-click) that you have done hide dust on, then open the surfinvert.py script to show only the dust. Then use the mask command mask #0 sel invert true to mask the density map (#0) to the selected surface (dust blobs only shown) and invert, since you want to keep everything outside the dust blobs, not everything inside the dust blobs. I tried it, works. But if you lower the threshold on the new map then of course you see more dust. Tom The surfinvert.py script is also on the Chimera Python scripts page http://plato.cgl.ucsf.edu/trac/chimera/wiki/Scripts <http://plato.cgl.ucsf.edu/trac/chimera/wiki/Scripts> > On Dec 8, 2015, at 5:05 PM, Gang (Gary) Ren wrote: > > Hi Tom, > > I like the density map after hide density map, is there any way to save the > density map after dust hide? Every time I save the density map, it saved the > original map instead of density map after hidden dust. > > Thanks a lot > Gary > > > >

1 0

Chimera-users December 2015