Two transparent models and memory leaks
C Akey report problems with display of two transparent models and excessive memory use and crashes when saving images. ------------ Tom- Sorry to bother you but I am having serious problems with Chimera while trying to make figures for a paper. After you fixed the sessions number problem, so that they are retained in the same numbered slots from one session to the next, I found that my most recent sessions made with this version, would not work properly when I wanted two different displayed volumes to have transparencies different from 1. This worked in earlier versions and then I started over with a new session, imported everything and it is working again. Maddening. If you have a ribbon within a volume and try to vary the transparency, it almost disappears instead of having a gradual blending effect (see attached figures A,D panels). I am using a PC under XP with 1Gb mem and 512 GB graphics card. I have checked and memory is not the problem. {However, if you quit a session then open another session, Chimera does not give the memory back to the system, so your memory use soars, YOU MUST QUIT BEFORE OPENING A NEW SESSION.} Here is another killer bug: When you record an image full screen, about half the time you get a fatal error in pythonw.exe, it wants you to contact Microsoft and then Chimera crashes losing everything. The error from chimera reads "failed 1073741891" but there is no chance to report the bug. So after battling to get to the point of recording images, the program quits on me about half the time. By the way, when Chimera is shown full screen on our new Linux machine, it doesn't clearly show all the icons on the left hand side of the screen, they are partly occluded. sorry about the bugs but its starting to get to me. cheers C Akey
Hi Christopher, Chimera does not correctly handle more than one transparent model. If you have two transparent models the one with the higher model id number is rendered second and always appears in front of the one with lower model id number. The reason you observed different behaviour (sometimes looks ok, sometimes wrong) is because it depends on the model id numbers. If the transparent model in front has the higher id number then it looks ok, otherwise it looks wrong. Opaque models use the OpenGL depth buffer and do not have this problem. We will need to look into the memory leak (memory is not released when closing a session). What version of Chimera, 1.2352? The crash on Windows is very likely caused by running out of memory when rendering the image. Capturing a full screen image with supersampling (made 3x larger in both dimensions = 9x more pixels) can take significant memory (10 - 100 Mbytes). A machine with 1 Gbyte of memory is barely adequate for displaying ribosome structures (~100,000 atoms) and large density maps using Chimera. My Mac machines have 1.5 Gbytes and 2 Gbytes and I seldom work with atomic models as large as yours. Many EM Chimera users I work with use machines with at least 3 Gbytes of memory. I'll submit a Chimera bug report suggesting we look for the large memory allocations done during image saving and try to change the code to catch those allocation failures and avoid crashing. I don't have a clear picture of the occluded icons problem you observe with Chimera displaying full screen on your new Linux machine. Could you send a snapshot of that? Tom
More details from C Akey about crashes and transparency problems. ----------- Tom- I asked JF to send you a snapshot of the linux screen. You are right, when as each image is recorded the memory is taken away from the pc and IT IS NOT RETURNED. So after 2 or 3 snaps of a big image it gets to abit over 1Gb and Chimera has a fit or python has a fit. However, I am puzzled as I take a few snapshots of a big area and they are fine, then after rebooting the first snapshot image crashes of the same number of atoms, nothing changed. Instead of using about 100 Mb of memory during the image acquisition it used over 400 and crashed the machine. Yeah, when I start over on the next paper I will only use the linux machine with 4Gb of memory, but right now I am just trying to finish up here. How do I take somewhat lower res pictures off the screen????????? As to the two transparent models, this is important and needs to work consistently. But knowing about it allows one to try and work around the problem.....argh. But I am not sure the ID number is the whole story, because with two models in 3 and 10, 3 doesn't work properly, but in the same session with models in 5 and 8, both look fine when adjusting the transparency. cwa
Hi Christopher, When I save a full screen image in Chimera 1.2352 on the Mac the memory use rose from 54 Mbytes to 68 Mbytes. Then I saved the same image 2 more times and memory did not increase at all. It also never went back from 68 Mbytes to 54 Mbytes, but that is probably not a bug. Python may be holding that memory and will reuse it in subsequent allocations. In general when you allocate memory and then free it the operating system may not report the reduction in memory because it in fact has not been given back to the operating system. Instead the memory management for that application is keeping the memory and will reuse it in subsequent allocations. If your memory use goes up and up each time you save an image then that indicates a bug and I will investigate if you tell me which version of Chimera and on which operating system (Windows?). I'm not sure what to think of the unpredictability of your crashes. If you sometimes start Chimera and save an image and it crashes, and then do the exact same steps and it doesn't crash it will be hard for us to reproduce the problem on our machines -- a necessary step for fixing it. You can turn off the 3x3 supersampling when saving images to avoid using so much memory during image capture. In the "Save Image" dialog press the "Image Setup" button and then the preferences dialog will appear and you change "Supersample 3x3" to "Supersample 1x1". Lines may appear a bit more jagged in the resulting image. You'll have to look at the saved image to decide. Ok, I didn't tell you exactly the right rule for when two transparent models can be displayed approximately correctly. It is not always whether the one in front has higher or lower model id number. What really matters is the order in which the models were opened. The last opened transparent model will appear in front. It can have a lower id number than an earlier opened transparent model. I think both the old and new volume session saving preserve the order of opening the volume data sets. So I expect that restoring a session should not change the appearance of two transparent volume data sets. But the order of opening atomic models (e.g. ribbons) and volumes is not preserved. In restoring, the atomic models are all created before any volumes. The same problem existed with the older volume session code. We do not support having two transparent models. That limitation is described in the documentation. http://www.cgl.ucsf.edu/chimera/docs/ContributedSoftware/volumeviewer/framev... Unfortunately it is a fundamental limitation of the current Chimera architecture. So it will not be fixed anytime soon. It may be possible to have session restore order the models to match the original order but it is only a bandaid. Sometimes model 1 is in front of 2 in one place but behind it in another and transparency will not work right no matter what the order is in that case. Tom
participants (1)
-
Thomas Goddard