Hello, Recently I have been converting most of my scientific data to the HDF5 format. HDF5 is a powerful, high performance data format library. I found an absolutely wonderful open source code, PyTables, which provides an HDF5 interface. It adds enormous value to HDF5 by making it much easier to use, and exposing a lot of the complex functionality that HDF5 supports (such as variable-length records). http://www.pytables.org/moin I would really appreciate it if you guys would consider adding PyTables. I would definitely convert a lot of my existing extensions and processing tools to use PyTables- for example, when I analyze trajectories to find hydrogen bond data and use that to render long movies, PyTables makes it a lot easier (I already used the Chimera headers to build my own copy of PyTables on Linux, but it would be a lot more painful to do on Windows). PyTables depends on numarray (although it also provides Numeric Python support). I'd like to see numarray in Chimera as well (although I could live with just Numeric support) Dave
On 4/3/06, David E. Konerding <dekonerding@lbl.gov> wrote:
Hello,
Recently I have been converting most of my scientific data to the HDF5 format. HDF5 is a powerful, high performance data format library. I found an absolutely wonderful open source code, PyTables, which provides an HDF5 interface. It adds enormous value to HDF5 by making it much easier to use, and exposing a lot of the complex functionality that HDF5 supports (such as variable-length records).
I would really appreciate it if you guys would consider adding PyTables. I would definitely convert a lot of my existing extensions and processing tools to use PyTables- for example, when I analyze trajectories to find hydrogen bond data and use that to render long movies, PyTables makes it a lot easier (I already used the Chimera headers to build my own copy of PyTables on Linux, but it would be a lot more painful to do on Windows).
Actually windows is pretty much binary compatible, so just download the tables-1.3.win32-py2.4.exe and copy the module into chimera's site-packages folder. I have done this with numpy and matplotlib. You'll have to also get the hdf5 just as if you were normally installing on windows. Info found here, http://www.pytables.org/docs/manual/x457.html .
PyTables depends on numarray (although it also provides Numeric Python support). I'd like to see numarray in Chimera as well (although I could live with just Numeric support)
PyTables also supports numpy now, which is the new agreed pyarray package. I have been using numpy in chimera with no problems. The one hitch on OSX is that numpy and Numeric can't be imported in the same script (complaints about multiarray.so). It's not a problem on other platforms. I believe I made an informal request on the dev list to migrate completely from Numeric to numpy, but this probably doesn't make sense until the numpy 1.0 release. Actually the OSX issue brings up another feature request. I have a plugin that creates a surface as seen in, http://www.cgl.ucsf.edu/chimera/docs/ProgrammersGuide/Reference/surface.html . Could this approach please support float32 numpy arrays as well? I have to do a numpy->Numeric hack in windows/linux, but I can't do this in OSX due to the import issue. Thanks, Charlie
Hi Dave, I've been asked about HDF5 support in Chimera from Matt Dougherty who handles large volume data sets. He was investigating using it and I'm not sure if he adopted it for his data analysis. But that may be another use of HDF5 in Chimera. Tom
Hi Charlie, Currently Chimera uses Numeric and not numarray or Numpy. I write my own Python wrappers for our Chimera C++ code that uses Numeric for volume data because our wrapping program (wrappy) does not handle this. So it is some work to switch to Numpy, and I am unlikely to do so until it is absolutely clear that Numpy is superceding Numeric and numarray. What is the multiarray.so error on OSX when you use Numeric and Numpy? If there is a shared library conflict, then I probably will have the same trouble if our C++ code tries to support reading both formats for surfaces. Tom
On 4/3/06, Thomas Goddard <goddard@cgl.ucsf.edu> wrote:
Hi Charlie,
Currently Chimera uses Numeric and not numarray or Numpy. I write my own Python wrappers for our Chimera C++ code that uses Numeric for volume data because our wrapping program (wrappy) does not handle this. So it is some work to switch to Numpy, and I am unlikely to do so until it is absolutely clear that Numpy is superceding Numeric and numarray.
What is the multiarray.so error on OSX when you use Numeric and Numpy? If there is a shared library conflict, then I probably will have the same trouble if our C++ code tries to support reading both formats for surfaces.
import numpy import Numeric Traceback (most recent call last): File "<pyshell#3>", line 1, in ? import Numeric File "/Applications/Chimera.app/Contents/Resources/lib/python2.4/site-packages/Numeric/Numeric.py", line 91, in ? import multiarray SystemError: dynamic module not initialized properly
They both work fine when used separately. I have no clue what OSX does differently to bring this up.
Hi Charlie, The error when importing numpy and Numeric on Mac OSX is something to be solved by the numpy developers. When NumPy 1.0 comes out we will look at switching Chimera to use it. If we switch we will drop Numeric support. Chimera uses about 25 third-party Python modules and maintaining them takes time away from developing new features. The main consideration will be that NumPy is the most reliable, stable, trouble-free solution. Tom
Date: Mon, 3 Apr 2006 20:25:51 -0400 From: "Charlie Moad" <cwmoad@gmail.com> To: "Thomas Goddard" <goddard@cgl.ucsf.edu> Subject: Re: [Chimera-users] Please consider adding PyTables to Chimera Cc: chimera-users@cgl.ucsf.edu
import numpy import Numeric Traceback (most recent call last): File "<pyshell#3>", line 1, in ? import Numeric File "/Applications/Chimera.app/Contents/Resources/lib/python2.4/site-packages/Numeric/Numeric.py", line 91, in ? import multiarray SystemError: dynamic module not initialized properly
They both work fine when used separately. I have no clue what OSX does differently to bring this up.
participants (3)
-
Charlie Moad -
David E. Konerding -
Thomas Goddard