<html>#2543: Consolidate data formats to simplify postprocessing
<table style='border-spacing: 1ex 0pt; '>
<tr><td style='text-align:right'> Reporter:</td><td>Wolfgang Kastaun</td></tr>
<tr><td style='text-align:right'> Status:</td><td>new</td></tr>
<tr><td style='text-align:right'>Milestone:</td><td></td></tr>
<tr><td style='text-align:right'> Version:</td><td>development version</td></tr>
<tr><td style='text-align:right'> Type:</td><td>enhancement</td></tr>
<tr><td style='text-align:right'> Priority:</td><td>minor</td></tr>
<tr><td style='text-align:right'>Component:</td><td></td></tr>
</table>
<p>Comment (by Erik Schnetter):</p>
<p>The idea is to have one such metafile per output directory. I’ll have to think about the one-file-per-iteration setup, it does seem wasteful and inconvenient. There certainly won’t be one file per node, things would be aggregated.</p>
<p>If you like the design for CarpetX, then we can repeat it for Carpet (or, rather, CactusBase/IOUtil) and use it for all simulations. I’m sure we’ll have to iterate on the design, and then flush out a few bugs where the design doesn’t make sense or is too limited.</p>
<p>0D output etc. are already supported in the format. There is a key that specifies which directions of a variable is output: <code>[0,1,2]</code> is for 3D output, <code>[1]</code> is for output in the y direction, etc.</p>
<p>Yes, HDF5 is slow. That’s why I want to switch to ADIOS2. This format has essentially the same capabilities as HDF5 (blocks of data, arbitrary types, attributes, groups, etc.), but it properly separates metadata, and is parallel by design. It’s also safe to append to an ADIOS2 file (internally data are separated into “iterations” which cannot be modified once written).</p>
<p>--<br/>
Ticket URL: <a href='https://bitbucket.org/einsteintoolkit/tickets/issues/2543/consolidate-data-formats-to-simplify'>https://bitbucket.org/einsteintoolkit/tickets/issues/2543/consolidate-data-formats-to-simplify</a></p>
</html>