Re: [Jmol-users] Exploring the limits

[Rolf H. <rh...@fl...>]

Bob Hanson wrote:
> Rolf Huehne wrote:
> 
>> Q: Could a "memory estimation function" be integrated into Jmol that
>> would estimate the memory requirement prior to loading a specific
>> structure file?
>>
>>  
>>
> I think "prior to loading" is asking a lot. We've talked before about 
> possibly having a loading bar with a cancel option. An applet can know 
> how much memory is allocated, but I don't think it can know how much 
> overall is available, because as it needs more Java requests more.
> 

Q: Could at least a good rule of thumb for loading PDB format files be
provided?
 (When I looked at a few examples, 20 times the uncompressed file size
seemed to be adequate. But I would guess that it also depends somehow on
the division into models, chains etc.. And it might also change with
Java and OS versions.)

Since we started processing all ~106,000 PDB files (asymmetric +
biological units) for automatic image generation with Jmol we could
export the memory requirement for each structure and put it into a
database. But of course other users won't benefit from this solution.
And it might be different on different machines and Java versions.
(It takes about 2 days using 20 parallel processes on the machine Bob
would also like to have. But leaving out '1M4X' because it might take 3
or 4 days alone to run it with the image generation script.)

>> 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
>>  
>>
> this is runtime.freeMemory(), runtime.totalMemory(),  runtime.maxMemory()
> 
> That last one is not available in some systems.
> 

As always, false promises on platform independence, even with really
basic important stuff...


>> Q: What do you think about storing the memory requirements for each file?
>>
>>  
>>
> storing?
> 

Determine "runtime.totalMemory()" before loading a file (after removing
the previous one if not "load APPEND") and after loading it and store it
in a list variable for all files currently loaded.
But if the values are available one could do this also with scripting.

>> 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'?
>>
>>  
>>
> for the application, yes; for the applet, maybe not.
> 
>> 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.
>>
>>  
>>
> very difficult in the applet situation, I think.
> 

Yes, indeed! And if the freezing of our Jmol viewer occurs frequently I
fear users will avoid using it in the future.

Regards,
Rolf