Dear Bob and Angel and others,
I will certainly appreciate your help regarding the memory problems
that I'm having with JTAT!
1. YES I AM using Jmol.js in JTAT. (I did not use it in FirstGlance
in Jmol because it seems to me inadequately documented, and because I
felt I needed to understand what I was giving to Nature.)
2. The problem is not with the total amount of memory for any single
molecular view. The problem is that as one proceeds through a series
of molecular views, often but not always reloading Jmol applet, the
"total" amount of memory consumed in java (reported as "total" by
Jmol) gradually increases until there is none left ("total" = "maximum").
What I have seen indicates that some portion of memory from "dead and
gone" Jmols fails to be freed for reuse, and that this continues to
add up throughout each browser session. The only way I know to free
all the java memory for new molecular views is to close/quit the
browser, thereby quitting java. When you start a new browser session,
the memory is cleared.
I hope there are other ways that I don't yet know about!
Bob wrote:
>Or, alternatively, use code to deactivate applet divs that are not
>in use.
What code is that?
Here's what I am doing in JTAT currently. Please tell me how I can improve it.
A. I have an HTML div for Jmol (id="jmolAppletsDiv") at the outset,
and it remains in place throughout the JTAT session. Jmol.js is
loaded at the outset.
B. Before writing the first jmol object tag into the division, I
execute (one time only)
jmolInitialize(...);
jmolSetCallback(); //for messageCallback
jmolSetDocument(0); // because I gather HTML generated by Jmol.js
functions into strings.
C. Object tag HTML for Jmol(s) is gathered into a string variable
jhtml using calls to
jmolApplet( [s_jwidth, s_jheight], readySpt, jNameSuffix);
D. The Jmol(s) are written into jmolAppletsDiv in this manner:
document.getElementById("jmolAppletsDiv").innerHTML = jhtml;
E. The initial script specified in jmolApplet() messages a
recognizable token. When this token is seen in the messageCallback
stream, I assume that the corresponding Jmol has loaded and is ready
for action. (IS THERE A BETTER WAY TO DETECT JMOL READINESS?)
F. I then use jmolScript() to send a script to each Jmol that starts
with a load command, and then renders, colors, etc. producing the
initial molecular view.
SO FAR SO GOOD. We now have the first molecular display showing. I am
generally using small coordinate sets, so I haven't used much java memory yet.
G. Now, the user presses a button to display a different molecular view.
- If the new view uses the same PDB file(s) (coordinates), and the
same number of Jmols (1-4), only a new rendering script(s) is sent to
the EXISTING Jmol(s).
- If the new view uses different PDB file(s), but the same number
of Jmols, the scripts start with a "load" command, loading new
coordinates into the EXISTING Jmol(s).
IT WOULD BE EASY TO PUT IN A ZAP HERE IF THAT WOULD HELP. Although
the Jmol documentation is not explicit about what "load 1d66.pdb"
does, I assume this does an implicit zap, replacing the previous
coordinates with the new ones. If not, shouldn't it do an implicit zap?
- If the new view uses a different number of Jmols, new object HTML
is generated using jmolApplet() call(s), and it is written into the
existing jmolAppletsDiv.innerHTML SIMPLY REPLACING THE OBJECTS
(JMOLS) THAT WERE THERE BEFORE. IS THERE SOME MORE EFFECTIVE WAY TO
CLEAR OUT THE OLD JMOLS?
H. When moving to a new chapter, a new chapter.htm file is loaded
into the existing browser window, entirely replacing the old
chapter.htm. This starts the entire process over again, from loading
Jmol.js, setting up jmolAppletsDiv, to filling it with jmol
object(s), and when they message their readiness, having them load
PDB files and then scripting those coordinates.
SHOULD I ZAP OR DO SOME OTHER JMOL CLEAN UP PROCESS BEFORE LOADING A
NEW HTML DOCUMENT INTO THE WINDOW?
Currently, the links to new chapters are simple HTML links. If there
is some memory-clearing housekeeping I can do before loading the new
chapter.htm, it would be easy enough to make the chapter links run
javascript functions.
Bob wrote:
>You can save loads of memory just by using ZAP when a
>model's use is over.
It would be no problem at all to send "zap" to all existing Jmol
applets (up to 4) when a new molecular view button is pressed, before
loading new coordinates, or writing new Jmol object tag(s) into the
division. But generally I am just replacing the old coordinates with
new ones ("load 1d66.pdb"). If I have loaded .jvxl/.iso surface data
files, is their memory freed when I do a "load 1d66.pdb"? Again, the
question of an implicit zap comes up. If I need to do an explicit
zap, no problem.
Bob wrote:
>Another idea would be to make sure that on page loading the applets are
>NOT loading full models. This is very inefficient of resources.
I'm not sure what you mean by a "not full model". I'm using e.g.
"load 1d66.pdb".
Bob wrote:
>Java does this automatically, as needed. Don't go there. Basically, get
>rid of unnecessary memory-consuming objects, especially large molecular
>systems, cartoons, isosurfaces, etc.
I'm not sure what you mean by "get rid of". I am generally not
loading more data than I need for a given molecular view. If there is
some way to "get rid of" these data before I set up a new molecular
view, please tell me!
Bob wrote:
I have taken great pains to
>make sure that Jmol does not persist with objects that you think are gone.
>If they are gone, they are gone.
OK, it seems that I need to improve my understanding on how to make
them be "gone"!
Thanks, -Eric
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jmol-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-users
