H5Part development and discussion

[Wes Bethel <ewbethel AT lbl.gov>]

Hi,

I'm actually quite glad to see John B's note and comments. We had fully
expected some "growing pains" as others began to use H5part in new ways.

> 
> Achim could you please look at the 3 items/question and discuss this
> with the LBNL folks? Thanks
> 
>> Two H5Part items spring to mind
>> 1 : when reading (for example, position) arrays from file, one must
>> read X, then Y, then Z, copy them into a final {x,y,z} array, HDF5
>> should allow reading with strides so that a single read can place the
>> data into the array in the layout preferred. I will make some changes
>> to the H5Part API to support this. On a similar note, reading subsets
>> of data, or data where every N'th point is read should also be supported.

It would make more sense IMO for someone on the H5part team to implement
these features. That way, we can be sure to create new unit tests and
update the utility applications if need be. More broadly, we ought to
have some sort of overall strategy in mind as we move forward for
accepting changes from the community. This is a theme common across Open
Source projects.

>> 2 : There is no real support for other datatypes within the H5Part
>> API, the id,px,py,pz,x,y,z are hardcoded and the datatypes are preset.

May I ask for a clarification on this point? Does he mean, for example,
that he wants, say, int's rather than double's for px,py,pz, etc.?

>> 3 : The H5Part format is really not very general purpose - storing SPH
>> data and DEM data in there is requiring me to add various methods to
>> the API.

The original API was tailored to storing/retrieving particles. Work is
underway to add support for structured meshes and should be operational
later this summer or early this fall. On the horizon are plans to add
support for unstructured meshes and geometry, as well as support for
adaptive structured meshes. This work probably won't appear for another
12 months or so.

Thanks,
wes