Hi Slaton, Your list of bugs is very useful and we're kind of abashed that you've encountered so many fatal errors in the 1602 release. I've provided some preliminary comments on your list below. I'll be breaking your list into separate bug reports for entry into our bug-tracking system, so you will be getting several automated mails from that system as they are entered.
Some possible Chimera stability issues/bugs, most experienced using the Midas Emulator.
1. After running conic on a PDB structure, the output image is placed against a glaring (#f00) red background. When you click on the image to revert back to standard rendering, Chimera segfaults.
Reproduced this on our Linux system. On the SGI, the image was the same, but no seg fault. On a DEC, everything worked right.
2. Running neon results in the message "/usr/local/midas/bin/neon: Command not found." Chimera then segfaults.
In the 1602 release we switched from assuming that neon was part of a previous MidasPlus installation to providing it with Chimera. The emulator code wasn't properly updated to reflect this for neon (just conic). The seg fault is a separate problem with the underlying C++ code when the subprogram being run (neon) doesn't exist).
3. Running ribbonjr results in the message "/usr/local/midas/bin/ribbonjr: Command not found." Chimera then segfaults.
Ribbonjr isn't supplied with Chimera (only MidasPlus). We expect Chimera's built-in ribbon capabilities to be a sufficient replacement soon and therefore won't be expending the resources to port ribbonjr to the various platforms we support. The seg fault is the same thing as with neon.
4. If I generate a surface rendering of a PDB structure, and then adjust the probe size to very low resolution (say 30A) it segfaults. This is an important feature for looking at docking possibilities for smaller atomic structures with large low-resolution volumes. Maybe there is a better way to "filter" a surface generated from PDB atomic structure to a lower resolution? Thanks for any advice here.
Reproducible. Haven't investigated beyond that. One of our programmers, Tom Goddard, is working on a "multi-scale" extension that will be able to produce low-resolution surfaces of large structures. He might have some advice (he's cc'ed on this mail). We anticipate the initial version of the multi-scale extension will be part of the next Chimera release, which will probably be in March.
5. If I alt-tab away to another program while surface rendering (of PDB, not a volume) is present, when I tab back it segfaults.
Haven't reproduced this yet, but only tried on Mandrake Linux. Will try to access a Red Hat box to try it on.
6. Question, is there any plan to add raytracing ability for producing publication quality images?
Not directly. We anticipate generating input files for popular ray-tracing programs, which you would then run separately. _Might_ be in the next release, though I would guess the release or two after that is more likely.
If not is the best option for this to export to large TIFFs and reduce size in photoshop/gimp? thanks.
Creating a tiff is certainly the current most viable option. The "Save Image" panel is somewhat confusing in this regard, but you shouldn't have to "reduce size" in an external program. You should be able to specify your desired final size in the panel, and use the "Page Setup" button to increase the resolution (in particular, changing the "shades per color" from 2 to 256 will make the numbers in "dots per unit" corresponding 1-to-1 with pixels in the tiff (i.e. if your "units" is inches and "dots per unit" is 400, then the tiff will have 400 pixels per inch).
This is under linux, have tried both red hat 7.3 and red hat 8.0 releases on two different dual Xeon systems. One has a GeForce 4 card and the other has mediocre onboard ATI Rage graphics. The GF4 card has surprisingly "blah" performance in Chimera, not poor but not particularly great.
This is Chimera build 1602. The PDB structure used was 1aoi.
hope this is useful, slaton
Slaton Lipscomb Nogales Lab, UC Berkeley http://cryoem.berkeley.edu
Hi Eric, thanks for the reply.
2. Running neon results in the message "/usr/local/midas/bin/neon: Command not found." Chimera then segfaults.
In the 1602 release we switched from assuming that neon was part of a previous MidasPlus installation to providing it with Chimera. The emulator code wasn't properly updated to reflect this for neon (just conic). The seg fault is a separate problem with the underlying C++ code when the subprogram being run (neon) doesn't exist).
Is there an environment var like MIDASDIR or something that could be set, so that it looks in the right place for neon? Another workaround might be to symlink /usr/local/chimera/bin/neon to /usr/local/midas/bin/neon.
Ribbonjr isn't supplied with Chimera (only MidasPlus). We expect Chimera's built-in ribbon capabilities to be a sufficient replacement soon and therefore won't be expending the resources to port ribbonjr to the various platforms we support.
Makes sense. The names "neon", "conic" and "ribbonjr" no longer make much sense in the context of a full-featured package like Chimera anyway.
4. If I generate a surface rendering of a PDB structure, and then adjust the probe size to very low resolution (say 30A) it segfaults. This is an important feature for looking at docking possibilities for smaller atomic structures with large low-resolution volumes. Maybe there is a better way to "filter" a surface generated from PDB atomic structure to a lower resolution? Thanks for any advice here.
Reproducible. Haven't investigated beyond that. One of our programmers, Tom Goddard, is working on a "multi-scale" extension that will be able to produce low-resolution surfaces of large structures. He might have some advice (he's cc'ed on this mail). We anticipate the initial version of the multi-scale extension will be part of the next Chimera release, which will probably be in March.
Glad this one is reproducible, in the meantime I'm just converting all my my smaller PDB structures to volumes using SPIDER or pdb2mrc (which comes with the EMAN package). This may be a better idea anyway since volumes render faster in Chimera than molecular surfaces generated from pdb coordinates (less data representations to think about at once I guess).
6. Question, is there any plan to add raytracing ability for producing publication quality images?
Not directly. We anticipate generating input files for popular ray-tracing programs, which you would then run separately. _Might_ be in the next release, though I would guess the release or two after that is more likely.
Is there a free raytracing program you would recommend in this capacity? I know about pov-ray, just wondering if there is something better or more appropriate (for volumes, rather than PDB structures). PyMol is pretty, but very much atomic coordinates-centric.
If not is the best option for this to export to large TIFFs and reduce size in photoshop/gimp? thanks.
Creating a tiff is certainly the current most viable option. The "Save Image" panel is somewhat confusing in this regard, but you shouldn't have to "reduce size" in an external program. You should be able to specify your desired final size in the panel, and use the "Page Setup" button to increase the resolution (in particular, changing the "shades per color" from 2 to 256 will make the numbers in "dots per unit" corresponding 1-to-1 with pixels in the tiff (i.e. if your "units" is inches and "dots per unit" is 400, then the tiff will have 400 pixels per inch).
Thanks for the tip, will try this out. regards, slaton
On Wednesday, January 15, 2003, at 02:16 PM, slaton wrote:
In the 1602 release we switched from assuming that neon was part of a previous MidasPlus installation to providing it with Chimera. The emulator code wasn't properly updated to reflect this for neon (just conic). The seg fault is a separate problem with the underlying C++ code when the subprogram being run (neon) doesn't exist).
Is there an environment var like MIDASDIR or something that could be set, so that it looks in the right place for neon? Another workaround might be to symlink /usr/local/chimera/bin/neon to /usr/local/midas/bin/neon.
Well, neon in turn calls conic, so with conic not working I don't think much can be done until we get the next release out the door.
Glad this one is reproducible, in the meantime I'm just converting all my my smaller PDB structures to volumes using SPIDER or pdb2mrc (which comes with the EMAN package). This may be a better idea anyway since volumes render faster in Chimera than molecular surfaces generated from pdb coordinates (less data representations to think about at once I guess).
For large structures like 1aoi, the molecular surface is composed of many, many triangles [even if the probe radius is large], which as you've noticed frequently results in sluggish response. Until low-res surfaces are available via the multi-scale extension, the pdb-to-volume conversions you are doing may well result in the most responsiveness.
6. Question, is there any plan to add raytracing ability for producing publication quality images?
Not directly. We anticipate generating input files for popular ray-tracing programs, which you would then run separately. _Might_ be in the next release, though I would guess the release or two after that is more likely.
Is there a free raytracing program you would recommend in this capacity? I know about pov-ray, just wondering if there is something better or more appropriate (for volumes, rather than PDB structures). PyMol is pretty, but very much atomic coordinates-centric.
You could try VTK (www.vtk.org). --Eric
participants (2)
-
Eric Pettersen -
slaton