[Users] meeting minutes for 2015-08-31

[Ian Hinder]

On 31 Aug 2015, at 17:53, Roland Haas <rhaas at aei.mpg.de> wrote:

> writing timeseries data into hdf5:
> * Frank would like to use this for things like the Hamiltonian norm
> * HDF5 supports extensible datasets, an example on how to use this is
>  the HDF5 output of Multipole

I have thought about this a fair amount before.  Many thorns use their own output routines because Cactus does not provide what they need.  The Cactus output methods are designed to output grid variables and grid arrays, but many thorns would like to output tables of data which do not correspond to Cactus variables.  For example, AHFinderDirect and Multipole.  PunctureTracker handles this by creating Cactus variables for its data.  The down-side to this is that all the "trackers" are always output, leading to a very large number of columns in the ascii output, making it impossible for a human to understand without tedious column-counting.  Multipole cannot use this mechanism, because it wants to write ascii files with different names for different l,m,r,var combinations.  It could use a 5-dimensional grid array for this, but this would be very wasteful, and also impossible for humans to read.  HDF5 output of grid arrays is very immature, and rarely does what you want (e.g. it usually creates one dataset per iteration, making reading the file very tedious).

Instead, I think there should be a Cactus mechanism for outputting "tables" of data to "files".  These tables would have named "columns", and the "files" could be real ASCII files, or extensible datasets in HDF5 files.  The "rows" of the tables would correspond to output iterations.  The data would not have to correspond to Cactus variables.  Output would happen via aliased function calls.  Probably we would have an initial call to "register" the output table, and subsequent calls to add to it.  Whether the output happens via ascii or hdf5 should be transparent to the application code, controlled just by an option somewhere (either in the application, maybe a parameter, similar to how the interpolator options are handled).  

Such a system would allow a fair amount of duplicated code and logic to be eliminated, and provide nice clean consistent output files across all thorns that need them.  This would also simplify parsing of these files by analysis tools, as the formats would be guaranteed to be the same.

-- 
Ian Hinder
http://members.aei.mpg.de/ianhin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.einsteintoolkit.org/pipermail/users/attachments/20150902/f8db5958/attachment.html