- Chimera-dev - RBVI Mailing Lists

Working with several proteins
by Navya Shilpa Josyula 15 Apr '14

15 Apr '14

Hi, I am working on a set of 400 proteins and for all these proteins I have specific list of amino acid residues. I wanted to know if there is any available script or a command to get the following 1. atomic areaSAS 2. atomic B-factor values 3. CASTp identified pocket residues and 4. CASTp identified pocket volumes for all the residues of these 400 proteins to be written in a single file. Kindly help me at your earliest. Thank you in advance for your help. Regards, Navya

1 0

Re: [chimera-dev] Export Chimera models to Blender, Maya, Cinema4d
by Tom Goddard 09 Apr '14

09 Apr '14

Hi Matt, The sensible approach is to make a small example of the per-vertex collada coloring not working in Blender and submit it as a bug to the Blender developers and see if anything happens. If they just ignore it then it isn’t worth trying to find all the other bugs in their collada importer. If they do fix it, and you have another bug, then it will be worth sending a simple case of the next bug. By simple example, for example use a huge step size for a volume map, so all you see is one tetrahedron. A small example will allow the developer to easily open the text file and see how it is encoding the colors without having to deal with 500 pages of mesh coordinates. Also provide an image of the correct appearance as shown by Mac Preview. It is best to use Preview rather than Chimera since that shows that other software can read the colors. You can say the file comes from UCSF Chimera but just give them the file since they aren’t likely to get Chimera — that would be too much work for them. A good bug report might take an hour to create and submit. If you want test cases of all the Chimera export features, then you should make them. It sounds like a lot of work. Import bugs sometimes involve combinations of features so you will not be able to catch all the problems this way. I think instead the approach of submitting bugs as you find them to the responsible developers is the way to go. Tom On Apr 9, 2014, at 4:38 PM, Dougherty, Matthew T wrote: > It would be good to develop some test cases using the collada & X3D formats; something that generates all graphical methods used by chimera. Clearly CGL can't become bogged down chasing down and correcting other software packages. > > Sticking with my workflow strategy (using chimera as a modeller and using a pro-animation package to do more sophisticated production), it looks like I have two options: > > 1) fix the blender collada/x3d problem, the onus on me. Having some small test cases I can take to the blender community might bring resolution. If someone at CGL can generate them I will make the effort to track down the blender developers and resolve the problem. > > 2) switch to another animation package that could process the chimera test cases. Downside is learning new complex software. > Having a CGL webpage listing animation software that can read these test cases would be helpful in making purchases. > > This is not say I am giving up on chimera animation. For most of conference and supplemental animations I plan to stick with chimera because I plan through my sw extensions, to get the lab researchers to vet out coloring and camera positions; then there are the animations involving volume rendering, which I would expect cannot be moved to another package. > > But for the complex animations that involve raytracing, tricky camera trajectories, compositing models, lighting variance, stereo3D, etc.; that chimera can't perform and is uneconomical to duplicate those features within chimera. > > > > > > Matthew Dougherty > National Center for Macromolecular Imaging > Baylor College of Medicine > ________________________________________ > From: Tom Goddard [goddard(a)sonic.net] > Sent: Wednesday, April 09, 2014 4:24 PM > To: Dougherty, Matthew T > Cc: chimera-dev(a)cgl.ucsf.edu > Subject: Re: Export Chimera models to Blender, Maya, Cinema4d > > Hi Matt, > > Yes Chimera exports RGBA vertex colors of surfaces in X3D. Chimera does not use polygon colors, only vertex colors. I don’t know if Chimera exports vertex colors for Collada. Conrad Huang wrote that code and he would know the answer. > > “Passing the OpenGL scenegraph” is not a feasible solution. All of the graphics programs represent the data differently. If you just gave the OpenGL calls to render the scene — none of the programs could do anything with that low level information. The common ground between programs is through standard scene description file formats like Collada, X3D, FBX, …. > > Tom > > > On Apr 9, 2014, at 2:14 PM, Dougherty, Matthew T wrote: > >> Hi Tom, >> >> I agree with your assessment. I have looked at the blender import code, basically a bunch of if statements chopping text; that is, it does not use std conversion libraries, so they inherently pick favorites of the format, and other things are broken. >> >> Regarding collada, this seems to have best importation into blender. The normals are preserved. The problem I am running into using it are the colors. >> When I do a volume surface color and export collada, Importing into polytrans & blender the polygon colors are missing. Does chimera output colors at the polygons and vertex level? RGB, RGBA? >> >> I spoke with the president of x3d, he runs the viz at Virginia tech. He said partnering with X3d might be an option. Doing a grant together and they code is a possibility. >> >> FBX would be another route using their format library. That would provide reasonable compatibility to autodesk sw, and possibly blender et al. I have researched it. Blender does the same thing for fbx and x3d, chop text no std libraries. Fbx offers a lot, but you get a lot of boiler plate bloat. >> >> What I am digging into is the best animation strategy. Chimera is the best for getting into the data and visualizing it. But as you noted in prior emails it will never be a pro animation package with ray tracing and animation UI tools to manage timelines. Generic animation packages are generic with a few targeted plugins. Passing the OpenGL scenegraph in a socket would be nice. >> >> >> Matthew Dougherty >> National Center for Macromolecular Imaging >> Baylor College of Medicine >> ________________________________________ >> From: Tom Goddard [goddard(a)sonic.net] >> Sent: Wednesday, April 09, 2014 3:37 PM >> To: Dougherty, Matthew T >> Cc: chimera-dev(a)cgl.ucsf.edu >> Subject: Export Chimera models to Blender, Maya, Cinema4d >> >> Hi Matt, >> >> It has been a problem getting molecular models exported from Chimera to be read in by Blender and Maya. For example Greg in our lab recently looked at why Blender does not correctly show the end-caps on ribbons exported from Chimera as X3D. This is a bug in the Blender X3D importer. We’ve worked to make sure Chimera exports valid 3d scene files. But we don’t fix bugs in Blender or Maya. As you know, there seems to be know consensus in the 3d model field about what file format to use to exchange data. Conrad in our lab added Collada format export (in daily builds) but his experience was that only some software would properly render it. I also have been reading Collada format in our next generation Chimera work which has not been released. >> >> Graham Johnson who made ePMV is here at UCSF. I’d have to ask how he handles data exchange between the PMV molecular viewer and the animation packages (Cinema4d, Blender, Maya). My impression was that it used plugins written for each animation package which presents a user interface and can call PMV to compute molecular surfaces and do other molecular analysis. The plugin could just transfer the data in some internal format rather than using some standard file format. That solution can work if you have enough money to implement it. >> >> I think it will take interest from Blender, Maya, Cinema4d, … developers to make progress, and money to pay them to work on more reliable file exchange to allow molecular vis programs like Chimera to operate with professional animation programs. >> >> Tom >> >> >> On Apr 8, 2014, at 2:54 PM, Dougherty, Matthew T wrote: >> >>> UNM had a NSF grant to extend OpenGL to do rendering to a sphere, simplifying s3d. >>> >>> Blender now has a full dome camera as part of the cycles camera rig. So this 3 fisheye approach should apply in terms of workflow. >>> >>> Getting back to your comment regarding the inherent animation limitations of chimera, and the various scene graph export file glitches; more thought might be given yo bridge that gap. Both packages use python and OpenGL. >>> >>> The ePMV approach of extending maya, blender, etc seems like a strategy of avoiding a lot of graphic file problems. >>> >>> Any ideas how to export natively or pipeline the packages? >>> >>> Matthew Dougherty >>> National Center for Macromolecular Imaging >>> Baylor College of Medicine >>> ________________________________________ >>> From: Tom Goddard [goddard(a)sonic.net] >>> Sent: Tuesday, April 08, 2014 4:03 PM >>> To: Dougherty, Matthew T >>> Cc: chimera-dev(a)cgl.ucsf.edu >>> Subject: Re: [chimera-dev] dome camera/S3D >>> >>> Hi Matt, >>> >>> That looks interesting. Looks like the same technique I tried a few years ago at the Imiloa stereo dome in Hawaii where I used 24000 virtual cameras so that each vertical strip had the stereo cameras facing that strip. This paper describes camera hardware for videoing the real world so it uses just 3 fish-eye cameras and there are artifacts because of that. The author says the artifacts are much reduced with 5 cameras. It would be a good technique to try even for virtual rendering where you can get away with thousands of cameras, because it would be a lot faster to render. You’d especially want that for interactive rendering in stereo dome. My stereo dome rendering took 15 minutes per frame with the 24000 camera approach! >>> >>> http://www.cgl.ucsf.edu/Outreach/technotes/dome3d/dome3d.html >>> >>> Tom >>> >>> >>> On Apr 8, 2014, at 12:53 PM, Dougherty, Matthew T <matthewd(a)bcm.edu> wrote: >>> >>>> Hi Tom, >>>> >>>> came across this >>>> >>>> http://vision3d.iro.umontreal.ca/en/blog/2013/07/29/the-omnipolar-camera-a-… >>>> >>>> Matthew Dougherty >>>> National Center for Macromolecular Imaging >>>> Baylor College of Medicine >>>> ________________________________________ >>>> From: Tom Goddard [goddard(a)sonic.net] >>>> Sent: Monday, April 07, 2014 8:18 PM >>>> To: Dougherty, Matthew T >>>> Cc: chimera-dev(a)cgl.ucsf.edu >>>> Subject: Re: [chimera-dev] dome camera/S3D >>>> >>>> Hi Matt, >>>> >>>> Yes the parallax angle used for Chimera dome stereo with the stereo command is half the “convergence angle” if by convergence angle you mean the angle between the lines of sight from your two eyes to an object on the dome surface level with your eyes and midway between them. So if I was setting it for a viewer in the center of a 4 meter radius dome, with eye separation of 0.06 meters I would use an angle atan(0.03 / 4) = 0.43 degrees. >>>> >>>> The positive angle is for the right eye negative for the left eye, because the y-axis points up and a positive rotation in the standard mathematical conventions (right-hand rule) would rotate your straight ahead view line to instead point slightly leftward. The view line is supposed to intercept an object at dome distance midway between eyes. A simple test in Chimera dome mode using “stereo dome parallax 10” verifies that this gives a view from the right as should be seen by the right eye. >>>> >>>> It makes sense to use symmetrical values +d degrees for the right eye and -d degrees for the left eye. If instead you shifted the two parallax values so their sum is not zero, that would give an effect as if your head was facing a different direction in the dome other than straight ahead. >>>> >>>> The Chimera focal plane setting seen in the Top View mode of the Side View dialog (menu Tools / Viewing Controls / Side View) does correspond to the dome screen position in the straight ahead position. I say in the “straight ahead position” because the focal plane is a flat plane, and of course the dome is a spherical surface. The focal plane position is important. Setting the parallax value does two things. It moves the camera right or left along the x-axis, and it rotates the camera view direction. The shift along the x-axis is by an amount so that the view line will hit the mid-point on the dome screen, ie (x camera shift) = (focal distance) * tan(parallax). The Chimera “eye separation” parameter is not used for dome parallax mode. The reason for that is because the dome parallax mode isn’t a stereo mode — it renders only one image using one camera. You have to record your whole movie with a right eye setting, and then re-record it with a left eye setting, then combine the two movies with some external software. Since it is a mono mode being used twice, it doesn’t use the “eye separation” parameter in the Camera panel (menu Tools / Viewing Controls / Camera). Instead the eye separation is implied by the parallax value and focal plane distance. >>>> >>>> I realize this is all somewhat quirky. If we provided a real interactive dome stereo mode that for instance produced side-by-side left and right eye dome images, then we could do away with parallax and use the eye separation and focal distance parameters that are used for other Chimera stereo modes. Since the fish-eye projection generally needs to be warped before display on the dome, this interactive stereo mode would probably also need to accept a warping texture described in a file in order to be useful. >>>> >>>> Tom >>>> >>>> >>>> On Apr 7, 2014, at 2:10 PM, Dougherty, Matthew T wrote: >>>> >>>>> Hi Greg, >>>>> >>>>> I was experimenting with the dome parallax and needed some help understanding your sw and terminology. >>>>> >>>>> Reading the documentation: >>>>> Left- and right-eye stereo views for dome display can be generated by specifying parallax angles of opposite signs. >>>>> The views are rotated by p-angle degrees about the Y (vertical) axis through the center of the focal plane. >>>>> For example, views recorded with dome parallax ±5° can be combined to give a stereo effect when viewed in the forward (−Z) direction. >>>>> >>>>> >>>>> >>>>> When you talk about p-angle it reminds me of the angle of convergence. Is that correct? >>>>> >>>>> In hollywood terminology they calibrate the word "parallax" to percentages. Zero parallax is on the screen, positive is behind the screen, and negative in front of the screen. >>>>> >>>>> +5° would be the left eye, and -5° the right? >>>>> Proper usage would be +n and -n; that is symmetrical around 0? >>>>> as opposed to +5° and 0°, or +4 and -2? >>>>> >>>>> Is the focal plane actually the dome screen? >>>>> Setting the focal plane in the side view, does it actually do anything? >>>>> >>>>> >>>>> >>>>> Matthew Dougherty >>>>> National Center for Macromolecular Imaging >>>>> Baylor College of Medicine >>>>> >>>>> _______________________________________________ >>>>> Chimera-dev mailing list >>>>> Chimera-dev(a)cgl.ucsf.edu >>>>> http://plato.cgl.ucsf.edu/mailman/listinfo/chimera-dev >>>>> >>>> >>>> >>> >>> >> >> > >

2 1

Re: [chimera-dev] Export Chimera models to Blender, Maya, Cinema4d
by Tom Goddard 09 Apr '14

09 Apr '14

Hi Matt, Yes Chimera exports RGBA vertex colors of surfaces in X3D. Chimera does not use polygon colors, only vertex colors. I don’t know if Chimera exports vertex colors for Collada. Conrad Huang wrote that code and he would know the answer. “Passing the OpenGL scenegraph” is not a feasible solution. All of the graphics programs represent the data differently. If you just gave the OpenGL calls to render the scene — none of the programs could do anything with that low level information. The common ground between programs is through standard scene description file formats like Collada, X3D, FBX, …. Tom On Apr 9, 2014, at 2:14 PM, Dougherty, Matthew T wrote: > Hi Tom, > > I agree with your assessment. I have looked at the blender import code, basically a bunch of if statements chopping text; that is, it does not use std conversion libraries, so they inherently pick favorites of the format, and other things are broken. > > Regarding collada, this seems to have best importation into blender. The normals are preserved. The problem I am running into using it are the colors. > When I do a volume surface color and export collada, Importing into polytrans & blender the polygon colors are missing. Does chimera output colors at the polygons and vertex level? RGB, RGBA? > > I spoke with the president of x3d, he runs the viz at Virginia tech. He said partnering with X3d might be an option. Doing a grant together and they code is a possibility. > > FBX would be another route using their format library. That would provide reasonable compatibility to autodesk sw, and possibly blender et al. I have researched it. Blender does the same thing for fbx and x3d, chop text no std libraries. Fbx offers a lot, but you get a lot of boiler plate bloat. > > What I am digging into is the best animation strategy. Chimera is the best for getting into the data and visualizing it. But as you noted in prior emails it will never be a pro animation package with ray tracing and animation UI tools to manage timelines. Generic animation packages are generic with a few targeted plugins. Passing the OpenGL scenegraph in a socket would be nice. > > > Matthew Dougherty > National Center for Macromolecular Imaging > Baylor College of Medicine > ________________________________________ > From: Tom Goddard [goddard(a)sonic.net] > Sent: Wednesday, April 09, 2014 3:37 PM > To: Dougherty, Matthew T > Cc: chimera-dev(a)cgl.ucsf.edu > Subject: Export Chimera models to Blender, Maya, Cinema4d > > Hi Matt, > > It has been a problem getting molecular models exported from Chimera to be read in by Blender and Maya. For example Greg in our lab recently looked at why Blender does not correctly show the end-caps on ribbons exported from Chimera as X3D. This is a bug in the Blender X3D importer. We’ve worked to make sure Chimera exports valid 3d scene files. But we don’t fix bugs in Blender or Maya. As you know, there seems to be know consensus in the 3d model field about what file format to use to exchange data. Conrad in our lab added Collada format export (in daily builds) but his experience was that only some software would properly render it. I also have been reading Collada format in our next generation Chimera work which has not been released. > > Graham Johnson who made ePMV is here at UCSF. I’d have to ask how he handles data exchange between the PMV molecular viewer and the animation packages (Cinema4d, Blender, Maya). My impression was that it used plugins written for each animation package which presents a user interface and can call PMV to compute molecular surfaces and do other molecular analysis. The plugin could just transfer the data in some internal format rather than using some standard file format. That solution can work if you have enough money to implement it. > > I think it will take interest from Blender, Maya, Cinema4d, … developers to make progress, and money to pay them to work on more reliable file exchange to allow molecular vis programs like Chimera to operate with professional animation programs. > > Tom > > > On Apr 8, 2014, at 2:54 PM, Dougherty, Matthew T wrote: > >> UNM had a NSF grant to extend OpenGL to do rendering to a sphere, simplifying s3d. >> >> Blender now has a full dome camera as part of the cycles camera rig. So this 3 fisheye approach should apply in terms of workflow. >> >> Getting back to your comment regarding the inherent animation limitations of chimera, and the various scene graph export file glitches; more thought might be given yo bridge that gap. Both packages use python and OpenGL. >> >> The ePMV approach of extending maya, blender, etc seems like a strategy of avoiding a lot of graphic file problems. >> >> Any ideas how to export natively or pipeline the packages? >> >> Matthew Dougherty >> National Center for Macromolecular Imaging >> Baylor College of Medicine >> ________________________________________ >> From: Tom Goddard [goddard(a)sonic.net] >> Sent: Tuesday, April 08, 2014 4:03 PM >> To: Dougherty, Matthew T >> Cc: chimera-dev(a)cgl.ucsf.edu >> Subject: Re: [chimera-dev] dome camera/S3D >> >> Hi Matt, >> >> That looks interesting. Looks like the same technique I tried a few years ago at the Imiloa stereo dome in Hawaii where I used 24000 virtual cameras so that each vertical strip had the stereo cameras facing that strip. This paper describes camera hardware for videoing the real world so it uses just 3 fish-eye cameras and there are artifacts because of that. The author says the artifacts are much reduced with 5 cameras. It would be a good technique to try even for virtual rendering where you can get away with thousands of cameras, because it would be a lot faster to render. You’d especially want that for interactive rendering in stereo dome. My stereo dome rendering took 15 minutes per frame with the 24000 camera approach! >> >> http://www.cgl.ucsf.edu/Outreach/technotes/dome3d/dome3d.html >> >> Tom >> >> >> On Apr 8, 2014, at 12:53 PM, Dougherty, Matthew T <matthewd(a)bcm.edu> wrote: >> >>> Hi Tom, >>> >>> came across this >>> >>> http://vision3d.iro.umontreal.ca/en/blog/2013/07/29/the-omnipolar-camera-a-… >>> >>> Matthew Dougherty >>> National Center for Macromolecular Imaging >>> Baylor College of Medicine >>> ________________________________________ >>> From: Tom Goddard [goddard(a)sonic.net] >>> Sent: Monday, April 07, 2014 8:18 PM >>> To: Dougherty, Matthew T >>> Cc: chimera-dev(a)cgl.ucsf.edu >>> Subject: Re: [chimera-dev] dome camera/S3D >>> >>> Hi Matt, >>> >>> Yes the parallax angle used for Chimera dome stereo with the stereo command is half the “convergence angle” if by convergence angle you mean the angle between the lines of sight from your two eyes to an object on the dome surface level with your eyes and midway between them. So if I was setting it for a viewer in the center of a 4 meter radius dome, with eye separation of 0.06 meters I would use an angle atan(0.03 / 4) = 0.43 degrees. >>> >>> The positive angle is for the right eye negative for the left eye, because the y-axis points up and a positive rotation in the standard mathematical conventions (right-hand rule) would rotate your straight ahead view line to instead point slightly leftward. The view line is supposed to intercept an object at dome distance midway between eyes. A simple test in Chimera dome mode using “stereo dome parallax 10” verifies that this gives a view from the right as should be seen by the right eye. >>> >>> It makes sense to use symmetrical values +d degrees for the right eye and -d degrees for the left eye. If instead you shifted the two parallax values so their sum is not zero, that would give an effect as if your head was facing a different direction in the dome other than straight ahead. >>> >>> The Chimera focal plane setting seen in the Top View mode of the Side View dialog (menu Tools / Viewing Controls / Side View) does correspond to the dome screen position in the straight ahead position. I say in the “straight ahead position” because the focal plane is a flat plane, and of course the dome is a spherical surface. The focal plane position is important. Setting the parallax value does two things. It moves the camera right or left along the x-axis, and it rotates the camera view direction. The shift along the x-axis is by an amount so that the view line will hit the mid-point on the dome screen, ie (x camera shift) = (focal distance) * tan(parallax). The Chimera “eye separation” parameter is not used for dome parallax mode. The reason for that is because the dome parallax mode isn’t a stereo mode — it renders only one image using one camera. You have to record your whole movie with a right eye setting, and then re-record it with a left eye setting, then combine the two movies with some external software. Since it is a mono mode being used twice, it doesn’t use the “eye separation” parameter in the Camera panel (menu Tools / Viewing Controls / Camera). Instead the eye separation is implied by the parallax value and focal plane distance. >>> >>> I realize this is all somewhat quirky. If we provided a real interactive dome stereo mode that for instance produced side-by-side left and right eye dome images, then we could do away with parallax and use the eye separation and focal distance parameters that are used for other Chimera stereo modes. Since the fish-eye projection generally needs to be warped before display on the dome, this interactive stereo mode would probably also need to accept a warping texture described in a file in order to be useful. >>> >>> Tom >>> >>> >>> On Apr 7, 2014, at 2:10 PM, Dougherty, Matthew T wrote: >>> >>>> Hi Greg, >>>> >>>> I was experimenting with the dome parallax and needed some help understanding your sw and terminology. >>>> >>>> Reading the documentation: >>>> Left- and right-eye stereo views for dome display can be generated by specifying parallax angles of opposite signs. >>>> The views are rotated by p-angle degrees about the Y (vertical) axis through the center of the focal plane. >>>> For example, views recorded with dome parallax ±5° can be combined to give a stereo effect when viewed in the forward (−Z) direction. >>>> >>>> >>>> >>>> When you talk about p-angle it reminds me of the angle of convergence. Is that correct? >>>> >>>> In hollywood terminology they calibrate the word "parallax" to percentages. Zero parallax is on the screen, positive is behind the screen, and negative in front of the screen. >>>> >>>> +5° would be the left eye, and -5° the right? >>>> Proper usage would be +n and -n; that is symmetrical around 0? >>>> as opposed to +5° and 0°, or +4 and -2? >>>> >>>> Is the focal plane actually the dome screen? >>>> Setting the focal plane in the side view, does it actually do anything? >>>> >>>> >>>> >>>> Matthew Dougherty >>>> National Center for Macromolecular Imaging >>>> Baylor College of Medicine >>>> >>>> _______________________________________________ >>>> Chimera-dev mailing list >>>> Chimera-dev(a)cgl.ucsf.edu >>>> http://plato.cgl.ucsf.edu/mailman/listinfo/chimera-dev >>>> >>> >>> >> >> > >

2 1

Export Chimera models to Blender, Maya, Cinema4d
by Tom Goddard 09 Apr '14

09 Apr '14

Hi Matt, It has been a problem getting molecular models exported from Chimera to be read in by Blender and Maya. For example Greg in our lab recently looked at why Blender does not correctly show the end-caps on ribbons exported from Chimera as X3D. This is a bug in the Blender X3D importer. We’ve worked to make sure Chimera exports valid 3d scene files. But we don’t fix bugs in Blender or Maya. As you know, there seems to be know consensus in the 3d model field about what file format to use to exchange data. Conrad in our lab added Collada format export (in daily builds) but his experience was that only some software would properly render it. I also have been reading Collada format in our next generation Chimera work which has not been released. Graham Johnson who made ePMV is here at UCSF. I’d have to ask how he handles data exchange between the PMV molecular viewer and the animation packages (Cinema4d, Blender, Maya). My impression was that it used plugins written for each animation package which presents a user interface and can call PMV to compute molecular surfaces and do other molecular analysis. The plugin could just transfer the data in some internal format rather than using some standard file format. That solution can work if you have enough money to implement it. I think it will take interest from Blender, Maya, Cinema4d, … developers to make progress, and money to pay them to work on more reliable file exchange to allow molecular vis programs like Chimera to operate with professional animation programs. Tom On Apr 8, 2014, at 2:54 PM, Dougherty, Matthew T wrote: > UNM had a NSF grant to extend OpenGL to do rendering to a sphere, simplifying s3d. > > Blender now has a full dome camera as part of the cycles camera rig. So this 3 fisheye approach should apply in terms of workflow. > > Getting back to your comment regarding the inherent animation limitations of chimera, and the various scene graph export file glitches; more thought might be given yo bridge that gap. Both packages use python and OpenGL. > > The ePMV approach of extending maya, blender, etc seems like a strategy of avoiding a lot of graphic file problems. > > Any ideas how to export natively or pipeline the packages? > > Matthew Dougherty > National Center for Macromolecular Imaging > Baylor College of Medicine > ________________________________________ > From: Tom Goddard [goddard(a)sonic.net] > Sent: Tuesday, April 08, 2014 4:03 PM > To: Dougherty, Matthew T > Cc: chimera-dev(a)cgl.ucsf.edu > Subject: Re: [chimera-dev] dome camera/S3D > > Hi Matt, > > That looks interesting. Looks like the same technique I tried a few years ago at the Imiloa stereo dome in Hawaii where I used 24000 virtual cameras so that each vertical strip had the stereo cameras facing that strip. This paper describes camera hardware for videoing the real world so it uses just 3 fish-eye cameras and there are artifacts because of that. The author says the artifacts are much reduced with 5 cameras. It would be a good technique to try even for virtual rendering where you can get away with thousands of cameras, because it would be a lot faster to render. You’d especially want that for interactive rendering in stereo dome. My stereo dome rendering took 15 minutes per frame with the 24000 camera approach! > > http://www.cgl.ucsf.edu/Outreach/technotes/dome3d/dome3d.html > > Tom > > > On Apr 8, 2014, at 12:53 PM, Dougherty, Matthew T <matthewd(a)bcm.edu> wrote: > >> Hi Tom, >> >> came across this >> >> http://vision3d.iro.umontreal.ca/en/blog/2013/07/29/the-omnipolar-camera-a-… >> >> Matthew Dougherty >> National Center for Macromolecular Imaging >> Baylor College of Medicine >> ________________________________________ >> From: Tom Goddard [goddard(a)sonic.net] >> Sent: Monday, April 07, 2014 8:18 PM >> To: Dougherty, Matthew T >> Cc: chimera-dev(a)cgl.ucsf.edu >> Subject: Re: [chimera-dev] dome camera/S3D >> >> Hi Matt, >> >> Yes the parallax angle used for Chimera dome stereo with the stereo command is half the “convergence angle” if by convergence angle you mean the angle between the lines of sight from your two eyes to an object on the dome surface level with your eyes and midway between them. So if I was setting it for a viewer in the center of a 4 meter radius dome, with eye separation of 0.06 meters I would use an angle atan(0.03 / 4) = 0.43 degrees. >> >> The positive angle is for the right eye negative for the left eye, because the y-axis points up and a positive rotation in the standard mathematical conventions (right-hand rule) would rotate your straight ahead view line to instead point slightly leftward. The view line is supposed to intercept an object at dome distance midway between eyes. A simple test in Chimera dome mode using “stereo dome parallax 10” verifies that this gives a view from the right as should be seen by the right eye. >> >> It makes sense to use symmetrical values +d degrees for the right eye and -d degrees for the left eye. If instead you shifted the two parallax values so their sum is not zero, that would give an effect as if your head was facing a different direction in the dome other than straight ahead. >> >> The Chimera focal plane setting seen in the Top View mode of the Side View dialog (menu Tools / Viewing Controls / Side View) does correspond to the dome screen position in the straight ahead position. I say in the “straight ahead position” because the focal plane is a flat plane, and of course the dome is a spherical surface. The focal plane position is important. Setting the parallax value does two things. It moves the camera right or left along the x-axis, and it rotates the camera view direction. The shift along the x-axis is by an amount so that the view line will hit the mid-point on the dome screen, ie (x camera shift) = (focal distance) * tan(parallax). The Chimera “eye separation” parameter is not used for dome parallax mode. The reason for that is because the dome parallax mode isn’t a stereo mode — it renders only one image using one camera. You have to record your whole movie with a right eye setting, and then re-record it with a left eye setting, then combine the two movies with some external software. Since it is a mono mode being used twice, it doesn’t use the “eye separation” parameter in the Camera panel (menu Tools / Viewing Controls / Camera). Instead the eye separation is implied by the parallax value and focal plane distance. >> >> I realize this is all somewhat quirky. If we provided a real interactive dome stereo mode that for instance produced side-by-side left and right eye dome images, then we could do away with parallax and use the eye separation and focal distance parameters that are used for other Chimera stereo modes. Since the fish-eye projection generally needs to be warped before display on the dome, this interactive stereo mode would probably also need to accept a warping texture described in a file in order to be useful. >> >> Tom >> >> >> On Apr 7, 2014, at 2:10 PM, Dougherty, Matthew T wrote: >> >>> Hi Greg, >>> >>> I was experimenting with the dome parallax and needed some help understanding your sw and terminology. >>> >>> Reading the documentation: >>> Left- and right-eye stereo views for dome display can be generated by specifying parallax angles of opposite signs. >>> The views are rotated by p-angle degrees about the Y (vertical) axis through the center of the focal plane. >>> For example, views recorded with dome parallax ±5° can be combined to give a stereo effect when viewed in the forward (−Z) direction. >>> >>> >>> >>> When you talk about p-angle it reminds me of the angle of convergence. Is that correct? >>> >>> In hollywood terminology they calibrate the word "parallax" to percentages. Zero parallax is on the screen, positive is behind the screen, and negative in front of the screen. >>> >>> +5° would be the left eye, and -5° the right? >>> Proper usage would be +n and -n; that is symmetrical around 0? >>> as opposed to +5° and 0°, or +4 and -2? >>> >>> Is the focal plane actually the dome screen? >>> Setting the focal plane in the side view, does it actually do anything? >>> >>> >>> >>> Matthew Dougherty >>> National Center for Macromolecular Imaging >>> Baylor College of Medicine >>> >>> _______________________________________________ >>> Chimera-dev mailing list >>> Chimera-dev(a)cgl.ucsf.edu >>> http://plato.cgl.ucsf.edu/mailman/listinfo/chimera-dev >>> >> >> > >

1 0

Re: [chimera-dev] [Chimera-users] mutating residues
by Elaine Meng 08 Apr '14

08 Apr '14

Dear Hussain MR, The chimera-users(a)cgl.ucsf.edu address (not the others) is recommended for asking questions about using Chimera. To change an amino acid in a protein structure, you can use the Rotamers tool (in menu under Tools… Structure Editing) or the "swapaa" command. Please see the manual: <http://www.rbvi.ucsf.edu/chimera/docs/ContributedSoftware/rotamers/framerot…> <http://www.rbvi.ucsf.edu/chimera/docs/UsersGuide/midas/swapaa.html> There are "swapaa" examples in the link above, and examples of using Rotamers in the "Structure Analysis and Comparison Tutorial": <http://www.rbvi.ucsf.edu/chimera/docs/UsersGuide/tutorials/squalene.html> You can find tutorials and search the documentation using the Help menu in Chimera. I hope this helps, Elaine ---------- Elaine C. Meng, Ph.D. UCSF Computer Graphics Lab (Chimera team) and Babbitt Lab Department of Pharmaceutical Chemistry University of California, San Francisco On Apr 8, 2014, at 5:07 AM, MUHAMMAD RAMZAN MANWAR <geniouschemist26(a)gmail.com> wrote: > Dear Dr. Ferrin, > Hope this email finds you the best of your health. First of all, I did appreciate the effort that You and Your team did in the form of UCSF Chimera. Being the part of academic/government university, I have used Chimera tool for protein modeling and cited in my two articles: one published in JCB-Wiley and other in Hundawi in 2014. Current email I am sending to request for guidance about how can I substitute an amino acid (wild type to mutant residue) within protein 3D model by using Chimera. I will be thankful for your guidance, if possible. > With regards > Hussain MR > PACER-HD, KAU, KSA

1 0

Re: [chimera-dev] dome camera/S3D
by Tom Goddard 08 Apr '14

08 Apr '14

Hi Matt, That looks interesting. Looks like the same technique I tried a few years ago at the Imiloa stereo dome in Hawaii where I used 24000 virtual cameras so that each vertical strip had the stereo cameras facing that strip. This paper describes camera hardware for videoing the real world so it uses just 3 fish-eye cameras and there are artifacts because of that. The author says the artifacts are much reduced with 5 cameras. It would be a good technique to try even for virtual rendering where you can get away with thousands of cameras, because it would be a lot faster to render. You’d especially want that for interactive rendering in stereo dome. My stereo dome rendering took 15 minutes per frame with the 24000 camera approach! http://www.cgl.ucsf.edu/Outreach/technotes/dome3d/dome3d.html Tom On Apr 8, 2014, at 12:53 PM, Dougherty, Matthew T <matthewd(a)bcm.edu> wrote: > Hi Tom, > > came across this > > http://vision3d.iro.umontreal.ca/en/blog/2013/07/29/the-omnipolar-camera-a-… > > Matthew Dougherty > National Center for Macromolecular Imaging > Baylor College of Medicine > ________________________________________ > From: Tom Goddard [goddard(a)sonic.net] > Sent: Monday, April 07, 2014 8:18 PM > To: Dougherty, Matthew T > Cc: chimera-dev(a)cgl.ucsf.edu > Subject: Re: [chimera-dev] dome camera/S3D > > Hi Matt, > > Yes the parallax angle used for Chimera dome stereo with the stereo command is half the “convergence angle” if by convergence angle you mean the angle between the lines of sight from your two eyes to an object on the dome surface level with your eyes and midway between them. So if I was setting it for a viewer in the center of a 4 meter radius dome, with eye separation of 0.06 meters I would use an angle atan(0.03 / 4) = 0.43 degrees. > > The positive angle is for the right eye negative for the left eye, because the y-axis points up and a positive rotation in the standard mathematical conventions (right-hand rule) would rotate your straight ahead view line to instead point slightly leftward. The view line is supposed to intercept an object at dome distance midway between eyes. A simple test in Chimera dome mode using “stereo dome parallax 10” verifies that this gives a view from the right as should be seen by the right eye. > > It makes sense to use symmetrical values +d degrees for the right eye and -d degrees for the left eye. If instead you shifted the two parallax values so their sum is not zero, that would give an effect as if your head was facing a different direction in the dome other than straight ahead. > > The Chimera focal plane setting seen in the Top View mode of the Side View dialog (menu Tools / Viewing Controls / Side View) does correspond to the dome screen position in the straight ahead position. I say in the “straight ahead position” because the focal plane is a flat plane, and of course the dome is a spherical surface. The focal plane position is important. Setting the parallax value does two things. It moves the camera right or left along the x-axis, and it rotates the camera view direction. The shift along the x-axis is by an amount so that the view line will hit the mid-point on the dome screen, ie (x camera shift) = (focal distance) * tan(parallax). The Chimera “eye separation” parameter is not used for dome parallax mode. The reason for that is because the dome parallax mode isn’t a stereo mode — it renders only one image using one camera. You have to record your whole movie with a right eye setting, and then re-record it with a left eye setting, then combine the two movies with some external software. Since it is a mono mode being used twice, it doesn’t use the “eye separation” parameter in the Camera panel (menu Tools / Viewing Controls / Camera). Instead the eye separation is implied by the parallax value and focal plane distance. > > I realize this is all somewhat quirky. If we provided a real interactive dome stereo mode that for instance produced side-by-side left and right eye dome images, then we could do away with parallax and use the eye separation and focal distance parameters that are used for other Chimera stereo modes. Since the fish-eye projection generally needs to be warped before display on the dome, this interactive stereo mode would probably also need to accept a warping texture described in a file in order to be useful. > > Tom > > > On Apr 7, 2014, at 2:10 PM, Dougherty, Matthew T wrote: > >> Hi Greg, >> >> I was experimenting with the dome parallax and needed some help understanding your sw and terminology. >> >> Reading the documentation: >> Left- and right-eye stereo views for dome display can be generated by specifying parallax angles of opposite signs. >> The views are rotated by p-angle degrees about the Y (vertical) axis through the center of the focal plane. >> For example, views recorded with dome parallax ±5° can be combined to give a stereo effect when viewed in the forward (−Z) direction. >> >> >> >> When you talk about p-angle it reminds me of the angle of convergence. Is that correct? >> >> In hollywood terminology they calibrate the word "parallax" to percentages. Zero parallax is on the screen, positive is behind the screen, and negative in front of the screen. >> >> +5° would be the left eye, and -5° the right? >> Proper usage would be +n and -n; that is symmetrical around 0? >> as opposed to +5° and 0°, or +4 and -2? >> >> Is the focal plane actually the dome screen? >> Setting the focal plane in the side view, does it actually do anything? >> >> >> >> Matthew Dougherty >> National Center for Macromolecular Imaging >> Baylor College of Medicine >> >> _______________________________________________ >> Chimera-dev mailing list >> Chimera-dev(a)cgl.ucsf.edu >> http://plato.cgl.ucsf.edu/mailman/listinfo/chimera-dev >> > >

1 0

dome camera/S3D
by Dougherty, Matthew T 07 Apr '14

07 Apr '14

Hi Greg, I was experimenting with the dome parallax and needed some help understanding your sw and terminology. Reading the documentation: Left- and right-eye stereo views for dome display can be generated by specifying parallax angles of opposite signs. The views are rotated by p-angle degrees about the Y (vertical) axis through the center of the focal plane. For example, views recorded with dome parallax ±5° can be combined to give a stereo effect when viewed in the forward (−Z) direction. When you talk about p-angle it reminds me of the angle of convergence. Is that correct? In hollywood terminology they calibrate the word "parallax" to percentages. Zero parallax is on the screen, positive is behind the screen, and negative in front of the screen. +5° would be the left eye, and -5° the right? Proper usage would be +n and -n; that is symmetrical around 0? as opposed to +5° and 0°, or +4 and -2? Is the focal plane actually the dome screen? Setting the focal plane in the side view, does it actually do anything? Matthew Dougherty National Center for Macromolecular Imaging Baylor College of Medicine

2 1

tangent wave
by Dougherty, Matthew T 27 Mar '14

27 Mar '14

Hi, I just purchased a Tangent Wave that I plan to interface into chimera. The best design is to use sockets. Is there any precedence for using sockets in chimera? Matthew Dougherty National Center for Macromolecular Imaging Baylor College of Medicine

2 3

Re: [chimera-dev] S3D extension
by Tom Goddard 20 Mar '14

20 Mar '14

Hi Matt, Yes, unfortunately Chimera dialogs often do not track changes to the underlying parameters they are displaying. So if you want to directly control the Camera dialog settings for screen width, here is the Python code to get the ViewerDialog (which holds the Camera pane, Effects pane, Side View pane, …). >>> from chimera import dialogs >>> from chimera.viewing import ViewerDialog >>> d = dialogs.find(ViewerDialog.name) <chimera.viewing.ViewerDialog object at 0x10d6ebfd0> >>> d.screenWidth.get() 35.55118110236221 >>> d.screenWidth.set(45) The Tangent Wave looks fun. In getting work done with Chimera we don't venture beyond keyboard, mouse/trackpad input controls. But I can see how a specialized task like making videos can benefit from the extra dedicated knobs, trackballs and buttons. Unfortunately since any input device beyond keyboard, mouse, trackpad is rare, the more exotic devices don't get much support from software developers like us. That leaves you with the tricky task of trying to hook it up to work with our software. Sorry about that. Tom On Mar 20, 2014, at 4:15 PM, "Dougherty, Matthew T" wrote: > Hi Tom, > > I tried ScreenMMWidth last night but it produces anomalous results. > When I get the value using ScreenMMWidth it matches the gui screen size value. > > When I set the value using getScreenMMWidth, the gui value does not change, but distance to screen gui value changes. > Afterwards I get the value for screen width, which matches what I set, but does not match the gui value. > > using the hack similar to what you mentioned, I can set the value in the gui correctly. > But I could not figure out how to get the viewer1 dialog handle. > That is, I can create a second viewer and do the hack. > > Being able to modify gui values directly as though I used a mouse or keyboard, as a developer outside the chimera tent, this would be preferred. Conceptually this is easier than learning/fishing for the intricacies of gui callbacks and related functions. There is going to be latency, but frequently this is not a problem. > > ===== > On a related note, I bought one of these for evaluation: > http://www.tangentwave.co.uk/products_wave.asp > > I think this maybe the one-stop HID I have been looking for to handle coordinate xforms, volume rendering, S3D, and misc project management issues. <$1500. > it can also double duty on a variety of other apps, particularly color and video editing for linux, mac, windows. > > Besides the method of keyboard accelerators (which I may not need), I will be able to directly interact with it through sockets, so I will need some help devising a strategy to manage these realtime events within chimera, registering callbacks for socket events. With this device I will have three trackballs so using the hack you mention would not be good because of latency. I should get it next week. If it looks promising and could be fielded in the lab, I could get another one and send it to CGL for evaluation. > > > Matthew Dougherty > National Center for Macromolecular Imaging > Baylor College of Medicine > ________________________________________ > From: Tom Goddard [goddard(a)sonic.net] > Sent: Thursday, March 20, 2014 5:42 PM > To: Dougherty, Matthew T > Cc: chimera-dev(a)cgl.ucsf.edu > Subject: Re: [chimera-dev] S3D extension > > Hi Matt, > > from chimera import tkgui > tkgui.setScreenMMWidth(w) > w = tkgui.getScreenMMWidth() > > Here MM stands for millimeters. > > In general you don't want your Python code to find graphical user interface controls (entry fields, sliders, …) and modify their values. Instead you modify the parameter values and the graphical user interface should detect the change and update themselves. The case of the Icosahedron tool is just a hack where only the graphical user has access to the radius parameter. > > Tom > > > On Mar 19, 2014, at 11:13 PM, "Dougherty, Matthew T" wrote: > >> Now that I am working on a similar problem it may have a similar solution to the previous email. >> >> Specifically I am trying to add an extension to control eye seperation in animations. >> >> using the icosahedron extension as a reference, I figure I need to make a similar gui call in def set_s3d(es), and change the gui to the camera tab. >> >> # ----------------------------------------------------------------------------- >> # >> def change_s3d(start, last, step): >> range = (start, last, step) >> import Transition >> Transition.show_transition(set_s3d, range) >> >> # ----------------------------------------------------------------------------- >> # >> def set_s3d(es): >> import Transition >> Transition.show_label('eye separation', 'r = %.0f' % es) >> import Icosahedron.gui >> d = Icosahedron.gui.icosahedron_dialog() >> if d: >> d.radius.set_value(es) >> >> # ----------------------------------------------------------------------------- >> # >> import Transition >> arg_specs = (('es1', float), >> ('es2', float), >> ('frames', int)) >> >> add_transition_command('s3d', >> change_s3d, >> arg_specs, >> None, None) >> >> # ----------------------------------------------------------------------------- >> # ----------------------------------------------------------------------------- >> >> >> >> >> >> >> Matthew Dougherty >> National Center for Macromolecular Imaging >> Baylor College of Medicine >> ________________________________________ >> From: Dougherty, Matthew T >> Sent: Thursday, March 20, 2014 12:20 AM >> To: chimera-dev(a)cgl.ucsf.edu >> Subject: screen width >> >> I would like to set and get the parameter screen width. can you advise on the proper way? >> >> thx >> >> >> Matthew Dougherty >> National Center for Macromolecular Imaging >> Baylor College of Medicine >> >> _______________________________________________ >> Chimera-dev mailing list >> Chimera-dev(a)cgl.ucsf.edu >> http://plato.cgl.ucsf.edu/mailman/listinfo/chimera-dev >> > >

1 0

screen width
by Dougherty, Matthew T 20 Mar '14

20 Mar '14

I would like to set and get the parameter screen width. can you advise on the proper way? thx Matthew Dougherty National Center for Macromolecular Imaging Baylor College of Medicine

2 2

changing the radius value on volumeEraser
by Dougherty, Matthew T 10 Mar '14

10 Mar '14

Using python I would like to determine the eraser radius, calculate a new radius and update the widget. I can modify the radius value, but unable to update the parameter on the widget. Using this from VolumeEraser.gui import Volume_Eraser_Dialog v=Volume_Eraser_Dialog() r=v.sphere_radius_scale.value() print r r=r*0.5 v.sphere_radius_scale.set_value(r) If I have a widget radius of 8000,it accesses a default value of 2 rather than the value in the dialog box, and changes the sphere radius to 1. printing v I get the impression that I am access a different widget/gui. Matthew Dougherty National Center for Macromolecular Imaging Baylor College of Medicine

2 3

volume eraser
by Dougherty, Matthew T 07 Mar '14

07 Mar '14

Hi, I need some help as to how to call Erase() from VolumeEraser I am thinking it is something like this, but I am unable to determine what xxxxx value should be. from VolumeEraser.gui import Volume_Eraser_Dialog Volume_Eraser_Dialog.Erase(xxxxx) Matthew Dougherty National Center for Macromolecular Imaging Baylor College of Medicine

2 2

Re: [chimera-dev] how can i delete solovent and ligand from pdb file?
by Eric Pettersen 03 Mar '14

03 Mar '14

Hi, The issue is that a bunch of the relevant code isn't in Python -- it's in C++. It might simply be easier to use the criteria outlined in the "Automatic Categories" table in the surface command help page (http://www.cgl.ucsf.edu/chimera/docs/UsersGuide/midas/surface.html) to implement the ligand/solvent identification yourself. Nonetheless, the Python part of the code that identifies ligands and solvent is in the 'categorize' method found in <your Chimera installation>/share/Categorizer/__init__.py. There are various calls into C++ but most of them are trivial and are obvious as to what they do and are only there to make the routine faster (since it is called for every model that is opened). The one that is not so obvious is "roots = model.roots(1)" which calculates the "roots" of each graph component of the molecule (i.e. each molecular fragment that is not connected by covalent bonds to any other fragment). The source code for computing roots is in Molecule::mg_traversalOrganize() in libs/_molecule/Molecule.cpp of the C++ source code. You can fetch the source code via git. Details about that are here: Source Code for UCSF Chimera --Eric Eric Pettersen UCSF Computer Graphics Lab http://www.cgl.ucsf.edu On Mar 2, 2014, at 5:24 PM, unwicky wrote: > Thank for your attention!I have found the two commands,and I did so,but to do this,I must load all of chimera,that's too heavy,I hope I can get the pure code,thank you again! > > > > > At 2014-02-27 05:37:25,"Eric Pettersen" <pett(a)cgl.ucsf.edu> wrote: > On Feb 24, 2014, at 6:44 AM, unwicky <unwicky(a)126.com> wrote: > >> hello,i want to delete solvent and ligand from a pdb file,but to use chimera command line,it has to load to many components,can you show me the pure source code to to this?thank you > > Hi, > I'm guessing your question means: "I have a bunch of PDB files that I need to remove the solvent and ligand from and therefore need to automate the process. How do I do that?". If that's not right, let me know. Anyway, the Chimera commands to remove solvent and ligand are: > > del solvent > del ligand > > and therefore in Python can be called by: > > from chimera import runCommand as rc > rc("del solvent") > rc("del ligand") > > > In Chimera's Programmer's Guide (http://www.cgl.ucsf.edu/chimera/docs/ProgrammersGuide/index.html) there is a basic primer for looping through a bunch of data files and doing something on each one. You would just take the example in the basic primer and modify it to do the above (and write out the results). The direct link to the basic primer is here: > > http://www.cgl.ucsf.edu/chimera/docs/ProgrammersGuide/basicPrimer.html > > --Eric > > Eric Pettersen > UCSF Computer Graphics Lab > http://www.cgl.ucsf.edu > > > >

1 0

how can i delete solovent and ligand from pdb file?
by unwicky 26 Feb '14

26 Feb '14

hello,i want to delete solvent and ligand from a pdb file,but to use chimera command line,it has to load to many components,can you show me the pure source code to to this?thank you

2 1

frame number/scaling
by Dougherty, Matthew T 11 Feb '14

11 Feb '14

1) when I run an animation through a .com file the rendered image filenames increment. How can I locate that value as it is rendering? would like to create a button that will till me the last filename created. 2) sometimes I read in a vrml file and would like to change the xyz scaling for that model to match other models. Don't see a command for that. Any suggestions? thanks, Matthew Dougherty National Center for Macromolecular Imaging Baylor College of Medicine

3 2

cd command
by Dougherty, Matthew T 24 Jan '14

24 Jan '14

can you tell me where the chimera command "cd" python code is located? Matthew Dougherty National Center for Macromolecular Imaging Baylor College of Medicine

2 1

session callback
by Dougherty, Matthew T 24 Jan '14

24 Jan '14

I was wanting to execute some code during quit session, close session, and save session; priority on quit. Is this going to be straight forward, such as registering a callback? Matthew Dougherty National Center for Macromolecular Imaging Baylor College of Medicine

2 1

Moving atoms from HETATM to ATOM entries
by Jean-Didier Maréchal 24 Jan '14

24 Jan '14

Dear all, I am working with some chemically modified residues. For consistency with MMTK, I have to move non-natural atoms in the ATOM list of the pdb. I would like to do that directly from chimera and not editing the pdbfile. I thought that I could alter the heteroatom value of chimera's residues to get there. But whether this is not the right attribute or I miss something. What I do is: build my system, select the atoms of the non-natural and natural part of the residue. Make a new residue and then, having selected it: atoms=chimera.selection.currentAtoms() for a in atoms: a.residue.isHet=False This indeed changes the isHet attribute but when saving the pdb, the residue is in the HETATM field. Any pointer? Best, JD **************************** Dr. Jean-Didier Maréchal Associate Professor The Computational Biotechnological Chemistry Team Departament de Química Universitat Autònoma de Barcelona Edifici C.n. 08193 Cerdanyola (Barcelona) Tel: +34.935814936 e-mail: JeanDidier.Marechal(a)uab.es www: http://g <http://asklipio.qf.uab.es>ent.uab.cat/jdidier<http://ent.uab.es/jdidier>

2 2

pointers
by Dougherty, Matthew T 13 Jan '14

13 Jan '14

Hi, I am trying to track down some variables to develop some methods, and need some direction as to locations and practical options. 1) where do I find the name of the session variable? I want to build in organizational structure for the session files and data files in regards to project management. 2) the pull down menus change depending on the dialog that is the focus. Usually it is volume viewer and main window. Is there a way to lock in the main viewer pull down menu? would prefer that to be constant. 3)sometimes I need to transfer a session, or receive a session from somebody. If the session only uses pdb files I am ok. If there are mrc files involved, then they have to be located, bundled, transferred, and linkages repaired. I would like to get a list of all the extraneous data files that the session uses, and copy all those files into a single folder, that is usually on a thumb drive. So I would need to develop sw to locate those files, copy them as an aggregate along with the session file. 4) for S3D, is the focal plane the same thing as the convergence plane, or is it the screen plane? Is everything that is close to the camera is negative parallax, focal plane is zero parallax, everything behind is positive parallax? 5) I have a number of related animations using different session files. Usually I will create a core session, with the other files having small variants (eg, inclusion of different pdb or vrml files). Each session file produces a clip, each session file has a corresponding command file that sequences the positions, and other animation components. The end of clip1 is the beginning point for clip2, etc. Passing positions between session files is the problem. How do I export a position so as to import it into another session file? 6) I need to animate the lighting. I get the impression lighting is relative to the camera, but it could be to the origin, or to the aggregate of the models, or to the clipping planes, etc. not sure on this. It does not appear to be saved as part of the savepos command. I have dug into the lighting code and can move the lights around using the HID tools I am creating. What would be the best or viable or quickest approach to animate the lights? Matthew Dougherty National Center for Macromolecular Imaging Baylor College of Medicine

2 3

Re: [chimera-dev] Chimera python packaging
by Tom Goddard 08 Jan '14

08 Jan '14

Hi Thomas, Packaging all the libraries needed by PyTom like Chimera does it is a lot of work. For Chimera we build from source and include about 40 third-party libraries and programs (like Python, numpy, hdf5, PIL, ffmpeg, …) on Windows, Mac and Linux in 32-bit and 64-bit versions. The Chimera build and packaging system is just Makefiles we wrote, a system that has probably taken about 1 programmer-year to develop and maintain. Even though it is a lot of work, if you want to people to use your software you have to package it for an easy install. Requiring people to compile or install a dozen required packages will reduce your number of users I'd say by 10 to 100-fold. It looks like for PyTom you have about 10 required libraries and support Linux and Mac but not Windows. Probably distributing just 64-bit would be fine -- since that is needed for big data sets. There are plenty of problems trying to package these all up. Here are a few that come to mind. Your build machine may have libraries that your users will not have and when you compile third party libraries they may link against those. For instance, fftw might see that you have a blas system library and compile for it. So you often have to tell packages not to use such libraries. Sometimes no configure flag is available and we patch the third party build scripts. On Linux we only rely on Linux Standard Base (LSB) libraries. Common libraries like tiff, zip, jpeg are ones to look out for. On both Linux and Mac you'll need to tell your executables where to find the included shared libraries. We use environment variables (LD_LIBRARY_PATH, DYLD_LIBRARY_PATH on Mac) which means are exectutables shell scripts that set the environment variables and then start the real executable. The paths have to be relative paths since the user could install your package anywhere. On the Mac there are also Frameworks to worry about. We build Python as a Mac Framework, but maybe you would find it easier to instead use the non-framework version since that will be like Linux. You of course have to build on old versions of Mac and Linux operating systems if you want compatibility with older operating systems. For instance we build Mac Chimera on Mac OS 10.6 even though 10.9 is the current release. It is a pain to keep machines with old operating systems running. It is possible to compile on a newer operating system targeting an older operating system but we find it easier just to use the old operating system. Even with that compatibility among different Linux distributions was a bit of a nightmare in the past. I'm not sure if is still troublesome. You should make sure the licenses for the libraries you want to redistribute allow that. You'll have trouble using GPL libraries if you distribute any libraries that are not open source. This only scratches the surface of the long list of problems we have dealt with in building third-party libraries, packaging and distributing them. Tom On Jan 8, 2014, at 10:59 AM, Thomas Hrabe wrote: > Hi Tom, > > I am looking for ways to ship my old software pytom (pytom.org) in a way similar to chimera. > > Meaning that I want to add all required dependencies such as python, numpy, … to the whole package and ship the compiled version. > Is there anything I have to look out for, especially for the python? > How do you automate daily builds and all that? Do you use an integration server like jenkins? > > Thank you for your support, > Thomas > > > ---------------------------------- > > Thomas Hrabe (Ph.D.) > Sanford-Burnham > Medical Research Institute > 10901 North Torrey Pines Road > La Jolla, CA 92037, USA > +1 858 646 3100 ext 4070 > > > > > >

1 0

Re: [chimera-dev] [Chimera-users] keyboard shortcuts
by Tom Goddard 07 Jan '14

07 Jan '14

Hi Matt, I agree that difficulty of use kills interest in stereo -- needs to be as simple as binoculars, one knob. For recording transparent background animations currently you have to click the "Transparent background" button in the File / Save Image dialog. That switches Chimera rendering to use a frame buffer that includes transparency. You also will need to use PNG format for the movie recording images ("movie record format PNG") because that is the only recording format that handles transparency. Currently there is no command to set background transparency. We should add a "set backgroundTransparency true|false" command to do this so you can put it in a script. It will call the setBackgroundOpacity() routine in chimera/printer.py. Until that is added you could use a little Python script transpbg.py: from chimera import printer printer.setBackgroundOpacity(True) and call it from your movie command script with "open transpbg.py" The Chimera programming questions should go to chimera-dev(a)cgl.ucsf.edu to avoid spamming Chimera users who are not interested in programming issues. Tom On Dec 31, 2013, at 12:07 PM, "Dougherty, Matthew T" <matthewd(a)bcm.edu> wrote: > probably going to stick with the spreadsheet as my starting point for design and documentation. > Mapping the USB commands has to be hand crafted in concert with other non-chimera software manufacturer software. > The spreadsheet will allow me to deal with the mishmash, chimera commands, OS interactions, serial S3D serial/USB commands to projector. > > As for S3D, my analysis is that jumping through all the hoops is so awkward this is the main reason people don't mess with it. > One button to get in and out, turn a knob like a pair of binoculars. > Now that I got an 8ft rotating dome in my office, I am building a viz cockpit to push interactivity, s3D and volume rendering. > > just about finished with my first operational prototype, "UCP", user control panel. Will send it to chimera-dev for review. > it deals with a bunch of camera issues, particularly S3D so I can explore a range of interaxial distances. > It also gives me fine control of volume rendering, so I can accurately pull out stuff I would normally give up on. > Starting to feel pretty good about programming chimera extensions, at some point I plan to tackle the frame packing and a rework of space navigator. > > couple other things. > > 1) When I need to generate animations that have a transparent background I go to save image and set the transparency background. Sometimes I forget to do this and waste a lot of time on my rendering. > > I would like to add a new animation command to so I can set the transparency in my .com files. What is the chimera variable I need to set? > Also plan similar commands to set the screensize, screen distance and eye separation; but know how to do those. > > 2) These kinds of posts, should I be sending them to chimera-users or chimera-dev? > > > > Matthew Dougherty > National Center for Macromolecular Imaging > Baylor College of Medicine > ________________________________________ > From: Tom Goddard > Sent: Tuesday, December 31, 2013 1:36 PM > To: Dougherty, Matthew T > Subject: Re: [Chimera-users] keyboard shortcuts > > Ok. You might have your code use: > > for k in ('!001', '!002', '!003'): > add(k, 'HID', lambda: HID(k)) > > or if they really are just numbered > > for k in range(25): > s = '!%03d' % k > add(s, 'HID', lambda: HID(s)) > > Tom > > > On Dec 31, 2013, at 11:29 AM, "Dougherty, Matthew T" wrote: > >> thx, I can generate that in a spreadsheet and paste it in. >> >> add( >> '!001', 'HID', lambda: HID('!001'), >> '!002', 'HID', lambda: HID('!002'), >> ... >> ) >> >> >> suggestion on chimera2, if you are going to use keyboard shortcuts I would recommend changing the ordering so the description is the last item. This makes it easier to read because the text and def tend to be 2-6 characters so the columns line up, and the descriptions lengths are hi;ghrange from 3-30 characters. >> >> Matthew Dougherty >> National Center for Macromolecular Imaging >> Baylor College of Medicine >> ________________________________________ >> From: Tom Goddard >> Sent: Tuesday, December 31, 2013 12:26 PM >> To: Dougherty, Matthew T >> Subject: Re: [Chimera-users] keyboard shortcuts >> >> There is no way to fetch the last keyboard shortcut typed. But you can achieve the same thing with the code I gave in the previous message. >> >> Tom >> >> >> On Dec 31, 2013, at 2:06 AM, "Dougherty, Matthew T" wrote: >> >>> Hi Tom, >>> >>> attached is what I am doing now. >>> >>> >>> Would like to do this instead >>> >>> def register_accelerators(): >>> accelerators = [ >>> ('!001',HID,'HID'), >>> ('!002',HID,'HID'), >>> ('!003',HID,'HID'), >>> ('!004',HID,'HID'), .... >>> >>> >>> def HID(): >>> get keyboard shortcut text string >>> call Matt's def passing the text string >>> matt's def is part of another chimera extension TBD >>> >>> >>> >>> >>> Matthew Dougherty >>> National Center for Macromolecular Imaging >>> Baylor College of Medicine >>> ________________________________________ >>> From: Tom Goddard >>> Sent: Monday, December 30, 2013 2:21 PM >>> To: Dougherty, Matthew T >>> Cc: chimera-users(a)cgl.ucsf.edu >>> Subject: Re: [Chimera-users] keyboard shortcuts >>> >>> Hi Matt, >>> >>> I don't understand your question. Is the idea that you want to register a single keyboard shortcut handler that handles many different shortcuts and takes the two-letter shortcut characters as an argument? You would still need to register that function for every set of shortcut keys it handles. You could do something like >>> >>> from Accelerators import add_accelerator as add >>> add('pq', 'Here is a description of what this shortcut does', lambda: myHandler('pq')) >>> >>> The "lambda" business is Python code that creates a function, in this case taking no arguments. And in this example it calls the funtion myHandler with argument "pq". >>> >>> Tom >>> >>> >>> >>> On Dec 27, 2013, at 4:56 PM, "Dougherty, Matthew T" wrote: >>> >>>> I am writing a bunch of USB-HID keyboard shortcuts for some extensions I am writing. >>>> >>>> Usually one shortcut per def. Since my decoding of HID is integrally tied to the extension, I would like to simplify all my shortcuts coming from one device to one def. >>>> >>>> As of now if I have 100 button commands I have to 1) register 100 shortcuts, 2) create 100 defs, 3) do corresponding stuff in my extension. >>>> I would prefer to call one def that passes the actual keyboard string to my extension, thereby simplifying my user accelerators to just registration. >>>> >>>> How do I get the string within my keyboard shortcuts python file? >>>> >>>> thanks, >>>> >>>> >>>> Matthew Dougherty >>>> National Center for Macromolecular Imaging >>>> Baylor College of Medicine >>>> _______________________________________________ >>>> Chimera-users mailing list >>>> Chimera-users(a)cgl.ucsf.edu >>>> http://plato.cgl.ucsf.edu/mailman/listinfo/chimera-users >>>> >>> >>> <USB-HID-D5.py> >> >> > >

3 3

writing in b-factor field
by MARIA VITTORIA CUBELLIS 30 Dec '13

30 Dec '13

Dear sir/madam, I have a file that associates to each amino acid of a protein A a given value v. I would like to transfer this value to the b-factor field of the protein A the value v. I have a single value for each aminoacid N1,N2... I would like to transfer the value to each atom let say N1 C v1 N1 CO v1 N1 N v1 .... .... N2 C v2 N2 CO v2 N2 N v2 and so on is it possible to this withe chimera? thank you mvcubellis

2 1

volume rendering & histogram
by Dougherty, Matthew T 26 Dec '13

26 Dec '13

Hi, I was trying to develop an HID for volume rendering. How do I get access using python to the color and density values. I would like to read them and modify their values for color and threshold. I also would like to read the values for the histogram. Matthew Dougherty National Center for Macromolecular Imaging Baylor College of Medicine

1 1

Re: [chimera-dev] creating an extension
by Conrad Huang 09 Dec '13

09 Dec '13

Sorry for the terse message, Matt. The link is to how Chimera dialogs are initialized in extensions and the example only uses Tkinter widgets. For a new extension, I would follow the example template but use Pmw widgets in place of the Tkinter ones. Tkinter widgets tend to be very basic and you have to do a lot of work to get even simple layouts. Pmw widgets (built on top of Tkinter) have more options and require less coding. I really like their documentation (http://pmw.sourceforge.net/doc/index.html) and generally just use the reference manual pages which contain working example code at the bottom. Conrad On 12/9/2013 3:10 PM, Dougherty, Matthew T wrote: > Hi Conrad, > > Thanks for the link. Not clear on what is going here. You suggest > PMW, but the link involves tkinter. Not that familiar with pmw or > tkinter, their overlap or integration. Make sure I am correct on > this, the link is non pmw? My inclination is to go pmw, at the same > want to go with the overall programming methods. > > Matthew Dougherty National Center for Macromolecular Imaging Baylor > College of Medicine ________________________________________ From: > Conrad Huang [conrad(a)cgl.ucsf.edu] Sent: Monday, December 09, 2013 > 12:45 PM To: Dougherty, Matthew T; chimera-dev(a)cgl.ucsf.edu Subject: > Re: [chimera-dev] creating an extension > > Personally, I would just stick with a standard Python GUI like Pmw. > There's example code that work and it's well documented. Perhaps > http://www.cgl.ucsf.edu/chimera/docs/ProgrammersGuide/Examples/Main_Extensi… > > might help. > > Conrad > > On 12/7/2013 3:03 PM, Dougherty, Matthew T wrote: >> Hi, >> >> I am trying to create a simple extension that has a column of >> buttons (qty 10-20) having a corresponding column of user defined >> text blocks. When I push a button, the corresponding text string >> will be read and processed as a command string (eg, "reset >> default", "rock X 3", "move Z 2000") >> >> I started with VolumePlanes and whittled it down to the nub to >> figure out what it was doing relative to what I want; below. I am >> realizing the buttons defined by this example extension uses some >> specific chimera GUI strategies. My going with a row of buttons >> would work as in this volumeplanes example, but is second >> preference on layout. More visually intuitive to have it side by >> side. Not sure this is possible with another dozen lines of code, >> or if I would need to go about it another route using different >> CGLTk api's and scrap using this volumeplane extension as a boiler >> plate. >> >> >> So I am realizing that this is putting me into the intricacies of >> CGLtk. An alternate would be to go with std python gui code. I >> also know you are reinventing chimera, one reason being the tk >> libraries, which opens up a third approach. So I am at a crossroad >> as to how to proceed. Because the code is relatively small, a >> rewrite for chimera2 does not seem an issue. Also there are some >> issues with parenting I am unfamiliar with (eg, t.withdraw(), >> columnconfigure). >> >> I am thinking this might be a good example of an extension for a >> beginner, so writing it as such might be useful for others. >> Particularly for new developers trying to sort out the boundaries >> between python, chimera, tk, and the extension linkages. >> >> Need some direction as to which way to go for the least amount of >> work of coding. >> >> thanks, >> >> Matthew Dougherty National Center for Macromolecular Imaging >> Baylor College of Medicine >> >> >> =========== >> >> # >> ----------------------------------------------------------------------------- >> >> > >> import chimera >> from chimera.baseDialog import ModelessDialog import >> ButtonCommands >> >> # >> ----------------------------------------------------------------------------- >> >> > >> class Button_Commands_Dialog(ModelessDialog): >> title = 'Button Commands' name = 'button commands' buttons = >> ('C1', 'C2', 'C3','Close',) >> >> # >> --------------------------------------------------------------------------- >> >> > >> # > --------------------------------------------------------------------------- >> > def fillInUI(self, parent): t = parent.winfo_toplevel() >> self.toplevel_widget = t t.withdraw() >> >> parent.columnconfigure(2, weight = 2) >> >> from CGLtk import Hybrid >> >> ps = Hybrid.Scale(parent, 'Cmd1', 0, 10, 1, 0) ps.frame.grid(row = >> 2, column = 0, sticky = 'ew') >> >> ps.callback(self.change_plane_cb) >> ps.entry.bind('<KeyPress-Return>', self.change_plane_cb) self.plane >> = ps >> >> def change_plane_cb(self, full_size = False): return >> >> # >> --------------------------------------------------------------------------- >> >> > >> # > --------------------------------------------------------------------------- >> > def C1(self): c_1='echo c1' chimera.runCommand(c_1) >> >> def C2(self): c_2='echo c2' chimera.runCommand(c_2) >> >> def C3(self): c_3='echo c3' chimera.runCommand(c_3) >> >> # >> ----------------------------------------------------------------------------- >> >> > >> def Button_Commands_dialog(create = False): >> from chimera import dialogs return >> dialogs.find(Button_Commands_Dialog.name, create=create) >> >> # >> ----------------------------------------------------------------------------- >> >> > >> def show_button_commands_dialog(): >> from chimera import dialogs return >> dialogs.display(Button_Commands_Dialog.name) >> >> # >> ----------------------------------------------------------------------------- >> >> > >> from chimera import dialogs >> dialogs.register(Button_Commands_Dialog.name, >> Button_Commands_Dialog, replace = True) >> >> _______________________________________________ Chimera-dev >> mailing list Chimera-dev(a)cgl.ucsf.edu >> http://plato.cgl.ucsf.edu/mailman/listinfo/chimera-dev >> >

1 0

Re: [chimera-dev] apple events
by Tom Goddard 09 Dec '13

09 Dec '13

Maybe Apple events can be used to pass events between apps. I don't know. We do cross-platform code development (Windows, Mac, Linux), so we rarely are interested in mechanisms only available on Mac, and we know little about those. Tom On Dec 9, 2013, at 2:51 PM, "Dougherty, Matthew T" wrote: > Hi Tom, > > Just surveying possibilities. > > Thought apple events may be a way to pass events between apps. Currently using keyboard short cuts, thought this might be useful as another conduit of control. > > > > Matthew Dougherty > National Center for Macromolecular Imaging > Baylor College of Medicine > ________________________________________ > From: Tom Goddard [goddard(a)sonic.net] > Sent: Monday, December 09, 2013 4:41 PM > To: Dougherty, Matthew T > Cc: chimera-dev(a)cgl.ucsf.edu > Subject: Re: [chimera-dev] apple events > > Hi Matt, > > The Apple event code in Chimera I believe handles when a user drags a file onto Chimera. That is received as an Apple event and Chimera opens the file in response. Don't know what other Apple events might be interesting to handle. > > Tom > > > On Dec 6, 2013, at 11:34 AM, "Dougherty, Matthew T" wrote: > >> I was nosing around the code and I noticed something about an apple events handler. >> >> Wondering if this be applied to some of my development. >> >> Could you elaborate on its current use and potential application? >> >> >> Matthew Dougherty >> National Center for Macromolecular Imaging >> Baylor College of Medicine >> _______________________________________________ >> Chimera-dev mailing list >> Chimera-dev(a)cgl.ucsf.edu >> http://plato.cgl.ucsf.edu/mailman/listinfo/chimera-dev >> > >

2 1