[Users] meeting minutes for 2015-08-31

[Roland Haas]

Hello all,

> So far the workflow was different. You don't register variables to be
> output. You register variables, and the output thorns decide what gets
> output (using parameters). This seems cleaner to me, better separated.
> If this mechanism is missing something, we could think about adding it.
> What I can think of immediately are two things:
> 
> - provide a way to specify 'column names' for each variable
>   This could either be done via tags, and/or via a new CCTK function
>   if we think we need to change this at runtime
> - provide a way to specify validity of a variable - such that invalid
>   data isn't output (by default)
>   Designing this might be a little harder. We should avoid extra calls
>   just for this. One possibility would be an extra "valid" state for
>   each variable. But that doubles the number of variables and wouldn't
>   work for arrays anyway where only part of it might be valid, and part
>   is not. Leaving arrays aside for a moment, and assuming we would leave
>   the default of this 'state' to 'valid', we could provide a CCTK call
>   for thorns to specify that certain variables do not contain valid data
>   at a given time step. This would be collected as list (of variable
>   ids), and can be used by output thorns.
Would it already be sufficient to have a thorn IOHDF5Timeseries which
provides another output method (along with IOASCII, IOHDF5 and IOScalar)
that writes variables as time-series ie. extensible HDF5 datasets with
the first dimension being time? If given an option like
one_file_per_group it would combine all scalars in a group into
different columns of the output dataset. It would not be able to write
grid functions (or slices of them) since their extent can change during
the simulation but it would be able to write SCALARs and ARRAYS as well
as 0d data. The thorn would write one HDF5 dataset per Cactus variable.
This would mean that the new output method behaves very much like the
current ones and is more or less the equivalent CarpetIOASCII's compact
output format which works decently well for ASCII timeseries output.

Yours,
Roland

-- 
My email is as private as my paper mail. I therefore support encrypting
and signing email messages. Get my PGP key from http://keys.gnupg.net.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
Url : http://lists.einsteintoolkit.org/pipermail/users/attachments/20150902/a7d9907f/attachment.bin