This is a proposal for a new <dataset> element. It is intended to collect all fields using a single mesh and provide a place to attach files that include multiple fields on a mesh such as VTK files. With this usage, fields can no longer contain multiple components. Essentially, what used to be called components are now separate fields in a dataset (so that dataset fills the role that field used to). However, if fields (nee components) have different meshes, they must be placed in different datasets.

<dataset>

A <dataset> object represents a set of fields defined over a mesh. The mesh is usually a collection of points in space, but it can also represent points in energy, momentum, etc. The mesh is a separate <mesh> object. Each field is a separate <field> object.

    <dataset>
        <about>
            <label>My Data Set</label>
        </about>
        <mesh ref="output.mymesh" />
        <field ref="output.field1" />
        <field ref="output.field2" />
        <field id="field3">
          <about>
            <label><label>
            <description></description>
          </about>
          <units></units>
          <association></association>
          <elemtype></elemtype>
          <elemsize></elemsize>
          <values>...</values>
        </field>
    </dataset>

<about><label>

This is the label for the output.

<about><description>

This is the description of the output. It is revealed when the user hovers over the output in the drop-down list.

<mesh>

Specifiy the mesh element name over which the fields are defined. The mesh can be defined inline, or as a separate <mesh> object by using a "ref" attribute. If given inline, the mesh element should have an "id" attribute.

<field>

Specify a field belonging to the dataset. The field is defined over the mesh specified by <mesh>. The field may be contained in a separate <field> object by using a "ref" attribute, or inline with an "id" attribute. Fields can also be defined with association 'fielddata', in which case the field is simply an array of tuples with no mesh topology. If one of the alternatives below are used, a field element may be used (with id matching the field id in the file data) to specify additional metadata such as units, label and description.

Alternative to <mesh> and <field> elements:

<dx>

Specify a DX file inline containing the mesh and fields. Deprecated.

<vtk>

Specify a VTK file inline containing the mesh and fields.

<dicom>

Specify a path to a DICOM dataset.

<ucd>

Specify a ucd file inline containing the mesh and fields.

Issues

• Should <mesh> and <field>s be given inline? Should we support referencing external mesh/fields with something like an attribute: <mesh ref="output.mymesh" />? This might make it easier to transition and be backwards compatible.
• To implement views, it may be necessary to divide outputs into data outputs and view outputs:

    <run>
      <tool />
      <input />
      <output>
        <data>
          <dataset><vtk>...</vtk></dataset>
          ...
        </data>
        <views>
          <view>...</view>
          ...
        </views>
      </output>
    </run>
  

  Or perhaps views should exist at the level of inputs/outputs? In any case, going forward data and view representations should be kept separate. We can define default views for data outputs, but we shouldn't have hybrid objects that contain both the data and the view properties for a view of the data.