Hi all,
the largest PDB file in the Protein Data Bank is currently the
biological unit file for entry '1M4X' (1m4x.pdb1), the PBCV-1 virus capsid.
Here are some data relevant for handling it with Jmol (application,
800x800, default settings):
compressed file size : 314 MB
uncompressed file size : 1.3 GB (!)
number of models : 1680
number of chains per model : 3
number of residues per chain: 413
total number of atoms : 16284240 (!)
open time: openFile(1m4x.pdb1.gz)1166702 ms (~20 min.)
memory used until message "1680 models...": 8.4 GB
CPU time until 1 model visible as wireframe: 114 min.
memory used after 1 model visible: 22 GB (!)
CPU time for "frame all" command: 2348 min. (~39 hours !)
memory used after all models visible: 22 GB
time for slight rotation with mouse : 2-4 min.
time for slight zoom increase with scroll wheel: 1.5 min.
time for "reset" command: >15 min. (I stopped the test)
---- Test System -------------------------
Jmol: 11.3.47, application
Java: 1.4.2_13
OS : Linux, SuSE Enterprise 10
CPU : Dual core Itanium 2, 1.6 GHz (18x)
RAM : 142 GB (physical)
------------------------------------------
I presented this extreme example here as a hopefully interesting
introduction into one major problem that you have to deal with if you
want to provide acceses to any PDB entry with Jmol (asymmetric and
biological units, as our 'JenaLib' does): OUT OF MEMORY !
Because an "OUT OF MEMORY" error freezes Jmol and the standard user most
likely won't take a look at the Java console it would be really good to
be able to warn the user at least.
Since memory requirements and availability differ largely between users
I would prefer a solution that would orient at the individual
configurations and files loaded.
Q: Could a "memory estimation function" be integrated into Jmol that
would estimate the memory requirement prior to loading a specific
structure file?
Additionally it would be necessary to be able to obtain information on
the free and maximum available memory within Jmol (and what would become
free if the currently loaded file(s) would be discarded).
I know that there is the "_memory" variable that contains information on
the free and used memory. But when I looked at the 3 different manually
reachable sources for memory information ("context menu", "print
_memory", "Java Console") after loading entry "1DEH"
(http://www.fli-leibniz.de/cgi-bin/3d_mapping.pl?CODE=1deh) I got the
following results:
1) context menu
18 MB total
6 MB free
254 MB maximum
2) print _memory
12.8/18.8
3) Java console
18,352 K
6,121 K free (33%)
And after requesting a garbage collection within the Java console it
changed to the following:
1) context menu
18 MB total
9 MB free
254 MB maximum
2) print _memory
8.6/18.8
3) Java console
18,352 K
10,356 K free (56%)
So it looks as if the reported free memory does only take into account
the currently allocated memory but not the maximum available memory.
Therefore the maximum available memory should also be available within
Jmol scripting.
And it would also be good to be able to request a garbage collection.
(Avoiding false alarm because of calculation with wrong numbers.)
Q: What do you think about storing the memory requirements for each file?
And since file loading is not the only memory consuming thing, it would
be good to be able to obtain other memory information too.
>From Bob's information about the high memory needs for
'antialiasDisplay' it looks like a good candidate for this.
Q: Could a "memory estimation function" be integrated into Jmol that
would estimate the additional memory requirement prior to 'set
antialiasDisplay true'?
Since the "OUTO OF MEMORY" problem not only occurs with very large
structures but for example also if a number of applets is started within
a single browser session, I think this might be of general interest
also to others.
While working with the extreme example '1m4x' I noticed that the CPU
usage was almost all the time at 100% (refered to 1 CPU). Only if a
screen update was necessary because for example a hidden part of the
Jmol window became visible this went up to 200%.
Q: Is there any way to benefit from multiple CPUs within Jmol?
Regards,
Rolf
-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users
