Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#977 closed defect (wontfix)

can't load PDB's larger than a certain size?

Reported by: charles.sindelar@… Owned by: Eric Pettersen
Priority: normal Milestone:
Component: Input/Output Version:
Keywords: Cc: chimera-programmers
Blocked By: Blocking:
Notify when closed: Platform: all
Project: ChimeraX

Description

Hi there, greetings to the UCSF ChimeraX team and happy new year!

I’m enjoying the beautiful graphics and other major improvements in ChimeraX but have run into a vexing problem: whenever I try to load PDB’s larger than a certain size (seems to be around 20000 atoms), the program just hangs; I get a “color spinning wheel of death” and I have to force quit.

Only workaround I have found is to divide up my PDB files into smaller chunks.

Any idea what might be triggering this unfortunate behavior?

I attach a working and nonworking example in case this is helpful…

Many thanks, Chuck

Working example:


Non-working example:




adp_stateA_actin_chimera.pdb

AM.pdb

Attachments (2)

adp_stateA_actin_chimera.pdb (1.2 MB ) - added by charles.sindelar@… 8 years ago.
Added by email2trac
AM.pdb (1.7 MB ) - added by charles.sindelar@… 8 years ago.
Added by email2trac

Change History (8)

by charles.sindelar@…, 8 years ago

Added by email2trac

by charles.sindelar@…, 8 years ago

Attachment: AM.pdb added

Added by email2trac

comment:1 by Eric Pettersen, 8 years ago

Component: UnassignedInput/Output
Owner: set to Eric Pettersen
Platform: all
Project: ChimeraX
Status: newaccepted

comment:2 by Eric Pettersen, 8 years ago

Status: acceptedfeedback

Hi Chuck!

I'm glad that ChimeraX is kinda-sorta working for you mostly, kind of. :-) Anyway, I opened your files in the current ChimeraX daily build and they both opened lickety-split. What version/date of ChimeraX are you running (first line of the log when you start up) and on what platform?

--Eric

in reply to:  5 comment:3 by charles.sindelar@…, 8 years ago

Hi Eric!  Great to hear from you, thanks for looking into this little issue.  

I noticed this problem with the first version of ChimeraX I tried back in June, and it stayed with me when I updated it last fall (v 0.1).

System info is below.  Only thing I can think of is maybe my GPU runs out of memory (being 7 years old and all…)

Cheers! -  Chuck


MacBook Pro (13-inch, Mid 2010)
MacOS X 10.13.2 (17C88)
2.4 GHz Intel Core 2 Duo
16 GB 1067 MHz DDR3

UCSF ChimeraX version: 0.1 (2017-11-09)
OpenGL version: 3.3 NVIDIA-10.4.14 310.90.30.05b27
OpenGL renderer: NVIDIA GeForce 320M OpenGL Engine
OpenGL vendor: NVIDIA Corporation



comment:4 by Eric Pettersen, 8 years ago

Cc: chimera-programmers added
Resolution: wontfix
Status: feedbackclosed

Hi Chuck,

Well I tried your files on a 2012 MacBook Pro running a version of ChimeraX from September, and again both worked fine. However, when I went to a 2010 MacBook Pro with a card similar to yours (NVIDIA GeForce GT 330M) then opening even your "good" structure was very slow -- principally drawing it (0.7 to open/read; 834 seconds [~14 minutes] to draw). This means that the card/driver either has a software implementation of critical ChimeraX graphics calls, or very poor/limited hardware implementations of them.
AFAIK, there is no solution for this (on Mac) other than getting a machine with a more modern graphics card.

--Eric

comment:5 by Eric Pettersen, 8 years ago

Just as an addendum, the reason some structures work fine and other slightly larger structures "hang" is that some graphics calls will be handled in hardware for data below a certain size threshold, but above that threshold it will be handled by a much, much slower software implementation.

--Eric

in reply to:  8 comment:6 by goddard@…, 8 years ago

This general problem is on our radar, that old graphics hardware can run literally 1000x slower by falling back to software rendering and ChimeraX does not have any way to know the graphics driver is so limited other than to time the rendering (which is too late, if it takes 800 seconds the first time it tries to draw a structure).

We have no easy solution.  One idea would be to run graphics benchmarks the first time ChimeraX is run on a machine and try to see if it is unusably slow.  But there are tons of OpenGL graphics features we would need to test.  Then if it is slow, having the ability to disable those would be complex -- what would ChimeraX do just fail to render if it needed one of those features?  But at a minimum the benchmarks could advise that your graphics is not capable of running ChimeraX well.  Still it would be a lot of work to try to cover most of the OpenGL we use.  And the end result seems no better, you already see ChimeraX can't run on the computer, we cannot remedy that.

Maybe a plausible approach would be to just include a black-list of graphics known to be inadequate and ChimeraX would warn the first time you run on such a system, and maybe every time log it at the top of the log.  But it is very hard to make such a list cover even a fraction of the old systems, we don't have access to those old systems to test.  It would probably need ChimeraX tool so a user could report their system as having inadequate graphics.

So while we would like to not waste our user's time by running ChimeraX on inadequate graphics, it is hard to even warn them.  It is a conscious decision that we will not cripple ChimeraX by requiring it to run on lowest-common-denominator hardware.  Unfortunately Chimera users might expect this because the 20-year old Chimera does run on lowest-common-denominator hardware because it's graphics code is so ancient.

Note: See TracTickets for help on using tickets.