Re: [Jmol-users] Jmol -- two major advances
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
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 --
Re: [Jmol-users] Jmol -- two major advances
On 04/07/2010 02:10 PM, Robert Hanson wrote: 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. I repeated it with a filename (I thought without one the application would ask for one in a file select box, but I remember now that a question mark is needed for that) and now only got the following error message: java.lang.ArrayIndexOutOfBoundsException rendering error? The image was written but it looks distorted: http://www.fli-leibniz.de/ImgLibPDB/tmp/1m4x-biol_unit-full-distorted.png It should look like this one (generated with C-alpha only): http://www.fli-leibniz.de/ImgLibPDB/thumbnail/manual/1m4x.pdb1_small.gif 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
Re: [Jmol-users] Jmol -- two major advances
Rolf, I think what's happening is that the image is too complex. There is a 2-second timeout on the refreshing request, and that is done right before the image is created. So in general, displays take less than 2 seconds, and we have no problem. But if a display takes more than 2 seconds, Jmol ignores the hold and continues -- this was important because in certain situations Jmol would make a request to the operating system for a repaint, and it would not be returned for some reason. I'm not saying I really understand it. But that timeout on the rendering wait fixes that. I believe it would work if you did this as a command line job with the -ion flags set (silent, no console, no display). With no display there won't be any rendering request. Please do try that. Bob On Wed, Apr 7, 2010 at 7:59 AM, Rolf Huehne rhue...@fli-leibniz.de wrote: On 04/07/2010 02:10 PM, Robert Hanson wrote: 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. I repeated it with a filename (I thought without one the application would ask for one in a file select box, but I remember now that a question mark is needed for that) and now only got the following error message: java.lang.ArrayIndexOutOfBoundsException rendering error? The image was written but it looks distorted: http://www.fli-leibniz.de/ImgLibPDB/tmp/1m4x-biol_unit-full-distorted.png It should look like this one (generated with C-alpha only): http://www.fli-leibniz.de/ImgLibPDB/thumbnail/manual/1m4x.pdb1_small.gif 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 -- 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
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? 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. --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
Re: [Jmol-users] Jmol -- two major advances
On 04/07/2010 03:26 PM, Charles Shubert 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%? Actually there are 36 cores running at pulsating rates with a total average of 2400%. Unfortunately only until all the required memory is acquired (presumably until actual file loading is finished). 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
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? no - 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 hans...@stolaf.edu *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.dewrote: 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)
Re: [Jmol-users] Jmol -- two major advances
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? no - 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
Re: [Jmol-users] Jmol -- two major advances
On 04/07/2010 05:37 PM, Robert Hanson wrote: 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? no So how do you explain the obvious multi-threading during file loading? While loading 1m4x the multi-threading pulses are rather short at the beginning (1-2 sec) and then 10 sec or more single-threading, but increasing up to about 30 sec later. 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
Re: [Jmol-users] Jmol -- two major advances
I'm not surprised about this. The multi-threading in loading the file probably is in either Java's file handling or the operating system's file system. Most non-gaming higher level software with a modern user interface really doesn't do enough intensive computation to justify making the software thread safe. Times seem to be changing, however. --Chuck - Original Message - From: Rolf Huehne rhue...@fli-leibniz.de To: jmol-users@lists.sourceforge.net Sent: Wednesday, April 07, 2010 12:13 PM Subject: Re: [Jmol-users] Jmol -- two major advances On 04/07/2010 05:37 PM, Robert Hanson wrote: 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? no So how do you explain the obvious multi-threading during file loading? While loading 1m4x the multi-threading pulses are rather short at the beginning (1-2 sec) and then 10 sec or more single-threading, but increasing up to about 30 sec later. 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 -- 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
Which version of Jmol does creating isosurfaces progressively? I may have a little time next week to take a look at the code. Jmol 11.9 -- aka 12.0.RCx We have a couple of interfaces, and I could give you a quick rundown, but not on the users list, probably. I'll send you a note off-list Bob -- 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
Bob, On Wed, Apr 7, 2010 at 5:37 PM, Robert Hanson hans...@stolaf.edu wrote: 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. How is a Jmol view (Image) currently calculated? Wasn't this done pixel by pixel (that's what I remember, but I might be mixing up things)? Would it then not be possible to divide the Image into 2 parts and calculate each in 2 threads (etc)? Egon -- Post-doc @ Uppsala University Proteochemometrics / Bioclipse Group of Prof. Jarl Wikberg Homepage: http://egonw.github.com/ Blog: http://chem-bla-ics.blogspot.com/ PubList: http://www.citeulike.org/user/egonw/tag/papers -- 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
On Wed, Apr 7, 2010 at 12:43 PM, Egon Willighagen egon.willigha...@gmail.com wrote: Bob, On Wed, Apr 7, 2010 at 5:37 PM, Robert Hanson hans...@stolaf.edu wrote: 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. How is a Jmol view (Image) currently calculated? Wasn't this done pixel by pixel (that's what I remember, but I might be mixing up things)? Would it then not be possible to divide the Image into 2 parts and calculate each in 2 threads (etc)? OK, so that's another possibility. You have to go through all the shapes, of course, with both processors, and I'm not clear how you would exactly do that, but I suppose you could somehow cut it apart some way like that. More probably what you would do is, say, have all the cartoons rendered by one and all the spacefill by another, etc. Then merge the components. I'd have to think about how that would work in terms of translucency. For example, we don't sort the translucent objects to make an approximate order that I think is necessary for OpenGL (trading pixel-by-pixel accuracy for object-by-object accuracty). It's been a while since I thought about that. Instead we use a base plane buffer and a translucent buffer and then do the pixel ordering pixel by pixel. Either way there are trade-offs. This was easier on memory and faster. Still, I suppose this might work with multiple threads. yes, that could work Bob Egon -- Post-doc @ Uppsala University Proteochemometrics / Bioclipse Group of Prof. Jarl Wikberg Homepage: http://egonw.github.com/ Blog: http://chem-bla-ics.blogspot.com/ PubList: http://www.citeulike.org/user/egonw/tag/papers -- 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 -- 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
[Jmol-users] Live 3D Jmol in PDF files
At various times there has been lively discussion on this list about the prospects of having live 3D Jmol in PDF files. No, it's still not possible. But I thought I would put together a little PDF that shows that you don't need to have that capability to do effectively the same thing (at least on websites). http://chemapps.stolaf.edu/jmol/docs/examples-11/data/live3DJmol.pdf Obvious limitations: -- not transportable. -- still requires a number of files. Bob -- 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] Live 3D Jmol in PDF files
Bob, Very interesting. I quite agree that pdf files with U3D become very big very fast. It seems to me this would also work for a downloaded pdf file if you included the full path in the link? I.e. if I open the downloaded pdf in a browser, shouldn't clicking on the picture take me to your website? One thought, wouldn't the .epub files be a more natural environment for Jmol? It's partly xhtml based, but can be made to look much like a pdf file (though I am not sure how). Jan Robert Hanson hans...@stolaf.edu skrev: At various times there has been lively discussion on this list about the prospects of having live 3D Jmol in PDF files. No, it's still not possible. But I thought I would put together a little PDF that shows that you don't need to have that capability to do effectively the same thing (at least on websites). http://chemapps.stolaf.edu/jmol/docs/examples-11/data/live3DJmol.pdf Obvious limitations: -- not transportable. -- still requires a number of files. Bob -- 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® 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 -- 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
