Re: [Jmol-users] Jmol -- two major advances

Charles Shubert Wed, 07 Apr 2010 09:09:36 -0700

The users of my app have a variety of machines, so I may have to wait until GPU 
programming languages settle down a bit more before launching into this space.  
Most of the users, however, do have at least dual core machines.

"Yes, surfaces would be the place where this could be very helpful. One
thread could be independently building the planes of data that are processed by
the Marching Cube algorithm. I recently set Jmol up so that it creates
isosurfaces "progressively" -- that is, it only reads as much of the file at a
time to create the small slice of data necessary for the moment. This already
has markedly increased performance because one never actually holds an nX x nY
x nZ block of data in memory at any time. The Marching Cube class requests
blocks of data from the VolumeFileReader class -- sounds perfect for
multithreading. It seems to me isosurfaces would be a place where those
processors could help -- at least one more. Maybe something to look into. If
it's not difficult to set up, I'm game."

Which version of Jmol does creating isosurfaces "progressively"? I may have a
little time next week to take a look at the code.

--Chuck
----- Original Message -----
From: Robert Hanson
To: Charles Shubert ; jmol-users@lists.sourceforge.net
Sent: Wednesday, April 07, 2010 11:37 AM
Subject: Re: [Jmol-users] Jmol -- two major advances

On Wed, Apr 7, 2010 at 8:26 AM, Charles Shubert <cshub...@mit.edu> wrote:

I'm confused by the 2400% CPU usage claimed below. Does this imply that 24
cores of a multicore machine are running at 100%?

I have not been able to get Jmol to run on more than one core of my Mac 8
core machine. In looking at the source code for Jmol 11.8.not_too_long_ago
there seems to be a spot in the script interpreter to launch multiple threads
which could exploit a multicore machine, but seems to launch only one thread to
run the script itself. The code for this version's interpreter doesn't seem
thread safe at first blush, so it doesn't seem like it is possible to get more
than 100% CPU usage there.

So, my questions are:

- Does Jmol 12 exploit Java multi-threading?

- If so, is this multi-threading for "file loading only" or a side-effect
of something in Java or the operating system?
- Is there a way to exploit multi-threading in Jmol?

I'm sure there is. And if VMD is any example, the use of GPUs would vastly
increase performance. It would be a great project for someone to explore. Since
I know nothing about parallel processing, I'm not the one to take it on.

Mostly the "multithreading" aspects of Jmol are not that. They are
independent threads that carry out totally independent, unrelated tasks. Mostly
this is not a help in terms of performance; mostly it is a headache!

My Jmol app uses isosurface rendering for quaternary structure of proteins.
Right now, seven of the cores on my machine are idle and one is very busy. It
would be nice to be able to put the calculation of every chain's isosurface on
a thread to take advantage of whatever multicore capacity a user's machine has.

Yes, surfaces would be the place where this could be very helpful. One thread
could be independently building the planes of data that are processed by the
Marching Cube algorithm. I recently set Jmol up so that it creates isosurfaces
"progressively" -- that is, it only reads as much of the file at a time to
create the small slice of data necessary for the moment. This already has
markedly increased performance because one never actually holds an nX x nY x nZ
block of data in memory at any time. The Marching Cube class requests blocks of
data from the VolumeFileReader class -- sounds perfect for multithreading. It
seems to me isosurfaces would be a place where those processors could help --
at least one more. Maybe something to look into. If it's not difficult to set
up, I'm game.

Bob

--Chuck

--- Original Message -----
From: Robert Hanson
To: jmol-users@lists.sourceforge.net
Sent: Wednesday, April 07, 2010 8:10 AM
Subject: Re: [Jmol-users] Jmol -- two major advances

Wow, thanks, Rolf. I thought perhaps you could do that! Oh, so close!

First,

write PNG

just sends the image to your clipboard as an actual system-dependent
image since you didn't specify a file name. So it was trying to create that
when the error occurred. I'm guessing that happened not because the file was so
large but instead because the ribbon was so tiny. I'll see if I can reproduce
that.

JPG64

should not be there at all.

Bob

On Wed, Apr 7, 2010 at 4:32 AM, Rolf Huehne <rhue...@fli-leibniz.de>
wrote:

On 04/05/2010 06:50 PM, Robert Hanson wrote:
> Thanks, Peter. Yes, that's a killer. Definitely not ready to read
16,000,000
> atoms! But I have added a new option that lets you load some smaller
number
> of biomolecule transformations. Looks like we'll have to let Rolf
open that
> one for us.... ;)
>

Using Jmol 12.0.RC4_dev rev 12773 I opened the full 1m4x biological unit
file with all atoms successfully. It took about 520 minutes CPU time and
21 GB of memory. (Until the memory was filled the CPU usage raised up to
2400%, then it stayed at 100% for several hours.)

(When I tried this before the same amount of memory was used but Jmol
somehow got stuck and I never got anything rendered.)

You can't really work interactively (unless you have a CPU that is at
least 600 times faster than a 1.6 GHz Itanium processor) because it
takes about one minute for a command to work on all atoms.
But at least you can work with script commands.

When I tried to export an image with "write png" I got the following
error message:

JPG64
java.lang.ArrayIndexOutOfBoundsException: -1
at org.jmol.g3d.Hermite3D.renderHermiteRibbon(Unknown Source)
at org.jmol.g3d.Graphics3D.drawHermite(Unknown Source)
at
org.jmol.shapebio.BioShapeRenderer.renderHermiteRibbon(Unknown Source)
at org.jmol.shapebio.CartoonRenderer.render1(Unknown Source)
at org.jmol.shapebio.CartoonRenderer.renderBioShape(Unknown
Source)
at org.jmol.shapebio.BioShapeRenderer.render(Unknown Source)
at org.jmol.shape.ShapeRenderer.render(Unknown Source)
at org.jmol.viewer.RepaintManager.render1(Unknown Source)
at org.jmol.viewer.RepaintManager.render(Unknown Source)
at org.jmol.viewer.Viewer.render(Unknown Source)
at org.jmol.viewer.Viewer.getImage(Unknown Source)
at org.jmol.viewer.Viewer.getScreenImage(Unknown Source)
at org.jmol.viewer.Viewer.renderScreenImage(Unknown Source)
at org.jmol.viewer.Viewer.renderScreenImage(Unknown Source)
at org.openscience.jmol.app.jmolpanel.DisplayPanel.paint(Unknown
Source)
at javax.swing.JComponent.paintToOffscreen(JComponent.java:5124)
at

javax.swing.BufferStrategyPaintManager.paint(BufferStrategyPaintManager.java:278)
at javax.swing.RepaintManager.paint(RepaintManager.java:1224)
at javax.swing.JComponent._paintImmediately(JComponent.java:5072)
at javax.swing.JComponent.paintImmediately(JComponent.java:4882)
at
javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:785)
at
javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:713)
at
javax.swing.RepaintManager.seqPaintDirtyRegions(RepaintManager.java:693)
at

javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run(SystemEventQueueUtilities.java:125)
at
java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
at

java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
at

java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
at

java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
rendering error?

Regards,
Rolf

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

--
Robert M. Hanson
Professor of Chemistry
St. Olaf College
1520 St. Olaf Ave.
Northfield, MN 55057
http://www.stolaf.edu/people/hansonr
phone: 507-786-3107

If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900

--------------------------------------------------------------------------

_______________________________________________
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

--
Robert M. Hanson
Professor of Chemistry
St. Olaf College
1520 St. Olaf Ave.
Northfield, MN 55057
http://www.stolaf.edu/people/hansonr
phone: 507-786-3107

If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

_______________________________________________
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

Re: [Jmol-users] Jmol -- two major advances

Reply via email to