Its main product is a library with four interface levels available for CGNS application developpers:
A CGNS/HDF5 file has an HDF5 layout that can be read or write by any application using MLL functions as well as CHLone functions. The resulting file you obtain using CHLone is the same as a file obtained using CGNS/MLL, the change is the actual implementation of the HDF5 function calls performed.
The features CHLone (CGNS HDF5 Library only node edition) wants to change or add comparing to MLL are:
- path-based retrieval of nodes
- thread-safe & multi-threading support
- no-buffer read/write, data read/write only if explicitely required
- full int32/int64/float32/float64/xxx support
- memory contiguous load/save of arrays
- optional checks (also remove useless extra checks)
- HDF5 physical driver independence
- test suites with coverage
The reason why CHLone has been developped is to provide the CGNS community with another way to build and check their files.
Today, the CGNS standard defines a data model for CFD and comes with a example implementation library, so-called the CGNS/MLL.
The data model is a tree composed of atomic nodes, the document so-called CGNS/SIDS is the specification for this data model which physical representation is made by means of a ‘mapping’. There are a SIDS-to-ADF mapping, SIDS-to-HDF5 and SIDS-to-Python. These mappings have actual implementations, these provide the users with functions calls that manipulates a single node or a sub-tree of nodes. The unique implementation of SIDS-to-ADF, SIDS-to-HDF5 and SIDS-to-XML is the so-called CGNS/MLL, that stands for Mid-Level Library.
There is no other implementation, thus the only way to be sure your data is CGNS/SIDS compliant is the fact that you can read and write it using CGNS/MLL. CHLone wants to dissociate the compliance to the use of CGNS/MLL.
The CHLone library is not better than the CGNS/MLL library, it is something different.