[chimera-dev] Re: Chimera issues

Eric Pettersen pett at cgl.ucsf.edu
Wed Jan 15 14:04:25 PST 2003


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




More information about the Chimera-dev mailing list