FiberVISH: HDF5 Chart Objects

Fiber Bundle HDF5 - Chart objects

A Chart is a group in the toplevel bundle group defining a collection of chart objects. A chart object is just a named reference point (like an anchor), which is used to allow detection of compatibility among various data groups. It also defines named types for Points, Vectors, Covectors, Metrices and similar data types.

Charts
  |
  \----> "Standard Cartesian Chart 3D"
          |
	  |---> typedef { float x, y, z;  } Point;	# HDF5 Type definition
	  |---> typedef { float Dx,Dy,Dz; } Vector;	# HDF5 Type definition
	  |---> typedef { float dx,dy,dz; } Covector;	# HDF5 Type definition
	  |
	[...]

In a forthcoming notation, also transformation rules will be specifable among chart objects.

Defining Coordinates in HDF5

Coordinates are defined via the information

dimension (2D, 3D, ...)
number type (float, double, complex, ...)
naming ("x", "y", "theta", "rho", ...)

This set of information is stored all together in an HDF5 named type. This data type is used for storing datasets in the specific coordinate system.

Example: The coordinate type of a point in cartesian 3D coordinates, represented via variables of type `float':

struct	Point { float x,y,z; }

Let Chart_id be the group Id of the corresponding char object. The accompanying HDF5 code for creating the Point type is then:

Point_hid_t = H5Tcreate(H5T_COMPOUND, 3*sizeof(float ) );

  H5Tinsert(Point_hid_t, "x", 0*sizeof(float), H5T_NATIVE_FLOAT );
  H5Tinsert(Point_hid_t, "y", 1*sizeof(float), H5T_NATIVE_FLOAT );
  H5Tinsert(Point_hid_t, "z", 2*sizeof(float), H5T_NATIVE_FLOAT );

H5Tcommit(Chart_id, "Point", Point_hid_t);

Other derived types are: Vector, Covector and Metric . Arbitrary geometric objects (tensors beeing a special case of them) can be defined on the tangential space. Their definition is derived from the definition of a point, whereby vectors have a leading `D' in their name:

Vector_hid_t = H5Tcreate(H5T_COMPOUND, 3*sizeof(float ) );

  H5Tinsert(Vector_hid_t, "Dx", 0*sizeof(float), H5T_NATIVE_FLOAT );
  H5Tinsert(Vector_hid_t, "Dy", 1*sizeof(float), H5T_NATIVE_FLOAT );
  H5Tinsert(Vector_hid_t, "Dz", 2*sizeof(float), H5T_NATIVE_FLOAT );

H5Tcommit(Chart_id, "Vector", Vector_hid_t);

and covectors a leading `d':

Covector_hid_t = H5Tcreate(H5T_COMPOUND, 3*sizeof(float ) );

  H5Tinsert(Covector_hid_t, "dx", 0*sizeof(float), H5T_NATIVE_FLOAT );
  H5Tinsert(Covector_hid_t, "dy", 1*sizeof(float), H5T_NATIVE_FLOAT );
  H5Tinsert(Covector_hid_t, "dz", 2*sizeof(float), H5T_NATIVE_FLOAT );

H5Tcommit(Chart_id, "Covector", Covector_hid_t);

In general, covariant (lower) indices are denoted via a lower case `d', kontravariant (upper) indices via an upper case `D' preceding the coordinate name. Thus "Dxdy" denotes the A^x_y component of a tensor. Antisymmetric tensors (which require less storage space) may be denoted eg. via "dx^dy", and symmetric ones can be abbreviated via direct concatenation of the coordinate names, thus definining the components of the metric as "dxx" (which means dx²). For cartesian coordinates the resulting HDF5 (including memory location) type is:

"dxx"              +0    native float
"dxy"              +4    native float
"dxz"              +8    native float
"dyy"              +12   native float
"dyz"              +16   native float
"dzz"              +20   native float

Given two indices i and j, the location of the element g_ij in memory is given by i*DIM + j (DIM beeing the dimension of the tangential space, e.g. DIM=3). The entire size is given by DIM*(DIM+1)/2, thus the metric in three dimension occupies 6 elements.

See the <A href=examples.html::SWmetric">Schwarzschild metric as an example for data given in two coordinate systems (cartesian and polar).

Extensions and Restrictions

The naming notation has not yet been reviewed for application to arbitrary mixtures of symmetric and antisymmetric covariant and contravariant indices. An interesting example would be the formulation of the Riemann tensor of rank four, but due to symmetries only 20 components need to be stored.
The naming notation has not yet been reviewed for non-tensor indicable objects like the Christoffel symbols. Maybe the introduction of other letters than `d' and `D' is recommendable here.
The native type (`float' in the above example) is inherited from the base space (coordinate type) and kept identical for all objects in the tangential space. An advanced implementation could be more flexible here and allow arbitrary mixtures of eg. floats and doubles in tensores. (Is there really a demand for such flexibility?)
The ordering of the elements needs to be as specified here; an advanced implementation could use the names of the members to enable automatic type conversion among different layouts.