[Gmsh] gmsh datafile format

[Geordie McBain]

2010/9/14 Dalton Harvie <daltonh at unimelb.edu.au>:
> Dear Christophe,
>
> I've been using gmsh for a few months now and am a big fan.
>
> I've built a new FV solver that uses the gmsh datafile format for output and storage/reuse purposes (will be released soon under the GNU GPL).
>
> As well as spatially varying data, I want to include scalar, vector and tensor values that have no spatial location in this file.  I've been using the following $Data/$EndData statements in the files to do this, for example for a scalar:
>
> $Data
> 1
> "<C_lift>"
> 0
> 3
> 0
> 1
>     1
>     1      -0.156993E-02
> $EndData
>
> gmsh doesn't complain about these statements.  The integer tags are the same as for other kinds of data - timestep, number of components (1, 3 or 9), number of data statements (=1).
>
> Are you interested in incorporating something like this into the file specification?  Do you have plans to be able to handle non-spatial data in gmsh?

I second this feature-request.

Of course, such blocks are silently accepted according to the current
specification: `Any section with an unrecognized header is simply
ignored' (9.1 MSH ASCII file format), but it might be nice to be able
to access these values for postprocessing; e.g. one might read the
thermal conductivity as a single scalar and multipy it by -1 and a
vector field representing a temperature gradient to get the Fourier
heat conduction flux vector field, or one might read a gravitational
field as a single vector and use it to add back the hydrostatic
component of pressure to the reduced pressure often used in
incompressible fluid mechanics.

Also, if one had an unspatial block like this, it would be a natural
place to put such values as the result of the Integrate plug-in.
Currently this value, which naturally does not vary in space, is
attached to a single fictitious node.