pytables-users — PyTables users discussion list

Fwd: Re: [Pytables-users] writing pytables HDF files without python

[Francesc A. <fa...@op...>]

-- 
Francesc Alted

[Pytables-users] writing pytables HDF files without python

[<ho...@gl...>]

Dear List,

We have a customer who wants to feed some of our programs taking
pytables HDF files from a Fortran program. We managed together to add
the required attributes to make shure pytables does not complain, but
we now have the problem that the Fortran 90 HDF routines write=20

            ATTRIBUTE "CLASS" {
               DATATYPE  H5T_STRING {
                     STRSIZE 5;
                     STRPAD H5T_STR_SPACEPAD;
                     CSET H5T_CSET_ASCII;
                     CTYPE H5T_C_S1;
                  }                =20
               DATASPACE  SCALAR =20
               DATA {
                  "Array"
               }=20
            }=20

into the generated HDF5 file which leads to the error message

...
  File =
"/usr/local/fitools/sandbox/linux/lib/python2.2/site-packages/tables/Grou=
p.py", line 125, in _g_openFile
    objgroup._g_openFile()
  File =
"/usr/local/fitools/sandbox/linux/lib/python2.2/site-packages/tables/Grou=
p.py", line 144, in _g_openFile
    raise RuntimeError, \
RuntimeError: Dataset object in file is unknown!
                      class ID: Array=AF#@o

It seems pytables reads too much data and so gets garbage after the
wanted string. Could there be a workaround either on the Fortran or
the pytables side.

Thanks for your help.

Kind regards

Berthold H=F6llmann
--=20
Germanischer Lloyd AG
CAE Development
Vorsetzen 35
20459 Hamburg
Phone: +49(0)40 36149-7374
Fax: +49(0)40 36149-7320
e-mail: ho...@gl...
Internet: http://www.gl-group.com
=20
=20
=20
=20
****************************************************
=20
=20
Beachten Sie:  Wir moechten Sie informieren, dass die E-Mail-Adresse des =
Germanischen Lloyd sowie unsere Web-Adresse mit Wirkung vom 1. Maerz =
2003 auf den Namen gl-group.com umgestellt wurde.
=20
=20
Dies bedeutet, dass die bisherige Adresse Kur...@ge... =
durch die neue Adresse Kur...@gl... ersetzt wird. Die =
Homepage des GL ist kuenftig ueber die Adresse 'http://www.gl-group.com' =
aufrufbar. Die bisher verwendeten Adressen bleiben f=FCr eine =
Uebergangsfrist erreichbar.
=20
=20
****************************************************=20
=20
Please notice: We would like to inform you that the e-mail address of =
Germanischer Lloyd as well as our internet address had been changed to  =
gl-group.com with effect from 1st March 2003.
=20
=20
This means that the previous address sho...@ge... will be =
replaced by sho...@gl.... From now on the GL homepage can be =
accessed at the address 'http://www.gl-group.com'. The old addresses =
remain valid for a transitional period.
=20

=20
=20
****************************************************
=20
=20
=20
=20
This e-mail contains confidential information for the exclusive =
attention of the intended addressee. Any access of third parties to this =
e-mail is unauthorised. Any use of this e-mail by unintended recipients =
such as copying, distribution, disclosure etc. is prohibited and may be =
unlawful. When addressed to our clients the content of this e-mail is =
subject to the General Terms and Conditions of GL's Group of Companies =
applicable at the date of this e-mail. =20
=20
GL's Group of Companies does not warrant and/or guarantee that this =
message at the moment of receipt is authentic, correct and its =
communication free of errors, interruption etc.=20
=20

=20

[Pytables-users] Re: slowness w/many groups in pytables

[Francesc A. <fa...@op...>]

Hi John,

A Dimecres 11 Juny 2003 19:45, vareu escriure:
> If I create a trivial set of data w/3000+groups, when opening for
> reading, pytables takes almost 30 seconds, on the command:
>

Well, 3000 groups is not too bad for an start :-)

> fileh=tables.openFile(Hdf_file)
>
> Should it take this long to build the metadata?

My tests (using a P4@2GHz w 256 MB & Linux) show that it takes roughly 4
seconds for 3000 groups and little more that 5 s for 3000 leafs (small
arrays in this case). So, I don't know about your machine, but it seems
like if it is somewhat slow. Anyway, the metainformation reading process can
surely be improved by converting the appropriate python code into Pyrex, but
I don't know if this is worth the effort.

>
> This implies you want to organize w/few groups and many tables.

I think that your best bet is to use as few groups and tables as you can and
create as large tables as possible. This is what pytables (and HDF5) is
optimized for. Even if you have to made some redundancies on table columns,
you can always activate the compression, so that in my opinion, this will
not affect the access perfomance or final file sizes very much (rather the
contrary).

Cheers,

-- 
Francesc Alted

Re: [Pytables-users] OS X intall problem

[Francesc A. <fa...@op...>]

Hi Gary!,

I have never tried to compile PyTables on MacOSX, but it would be nice to
include support for such a nice OS.

After googling a bit, I have found some clues about what may be happening=
=2E
The problem seems to be in the space on the architecture name ("Power
Macintosh-2.2"). Some people (Steve Graham) suggest to strip out this spa=
ce
with the next patch applied to the util.py file on the distuils package.
=46rom the original post:

> The patch is as follows:
> --- util.py     Tue Nov  5 01:29:27 2002
> +++ util.py.osx Tue Nov  5 01:26:22 2002
> @@ -67,6 +67,8 @@
>          m =3D rel_re.match(release)
>          if m:
>              release =3D m.group()
> +    elif osname[:6] =3D=3D "darwin":
> +       machine =3D machine.replace(' ','')
>
>      return "%s-%s-%s" % (osname, release, machine)
> ----end patch (don't include this in file)----
>
> You can patch util.py (after making a backup) like so:
>
> # cd /path/to/python/lib/distutils/
> # cp util.py util.py.orig
> # patch -u -p0 < patch_filename
>
> Where patch_filename is the file you save the patch into.
> If you don't want to use patch you can add the two line fix by hand :)
>
> This will cause the output_dir variable to be set to
> 'build/temp.darwin-6.3-PowerMacintosh-2.2/'
>
> I'm sure there is an easier way to set the build directory through opti=
ons
> in either setup.py or through the command line but I can't find any. Th=
is
> fix seemed to work for me.
>
> -Steve

Just apply this patch and try again. Tell me about your results, please, =
as
I would like to inform on other users about the right solution. It would =
be
nice if you find a more elegant solution (i.e. without need to apply a pa=
tch).

Luck!,

--=20
Francesc Alted

[Pytables-users] OS X intall problem

[Gary R. <gro...@tr...>]

I'm excited about pytables but am unable to install it on OS X.

When I do:

   python setup.py build_ext --inplace

I get the following output leading up to the failure:

> skipping src/H5LT.c (build/temp.darwin-6.3-Power Macintosh-2.2/H5LT.o
> up-to-date)
> skipping src/H5TB.c (build/temp.darwin-6.3-Power Macintosh-2.2/H5TB.o
> up-to-date)
> skipping src/H5TB-opt.c (build/temp.darwin-6.3-Power Macintosh-2.2/H5TB-opt.o
> up-to-date)
> gcc -arch i386 -arch ppc -bundle -flat_namespace -undefined suppress
> build/temp.darwin-6.3-Power Macintosh-2.2/hdf5Extension.o
> build/temp.darwin-6.3-Power Macintosh-2.2/calcoffset.o
> build/temp.darwin-6.3-Power Macintosh-2.2/arraytypes.o
> build/temp.darwin-6.3-Power Macintosh-2.2/getfieldfmt.o
> build/temp.darwin-6.3-Power Macintosh-2.2/utils.o build/temp.darwin-6.3-Power
> Macintosh-2.2/H5Zlzo.o build/temp.darwin-6.3-Power Macintosh-2.2/H5Zucl.o
> build/temp.darwin-6.3-Power Macintosh-2.2/H5ARRAY.o
> build/temp.darwin-6.3-Power Macintosh-2.2/H5LT.o build/temp.darwin-6.3-Power
> Macintosh-2.2/H5TB.o build/temp.darwin-6.3-Power Macintosh-2.2/H5TB-opt.o
> -L/usr/local/lib -Wl,-R/usr/local/lib -lhdf5 -o tables/hdf5Extension.so
> ld: for architecture i386
> ld: unknown flag: -R/usr/local/lib
> error: command 'gcc' failed with exit status 1

Any ideas???? I hope to use pytables in a project and I'm stuck until this
is resolved.



--Gary

-- 
<http://ThisURLEnablesEmailToGetThroughOverzealousSpamFilters.org>

Gary Robinson
CEO
Transpose, LLC
gro...@tr...
207-942-3463
http://www.transpose.com
http://radio.weblogs.com/0101454

Re: [Pytables-users] Maximum size of Array

[Francesc A. <fa...@op...>]

A Divendres 16 Maig 2003 12:58, v=E0reu escriure:
> > For images I think that a far better solution would be to use Array
> > objects.
> > If you need to save a lot of images, a group can host up to 4096 of
> > such
> > objects, but you can use more groups if you need them. Arrays are not
> > enlargeable right now, but for images this is not a problem.
>
> This looks good,
> I suppose I should check if there is a limit to the number of groups
> as well
> Cheers
> Ed

Yes, there is also a limit. In general, you can hang up to 4096 objects f=
rom
a group, and that includes datasets as well as other groups. There is als=
o a
limitation on how deep can go the tree, which is 512 levels right now (it
can't go much beyond 1000 because of limits on recursive deepness in
Python). By making your tree wider and deeper, you can in fact save a rea=
lly
*huge* number of objects on it, but be careful, because groups (datasets
also, but much less) takes memory (the metainformation), so, if the tree =
is
reasonably balanced, the limit is mainly imposed by the available memory =
on
your system, not because of PyTables limitations.

Cheers,

--=20
Francesc Alted

Re: [Pytables-users] Maximum size of Array

[Francesc A. <fa...@op...>]

A Divendres 16 Maig 2003 11:51, Edward Hartley va escriure:
>
> I am dealing with images and image feature sets so I was wanting to
> create storage
> for these. I naively thought a table row would be appropriate clearly
> it isn't.

For images I think that a far better solution would be to use Array objec=
ts.
If you need to save a lot of images, a group can host up to 4096 of such
objects, but you can use more groups if you need them. Arrays are not
enlargeable right now, but for images this is not a problem.

Cheers,

--=20
Francesc Alted

Re: [Pytables-users] Maximum size of Array

[Edward H. <ha...@co...>]

On Friday, May 16, 2003, at 12:17  pm, Francesc Alted wrote:

> A Divendres 16 Maig 2003 10:42, Edward Hartley va escriure:
>> However question was directed at finding the maximum size of a Column
>> entry in a row
>> not at the maximum number of rows.
>> I have found that the maximum size of an array entry in a group is
>> about 2**27 before the interpreter
>> cannot get any more memory on my machine with 128M swap.
>
> I don't fully understand what are you trying to mean, but it seems 
> like if
> you are trying to put big columns elements on a table. If so, as 
> PyTables
> uses a I/O buffer where the differents rows are putted there before 
> writing
> them to disk, it has a current limitation of rowsizes less than 600 KB 
> in
> size (mainly because of processor cache efficency reasons).
Many thanks this was the limit I have been hitting, 600kB seems 
reasonable
> Right now, I
> didn't realize that anybody would want more than that, because the 
> normal
> situation is to break down your data into small pieces that would form 
> the
> rows to be added.
>
I am dealing with images and image feature sets so I was wanting to 
create storage
for these. I naively thought a table row would be appropriate clearly 
it isn't.
> So, if you are willing to deal with very large row sizes, I would 
> recommend
> you to breakdown your row data into smaller chunks and then 
> reconstruct the
> data during table reading if you want to.
>
> Besides, if you are trying to use arrays of 2**27 elements, this means 
> 134
> millions, so, if your arrays are single-precisition floats, that 
> represents
> 134*4= 536 MB (!), which is just too much for your machine.
>
I agree on your assessment of the problems with dealing with objects of 
this size.
This was an exercise I conducted to find where the boundary was after 
finding that there
was a problem using table rows and does not represent a realistic case.

> However, you discovered a flaw on PyTables design in that it doesn't 
> check
> for row sizes bigger than the I/O buffer. I'll try to add that on the 
> CVS
> version and issue a warn to the user in case that happens.
>
Thats useful many thanks again
> Cheers,
>
> -- 
> Francesc Alted
>

Re: [Pytables-users] Maximum size of Array

[Francesc A. <fa...@op...>]

A Divendres 16 Maig 2003 10:42, Edward Hartley va escriure:
> However question was directed at finding the maximum size of a Column
> entry in a row
> not at the maximum number of rows.
> I have found that the maximum size of an array entry in a group is
> about 2**27 before the interpreter
> cannot get any more memory on my machine with 128M swap.

I don't fully understand what are you trying to mean, but it seems like i=
f
you are trying to put big columns elements on a table. If so, as PyTables
uses a I/O buffer where the differents rows are putted there before writi=
ng
them to disk, it has a current limitation of rowsizes less than 600 KB in
size (mainly because of processor cache efficency reasons). Right now, I
didn't realize that anybody would want more than that, because the normal
situation is to break down your data into small pieces that would form th=
e
rows to be added.

So, if you are willing to deal with very large row sizes, I would recomme=
nd
you to breakdown your row data into smaller chunks and then reconstruct t=
he
data during table reading if you want to.

Besides, if you are trying to use arrays of 2**27 elements, this means 13=
4
millions, so, if your arrays are single-precisition floats, that represen=
ts
134*4=3D 536 MB (!), which is just too much for your machine.

However, you discovered a flaw on PyTables design in that it doesn't chec=
k
for row sizes bigger than the I/O buffer. I'll try to add that on the CVS
version and issue a warn to the user in case that happens.

Cheers,

--=20
Francesc Alted

Re: [Pytables-users] Maximum size of Array

[Edward H. <ha...@co...>]

On Friday, May 16, 2003, at 11:02  am, Francesc Alted wrote:

> A Dijous 15 Maig 2003 19:52, Edward Hartley va escriure:
>> Hi
>> is there any limit in the HDF5 file layer on the size of table 
>> entries?
>
> To my understanding no (well, at least a practical limit). The number 
> of
> rows on datasets (a table is a special type of dataset) in HDF5 are of 
> type
> hsize_t which is bound to integers of 64 bits both in modern Unix and
> Windows. So, your tables can have up to 2**63 rows, which is something 
> like
> 1e19 (!).
>
Thanks my knowing this is usefull.
However question was directed at finding the maximum size of a Column 
entry in a row
not at the maximum number of rows.
I have found that the maximum size of an array entry in a group is 
about 2**27 before the interpreter
cannot get any more memory on my machine with 128M swap.
This is without a flush operation
Regards
Ed
> Cheers,
>
> -- 
> Francesc Alted
>
>
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux enterprise 
> solutions
> www.enterpriselinuxforum.com
>
> _______________________________________________
> Pytables-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pytables-users
>

Re: [Pytables-users] Maximum size of Array

[Francesc A. <fa...@op...>]

A Dijous 15 Maig 2003 19:52, Edward Hartley va escriure:
> Hi
> is there any limit in the HDF5 file layer on the size of table entries?

To my understanding no (well, at least a practical limit). The number of
rows on datasets (a table is a special type of dataset) in HDF5 are of ty=
pe
hsize_t which is bound to integers of 64 bits both in modern Unix and
Windows. So, your tables can have up to 2**63 rows, which is something li=
ke
1e19 (!).

Cheers,

--=20
Francesc Alted

[Pytables-users] Maximum size of Array

[Edward H. <ha...@co...>]

Hi
is there any limit in the HDF5 file layer on the size of table entries?

Regards
Ed
------------------------------------------------------------------------ 
---------------------------
------------------------------------------------------------------------ 
---------------------------
Ed Hartley								Tel  01524 593675
Researcher 								Fax 01524 593608
Computing Department
Lancaster University
LA1 4YW

Re: [Pytables-users] (no subject)

[Francesc A. <fa...@op...>]

A Dilluns 12 Maig 2003 14:21, Marc Gehling va escriure:
> Hello,
>
> when i start the second example tutorial2-1.py on win32, the example gi=
ve
> an error in line 21
>

I guess this is because the numarray Win32 version seems to not support t=
he
"UInt64" types. Please, on "tutorial1-1.py" substitute the line:

    idnumber  =3D Col("UInt64", 1)     # Unsigned long long=20

by

    idnumber  =3D Col("Int64", 1)     # Signed long long=20

and run again the tutorial1-1.py before running tutorial1-2.py. That shou=
ld
solve the problem. I'll try to address this problem on CVS.

Cheers,

--=20
Francesc Alted

[Pytables-users] (no subject)

[Marc G. <M.G...@gm...>]

Hello,

when i start the second example tutorial2-1.py on win32, the example give an
error in line 21


...
20 # Reopen the file in append mode
21 h5file = openFile(filename, "a")
....


-**-**-**-**- open the previous tutorial file -**-**-**-**-**-
Traceback (most recent call last):
  File "tutorial1-2.py", line 21, in ?
    h5file = openFile(filename, "a")
  File "C:\Python22\Lib\site-packages\tables\File.py", line 146, in openFile
    return File(path, mode, title, new, trMap)
  File "C:\Python22\Lib\site-packages\tables\File.py", line 210, in __init__
    self.root = self.__getRootGroup()
  File "C:\Python22\Lib\site-packages\tables\File.py", line 297, in
__getRootGroup
    root._g_openFile()
  File "C:\Python22\Lib\site-packages\tables\Group.py", line 125, in
_g_openFile
    objgroup._g_openFile()
  File "C:\Python22\Lib\site-packages\tables\Group.py", line 148, in
_g_openFile
    objgroup._g_putObjectInTree(name, self)
  File "C:\Python22\Lib\site-packages\tables\Leaf.py", line 83, in
_g_putObjectInTree
    self._open()
  File "C:\Python22\Lib\site-packages\tables\Table.py", line 284, in _open
    fields[self.colnames[i]] = Col(vartype, length, pos = i)
  File "C:\Python22\Lib\site-packages\tables\IsDescription.py", line 86, in
__init__
    raise TypeError, "Illegal type: %s" % `dtype`
TypeError: Illegal type: UInt64

i can view my tutorial1.h5 file with h5ls.exe. 

any help. 

------------------------------------
NT 4.00.1381
Python 2.2.2 on win32

table 0.5
numarray 0.5 win32
numeric 23 win32
zlib 114dll
lzo 1.08
--------------------------------

Marc Gehling
-- ps When you need my tutorial1.h5 file, i can send it to you.

-- 
+++ GMX - Mail, Messaging & more  http://www.gmx.net +++
Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage!

Re: [Pytables-users] Errors with tables 0.5 on win32

[Francesc A. <fa...@op...>]

Hello Marc,

You are right; the problem even happen with the Unix version. I had only
tested extensively pytables 0.5 against numarray 0.5, not 0.4. The proble=
m
is due to an optimization that works well for numarray 0.5, but not for 0=
=2E4.
I'll try to disable this optimization or enable some other cure. Meanwhil=
e,
you can install numarray 0.5 to make pytables to work correctly.

Thanks for the report,

A Dilluns 12 Maig 2003 10:20, Marc Gehling va escriure:
> when i start the example tutorial1-1.py on win32, the example stop in l=
ine
> 60 with error. ( Dr. Watson )
>
> ...
> 59   particle['pressure'] =3D float(i*i)
> 60   particle['energy'] =3D float(particle['pressure'] ** 4)
> 61   particle['idnumber'] =3D i * (2 ** 34)
> ....

--=20
Francesc Alted

[Pytables-users] Errors with tables 0.5 on win32

[Marc G. <M.G...@gm...>]

Hello,

when i start the example tutorial1-1.py on win32, the example stop in line
60 with error. ( Dr. Watson )

...
59   particle['pressure'] = float(i*i)
60   particle['energy'] = float(particle['pressure'] ** 4)
61   particle['idnumber'] = i * (2 ** 34)
....

my system
----------------------
NT 4.00.1381 german
Python 2.2.2 on win32

table 0.5
numarray 0.4 win32
numeric 23 win32
zlib 114dll
lzo 1.08
-------------------------

any help.

Marc Gehling

-- 
+++ GMX - Mail, Messaging & more  http://www.gmx.net +++
Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage!

Re: [Pytables-users] Support for Arrays in Tables

[Edward H. <ha...@co...>]

On Monday, April 14, 2003, at 12:56  pm, Francesc Alted wrote:

> A Dilluns 14 Abril 2003 13:28, Edward Hartley va escriure:
>> I have found another way to get around the issue by specifying the
>> shape in one field
>> class my_array(IsDescription):
>> 	array_ shape = Col('UInt8', shape)
>> 	ravelled_array=Col('UInt8' , data)
>> it occurs to me that with suitable accessor methods this would solve 
>> it
>> completely?
>
> Right. I've already thought implementing something similar to emulate
> transparently more than one-dimensional arrays as Table columns. 
> However,
> for a series of reasons, I prefer to wait until recarray objects 
> support
> that natively.
  I agree waiting for recarray support is appropriate
>
> Meanwhile, you can effectively deal with multimensional arrays in your
> suggested way.
>
agreed

Re: [Pytables-users] Support for Arrays in Tables

[Francesc A. <fa...@op...>]

A Dilluns 14 Abril 2003 13:28, Edward Hartley va escriure:
> I have found another way to get around the issue by specifying the
> shape in one field
> class my_array(IsDescription):
> =09array_ shape =3D Col('UInt8', shape)
> =09ravelled_array=3DCol('UInt8' , data)
> it occurs to me that with suitable accessor methods this would solve it
> completely?

Right. I've already thought implementing something similar to emulate
transparently more than one-dimensional arrays as Table columns. However,
for a series of reasons, I prefer to wait until recarray objects support
that natively.

Meanwhile, you can effectively deal with multimensional arrays in your
suggested way.

> many thanks once again

You are welcome!

BTW, I'm curious about the kind of applications that PyTables is being us=
ed.
May I ask which is yours?

--=20
Francesc Alted

Re: [Pytables-users] Support for Arrays in Tables

[Edward H. <ha...@co...>]

On Sunday, April 13, 2003, at 06:37  am, Francesc Alted wrote:

> A Dissabte 12 Abril 2003 17:43, Edward Hartley va escriure:
>>
Many thanks for the speedy reply
>> is there going to be  support for arrays in tabels
>> specifically what I'm trying to do is put arrays into
>> tables as leafs. I may be mistaken but I think this is
>> currently not supported but the creation of arrays from
>> table data is.
>
> I don't understand well your question. The Array and Table objects are 
> Leaf
> objects, so you can't have an Array with a Table as parent.
>
Sorry about my inaccuracy about the terminology
> However, Table do accept numarray arrays as columns elements in this 
> way:
>
> field = Col("Float32", 3)
>
yes I was aware of that
> where 3 means the number of elements of your array. 0.4 version only
> supports unidimensional arrays as elements, however. This is an actual
> limitation on numarray code, that will be removed soon (I hope).
>
Ah I hadn't realised
> Another possibility may be to use attributes to attach an array to a 
> Table
> object through the use of the setAttr() method available on Leaf 
> objects.
> Right now, only character attributes are supported, but by combining 
> them
> with cPikle, you can attach any object you may want to a Leaf.
>
This is interesting
I have found another way to get around the issue by specifying the 
shape in one field
class my_array(IsDescription):
	array_ shape = Col('UInt8', shape)
	ravelled_array=Col('UInt8' , data)
it occurs to me that with suitable accessor methods this would solve it 
completely?
many thanks once again
Ed Hartley


>
> -- 
> Francesc Alted
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of TotalView, The 
> debugger
> for complex code. Debugging C/C++ programs can leave you feeling lost 
> and
> disoriented. TotalView can help you find your way. Available on major 
> UNIX
> and Linux platforms. Try it free. www.etnus.com
> _______________________________________________
> Pytables-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pytables-users
>

Re: [Pytables-users] Support for Arrays in Tables

[Francesc A. <fa...@op...>]

A Dissabte 12 Abril 2003 17:43, Edward Hartley va escriure:
> Hi
> is there going to be  support for arrays in tabels
> specifically what I'm trying to do is put arrays into
> tables as leafs. I may be mistaken but I think this is
> currently not supported but the creation of arrays from
> table data is.

I don't understand well your question. The Array and Table objects are Le=
af
objects, so you can't have an Array with a Table as parent.

However, Table do accept numarray arrays as columns elements in this way:

field =3D Col("Float32", 3)

where 3 means the number of elements of your array. 0.4 version only
supports unidimensional arrays as elements, however. This is an actual
limitation on numarray code, that will be removed soon (I hope).

Another possibility may be to use attributes to attach an array to a Tabl=
e
object through the use of the setAttr() method available on Leaf objects.
Right now, only character attributes are supported, but by combining them
with cPikle, you can attach any object you may want to a Leaf.

Hope that helps,

--=20
Francesc Alted

[Pytables-users] Support for Arrays in Tables

[Edward H. <ha...@co...>]

Hi
is there going to be  support for arrays in tabels
specifically what I'm trying to do is put arrays into
tables as leafs. I may be mistaken but I think this is
currently not supported but the creation of arrays from
table data is.
Regards
Ed Hartley

Re: [Pytables-users] C/Fortran interface to pytables database?

[Francesc A. <fa...@op...>]

Hello!

A Dimecres 12 Febrer 2003 21:21, Jeff Whitaker va escriure:
> Can pytables data files be read in C/Fortran using the standard HDF5 AP=
I?

Yes, of course. PyTables only add some special attributes to the groups a=
nd
datasets, but you can happily bypass them when reading from C/Fortran. Th=
ese
attributes are metadata for the groups and datasets, like the title for e=
ach
dataset, the pytables version format, the kind of Python object saved the=
re,
and a few more.

In the coming version of PyTables (0.3), it will be able to read generic
HDF5 files created from C/Fortran/Java whenever they are arrays (homogene=
ous
datasets) or tables (heterogeneous data made from H5T_COMPOUND type). I h=
ope
to add support for more objects in the future, but with the existing
support, PyTables should be able to read the 95% of existing HDF5 files.

Cheers,

--=20
Francesc Alted

[Pytables-users] C/Fortran interface to pytables database?

[Jeff W. <js...@cd...>]

Can pytables data files be read in C/Fortran using the standard HDF5 API?

-Jeff

-- 
Jeffrey S. Whitaker         Phone : (303)497-6313
NOAA/OAR/CDC  R/CDC1        FAX   : (303)497-6449
325 Broadway                Web   : http://www.cdc.noaa.gov/~jsw
Boulder, CO, USA 80305-3328 Office: Skaggs Research Cntr 1D-124

[Pytables-users] Second test

[Francesc A. <fa...@op...>]

Hi, the sencond test

-- 
Francesc Alted                            PGP KeyID:      0x61C8C11F
Scientific aplications developer
Public PGP key available: http://www.openlc.org/falted_at_openlc.asc
Key fingerprint = 1518 38FE 3A3D 8BE8 24A0  3E5B 1328 32CC 61C8 C11F

[Pytables-users] This is a test

[Francesc A. <fa...@im...>]

This is a test. Ignore it.

-- 
He fet açò més llarg de lo habitual
per que no he tingut temps per a
fer-ho més curt.  -- Blaise Pascal