https://www.xdmf.org/api.php?action=feedcontributions&user=Dave.demarle&feedformat=atomXdmfWeb - User contributions [en]2024-03-29T08:21:28ZUser contributionsMediaWiki 1.39.3https://www.xdmf.org/index.php?title=User_talk:Jgflemin&diff=198User talk:Jgflemin2016-04-19T13:54:43Z<p>Dave.demarle: Welcome!</p>
<hr />
<div>'''Welcome to ''XdmfWeb''!'''<br />
We hope you will contribute much and well.<br />
You will probably want to read the [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents help pages].<br />
Again, welcome and have fun! [[User:Dave.demarle|Dave.demarle]] ([[User talk:Dave.demarle|talk]]) 09:54, 19 April 2016 (EDT)</div>Dave.demarlehttps://www.xdmf.org/index.php?title=User:Jgflemin&diff=197User:Jgflemin2016-04-19T13:54:43Z<p>Dave.demarle: Creating user page for new user.</p>
<hr />
<div>I am the Lead Developer and Operator for the ADCIRC Surge Guidance System (ASGS) (https://github.com/jasonfleming/asgs), a software automation system and collection of utilities for the finite element ADCIRC (ADvanced Circulation) coastal ocean model (http://www.adcirc.org). I implemented the i/o code in ADCIRC for natively reading and writing XDMF data files using the Fortran XDMF API. I've also created/maintain/extend standalone utility programs that convert to/from ADCIRC ascii file format to XDMF format using the Fortran XDMF API. Finally, I have created/maintain/extend standalone utility programs that generate XDMF-compliant XML files for ADCIRC's native NetCDF4 formatted output files, taking advantage of the fact that NetCDF4 uses the HDF5 library underneath to write the files. This results in a set of output files that simultaneously satisfies the NetCDF4, HDF5, and XDMF format standards. More information is available from http://www.seahorsecoastal.com.</div>Dave.demarlehttps://www.xdmf.org/index.php?title=XDMF_Model_and_Format&diff=196XDMF Model and Format2016-04-19T13:16:06Z<p>Dave.demarle: correct type</p>
<hr />
<div>[[Image:XdmfLogo1.gif]]<br />
<br />
Here the XDMF3 Model and Format is described.<br />
See [[Xdmf2 Model and Format Archive]] for the previous version.<br />
<br />
The need for a standardized method to exchange scientific data between High Performance Computing codes and tools lead to the development of ''the eXtensible Data Model and Format'' (''XDMF'').<br />
Uses for XDMF range from a standard format used by HPC codes to take advantage of widely used visualization programs like ParaView[https://www.paraview.org] and EnSight[https://www.ceisoftware.com], to a mechanism for performing coupled calculations using multiple, previously stand alone codes. <br />
<br />
XDMF categorizes data by two main attributes; size and function.<br />
Data can be ''Light'' (typically less than about a thousand values) or ''Heavy'' (megabytes, terabytes, etc.).<br />
In addition to raw values, data can refer to ''Format'' (rank and dimensions of an array) or ''Model'' (how that data is to be used. i.e. XYZ coordinates vs. Vector components).<br />
<br />
XDMF uses XML to store Light data and to describe the data Model.<br />
Either HDF5[https://www.hdfgroup.org/HDF5] or binary files can be used to store Heavy data.<br />
The data Format is stored redundantly in both XML and HDF5.<br />
This allows tools to parse XML to determine the resources that will be required to access the Heavy data. <br />
For the binary Heavy data option, the xml must list a filename where the binary data is stored.<br />
<br />
While not required, a C++ API is provided to read and write '''XDMF''' data. This API has also been wrapped so it is available from popular languages like Python, Tcl, and Java.<br />
The API is not necessary in order to produce or consume XDMF data.<br />
Currently several HPC codes that already produced HDF5 data, use native text output to produce the XML necessary for valid XDMF. <br />
<br />
==XML==<br />
<br />
The eXtensible Markup Language (XML) format is widely used for many purposes and is well documented at many sites.<br />
There are numerous open source parsers available for XML.<br />
The XDMF API takes advantage of the libxml2 parser to provide the necessary functionality.<br />
Without going into too much detail, XDMF views XML as a "personalized HTML" with some special rules.<br />
It it case sensitive and is made of three major components: elements, entities, and processing information.<br />
In XDMF the '''element''' is the most important component.<br />
Additionally XDMF takes advantage of two major extensions to XML: '''XInclude''' and '''XPath'''.<br />
<br />
===Elements===<br />
Elements follow the basic form:<br />
<br />
&lt;ElementTag<br />
AttributeName="AttributeValue"<br />
AttributeName="AttributeValue"<br />
... &gt;<br />
''CData''<br />
&lt;/ElementTag&gt;<br />
<br />
<br />
Each element begins with a &lt;tag&gt; and ends with a &lt;/tag&gt;.<br />
Optionally there can be several "Name=Value" pairs which convey additional information.<br />
Between the &lt;tag&gt; and the &lt;/tag&gt; there can be other &lt;tag&gt;&lt;/tag&gt; pairs and/or character data (CData).<br />
CData is typically where the values are stored; like the actual text in an HTML document.<br />
The XML parser in the XDMF API parses the XML file and builds a tree structure in memory to describe its contents.<br />
This tree can be queried, modified, and then "serialized" back into XML.<br />
<br />
Comments in XML start with a "&lt;!--" and end with a "--&gt;". So &lt;!--This is a Comment --&gt;.<br />
<br />
XML is said to be "well formed" if it is syntactically correct.<br />
That means all of the quotes match, all elements have end elements, etc.<br />
XML is said to be "valid" if it conforms to the ''Schema'' or ''DTD'' defined at the head of the document.<br />
For example, the schema might specify that element type A can contain element B but not element C.<br />
Verifying that the provided XML is well formed and/or valid are functions typically performed by the XML parser.<br />
<br />
<br />
===XInclude===<br />
As opposed to entity references in XML (see below), XInclude allows for the inclusion of files that are not well formed XML.<br />
This means that with XInclude the included file could be well formed XML or perhaps a flat text file of values. The syntax looks like this :<br />
<br />
'''&lt;Xdmf Version="2.0" xmlns:xi="<nowiki>[http://www.w3.org/2001/XInclude]</nowiki>"&gt;'''<br />
'''&lt;xi:include href="Example3.xmf"/&gt;'''<br />
'''&lt;/Xdmf&gt;'''<br />
<br />
the xmlns:xi establishes a namespace xi. Then anywhere within the Xdmf element, xi:include will pull in the URL.<br />
<br />
===XPath===<br />
This allows for elements in the XML document and the API to reference specific elements in a document.<br />
For example:<br />
<br />
The first Grid in the first Domain<br />
'''/Xdmf/Domain/Grid'''<br />
The tenth Grid .... XPath is one based.<br />
'''/Xdmf/Domain/Grid<nowiki>[</nowiki>10<nowiki>]</nowiki>'''<br />
The first grid with an attribute ''Name'' which has a value of ''"Copper Plate"''<br />
'''/Xdmf/Domain/Grid<nowiki>[</nowiki>@Name="Copper Plate"<nowiki>]</nowiki>'''<br />
<br />
All valid XDMF must appear between the &lt;Xdmf&gt; and the &lt;/Xdmf&gt; tags.<br />
So a minimal (empty) XDMF XML file would be:<br />
<br />
'''&lt;?xml version="1.0" ?&gt;'''<br />
'''&lt;!DOCTYPE Xdmf SYSTEM "Xdmf.dtd" <nowiki>[</nowiki><nowiki>]</nowiki>&gt;'''<br />
'''&lt;Xdmf Version="2.0"&gt;'''<br />
'''&lt;/Xdmf&gt;'''<br />
<br />
While there exists an Xdmf DTD and a Schema they are only necessary for validating parsers.<br />
For performance reasons, validation is typically disabled.<br />
<br />
===Entities===<br />
In addition to Xinclude and XPath, which allow for references to data outside the actual XMDF, XML's basic substitution mechanism of entities can be used to render the XDMF document more readable.<br />
For instance, once an entity alias has been defined in the header via<br />
<br />
'''&lt;?xml version="1.0" ?&gt;'''<br />
'''&lt;!DOCTYPE Xdmf SYSTEM "Xdmf.dtd" <nowiki>[</nowiki>'''<br />
'''&lt;!ENTITY cellDimsZYX "45 30 120"&gt;'''<br />
'''<nowiki>]</nowiki>&gt;'''<br />
<br />
the text in double quotes is substituted for the entity reference ''&cellDimsZXY;'' (note the trailing semicolon) whenever the parser encounters the latter in the remaining part of the document.<br />
<br />
==XDMF Elements==<br />
<br />
The organization of XDMF begins with the ''Xdmf'' element.<br />
So that parsers can distinguish from previous versions of XDMF, there exists a ''Version'' attribute (currently at 3.0).<br />
Any element in XDMF can have a ''Name'' attribute or have a ''Reference'' attribute.<br />
The Name attribute becomes important for grids while the Reference attribute is used to take advantage of the XPath facility (more detail on this later).<br />
Xdmf elements contain one or more ''Domain'' elements (computational domain).<br />
There is seldom motivation to have more than one Domain. <br />
<br />
A Domain can have one or more ''Grid'' elements.<br />
Each Grid contains a ''Topology'', ''Geometry'', and zero or more ''Attribute'' elements.<br />
Topology specifies the connectivity of the grid while Geometry specifies the location of the grid nodes.<br />
Attribute elements are used to specify values such as scalars and vectors that are located at the node, edge, face, cell center, or grid center. <br />
<br />
To specify actual values for connectivity, geometry, or attributes, XDMF defines a ''DataItem'' element.<br />
A DataItem can provide the actual values or provide the physical storage (which is typically an HDF5 file).<br />
<br />
===XdmfItem===<br />
<br />
There are six different types of DataItems :<br />
# '''Uniform''' - this is the default. A single array of values.<br />
# '''Collection''' - a one dimension array of DataItems<br />
# '''Tree''' - a hierarchical structure of DataItems<br />
# '''HyperSlab''' - contains two data items. The first selects the start, stride and count indexes of the second DataItem.<br />
# '''Coordinates''' - contains two DataItems. The first selects the parametric coordinates of the second DataItem.<br />
# '''Function''' - calculates an expression.<br />
<br />
====Uniform====<br />
<br />
The simplest type is Uniform that specifies a single array.<br />
As with all XDMF elements, there are reasonable defaults wherever possible.<br />
So the simplest DataItem would be :<br />
<br />
'''&lt;DataItem Dimensions="3"&gt;'''<br />
'''1.0 2.0 3.0'''<br />
'''&lt;/DataItem&gt;'''<br />
<br />
Since no ''ItemType'' has been specified, Uniform has been assumed.<br />
The default ''Format'' is XML and the default ''NumberType'' is a 32 bit floating point value.<br />
So the fully qualified DataItem for the same data would be:<br />
<br />
'''&lt;DataItem ItemType="Uniform"'''<br />
'''Format="XML"'''<br />
'''NumberType="Float" Precision="4"'''<br />
'''Rank="1" Dimensions="3"&gt;'''<br />
'''1.0 2.0 3.0'''<br />
'''&lt;/DataItem&gt;'''<br />
<br />
Since it is only practical to store a small amount of data values in the XML, production codes typically write their data to HDF5 and specify the location in XML.<br />
HDF5 is a hierarchical, self describing data format.<br />
So an application can open an HDF5 file without any prior knowledge of the data and determine the dimensions and number type of all the arrays stored in the file.<br />
XDMF requires that this information also be stored redundantly in the XML so that applications need not have access to the actual heavy data in order to determine storage requirements.<br />
<br />
For example, suppose an application stored a three dimensional array of pressure values at each iteration into an HDF5 file. The XML might be :<br />
<br />
'''&lt;DataItem ItemType="Uniform"'''<br />
'''Format="HDF"'''<br />
'''NumberType="Float" Precision="8"'''<br />
'''Dimensions="64 128 256"&gt;'''<br />
'''OutputData.h5:/Results/Iteration 100/Part 2/Pressure'''<br />
'''&lt;/DataItem&gt;'''<br />
<br />
Alternatively, an application may store its data in binary files.<br />
In this case the XML might be.<br />
<br />
'''&lt;DataItem ItemType="Uniform"'''<br />
'''Format="Binary"'''<br />
'''Dimensions="64 128 256"&gt;'''<br />
'''PressureFile.bin'''<br />
'''&lt;/DataItem&gt;'''<br />
<br />
Dimensions are specified with the slowest varying dimension first (i.e. KJI order).<br />
The HDF filename can be fully qualified, if it is not it is assumed to be located in the current directory or the same directory as the XML file. <br />
<br />
====Collection and Tree====<br />
<br />
Collections are Trees with only a single level.<br />
This is such a frequent occurrence that it was decided to make a Collection a separate type in case the application can optimize access.<br />
Collections and Trees have DataItem elements as children.<br />
The leaf nodes are Uniform DataItem elements:<br />
<br />
'''&lt;DataItem Name="Tree Example" ItemType="Tree"&gt;'''<br />
'''&lt;DataItem ItemType="Tree"&gt;'''<br />
'''&lt;DataItem Name="Collection 1" ItemType="Collection"&gt;'''<br />
'''&lt;DataItem Dimensions="3"&gt;'''<br />
'''1.0 2.0 3.0'''<br />
'''&lt;/DataItem&gt;'''<br />
'''&lt;DataItem Dimensions="4"&gt;'''<br />
'''4 5 6 7'''<br />
'''&lt;/DataItem&gt;'''<br />
'''&lt;/DataItem&gt;'''<br />
'''&lt;/DataItem&gt;'''<br />
'''&lt;DataItem Name="Collection 2" ItemType="Collection"&gt;'''<br />
'''&lt;DataItem Dimensions="3"&gt;'''<br />
'''7 8 9'''<br />
'''&lt;/DataItem&gt;'''<br />
'''&lt;DataItem Dimensions="4"&gt;'''<br />
'''10 11 12 13'''<br />
'''&lt;/DataItem&gt;'''<br />
'''&lt;/DataItem&gt;'''<br />
'''&lt;DataItem ItemType="Uniform"'''<br />
'''Format="HDF"'''<br />
'''NumberType="Float" Precision="8"'''<br />
'''Dimensions="64 128 256"&gt;'''<br />
'''OutputData.h5:/Results/Iteration 100/Part 2/Pressure'''<br />
'''&lt;/DataItem&gt;'''<br />
'''&lt;/DataItem&gt;'''<br />
<br />
This DataItem is a tree with three children.<br />
The first child is another tree that contains a collection of two uniform DataItem elements.<br />
The second child is a collection with two uniform DataItem elements.<br />
The third child is a uniform DataItem. <br />
<br />
====HyperSlab====<br />
<br />
A ''HyperSlab'' specifies a subset of some other DataItem.<br />
The slab is specified by giving the start, stride, and count of the values in each of the target DataItem dimensions.<br />
For example, given a dataset MyData.h5:/XYZ that is 100x200x300x3, we could describe a region starting at <nowiki>[</nowiki>0,0,0,0<nowiki>]</nowiki>, ending at <nowiki>[</nowiki>50, 100, 150, 2<nowiki>]</nowiki> that includes every other plane of data with the HyperSlab DataItem <br />
<br />
'''&lt;DataItem ItemType="HyperSlab"'''<br />
'''Dimensions="25 50 75 3"'''<br />
'''Type="HyperSlab"&gt;'''<br />
'''&lt;DataItem'''<br />
'''Dimensions="3 4"''' <br />
'''Format="XML"&gt;'''<br />
'''0 0 0 0 '''<br />
'''2 2 2 1 '''<br />
'''25 50 75 3'''<br />
'''&lt;/DataItem&gt;'''<br />
'''&lt;DataItem'''<br />
'''Name="Points"'''<br />
'''Dimensions="100 200 300 3"'''<br />
'''Format="HDF"&gt;'''<br />
'''MyData.h5:/XYZ'''<br />
'''&lt;/DataItem&gt;'''<br />
'''&lt;/DataItem&gt;'''<br />
<br />
Notice that the first DataItem specified Start, Stride and Count for each dimension of the second DataItem.<br />
<br />
====Coordinate====<br />
Suppose, instead that we only wish to specify the first Y data value from the DataItem and the last X value.<br />
This can be accomplished by providing the parametric coordinates of the desired values and using the ''Coordinates'' ItemType.<br />
<br />
'''&lt;DataItem ItemType="Coordinate"'''<br />
'''Dimensions="2"'''<br />
'''Type="Coordinate"&gt;'''<br />
'''&lt;DataItem'''<br />
'''Dimensions="2 4"'''<br />
'''Format="XML"&gt;'''<br />
'''0 0 0 1'''<br />
'''99 199 299 0'''<br />
'''&lt;/DataItem&gt;'''<br />
'''&lt;DataItem'''<br />
'''Name="Points"'''<br />
'''Dimensions="100 200 300 3"'''<br />
'''Format="HDF"&gt;'''<br />
'''MyData.h5:/XYZ'''<br />
'''&lt;/DataItem&gt;'''<br />
'''&lt;/DataItem&gt;'''<br />
<br />
The first Y value is index 1 of item 0,0,0 while the last X value is index 0 of item 99, 199, 299. The dimensionality of the specified coordinates must match that of the target DataItem. <br />
<br />
====Function====<br />
<br />
''Function'' ItemType specifies some operation on the children DataItem elements. The elements are referenced by $X where X is the zero based index of the child. For example, the following DataItem would add the two children DataItem elements together in a value by value operation resulting in the values 5.1, 7.2 and 9.3 :<br />
<br />
'''&lt;DataItem ItemType="Function" '''<br />
'''Function="$0 + $1"'''<br />
'''Dimensions="3"&gt;'''<br />
'''&lt;DataItem Dimensions="3"&gt;'''<br />
'''1.0 2.0 3.0'''<br />
'''&lt;/DataItem&gt;'''<br />
'''&lt;DataItem Dimensions="3"&gt;'''<br />
'''4.1 5.2 6.3'''<br />
'''&lt;/DataItem&gt;'''<br />
'''&lt;/DataItem&gt;'''<br />
<br />
The function description can be arbitrarily complex and contain SIN, COS, TAN, ACOS, ASIN, ATAN, LOG, EXP, ABS, and SQRT. In addition, there are the JOIN() and WHERE() expressions. JOIN can concatenate or interlace arrays while WHERE() can extract values where some condition is true. In the following examples we take advantage of the XPath facility to reference DataItem elements that have been previously specified :<br />
<br />
Add the value 10 to every element<br />
<br />
'''&lt;DataItem Name="MyFunction" ItemType="Function"'''<br />
''' Function="10 + $0"&gt;'''<br />
''' &lt;DataItem Reference="/Xdmf/DataItem<nowiki>[</nowiki>1<nowiki>]</nowiki>" /&gt;'''<br />
''' &lt;/DataItem&gt;''' <br />
<br />
Multiply two arrays (element by element) and take the absolute value<br />
<br />
''' &lt;DataItem ItemType="Function"'''<br />
''' Function="ABS($0 <nowiki>*</nowiki> $1)"&gt;'''<br />
''' &lt;DataItem Reference="/Xdmf/DataItem<nowiki>[</nowiki>1<nowiki>]</nowiki>" /&gt;'''<br />
''' &lt;DataItem Reference="/Xdmf/DataItem<nowiki>[</nowiki>2<nowiki>]</nowiki>" /&gt;'''<br />
''' &lt;/DataItem&gt;'''<br />
<br />
Select element 5 thru 15 from the first DataItem<br />
<br />
''' &lt;DataItem ItemType="Function"'''<br />
''' Function="$0<nowiki>[</nowiki>5:15<nowiki>]</nowiki>"&gt;'''<br />
''' &lt;DataItem Reference="/Xdmf/DataItem<nowiki>[</nowiki>1<nowiki>]</nowiki>" /&gt;'''<br />
''' &lt;/DataItem&gt;'''<br />
<br />
Concatenate two arrays<br />
<br />
''' &lt;DataItem ItemType="Function"'''<br />
''' Function="JOIN($0 ; $1)"&gt;'''<br />
''' &lt;DataItem Reference="/Xdmf/DataItem<nowiki>[</nowiki>1<nowiki>]</nowiki>" /&gt;'''<br />
''' &lt;DataItem Reference="/Xdmf/DataItem<nowiki>[</nowiki>2<nowiki>]</nowiki>" /&gt;'''<br />
''' &lt;/DataItem&gt;'''<br />
<br />
Interlace 3 arrays (Useful for describing vectors from scalar data)<br />
<br />
''' &lt;DataItem ItemType="Function"'''<br />
''' Function="JOIN($0 , $1, $2)"&gt;'''<br />
''' &lt;DataItem Reference="/Xdmf/DataItem<nowiki>[</nowiki>1<nowiki>]</nowiki>" /&gt;'''<br />
''' &lt;DataItem Reference="/Xdmf/DataItem<nowiki>[</nowiki>2<nowiki>]</nowiki>" /&gt; '''<br />
''' &lt;DataItem Reference="/Xdmf/DataItem<nowiki>[</nowiki>3<nowiki>]</nowiki>" /&gt;'''<br />
''' &lt;/DataItem&gt;'''<br />
<br />
===Grid===<br />
<br />
The DataItem element is used to define the data format portion of XDMF.<br />
It is sufficient to specify fairly complex data structures in a portable manner.<br />
The data model portion of XDMF begins with the ''Grid'' element. A Grid is a container for information related to 2D and 3D points, structured or unstructured connectivity, and assigned values.<br />
<br />
The Grid element now has a GridType attribute. Valid GridTypes are :<br />
# '''Uniform''' - a homogeneous single grid (i.e. a pile of triangles)<br />
# '''Collection''' - an array of Uniform grids all with the same Attributes<br />
# '''Tree''' - a hierarchical group<br />
# '''SubSet ''' - a portion of another Grid<br />
<br />
====Uniform, Collection, and Tree====<br />
Uniform Grid elements are the simplest type and must contain a ''Topology'' and ''Geometry'' element.<br />
If GridType is Collection, a CollectionType can be specified as either "Spatial" or "Temporal".<br />
Just like the DataItem element, Tree and Collection Grid elements contain other Grid elements as children:<br />
<br />
'''&lt;Grid Name="Car Wheel" GridType="Tree"&gt;'''<br />
'''&lt;Grid Name="Tire" GridType="Uniform"&gt;'''<br />
'''&lt;Topology ...'''<br />
'''&lt;Geometry ...'''<br />
'''&lt;/Grid&gt;'''<br />
'''&lt;Grid Name="Lug Nuts" GridType="Collection"&gt;'''<br />
'''&lt;Grid Name="Lug Nut 0" GridType="Uniform"'''<br />
'''&lt;Topology ....'''<br />
'''&lt;Geometry ...'''<br />
'''&lt;/Grid&gt;'''<br />
'''&lt;Grid Name="Lug Nut 1" GridType="Uniform"'''<br />
'''&lt;Topology ...'''<br />
'''&lt;Geometry ...'''<br />
'''&lt;/Grid&gt;'''<br />
'''&lt;Grid Name="Lug Nut 2" GridType="Uniform"'''<br />
'''&lt;Topology ...'''<br />
'''&lt;Geometry ...'''<br />
'''&lt;/Grid&gt;'''<br />
'''&lt;/Grid&gt;'''<br />
'''.'''<br />
'''.'''<br />
'''.''' <br />
<br />
====SubSet====<br />
A SubSet GridType is used to define a portion of another grid or define new attributes on the grid. This allows users to share the geometry and topology of another grid, the attributes from the original grid are not assigned. The Section attribute of a SubSet can be ''DataItem'' or ''All'' :<br />
<br />
''' &lt;Grid Name="Portion" GridType="Subset" Section="DataItem"&gt;'''<br />
''&lt;!-- Select 2 cells from another grid. Which 2 are defined by the DataItem --&gt;''<br />
''' &lt;DataItem''' <br />
''' DataType="Int"'''<br />
''' Dimensions="2"'''<br />
''' Format="XML"&gt;'''<br />
''' 0 2'''<br />
''' &lt;/DataItem&gt;'''<br />
''' &lt;Grid Name="Target" Reference="XML"&gt;'''<br />
''' /Xdmf/Domain/Grid<nowiki>[</nowiki>@Name="Main Grid"<nowiki>]</nowiki>'''<br />
''' &lt;/Grid&gt;'''<br />
''' &lt;Attribute Name="New Values" Center="Cell"&gt;'''<br />
''' &lt;DataItem Format="XML" Dimensions="2"&gt;'''<br />
''' 100 150'''<br />
''' &lt;/DataItem&gt;'''<br />
''' &lt;/Attribute&gt;'''<br />
''' &lt;/Grid&gt;'''<br />
<br />
Or<br />
<br />
''' &lt;Grid Name="Portion" GridType="Subset" Section="All"&gt;'''<br />
''&lt;!-- Select the entire grid and add an attribute --&gt;''<br />
''' &lt;Grid Name="Target" Reference="XML"&gt;'''<br />
''' /Xdmf/Domain/Grid<nowiki>[</nowiki>@Name="Main Grid"<nowiki>]</nowiki>'''<br />
''' &lt;/Grid&gt;'''<br />
''' &lt;Attribute Name="New Values" Center="Cell"&gt;'''<br />
''' &lt;DataItem Format="XML" Dimensions="3"&gt;'''<br />
''' 100 150 200'''<br />
''' &lt;/DataItem&gt;'''<br />
''' &lt;/Attribute&gt;'''<br />
''' &lt;/Grid&gt;'''<br />
<br />
===Topology===<br />
<br />
The Topology element describes the general organization of the data.<br />
This is the part of the computational grid that is invariant with rotation, translation, and scale.<br />
For structured grids, the connectivity is implicit.<br />
For unstructured grids, if the connectivity differs from the standard, an Order may be specified.<br />
Currently, the following Topology cell types are defined :<br />
<br />
====Linear====<br />
* Polyvertex - a group of unconnected points<br />
* Polyline - a group of line segments<br />
* Polygon<br />
* Triangle<br />
* Quadrilateral<br />
* Tetrahedron<br />
* Pyramid<br />
* Wedge<br />
* Hexahedron<br />
<br />
====Quadratic====<br />
* Edge_3 - Quadratic line with 3 nodes<br />
* Tri_6<br />
* Quad_8<br />
* Tet_10<br />
* Pyramid_13<br />
* Wedge_15<br />
* Hex_20<br />
<br />
====Arbitrary====<br />
* Mixed - a mixture of unstructured cells<br />
<br />
====Structured====<br />
* 2DSMesh - Curvilinear<br />
* 2DRectMesh - Axis are perpendicular<br />
* 2DCoRectMesh - Axis are perpendicular and spacing is constant<br />
* 3DSMesh<br />
* 3DRectMesh<br />
* 3DCoRectMesh<br />
<br />
There is a ''NodesPerElement'' attribute for the cell types where it is not implicit.<br />
For example, to define a group of Octagons, set TopologyType="Polygon" and NodesPerElement="8".<br />
For structured grid topologies, the connectivity is implicit.<br />
For unstructured topologies the Topology element must contain a DataItem that defines the connectivity:<br />
<br />
'''&lt;Topology TopologyType="Quadrilateral" NumberOfElements="2" &gt;'''<br />
'''&lt;DataItem Format="XML" DataType="Int" Dimensions="2 4"&gt;'''<br />
'''0 1 2 3'''<br />
'''1 6 7 2'''<br />
'''&lt;/DataItem&gt;'''<br />
'''&lt;/Topology&gt;'''<br />
<br />
The connectivity defines the indexes into the XYZ geometry that define the cell.<br />
In this example, the two quads share an edge defined by the line from node 1 to node 2.<br />
A Topology element can define ''Dimensions'' or ''NumberOfElements''; this is just added for clarity.<br />
<br />
Mixed topologies must define the cell type of every element.<br />
If that cell type does not have an implicit number of nodes, that must also be specified.<br />
In this example, we define a topology of three cells consisting of a Tet (cell type 6) a Polygon (cell type 3) and a Hex (cell type 9):<br />
<br />
'''&lt;Topology TopologyType="Mixed" NumberOfElements="3" &gt;'''<br />
'''&lt;DataItem Format="XML" DataType="Int" Dimensions="20"&gt;'''<br />
'''6 0 1 2 7'''<br />
'''3 4 4 5 6 7'''<br />
'''9 8 9 10 11 12 13 14 15'''<br />
'''&lt;/DataItem&gt;'''<br />
'''&lt;/Topology&gt;''' <br />
<br />
Notice that the Polygon must define the number of nodes (4) before its connectivity.<br />
The cell type numbers are defined in the API documentation.<br />
<br />
===Geometry===<br />
<br />
The Geometry element describes the XYZ values of the mesh. The important attribute here is the organization of the points. The default is XYZ; an X,Y, and Z for each point starting at parametric index 0. Possible organizations are :<br />
<br />
* '''XYZ''' - Interlaced locations<br />
* '''XY''' - Z is set to 0.0<br />
* '''X_Y_Z''' - X,Y, and Z are separate arrays<br />
* '''VXVYVZ''' - Three arrays, one for each axis<br />
* '''ORIGIN_DXDYDZ''' - Six Values : Ox,Oy,Oz + Dx,Dy,Dz<br />
* '''ORIGIN_DXDY''' - Four Values : Ox,Oy + Dx,Dy<br />
<br />
<br />
The following Geometry element defines 8 points :<br />
<br />
'''&lt;Geometry GeometryType="XYZ"&gt;'''<br />
'''&lt;DataItem Format="XML" Dimensions="2 4 3"&gt;'''<br />
'''0.0 0.0 0.0'''<br />
'''1.0 0.0 0.0'''<br />
'''1.0 1.0 0.0'''<br />
'''0.0 1.0 0.0''' <br />
'''0.0 0.0 2.0'''<br />
'''1.0 0.0 2.0'''<br />
'''1.0 1.0 2.0'''<br />
'''0.0 1.0 2.0'''<br />
'''&lt;/DataItem&gt;'''<br />
'''&lt;/Geometry&gt;'''<br />
<br />
Together with the Grid and Topology element we now have enough to define a full XDMF XML file (that can be visualized in VisIt or ParaView) that defines two quadrilaterals that share an edge (notice not all points are used):<br />
<br />
[[File:3DUnstructuredMesh.jpeg|320px|thumb|right|An unstructured mesh consisting of two quadrilaterals that share an edge (visualized using VisIt)]]<br />
<br />
'''&lt;?xml version="1.0" ?&gt;'''<br />
'''&lt;!DOCTYPE Xdmf SYSTEM "Xdmf.dtd" []&gt;'''<br />
'''&lt;Xdmf Version="2.0" xmlns:xi="<nowiki>[http://www.w3.org/2001/XInclude</nowiki>]"&gt;'''<br />
'''&lt;Domain&gt;'''<br />
'''&lt;Grid Name="Two Quads"&gt;'''<br />
'''&lt;Topology TopologyType="Quadrilateral" NumberOfElements="2"&gt;'''<br />
'''&lt;DataItem Format="XML" DataType="Int" Dimensions="2 4"&gt;'''<br />
'''0 1 2 3'''<br />
'''1 6 7 2'''<br />
'''&lt;/DataItem&gt;'''<br />
'''&lt;/Topology&gt;'''<br />
'''&lt;Geometry GeometryType="XYZ"&gt;'''<br />
'''&lt;DataItem Format="XML" Dimensions="2 4 3"&gt;'''<br />
'''0.0 0.0 0.0'''<br />
'''1.0 0.0 0.0'''<br />
'''1.0 1.0 0.0'''<br />
'''0.0 1.0 0.0'''<br />
'''0.0 0.0 2.0'''<br />
'''1.0 0.0 2.0'''<br />
'''1.0 1.0 2.0'''<br />
'''0.0 1.0 2.0'''<br />
'''&lt;/DataItem&gt;'''<br />
'''&lt;/Geometry&gt;'''<br />
'''&lt;/Grid&gt;'''<br />
'''&lt;/Domain&gt;'''<br />
'''&lt;/Xdmf&gt;'''<br />
<br />
It is valid to have DataItem elements to be direct children of the Xdmf or Domain elements.<br />
This could be useful if several Grids share the same Geometry but have separate Topology:<br />
<br />
[[File:3DUnstructuredParaView.png|450px|thumb|right|An unstructured mesh consisting of two quadrilaterals that share an edge (visualized using ParaView)]]<br />
<br />
'''&lt;?xml version="1.0" ?&gt;'''<br />
'''&lt;!DOCTYPE Xdmf SYSTEM "Xdmf.dtd" <nowiki>[</nowiki><nowiki>]</nowiki>&gt;'''<br />
'''&lt;Xdmf Version="2.0" xmlns:xi="<nowiki>[http://www.w3.org/2001/XInclude</nowiki>]"&gt;'''<br />
'''&lt;Domain&gt;'''<br />
'''&lt;DataItem Name="Point Data" Format="XML" Dimensions="2 4 3"&gt;'''<br />
'''0.0 0.0 0.0'''<br />
'''1.0 0.0 0.0'''<br />
'''1.0 1.0 0.0'''<br />
'''0.0 1.0 0.0'''<br />
'''0.0 0.0 2.0'''<br />
'''1.0 0.0 2.0'''<br />
'''1.0 1.0 2.0'''<br />
'''0.0 1.0 2.0'''<br />
'''&lt;/DataItem&gt;'''<br />
'''&lt;Grid Name="Two Quads"&gt;'''<br />
'''&lt;Topology Type="Quadrilateral" NumberOfElements="2" &gt;'''<br />
'''&lt;DataItem Format="XML" '''<br />
'''DataType="Int"'''<br />
'''Dimensions="2 4"&gt;'''<br />
'''0 1 2 3'''<br />
'''1 6 7 2'''<br />
'''&lt;/DataItem&gt;'''<br />
'''&lt;/Topology&gt;'''<br />
'''&lt;Geometry Type="XYZ"&gt;'''<br />
'''&lt;DataItem Reference="XML"&gt;'''<br />
'''/Xdmf/Domain/DataItem<nowiki>[</nowiki>@Name="Point Data"<nowiki>]</nowiki>'''<br />
'''&lt;/DataItem&gt;'''<br />
'''&lt;/Geometry&gt;'''<br />
'''&lt;/Grid&gt;'''<br />
'''&lt;/Domain&gt;'''<br />
'''&lt;/Xdmf&gt;'''<br />
<br />
<br />
<br />
===Attribute===<br />
<br />
The Attribute element defines values associated with the mesh. Currently the supported types of values are :<br />
<br />
* '''Scalar'''<br />
* '''Vector'''<br />
* '''Tensor''' - 9 values expected<br />
* '''Tensor6''' - a symmetrical tensor<br />
* '''Matrix ''' - an arbitrary NxM matrix<br />
These values can be centered on :<br />
* '''Node'''<br />
* '''Edge'''<br />
* '''Face'''<br />
* '''Cell'''<br />
* '''Grid'''<br />
<br />
A Grid centered Attribute might be something like "Material Type" where the value is constant everywhere in the grid. <br />
Edge and Face centered values are defined, but do not map well to many visualization systems (ParaView, for example, ignores them at present).<br />
Edge and Face values are defined for each Cell in turn, using VTK ordering. The same Face or Edge may be visited multiple times, with duplicate values.<br />
<br />
Typically Attributes are assigned on the Node :<br />
<br />
'''&lt;Attribute Name="Node Values" Center="Node"&gt;'''<br />
'''&lt;DataItem Format="XML" Dimensions="6 4"&gt;'''<br />
'''100 200 300 400'''<br />
'''500 600 600 700'''<br />
'''800 900 1000 1100'''<br />
'''1200 1300 1400 1500'''<br />
'''1600 1700 1800 1900'''<br />
'''2000 2100 2200 2300'''<br />
'''&lt;/DataItem&gt;'''<br />
'''&lt;/Attribute&gt;'''<br />
Or assigned to the cell centers :<br />
'''&lt;Attribute Name="Cell Values" Center="Cell"&gt;'''<br />
'''&lt;DataItem Format="XML" Dimensions="3"&gt;'''<br />
''' 3000 2000 1000'''<br />
''' &lt;/DataItem&gt;'''<br />
'''&lt;/Attribute&gt;'''<br />
<br />
===Set===<br />
<br />
The '''Set''' element may be used to define Attributes on a subset of entities of a '''Grid'''. <br />
<br />
Valid SetTypes are:<br />
* '''Node'''<br />
* '''Edge'''<br />
* '''Face''' <br />
* '''Cell'''<br />
<br />
'''Set''' may have multiple DataItems.<br />
The last DataItem always provides the indices of the entity.<br />
If SetType is Face or Edge, the First DataItem defines the Cell indices, and subsequent Dataitems define the Cell-local Face or Edge indices.<br />
It is therefore possible to define multiple values on Edges or Faces. The following example defines values on Face 0 of Cells 1,2,3 and 4.<br />
<br />
'''&lt;Set Name="Ids" SetType="Face"&gt;'''<br />
''' &lt;DataItem Format="XML" Dimensions="4" &gt;'''<br />
''' 1 2 3 4'''<br />
''' &lt;/DataItem&gt;'''<br />
''' &lt;DataItem Format="XML" Dimensions="4" &gt;'''<br />
''' 0 0 0 0'''<br />
''' &lt;/DataItem&gt;''' <br />
''' &lt;Attribute Name="Example" Center="Face"&gt;'''<br />
''' &lt;DataItem Format="XML" Dimensions="4" &gt;'''<br />
''' 100.0 110.0 100.0 200.0'''<br />
''' &lt;/DataItem&gt;'''<br />
''' &lt;/Attribute&gt;'''<br />
'''&lt;/Set&gt;'''<br />
<br />
===Time===<br />
<br />
The '''Time''' element is a child of the '''Grid''' element and specifies the temporal information for the grid. The type of time element is defined by the '''TimeType''' attribute of the element. Valid TimeTypes are :<br />
* '''Single''' - A single time value for the entire grid<br />
* '''HyperSlab''' - Start, Stride, Count<br />
* '''List''' - A list of discrete times<br />
* '''Range''' - Min, Max<br />
<br />
So in the simplest form, specifying a single time :<br />
'''&lt;Time Value="0.1" /&gt;'''<br />
<br />
For a more complex situation, consider a grid with GridType="Collection" which contains a set 100 children grids written every 1usec of simulation time :<br />
&lt;Time TimeType="HyperSlab"&gt;<br />
&lt;DataItem Format="XML" NumberType="Float" Dimensions="3"&gt;<br />
0.0 0.000001 100<br />
&lt;/DataItem&gt;<br />
&lt;/Time&gt;<br />
<br />
For a collection of grids not written at regular intervals :<br />
&lt;Time TimeType="List"&gt;<br />
&lt;DataItem Format="XML" NumberType="Float" Dimensions="7"&gt;<br />
0.0 0.1 0.5 1.0 1.1 10.0 100.5<br />
&lt;/DataItem&gt;<br />
&lt;/Time&gt;<br />
<br />
For data which is valid not at a discrete time but within a range :<br />
&lt;Time TimeType="Range"&gt;<br />
&lt;DataItem Format="XML" NumberType="Float" Dimensions="2"&gt;<br />
0.0 0.5<br />
&lt;/DataItem&gt;<br />
&lt;/Time&gt;<br />
<br />
===Information===<br />
<br />
There is regularly code or system specific information that needs to be stored with the data that does not map to the current data model. There is an ''Information'' element. This is intended for application specific information that can be ignored. A good example might be the bounds of a grid for use in visualization. Information elements have a Name and Value attribute. If Value is nonexistent the value is in the CDATA of the element :<br />
<br />
'''&lt;Information Name="XBounds" Value="0.0 10.0"/&gt;'''<br />
'''&lt;Information Name="Bounds"&gt; 0.0 10.0 100.0 110.0 200.0 210.0 &lt;/Information&gt;'''<br />
<br />
Several items can be addressed using the ''Information'' element like time, units, descriptions, etc. without polluting the XDMF schema.<br />
If some of these get used extensively they may be promoted to XDMF elements in the future.<br />
<br />
===XML Element (Xdmf ClassName) and Default XML Attributes===<br />
<br />
* Attribute (XdmfAttribute)<br />
Name (no default)<br />
AttributeType <span style='color:red'>Scalar</span> | Vector | Tensor | Tensor6 | Matrix | GlobalID<br />
Center <span style='color:red'>Node</span> | Cell | Grid | Face | Edge<br />
<br />
* DataItem (XdmfDataItem)<br />
Name (no default)<br />
ItemType <span style='color:red'>Uniform</span> | Collection | tree | HyperSlab | coordinates | Function<br />
Dimensions (no default) in KJI Order<br />
NumberType <span style='color:red'>Float</span> | Int | UInt | Char | UChar<br />
Precision 1 | 2 (Int or UInt only) |<span style='color:red'>4</span> | 8<br />
Format <span style='color:red'>XML</span> | HDF | Binary<br />
Endian <span style='color:red'>Native</span> | Big | Little (applicable only to Binary format)<br />
Compression <span style='color:red'>Raw</span>|Zlib|BZip2 (applicable only to Binary format and depend on xdmf configuration)<br />
Seek <span style='color:red'>0</span> (number of bytes to skip, applicable only to Binary format with Raw compression)<br />
<br />
* Domain (XdmfDomain)<br />
Name (no default)<br />
<br />
* Geometry (XdmfGeometry)<br />
GeometryType <span style='color:red'>XYZ</span> | XY | X_Y_Z | VxVyVz | Origin_DxDyDz | Origin_DxDy<br />
<br />
* Grid (XdmfGrid)<br />
Name (no default)<br />
GridType <span style='color:red'>Uniform</span> | Collection | Tree | Subset<br />
CollectionType <span style='color:red'>Spatial</span> | Temporal (Only Meaningful if GridType="Collection")<br />
Section <span style='color:red'>DataItem</span> | All (Only Meaningful if GridType="Subset")<br />
<br />
* Information (XdmfInformation)<br />
Name (no default)<br />
Value (no default)<br />
<br />
* Xdmf (XdmfRoot)<br />
Version <span style='color:red'>Current Version</span> | *<br />
<br />
* Topology (XdmfTopology)<br />
Name (no default)<br />
TopologyType Polyvertex | Polyline | Polygon |<br />
Triangle | Quadrilateral | Tetrahedron | Pyramid| Wedge | Hexahedron |<br />
Edge_3 | Triagle_6 | Quadrilateral_8 | Tetrahedron_10 | Pyramid_13 |<br />
Wedge_15 | Hexahedron_20 |<br />
Mixed |<br />
2DSMesh | 2DRectMesh | 2DCoRectMesh |<br />
3DSMesh | 3DRectMesh | 3DCoRectMesh<br />
NodesPerElement (no default) Only Important for Polyvertex, Polygon and Polyline<br />
NumberOfElements (no default)<br />
OR<br />
Dimensions (no default)<br />
Order each cell type has its own default<br />
BaseOffset <span style='color:red'>0</span> | #<br />
<br />
* Time<br />
TimeType <span style='color:red'>Single</span> | HyperSlab | List | Range<br />
Value (no default - Only valid for TimeType="Single")</div>Dave.demarlehttps://www.xdmf.org/index.php?title=Get_Xdmf&diff=183Get Xdmf2016-04-03T13:01:28Z<p>Dave.demarle: </p>
<hr />
<div>The old version of this page can be found at [http://xdmf.org/index.php/Get_Xdmf_original]<br />
<br />
Xdmf depends on hdf5 and has a header only dependency on boost. You must obtain and build those projects before you can build xdmf.<br />
To use Xdmf from Python or Java you will also need swig.<br />
<br />
To obtain xdmf:<br />
* git clone git://xdmf.org/Xdmf.git<br />
* mkdir build<br />
* cd build<br />
* ccmake ..<br />
* make<br />
<br />
To use xdmf from wrapped languages you will need to configure XDMF_WRAP_PYTHON, or XDMF_WRAP_JAVA on in ccmake.<br />
<br />
Xdmf is mirrored in VTK which has reader and writer classes the call into XDMF to do file IO. To use XDMF within VTK, simply turn on Module_vtkIOXdmf2 or Module_vtkIOXdmf3 on the advanced options page of you VTK configuration.</div>Dave.demarlehttps://www.xdmf.org/index.php?title=Version_1&diff=182Version 12016-04-03T12:44:49Z<p>Dave.demarle: </p>
<hr />
<div>Version "1" of xdmf is deprecated but it can be obtained via:<br />
<br />
cvs -d :pserver:anonymous@public.kitware.com:/cvsroot/Xdmf login<br />
cvs -d :pserver:anonymous@public.kitware.com:/cvsroot/Xdmf checkout Xdmf</div>Dave.demarlehttps://www.xdmf.org/index.php?title=Version_3&diff=181Version 32016-04-03T12:29:55Z<p>Dave.demarle: </p>
<hr />
<div>Version "3" of Xdmf is the master branch of:<br />
git://xdmf.org/Xdmf.git<br />
<br />
The initial plans for changes that went into version 3 are summarized on:<br />
[http://xdmf.org/index.php/Xdmf::New()]<br />
<br />
The overall goals included better performance and use of modern and more maintainable C++ programming idioms. This version adds a dependence on boost.<br />
<br />
Additionally, this version added support for Graph types and removed support for the SQL back end.</div>Dave.demarlehttps://www.xdmf.org/index.php?title=Version_2&diff=180Version 22016-04-03T12:28:35Z<p>Dave.demarle: </p>
<hr />
<div>Version "2" of Xdmf is being deprecated but it can be found in the history at:<br />
<br />
git clone git://xdmf.org/Xdmf.git<br />
<br />
There were two important branches in the repository, "master" (git SHA 6ca45404) and "pv" (git SHA 24470abd). The "pv" branch was restructured during the ParaView 4 release to update it to be compatible with VTK 6.x's modularized build system.<br />
<br />
The updates to Xdmf in version 2 are summarized in this paper:<br />
[http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADP023792]<br />
and this podcast [http://www.rce-cast.com/components/com_podcast/media/40RCE-xdmf.mp3]</div>Dave.demarlehttps://www.xdmf.org/index.php?title=Version_2&diff=179Version 22016-04-03T12:27:45Z<p>Dave.demarle: </p>
<hr />
<div>Version "2" of Xdmf is being deprecated but it can be found in the history at:<br />
<br />
git clone git://xdmf.org/Xdmf.git<br />
<br />
There were two important branches in the repository, "master" (git SHA 6ca45404) and "pv". The "pv" branch (git SHA 24470abd) was restructured during the ParaView 4 release to update it to be compatible with VTK 6.x's modularized build system.<br />
<br />
The updates to Xdmf in version 2 are summarized in this paper:<br />
[http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADP023792]<br />
and this podcast [http://www.rce-cast.com/components/com_podcast/media/40RCE-xdmf.mp3]</div>Dave.demarlehttps://www.xdmf.org/index.php?title=Version_2&diff=178Version 22016-04-03T12:27:18Z<p>Dave.demarle: </p>
<hr />
<div>Version "2" of Xdmf is being deprecated but it can be found at:<br />
<br />
git clone git://xdmf.org/Xdmf.git<br />
<br />
There were two important branches in the repository, "master" (git SHA 6ca45404) and "pv". The "pv" branch (git SHA 24470abd) was restructured during the ParaView 4 release to update it to be compatible with VTK 6.x's modularized build system.<br />
<br />
The updates to Xdmf in version 2 are summarized in this paper:<br />
[http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADP023792]<br />
and this podcast [http://www.rce-cast.com/components/com_podcast/media/40RCE-xdmf.mp3]</div>Dave.demarlehttps://www.xdmf.org/index.php?title=Get_Xdmf&diff=177Get Xdmf2016-04-02T19:38:16Z<p>Dave.demarle: </p>
<hr />
<div>The old version of this page can be found at [http://xdmf.org/index.php/Get_Xdmf_original]<br />
<br />
Xdmf depends on zlib and hdf5 and had a header only dependency on boost. You must obtain and build those projects before you can build xdmf.<br />
To use Xdmf from Python, Tcl or Java you will also need swig.<br />
<br />
To obtain xdmf:<br />
* git clone git://public.kitware.com/Xdmf.git<br />
* mkdir build<br />
* cd build<br />
* ccmake ..<br />
* make<br />
<br />
To use xdmf from wrapped languages you will need to configure XDMF_WRAP_PYTHON, or XDMF_WRAP_JAVA on in ccmake.<br />
<br />
Xdmf is also mirrored in VTK. To use XDMF within VTK, simply turn on Module_vtkIOXdmf2 or Module_vtkIOXdmf3 on the advanced options page of you VTK configuration.</div>Dave.demarlehttps://www.xdmf.org/index.php?title=Get_Xdmf&diff=176Get Xdmf2016-04-02T19:37:53Z<p>Dave.demarle: </p>
<hr />
<div>The old version of this page can be found at [http://xdmf.org/index.php/Get_Xdmf_original]<br />
<br />
Xdmf depends on zlib and hdf5 and had a header only dependency on boost. You must obtain and build those projects before you can build xdmf.<br />
To use Xdmf from Python, Tcl or Java you will also need swig.<br />
<br />
To obtain xdmf:<br />
* git clone git://public.kitware.com/Xdmf.git XDMF<br />
* mkdir build<br />
* cd build<br />
* ccmake ..<br />
* make<br />
<br />
To use xdmf from wrapped languages you will need to configure XDMF_WRAP_PYTHON, or XDMF_WRAP_JAVA on in ccmake.<br />
<br />
Xdmf is also mirrored in VTK. To use XDMF within VTK, simply turn on Module_vtkIOXdmf2 or Module_vtkIOXdmf3 on the advanced options page of you VTK configuration.</div>Dave.demarlehttps://www.xdmf.org/index.php?title=User_talk:Mn1729&diff=164User talk:Mn17292016-03-25T13:53:14Z<p>Dave.demarle: Welcome!</p>
<hr />
<div>'''Welcome to ''XdmfWeb''!'''<br />
We hope you will contribute much and well.<br />
You will probably want to read the [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents help pages].<br />
Again, welcome and have fun! [[User:Dave.demarle|Dave.demarle]] ([[User talk:Dave.demarle|talk]]) 09:53, 25 March 2016 (EDT)</div>Dave.demarlehttps://www.xdmf.org/index.php?title=User:Mn1729&diff=163User:Mn17292016-03-25T13:53:14Z<p>Dave.demarle: Creating user page for new user.</p>
<hr />
<div>I use HDF for meshes and found some mistakes in some of the xml file formats on this page. I would like to correct them for future users.</div>Dave.demarlehttps://www.xdmf.org/index.php?title=User_talk:Milanberjan&diff=159User talk:Milanberjan2015-05-01T14:05:36Z<p>Dave.demarle: Welcome!</p>
<hr />
<div>'''Welcome to ''XdmfWeb''!'''<br />
We hope you will contribute much and well.<br />
You will probably want to read the [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents help pages].<br />
Again, welcome and have fun! [[User:Dave.demarle|Dave.demarle]] ([[User talk:Dave.demarle|talk]]) 10:05, 1 May 2015 (EDT)</div>Dave.demarlehttps://www.xdmf.org/index.php?title=User:Milanberjan&diff=158User:Milanberjan2015-05-01T14:05:35Z<p>Dave.demarle: Creating user page for new user.</p>
<hr />
<div></div>Dave.demarlehttps://www.xdmf.org/index.php?title=User_talk:Chrisr&diff=156User talk:Chrisr2015-04-17T13:43:30Z<p>Dave.demarle: Welcome!</p>
<hr />
<div>'''Welcome to ''XdmfWeb''!'''<br />
We hope you will contribute much and well.<br />
You will probably want to read the [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents help pages].<br />
Again, welcome and have fun! [[User:Dave.demarle|Dave.demarle]] ([[User talk:Dave.demarle|talk]]) 09:43, 17 April 2015 (EDT)</div>Dave.demarlehttps://www.xdmf.org/index.php?title=User:Chrisr&diff=155User:Chrisr2015-04-17T13:43:29Z<p>Dave.demarle: Creating user page for new user.</p>
<hr />
<div></div>Dave.demarlehttps://www.xdmf.org/index.php?title=User_talk:Dhuckaby&diff=152User talk:Dhuckaby2015-01-12T15:08:11Z<p>Dave.demarle: Welcome!</p>
<hr />
<div>'''Welcome to ''XdmfWeb''!'''<br />
We hope you will contribute much and well.<br />
You will probably want to read the [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents help pages].<br />
Again, welcome and have fun! [[User:Dave.demarle|Dave.demarle]] ([[User talk:Dave.demarle|talk]]) 10:08, 12 January 2015 (EST)</div>Dave.demarlehttps://www.xdmf.org/index.php?title=User:Dhuckaby&diff=151User:Dhuckaby2015-01-12T15:08:11Z<p>Dave.demarle: Creating user page for new user.</p>
<hr />
<div>Mechanical Engineer<br />
National Energy Technology Laboratory</div>Dave.demarlehttps://www.xdmf.org/index.php?title=Get_Xdmf&diff=123Get Xdmf2014-08-19T20:42:37Z<p>Dave.demarle: </p>
<hr />
<div>The old version of this page can be found at [http://xdmf.org/index.php/Get_Xdmf_original]<br />
<br />
Xdmf depends on zlib and hdf5 and had a header only dependency on boost. You must obtain and build those projects before you can build xdmf.<br />
To use Xdmf from Python, Tcl or Java you will also need swig.<br />
<br />
To obtain xdmf:<br />
* git clone git://public.kitware.com/Xdmf2.git XDMF<br />
* mkdir build<br />
* cd build<br />
* ccmake ../XDMF<br />
* make<br />
<br />
To use xdmf from wrapped languages you will need to configure XDMF_WRAP_PYTHON, or XDMF_WRAP_JAVA on in ccmake.<br />
<br />
Xdmf is also mirrored in VTK. To use XDMF within VTK, simply turn on Module_vtkIOXdmf2 or Module_vtkIOXdmf3 on the advanced options page of you VTK configuration.</div>Dave.demarlehttps://www.xdmf.org/index.php?title=Examples/imagedata&diff=122Examples/imagedata2014-08-19T19:35:35Z<p>Dave.demarle: </p>
<hr />
<div>The following will read in an array of floats from h5 with the values associated with the points.<br />
<br />
<code format="XML"><br />
<br />
<?xml version="1.0" ?><br />
<!DOCTYPE Xdmf SYSTEM "Xdmf.dtd" []><br />
<Xdmf xmlns:xi="http://www.w3.org/2003/XInclude" Version="2.2"><br />
<Domain><br />
<Grid Name="Particle Images" GridType="Uniform"><br />
<Topology TopologyType="3DCORECTMesh" Dimensions="400 300 300"/><br />
<Geometry GeometryType="ORIGIN_DXDYDZ"><br />
<DataItem Name="Origin" Dimensions="3" NumberType="Float" Precision="4" Format="XML"><br />
0 0 0<br />
</DataItem><br />
<DataItem Name="Spacing" Dimensions="3" NumberType="Float" Precision="4" Format="XML"><br />
1 1 1<br />
</DataItem><br />
</Geometry><br />
<Attribute Name="second 0" AttributeType="Scalar" Center="Node"><br />
<DataItem Format="HDF" NumberType="UInt" Precision="2" Dimensions="400 300 300">test.hdf:/images/0/image</DataItem><br />
</Attribute><br />
</Grid><br />
</Domain><br />
</Xdmf><br />
<br />
</code><br />
<br />
<br />
The following will read in an array of floats from h5 with the values associated with the cells.<br />
<br />
<code format="XML"><br />
<br />
<?xml version="1.0" ?><br />
<!DOCTYPE Xdmf SYSTEM "Xdmf.dtd" []><br />
<Xdmf xmlns:xi="http://www.w3.org/2003/XInclude" Version="2.2"><br />
<Domain><br />
<Grid Name="Particle Images" GridType="Uniform"><br />
<Topology TopologyType="3DCORECTMesh" Dimensions="401 301 301"/><br />
<Geometry GeometryType="ORIGIN_DXDYDZ"><br />
<DataItem Name="Origin" Dimensions="3" NumberType="Float" Precision="4" Format="XML"><br />
0 0 0<br />
</DataItem><br />
<DataItem Name="Spacing" Dimensions="3" NumberType="Float" Precision="4" Format="XML"><br />
1 1 1<br />
</DataItem><br />
</Geometry><br />
<Attribute Name="second 0" AttributeType="Scalar" Center="Cell"><br />
<DataItem Format="HDF" NumberType="UInt" Precision="2" Dimensions="400 300 300">test.hdf:/images/0/image</DataItem><br />
</Attribute><br />
</Grid><br />
</Domain><br />
</Xdmf><br />
<br />
</code></div>Dave.demarlehttps://www.xdmf.org/index.php?title=Main_Page&diff=121Main Page2014-08-19T19:29:28Z<p>Dave.demarle: </p>
<hr />
<div>[[Image:XdmfLogo1.gif]]<br />
<br />
<span style='color:blue'><big>e<span style='color:red'>'''X'''</span>tensible <span style='color:red'>'''D'''</span>ata <span style='color:red'>'''M'''</span>odel and <span style='color:red'>'''F'''</span>ormat</big></span><br />
<br />
<br />
<br />
The need for a standardized method to exchange scientific data between High Performance Computing codes and tools lead to the development of the eXtensible Data Model and Format (XDMF) . Uses for XDMF range from a standard format used by HPC codes to take advantage of widely used visualization programs like ParaView, to a mechanism for performing coupled calculations using multiple, previously stand alone codes. <br />
<br />
Data format refers to the raw data to be manipulated. Information like number type ( float, integer, etc.), precision, location, rank, and dimensions completely describe the any dataset regardless of its size. The description of the data is also separate from the values themselves. We refer to the description of the data as '''Light''' data and the values themselves as '''Heavy''' data. Light data is small and can be passed between modules easily. Heavy data may be potentially enormous; movement needs to be kept to a minimum. Due to the different nature of heavy and light data, they are stored using separate mechanisms. Light data is stored using XML, Heavy data is typically stored using HDF5. While we could have chosen to store the light data using HDF5 attributes using XML does not require every tool to have access to the compiled HDF5 libraries in order to perform simple operations.<br />
<br />
Data model refers to the intended use of the data. For example, a three dimensional array of floating point vales may be the X,Y,Z geometry for a grid or calculated vector values. Without a data model, it is impossible to tell the difference. Since the data model only describes the data, it is purely light data and thus stored using XML. It is targeted at scientific simulation data concentrating on scalars, vectors, and tensors defined on some type of computational grid. Structured and Unstructured grids are described via their topology and geometry. Calculated, time varying data values are described as attributes of the grid. The actual values for the grid geometry, connectivity, and attribute values are contained in the data format. This separation of data format and model allows HPC codes to efficiently produce and store vales in a convenient manner without being encumbered by our data model which may be different from their internal arrangement.<br />
<br />
<br />
XDMF uses XML to store Light data and to describe the data Model. HDF5 is used to store Heavy data. The data Format is stored redundantly in both XML and HDF5. This allows tools to parse XML to determine the resources that will be required to access the Heavy data. <br />
<br />
The data model in XDMF stored in XML provides the knowledge of what is represented by the Heavy data. In this model, HPC data is viewed as a hierarchy of Domains. A Domain must contain at least one Grid. A Grid is the basic representation of both the geometric and computed/measured values. A Grid is considered to be a group of elements with Structured or Unstructured Topology and their associated values. In addition to the topology of the Grid, Geometry, specifying the X, Y, and Z positions of the Grid is required. Finally, a Grid may have one or more Attributes. Attributes are used to store any other value associated with the grid and may be referenced to the Grid or to individual cells that comprise the Grid. <br />
<br />
The concept of separating the light data from the heavy data is critical to the performance of this data model and format. HPC codes can read and write data in large, contiguous chunks that are natural to their internal data storage, to achieve optimal I/O performance. If codes were required to significantly re-arrange data prior to I/O operations, data locality, and thus performance, could be adversely affected, particularly on codes that attempt to make maximum use of memory cache. The complexity of the dataset is described in the light data portion, which is small and transportable. For example, the light data might specify a topology of one million hexaherda while the heavy data would contain the geometric XYZ values of the mesh and pressure values at the cell centers stored in large, contiguous arrays. This key feature will allow reusable tools to be built that do not put onerous requirements on HPC codes. Despite the complexity of the organization described in the XML below, the HPC code only needs to produce the three HDF5 datasets for geometry, connectivity, and pressure values.<br />
<br />
While not required, a C++ API is provided to read and write XDMF data. This API has also been wrapped so it is available from popular languages like Python, Tcl, and Java. The API is not necessary in order to produce or consume XDMF data. Currently several HPC codes that already produced HDF5 data, use native text output to produce the XML necessary for valid XDMF. <br />
<br />
'''More Detail'''<br />
<br />
*[[XDMF Model and Format]]<br />
<br />
*[[XDMF API]]<br />
<br />
'''How do I ...'''<br />
# [[Get Xdmf]]<br />
# [[Read Xdmf]]<br />
# [[Write Xdmf]]<br />
# [[Write from Fortran]]<br />
# [[Read from MySQL]]<br />
# [[Parallel IO with MPI]]<br />
<br />
'''Data Format Examples'''<br />
* The files for the xdmf3 regression test suite can be obtained from a VTK build tree in $BLDTREE/ExternalData/Testing/Data/XDMF<br />
* Generate or read in data to ParaView, and save it into XDMF format.<br />
* [http://www.paraview.org/Wiki/ParaView/Data_formats#Reading_a_time_varying_Raw_file_into_Paraview| time varying binary data dumps]<br />
* [[examples/imagedata | ImageData from h5 array]]<br />
<br />
'''History and Road Map'''<br />
* [[Version 1]]<br />
* [[Version 2]]<br />
* [[Version 3]]<br />
* [[V3_Road_Feature_Request|Feature Requests]]<br />
<br />
'''Mailing list'''<br />
* Join the Xdmf mailing list [http://www.kitware.com/cgi-bin/mailman/listinfo/xdmf here]<br />
<br />
'''Bug reports'''<br />
* To report a bug or request a feature, go to the [http://public.kitware.com/Bug Mantis Bugtracking system] and select Project:Xdmf from the dropdown list.<br />
<br />
=== web site administration ===<br />
<br />
'''Wiki Account'''<br />
* Please improve the pages! Send an email to Dave DeMarle at kitware.com with XDMF in the subject that includes your preferred user name and email address in the message body to do so.<br />
<br />
* [http://www.mediawiki.org/wiki/Help:Configuration_settings Configuration settings list]<br />
* [http://www.mediawiki.org/wiki/Help:FAQ MediaWiki FAQ]<br />
* [http://mail.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list]</div>Dave.demarlehttps://www.xdmf.org/index.php?title=Get_Xdmf&diff=120Get Xdmf2014-08-19T19:28:31Z<p>Dave.demarle: add updated content</p>
<hr />
<div>The old version of this page can be found at [http://xdmf.org/index.php/Get_Xdmf_original]<br />
<br />
Xdmf depends on boost, zlib and hdf5. You must build those projects before you can build xdmf.<br />
To use Xdmf from Python, Tcl or Java you will also need swig.<br />
<br />
To obtain xdmf:<br />
* git clone git://public.kitware.com/Xdmf2.git XDMF<br />
* mkdir build<br />
* cd build<br />
* ccmake ../XDMF<br />
* make<br />
<br />
To use xdmf from wrapped languages you will need to configure XDMF_WRAP_PYTHON, or XDMF_WRAP_JAVA on in ccmake.<br />
<br />
Xdmf is also mirrored in VTK. To use XDMF within VTK, simply turn on Module_vtkIOXdmf2 or Module_vtkIOXdmf3 on the advanced options page of you VTK configuration.</div>Dave.demarlehttps://www.xdmf.org/index.php?title=Get_Xdmf_original&diff=119Get Xdmf original2014-08-19T19:21:57Z<p>Dave.demarle: Dave.demarle moved page Get Xdmf to Get Xdmf original without leaving a redirect</p>
<hr />
<div>== '''Obtaining and Installing XDMF''' ==<br />
<br />
<pre style="color: red"> These instruction pertain to Xdmf version 1. </pre><br />
<br />
The eXtensible Data Model and Format (XDMF) is installed and maintained, along with the rest of the Interdisciplinary Computing Environment, on the HPC systems at the ARL MSRC. If you need access on other platforms, obtain the source via CVS and follow the installation instructions. XDMF has been built and tested on a variety of UNIX platforms and on Win32 and Cygwin.<br />
CVS Access to the XDMF Source Code Repository<br />
<br />
XDMF is obtained via CVS access to the XDMF source code repository as a user (anonymous, read-only access). One of the advantages of CVS access is that you can incrementally update your repository without having to retrieve the entire source distribution. The following assumes that you have a basic knowledge of CVS.<br />
<br />
Anonymous User Read-Only Access<br />
<br />
You can obtain read-only access to the CVS repository as follows.<br />
<br />
cvs -d :pserver:anonymous@public.kitware.com:/cvsroot/Xdmf login<br />
(respond with password xdmf)<br />
<br />
Follow this command by checking out the source code:<br />
cvs -d :pserver:anonymous@public.kitware.com:/cvsroot/Xdmf checkout Xdmf<br />
<br />
This CVS tree is Xdmf. Checkout the CVS in a clean directory as it will create an Xdmf directory and possibly overwrite an existing Xdmf tree. You will also need CMake which is a new cross platform build tool.<br />
<br />
'''Installation'''<br />
<br />
XDMF depends on Expat and HDF5. While a version of Expat and HDF5 comes with the the XDMF source, you might want to get the latest version of these packages. Obtain Expat from here . Obtain HDF from here. You'll also want Python (version 2.5 or later). Obtain Python from [http://www.python.org Python.Org]. If you want to use the scientific visualization tools, you'll need vtk ( version 5.0 or later ). Obtain vtk from [http://public.kitware.com Kitware.Com].<br />
<br />
<br />
Xdmf uses CMake for installation. Pre-Built binaries of CMake are available for many platforms, or you can install from source. The advantage of CMake is that it provides a consistent build system for UNIX and Win32. For this reason, we replaced the previous autoconf <nowiki>(./configure --prefix...)</nowiki> method with CMake.<br />
<br />
<br />
Once you�ve installed the necessary support packages, begin to build Xdmf for your platform. For example, suppose you wish to build a Linux version :<br />
<br />
<br />
<br />
# mkdir MyXdmf<br />
# cd MyXdmf<br />
# cvs <nowiki>-d ...</nowiki> login<br />
# cvs <nowiki>-d ...</nowiki> co Xdmf This creates an Xdmf directory of the source code<br />
# mkdir Linux<br />
# cd Linux<br />
# cmake ../Xdmf<br />
<br />
<br />
<br />
CMake comes with several different commands. The two most important are cmake (the command line version) and ccmake (a curses based gui version). Both versions create a Makefile in the current directory and a file ''CMakeCache.txt'' that contains the compile time options. Options include things like additional compiler flags, where to find various packages (like HDF and expat), and which parts to build ( shared objects, python interface, etc.). As you change the CMakeCache.txt file either by hand or via the gui, additional options may appear. For example, if you decide to build the Python interface, new options for the location of Python include files and libraries will appear in the CMakeCache.txt file after you re-run cmake.<br />
<br />
<br />
<br />
In short, you run cmake, change CMakeCache.txt, and re-run cmake until you have the configuration you want. CMake is fairly sophisticated and can make reasonable guesses for many of the options.<br />
<br />
<br />
<br />
Once this configuration process is complete, run ''make'' and the appropriate binaries will be built in the directory MyXdmf/Linux/bin. For each architecture, create a new directory and repeat the process. This allows you to keep all platforms synchronized to the same source code base.Depending on the configuration you will see the following files :<br />
<br />
* libXdmf.[a so dll] C++ class library for XDMF<br />
* _Xdmf.[so dll] Python interface<br />
* libXdmfTCL.[so dll] Tcl interface<br />
* XdmfFormatExample Executable to write/read XDMF file<br />
<br />
<br />
<br />
The Python interface has been built with the shadow classes. This means that accessing XDMF via Python done in an Object Oriented manner just like in C++. To use the Object Oriented interface, you need to copy Xdmf.py ( found in <nowiki>.../Xdmf/libsrc/Xdmf.py</nowiki>) somewhere in your Python path.</div>Dave.demarlehttps://www.xdmf.org/index.php?title=Get_Xdmf_original&diff=118Get Xdmf original2014-08-19T19:21:11Z<p>Dave.demarle: /* Obtaining and Installing XDMF */</p>
<hr />
<div>== '''Obtaining and Installing XDMF''' ==<br />
<br />
<pre style="color: red"> These instruction pertain to Xdmf version 1. </pre><br />
<br />
The eXtensible Data Model and Format (XDMF) is installed and maintained, along with the rest of the Interdisciplinary Computing Environment, on the HPC systems at the ARL MSRC. If you need access on other platforms, obtain the source via CVS and follow the installation instructions. XDMF has been built and tested on a variety of UNIX platforms and on Win32 and Cygwin.<br />
CVS Access to the XDMF Source Code Repository<br />
<br />
XDMF is obtained via CVS access to the XDMF source code repository as a user (anonymous, read-only access). One of the advantages of CVS access is that you can incrementally update your repository without having to retrieve the entire source distribution. The following assumes that you have a basic knowledge of CVS.<br />
<br />
Anonymous User Read-Only Access<br />
<br />
You can obtain read-only access to the CVS repository as follows.<br />
<br />
cvs -d :pserver:anonymous@public.kitware.com:/cvsroot/Xdmf login<br />
(respond with password xdmf)<br />
<br />
Follow this command by checking out the source code:<br />
cvs -d :pserver:anonymous@public.kitware.com:/cvsroot/Xdmf checkout Xdmf<br />
<br />
This CVS tree is Xdmf. Checkout the CVS in a clean directory as it will create an Xdmf directory and possibly overwrite an existing Xdmf tree. You will also need CMake which is a new cross platform build tool.<br />
<br />
'''Installation'''<br />
<br />
XDMF depends on Expat and HDF5. While a version of Expat and HDF5 comes with the the XDMF source, you might want to get the latest version of these packages. Obtain Expat from here . Obtain HDF from here. You'll also want Python (version 2.5 or later). Obtain Python from [http://www.python.org Python.Org]. If you want to use the scientific visualization tools, you'll need vtk ( version 5.0 or later ). Obtain vtk from [http://public.kitware.com Kitware.Com].<br />
<br />
<br />
Xdmf uses CMake for installation. Pre-Built binaries of CMake are available for many platforms, or you can install from source. The advantage of CMake is that it provides a consistent build system for UNIX and Win32. For this reason, we replaced the previous autoconf <nowiki>(./configure --prefix...)</nowiki> method with CMake.<br />
<br />
<br />
Once you�ve installed the necessary support packages, begin to build Xdmf for your platform. For example, suppose you wish to build a Linux version :<br />
<br />
<br />
<br />
# mkdir MyXdmf<br />
# cd MyXdmf<br />
# cvs <nowiki>-d ...</nowiki> login<br />
# cvs <nowiki>-d ...</nowiki> co Xdmf This creates an Xdmf directory of the source code<br />
# mkdir Linux<br />
# cd Linux<br />
# cmake ../Xdmf<br />
<br />
<br />
<br />
CMake comes with several different commands. The two most important are cmake (the command line version) and ccmake (a curses based gui version). Both versions create a Makefile in the current directory and a file ''CMakeCache.txt'' that contains the compile time options. Options include things like additional compiler flags, where to find various packages (like HDF and expat), and which parts to build ( shared objects, python interface, etc.). As you change the CMakeCache.txt file either by hand or via the gui, additional options may appear. For example, if you decide to build the Python interface, new options for the location of Python include files and libraries will appear in the CMakeCache.txt file after you re-run cmake.<br />
<br />
<br />
<br />
In short, you run cmake, change CMakeCache.txt, and re-run cmake until you have the configuration you want. CMake is fairly sophisticated and can make reasonable guesses for many of the options.<br />
<br />
<br />
<br />
Once this configuration process is complete, run ''make'' and the appropriate binaries will be built in the directory MyXdmf/Linux/bin. For each architecture, create a new directory and repeat the process. This allows you to keep all platforms synchronized to the same source code base.Depending on the configuration you will see the following files :<br />
<br />
* libXdmf.[a so dll] C++ class library for XDMF<br />
* _Xdmf.[so dll] Python interface<br />
* libXdmfTCL.[so dll] Tcl interface<br />
* XdmfFormatExample Executable to write/read XDMF file<br />
<br />
<br />
<br />
The Python interface has been built with the shadow classes. This means that accessing XDMF via Python done in an Object Oriented manner just like in C++. To use the Object Oriented interface, you need to copy Xdmf.py ( found in <nowiki>.../Xdmf/libsrc/Xdmf.py</nowiki>) somewhere in your Python path.</div>Dave.demarlehttps://www.xdmf.org/index.php?title=Parallel_IO_with_MPI&diff=117Parallel IO with MPI2014-08-19T19:17:41Z<p>Dave.demarle: </p>
<hr />
<div><pre style="color: red">Note code snippets on this page are from version 2 or 1 and need updating for xdmf 3.</pre><br />
<br />
(code, example and description provided by Will Dicharry)<br />
<br />
=== Controlling the I/O process for XdmfHeavyData ===<br />
<br />
The XDMF API provides a customization point to allow the heavy data sets<br />
to be written in a certain manner, depending on the application<br />
environment and independent of the heavy dataset format. New I/O<br />
strategies can be implemented by subclassing the callback classes<br />
defined in XdmfHeavyData.h and attaching them to XdmfHeavyData classes.<br />
This method has the advantage of applying a common strategy to any<br />
XdmfHeavyData subclass.<br />
<br />
The system works in the following way:<br />
<br />
XdmfHeavyData contains the non-virtual methods Open, Close, Read, and<br />
Write and the virtual methods DoOpen, DoClose, DoRead, and DoWrite.<br />
XdmfHeavyData subclasses should override these to open, close, read, and write a particular heavy data format independent of the application environment.<br />
<br />
In addition there are 4 callback base classes XdmfOpenCallback, XdmfCloseCallback, XdmfReadCallback, and XdmfWriteCallback. The callbacks should be implemented to replace the XdmfHeavyData's own Do methods. To decorate the existing I/O code, call dataset->Do* within the callback's Do* method. This allows implementors to define both pre and post callbacks, or even disable the output of a dataset entirely.<br />
<br />
=== Example ===<br />
<br />
Suppose we have an MPI environment with 4 processes. Each process<br />
contains part of an array with 100 values numbered 0 to 99; process 0<br />
with items 0-24, process 1 with items 25-49, etc. We would like to<br />
write this data to a single HDF file containing a single array of 100<br />
values, stored in increasing numerical order. To do this, we will<br />
communicate all of the data to process 0 and let process 0 handle the<br />
actual output of the array.<br />
<br />
We start by including the necessary headers and defining a very simple<br />
stream buffer utility class that simplifies encoding and decoding data<br />
between processes:<br />
<br />
<code><br />
#include <mpi.h><br />
#include <XdmfArray.h><br />
#include <XdmfHDF.h><br />
<br />
/// Simple memory buffer implementation that keeps track of it's stream pointer.<br />
class Buffer {<br />
private:<br />
std::size_t m_size;<br />
char* m_data;<br />
char* m_put;<br />
char* m_tell;<br />
<br />
public:<br />
Buffer( std::size_t size ) :<br />
m_size( size ),<br />
m_data( new char[size] ),<br />
m_put( m_data ),<br />
m_tell( m_data )<br />
{}<br />
<br />
~Buffer() {<br />
delete [] m_data;<br />
}<br />
<br />
/// copy a contiguous block into the buffer<br />
void put( const void* data, std::size_t size ) {<br />
memcpy( m_put, data, size );<br />
m_put += size;<br />
}<br />
<br />
/// put a single value into the buffer<br />
template< typename T ><br />
void put( const T& t ) {<br />
std::size_t size = sizeof( T );<br />
put( &t, size );<br />
}<br />
<br />
/// copy a contiguous block of data from the buffer to an already<br />
/// allocated location<br />
void tell( void* out, std::size_t size ) {<br />
memcpy( out, m_tell, size );<br />
m_tell += size;<br />
}<br />
<br />
<br />
/// Copy a single value into the buffer.<br />
template< typename T ><br />
T tell() {<br />
std::size_t tsize = sizeof( T );<br />
T tmp;<br />
tell( &tmp, tsize );<br />
return tmp;<br />
}<br />
<br />
std::size_t size() const {<br />
return m_size;<br />
}<br />
<br />
char* pointer() {<br />
return m_data;<br />
}<br />
<br />
void reset() {<br />
m_put = m_data;<br />
m_tell = m_data;<br />
}<br />
};<br />
</code><br />
<br />
We haven't yet called on the Xdmf API to do anything, the Buffer class<br />
is just a utility that we will use later.<br />
<br />
Now, we write our callback class that will customize the process of<br />
opening, reading, writing, and closing the heavy dataset. Since our<br />
communication strategy must implement a new function for each step, we will write one class that inherits XdmfOpenCallback, XdmfCloseCallback,<br />
XdmfWriteCallback, and XdmfReadCallback. Each one of the base classes<br />
has a single virtual method that takes a pointer to a XdmfHeavyData and<br />
the same arguments that XdmfHeavyData::Open, XdmfHeavyData::Close,<br />
XdmfHeavyData::Write, or XdmfHeavyData::Write would take and wraps the synchronization code around the actual XdmfHeavyData methods. Note that we call the virtual DoOpen, DoClose, DoRead, and DoWrite methods rather than the non-virtual Open, Close, Read, and Write methods.<br />
<br />
<code><br />
/// Callback implements parallel IO by communicating to process 0<br />
class CommunicationCallback :<br />
public XdmfOpenCallback,<br />
public XdmfWriteCallback,<br />
public XdmfCloseCallback,<br />
public XdmfReadCallback<br />
{<br />
private:<br />
int mCommRank;<br />
int mCommSize;<br />
public:<br />
<br />
/// Constructor initializes the Number of processors and local process<br />
/// ID.<br />
CommunicationCallback() {<br />
MPI_Comm_size( MPI_COMM_WORLD, &mCommSize );<br />
MPI_Comm_rank( MPI_COMM_WORLD, &mCommRank );<br />
}<br />
<br />
/// Reimplemented from XdmfOpenCallback::DoOpen. Only rank 0 is going<br />
/// to read or write, so only rank 0 will open the file.<br />
XdmfInt32 DoOpen(<br />
XdmfHeavyData* ds,<br />
XdmfConstString name,<br />
XdmfConstString access )<br />
{<br />
if ( mCommRank == 0 ) {<br />
// Call the actual DoOpen method from XdmfHeavyData<br />
return ds->DoOpen( name, access );<br />
} else {<br />
// Not rank 0, nothing to do.<br />
return XDMF_SUCCESS;<br />
}<br />
}<br />
<br />
/// Reimplemented from XdmfCloseCallback::DoClose. Again, only rank 0<br />
/// needs to do anything.<br />
XdmfInt32 DoClose( XdmfHeavyData* ds )<br />
{<br />
if ( mCommRank == 0 ) {<br />
// Call the heavy dataset's native close method.<br />
return ds->DoClose();<br />
} else {<br />
// not rank 0, nothing to do.<br />
return XDMF_SUCCESS;<br />
}<br />
}<br />
<br />
/// Reimplemented from XdmfWriteCallback::DoWrite. If the local<br />
/// process ID is 0, then we expect to receive data from everyone<br />
/// else. Otherwise, we send data. Rank 0 does all of the writing.<br />
XdmfInt32 DoWrite( XdmfHeavyData* ds, XdmfArray* array )<br />
{<br />
// This implementation assumes process 0 has the same data<br />
// size as everyone else<br />
<br />
// set up a stream buffer that is large enough to hold the data to<br />
// be sent or received. We require enough space for the rank,<br />
// start, stride, and count for the array plus enough space to hold<br />
// the actual array data.<br />
XdmfInt64 start[1], stride[1], count[1];<br />
XdmfInt32 slab_rank = ds->GetHyperSlab( start, stride, count );<br />
std::size_t slab_info_size =<br />
sizeof( XdmfInt32 ) // slab rank<br />
+ slab_rank * sizeof( XdmfInt64 ) * 3; // start, stride, and count<br />
Buffer buf( slab_info_size + array->GetCoreLength() );<br />
<br />
// If the local process ID is nonzero, pack the buffer and send to<br />
// process 0.<br />
if ( mCommRank != 0 ) {<br />
// copy rank and slab information into the buffer.<br />
buf.put( slab_rank );<br />
for ( int i = 0; i < slab_rank; ++i ) {<br />
buf.put( start[i] );<br />
buf.put( stride[i] );<br />
buf.put( count[i] );<br />
}<br />
// copy the actual data into the buffer.<br />
buf.put( array->GetDataPointer(), array->GetCoreLength() );<br />
// send to rank 0 in the global communicator.<br />
MPI_Send(<br />
buf.pointer(),<br />
buf.size(),<br />
MPI_BYTE,<br />
0,<br />
0,<br />
MPI_COMM_WORLD );<br />
} else {<br />
// Local process ID is 0, so we write local data then receive and<br />
// write remote data.<br />
<br />
// first, it's easy to write the local data<br />
ds->DoWrite( array );<br />
<br />
int processes_received = 1; // local data for process 0 is written<br />
<br />
// loop until the data for all processes has been received.<br />
while ( processes_received < mCommSize ) {<br />
// Fill the buffer with incoming data. We are assuming here<br />
// that all processes contain the same amount of data.<br />
MPI_Recv(<br />
buf.pointer(),<br />
buf.size(),<br />
MPI_BYTE,<br />
MPI_ANY_SOURCE,<br />
0,<br />
MPI_COMM_WORLD,<br />
0 );<br />
processes_received++;<br />
<br />
// unpack the buffer<br />
buf.reset(); // reset the stream pointer to the beginning<br />
// we mean rank in the linear algebra sense here<br />
slab_rank = buf.tell< XdmfInt32 >();<br />
// start, stride, and count are next.<br />
for( int i = 0; i < slab_rank; ++i ) {<br />
start[i] = buf.tell< XdmfInt64 >();<br />
stride[i] = buf.tell< XdmfInt64 >();<br />
count[i] = buf.tell< XdmfInt64 >();<br />
}<br />
// select the correct hyper slab in the heavy data set.<br />
ds->SelectHyperSlab( start, stride, count );<br />
// allocate an array to hold the off-core data.<br />
XdmfArray* recv = new XdmfArray;<br />
recv->CopyShape( array );<br />
// place the received data into the array.<br />
buf.tell( recv->GetDataPointer(), recv->GetCoreLength() );<br />
// write the off core data to the dataset by calling the heavy<br />
// data's DoWrite method.<br />
ds->DoWrite( recv );<br />
delete recv;<br />
}<br />
}<br />
<br />
return XDMF_SUCCESS;<br />
}<br />
<br />
/// Reimplemented from XdmfReadCallback::DoRead. Read the data from a<br />
/// heavy data source into an array only if the local process ID is 0.<br />
/// Otherwise, do nothing.<br />
XdmfArray* DoRead( XdmfHeavyData* ds, XdmfArray* array )<br />
{<br />
if ( mCommRank == 0 ) {<br />
// defer to the actual heavy data implementation of DoRead.<br />
return ds->DoRead( array );<br />
} else {<br />
// return an empty array.<br />
return NULL;<br />
}<br />
}<br />
}; // end of class CommunicationCallback<br />
</code><br />
<br />
One of the useful features of the above code is that it relies only on the abstract portion of the XdmfHeavyData interface. Therefore, it is general enough to be used when writing to any heavy dataset (either HDF or MySQL). In the future, if other heavy data output formats are added, the same strategy could apply to them as well.<br />
<br />
Now, we write a main program that generates the data, writes to an HDF dataset, and reads from the same file to verify the round trip.<br />
<br />
<code><br />
char const * const kDatasetName = "FILE:TestFile.h5:/XdmfHDFMPI";<br />
<br />
int main( int argc, char* argv[] ) {<br />
// Initialize MPI<br />
MPI_Init( &argc, &argv );<br />
<br />
// determine the local process ID<br />
int rank;<br />
MPI_Comm_rank( MPI_COMM_WORLD, &rank );<br />
<br />
// Create an HDF dataset to write out to.<br />
XdmfHDF* H5 = new XdmfHDF();<br />
// Attach an instance of the CommunicationCallback class defined above<br />
// to customize opening, writing, and closing the dataset.<br />
CommunicationCallback* cb = new CommunicationCallback;<br />
H5->setOpenCallback( cb );<br />
H5->setWriteCallback( cb );<br />
H5->setCloseCallback(cb );<br />
<br />
// Allocate an array of size 25 and fill it with values depending<br />
// on the local process ID (process 0 has 0-24, process 1 has<br />
// 25-49,...)<br />
XdmfArray* MyData = new XdmfArray();<br />
MyData->SetNumberType( XDMF_FLOAT32_TYPE );<br />
MyData->SetNumberOfElements( 25 );<br />
MyData->Generate( rank * 25, rank*25 + 24 );<br />
<br />
// Set the dataset's type to the array's type<br />
H5->CopyType( MyData );<br />
// Set up the dimensions of the dataset.<br />
XdmfInt64 dims[1];<br />
dims[0] = 100;<br />
H5->SetShape( 1, dims );<br />
// Set up the hyper slab for the dataset. Each process will select a<br />
// distinct portion of the dataset (process 0 has 0-24, process 1<br />
// 25-49,...)<br />
XdmfInt64 start[1], stride[1], count[1];<br />
start[0] = rank * 25;<br />
stride[0] = 1;<br />
count[0] = 25;<br />
// select the slab in the dataset corresponding to the local process.<br />
H5->SelectHyperSlab( start, stride, count );<br />
// Open the dataset.<br />
H5->Open( kDatasetName, "w" );<br />
// Write the array.<br />
H5->Write( MyData );<br />
// Close the dataset.<br />
H5->Close();<br />
<br />
// writing is complete, now we have a quick test to ensure the data<br />
// survives a round trip.<br />
bool failure = false;<br />
<br />
// Create a new dataset to read from<br />
XdmfHDF* H5In = new XdmfHDF();<br />
// Use the same callback.<br />
H5In->setReadCallback( cb );<br />
H5In->setOpenCallback( cb );<br />
H5In->setCloseCallback( cb );<br />
// Open the dataset for reading.<br />
H5In->Open( kDatasetName, "r" );<br />
// Read the data into an array.<br />
XdmfArray* result = H5In->Read();<br />
<br />
// if the read was successful, make sure the values for all processes<br />
// are in the file.<br />
if ( result ) {<br />
for ( size_t i = 0; i < 100; ++i ) {<br />
float value = result->GetValueAsFloat32( i );<br />
std::cout << i << " " << value << std::endl;<br />
failure = ( value != i );<br />
}<br />
}<br />
<br />
MPI_Finalize();<br />
<br />
delete H5;<br />
delete cb;<br />
delete MyData;<br />
delete H5In;<br />
delete result;<br />
<br />
if ( failure ) {<br />
return -1;<br />
} else {<br />
return 0;<br />
}<br />
};<br />
</code><br />
<br />
Running the program in an MPI environment with 4 processes produces a single HDF5 file TestFile.h5 with a single dataset XdmfHDFMPI containing the numbers 0 to 99. The full source of this example is available in the Xdmf source tree.</div>Dave.demarlehttps://www.xdmf.org/index.php?title=Read_from_MySQL&diff=116Read from MySQL2014-08-19T19:17:14Z<p>Dave.demarle: /* Accessing a MySQL DataBase */</p>
<hr />
<div>== '''Accessing a MySQL DataBase''' ==<br />
<br />
<pre style="color: red">Note SQL support was removed in xdmf 3.</pre><br />
<br />
Partial support for reading data from a MySQL database is available.<br />
MySQL is treated as another HeavyData format like HDF5. Currently<br />
database access is ReadOnly and is accessed by setting the '''Format''' of<br />
the '''DataItem''' in XML equal to '''MySQL'''<br />
<br />
<Attribute Name="Cell Centered Values" Center="Cell"><br />
<DataItem Format="MySQL"<br />
Server="localhost"<br />
User="root"<br />
DataBase="MnmiFromout"<br />
Dimensions="3"<br />
NumberType="Float"><br />
<![CDATA[SELECT X FROM Locations WHERE Time < 0.21]]><br />
</DataItem><br />
</Attribute><br />
<br />
A Valid SQL statement is placed in the CDATA of the DataItem. When the XdmfDataItem is<br />
updated, an atomic query is made and the result is placed in the XdmfArray of the DataItem.<br />
Putting a "<" (less than) in the CDATA will cause an error in the XML parser. The XML example<br />
above shows how to do this correctly.<br />
<br />
The Server, User, and DataBase attributes tell Xdmf how to access MySQL. There is also<br />
a Password attribute. Currently this is just clear text which is a really bad idea. This<br />
will change.</div>Dave.demarlehttps://www.xdmf.org/index.php?title=Write_from_Fortran&diff=115Write from Fortran2014-08-19T19:16:41Z<p>Dave.demarle: /* Writing Xdmf from Fortran */</p>
<hr />
<div>== Writing Xdmf from Fortran ==<br />
<br />
<pre style="color: red">Note code snippets on this page are from version 2 or 1 and need updating for xdmf 3.</pre><br />
<br />
Xdmf can be generated in many different manners. Using the low level HDF5 library and print statements <br />
is certainly one of them. Utilizing the XDMF API, however, provides some convenient advantages. Consider<br />
the following Fortran program which build a grid of Hexahedra with some node and cell centered values :<br />
<br />
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC<br />
C<br />
C Create a Grid of Hexahedron Centered at 0,0,0<br />
C<br />
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC<br />
SUBROUTINE CreateGrid( IDIM, JDIM, KDIM, XYZ, ICONN )<br />
INTEGER IDIM, JDIM, KDIM<br />
REAL*8 XYZ<br />
DIMENSION XYZ( 3, IDIM, JDIM, KDIM )<br />
INTEGER ICONN<br />
DIMENSION ICONN ( 8, ( IDIM - 1 ) * ( JDIM - 1 ) * ( KDIM - 1 ))<br />
INTEGER I, J, K, IDX<br />
REAL*8 X, Y, Z, DX, DY, DZ<br />
C Print *, 'Size = ', IDIM, JDIM, KDIM<br />
PRINT *, 'Initialze Problem'<br />
C XYZ Values of Nodes<br />
C From -1 to 1<br />
DX = 2.0 / ( IDIM - 1 )<br />
DY = 2.0 / ( JDIM - 1 )<br />
DZ = 2.0 / ( KDIM - 1 )<br />
Z = -1.0<br />
DO 112 K= 1, KDIM<br />
Y = -1.0<br />
DO 111 J= 1, JDIM<br />
X = -1.0<br />
DO 110 I= 1, IDIM<br />
XYZ( 1, I, J, K ) = X<br />
XYZ( 2, I, J, K ) = Y<br />
XYZ( 3, I, J, K ) = Z<br />
X = X + DX<br />
110 CONTINUE<br />
Y = Y + DY<br />
111 CONTINUE<br />
Z = Z + DZ<br />
112 CONTINUE<br />
C Connections<br />
IDX = 1<br />
DO 122 K= 0, KDIM - 2<br />
DO 121 J= 0, JDIM - 2<br />
DO 120 I= 1, IDIM - 1<br />
ICONN( 1, IDX ) = ( K * JDIM * IDIM ) + ( J * IDIM ) + I<br />
ICONN( 2, IDX ) = ( K * JDIM * IDIM ) + ( J * IDIM ) + I + 1<br />
ICONN( 3, IDX ) = ( ( K + 1 ) * JDIM * IDIM ) + ( J * IDIM ) + I + 1<br />
ICONN( 4, IDX ) = ( ( K + 1 ) * JDIM * IDIM ) + ( J * IDIM ) + I<br />
ICONN( 5, IDX ) = ( K * JDIM * IDIM ) + ( ( J + 1 ) * IDIM ) + I<br />
ICONN( 6, IDX ) = ( K * JDIM * IDIM ) + ( ( J + 1 ) * IDIM ) + I + 1<br />
ICONN( 7, IDX ) = ( ( K + 1 ) * JDIM * IDIM ) +<br />
C ( ( J + 1 ) * IDIM ) + I + 1<br />
ICONN( 8, IDX ) = ( ( K + 1 ) * JDIM * IDIM ) +<br />
C ( ( J + 1 ) * IDIM ) + I<br />
IDX = IDX + 1<br />
120 CONTINUE<br />
121 CONTINUE<br />
122 CONTINUE<br />
RETURN<br />
END<br />
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC<br />
C<br />
C Create a Node Centered Solution Field<br />
C<br />
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC<br />
SUBROUTINE NodeData( IDIM, JDIM, KDIM, XYZ, NCVALUES)<br />
INTEGER IDIM, JDIM, KDIM<br />
REAL*8 XYZ<br />
DIMENSION XYZ( 3, IDIM, JDIM, KDIM )<br />
REAL*8 NCVALUES<br />
DIMENSION NCVALUES( IDIM, JDIM, KDIM )<br />
INTEGER I, J, K<br />
REAL*8 X, Y, Z<br />
PRINT *, 'Calculating Node Centered Data'<br />
DO 212, K=1, KDIM<br />
DO 211, J=1, JDIM<br />
DO 210, I=1, IDIM<br />
X = XYZ( 1, I, J, K )<br />
Y = XYZ( 2, I, J, K )<br />
Z = XYZ( 3, I, J, K )<br />
NCVALUES( I, J, K ) = SQRT( ( X * X ) + ( Y * Y ) + ( Z * Z ))<br />
210 CONTINUE<br />
211 CONTINUE<br />
212 CONTINUE<br />
RETURN<br />
END<br />
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC<br />
C<br />
C Create a Cell Centered Solution Field<br />
C<br />
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC<br />
SUBROUTINE CellData( IDIM, JDIM, KDIM, ITER, KICKER, XYZ, CCVALUES)<br />
INTEGER IDIM, JDIM, KDIM, ITER, KICKER<br />
REAL*8 XYZ<br />
DIMENSION XYZ( 3, IDIM, JDIM, KDIM )<br />
REAL*8 CCVALUES<br />
DIMENSION CCVALUES( IDIM - 1, JDIM - 1, KDIM - 1 )<br />
INTEGER I, J, K<br />
PRINT *, 'Calculating Cell Centered Data for Iteration ', ITER<br />
DO 312, K=1, KDIM - 1<br />
DO 311, J=1, JDIM - 1<br />
DO 310, I=1, IDIM - 1<br />
X = XYZ( 1, I, J, K )<br />
CCVALUES( I, J, K ) =<br />
C SIN( ( ( X + 1 ) * IDIM * KICKER ) / 3 * ITER ) /<br />
C EXP( X / ( 1.0 * ITER ) )<br />
310 CONTINUE<br />
311 CONTINUE<br />
312 CONTINUE<br />
C Waste Time<br />
DO 313 I=1, 1000000<br />
X = 0.1 * ITER / I<br />
Y = SQRT( X * X )<br />
Z = EXP( Y )<br />
313 CONTINUE<br />
RETURN<br />
END<br />
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC<br />
C<br />
C Main Program :<br />
C Initialize Grid<br />
C Initialize Node Centered Data<br />
C For Iteration = 1 to 10<br />
C Generate Cell Centered Data<br />
C Done<br />
C<br />
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC<br />
PROGRAM HexMesh<br />
PARAMETER ( IDIM = 11 )<br />
PARAMETER ( JDIM = 13 )<br />
PARAMETER ( KDIM = 15 )<br />
REAL*8 XYZ<br />
DIMENSION XYZ( 3, IDIM, JDIM, KDIM )<br />
REAL*8 NCVALUES<br />
DIMENSION NCVALUES( IDIM, JDIM, KDIM )<br />
C<br />
REAL*8 CCVALUES<br />
DIMENSION CCVALUES( IDIM - 1, JDIM - 1, KDIM - 1 )<br />
C<br />
INTEGER ICONN<br />
DIMENSION ICONN ( 8, ( IDIM - 1 ) * ( JDIM - 1 ) * ( KDIM - 1 ))<br />
C<br />
INTEGER ITER, KICKER, NITER, NARG<br />
INTEGER IUNIT<br />
CHARACTER*80 ARGIN<br />
C<br />
NARG = IARGC()<br />
IF( NARG .GE. 1 ) THEN<br />
CALL GETARG( 1, ARGIN )<br />
READ( ARGIN, '(I)') NITER<br />
ELSE<br />
NITER = 10<br />
ENDIF<br />
CALL CreateGrid ( IDIM, JDIM, KDIM, XYZ, ICONN )<br />
CALL NodeData( IDIM, JDIM, KDIM, XYZ, NCVALUES)<br />
C<br />
IUNIT = 14<br />
OPEN( IUNIT, FILE='XYZ.dat', STATUS='unknown' )<br />
REWIND IUNIT<br />
WRITE ( IUNIT, * ) IDIM * JDIM * KDIM<br />
WRITE ( IUNIT, * ) XYZ<br />
CLOSE ( IUNIT )<br />
C<br />
IUNIT = 14<br />
OPEN( IUNIT, FILE='CONN.dat', STATUS='unknown' )<br />
REWIND IUNIT<br />
WRITE ( IUNIT, * ) 'Hex', ( IDIM - 1 ) * ( JDIM - 1 ) * ( KDIM - 1 )<br />
WRITE ( IUNIT, * ) ICONN<br />
CLOSE ( IUNIT )<br />
C<br />
IUNIT = 14<br />
OPEN( IUNIT, FILE='NodeValues.dat', STATUS='unknown' )<br />
REWIND IUNIT<br />
WRITE ( IUNIT, * ) NCVALUES<br />
CLOSE ( IUNIT )<br />
C<br />
IUNIT = 14<br />
OPEN( IUNIT, FILE='CellValues.dat', STATUS='unknown' )<br />
REWIND IUNIT<br />
C<br />
KICKER = NITER<br />
DO 1000 ITER = 1, NITER<br />
CALL CellData( IDIM, JDIM, KDIM, ITER, KICKER, XYZ, CCVALUES)<br />
WRITE ( IUNIT, * ) CCVALUES<br />
1000 CONTINUE<br />
CLOSE ( IUNIT )<br />
C<br />
END<br />
<br />
Running the program produces four files XYZ.dat, CONN.dat, NodeValues.dat and CellValues.dat. Now<br />
let's suppose we want to generate Xdmf. We could use the HDF5 fortran bindings and produce the XML<br />
via print statements (we could also shove bamboo shoots under our fingernails). A better approach<br />
would be to create a 'C' wrapper routine that we call from fortran which contains all of the necessary<br />
Xdmf calls to produce valid Xdmf XML and HDF5 files :<br />
<br />
#include <Xdmf.h><br />
// We want the filenames to be based on the iteration<br />
// and padded with zeros<br />
using std::setw;<br />
using std::setfill;<br />
<br />
<br />
<br />
// This works with g77. Different compilers require different<br />
// name mangling.<br />
'''#define XdmfWrite xdmfwrite_'''<br />
<br />
<br />
<br />
<br />
//<br />
// C/C++ expect NULL terminated strings. Here is a conversion subroutine.<br />
char *<br />
DemoConvertFortranString( char *FtnName ) {<br />
static char Name[80];<br />
char *np;<br />
memcpy(Name, FtnName, 79 );<br />
Name[79] = '\0';<br />
np = &Name[78];<br />
while( ( np > Name ) && ( *np <= ' ') ) {<br />
np--;<br />
}<br />
*np = '\0';<br />
return( Name );<br />
}<br />
<br />
<br />
<br />
//<br />
// C++ will mangle the name based on the argument list. This tells the<br />
// compiler not to mangle the name so we can call it from 'C' (but<br />
// really Fortran in this case)<br />
//<br />
extern "C" {<br />
//<br />
void<br />
'''XdmfWrite(''' char *FtnName, int *Iteration,<br />
int *NumberOfPoints, int *NumberOfHex, XdmfFloat64 *Points,<br />
XdmfInt32 *Conns, XdmfFloat64 *NodeData,<br />
XdmfFloat64 *CellData){<br />
char *Name;<br />
char FullName[80];<br />
ostrstream DataName(FullName, 80);<br />
XdmfDOM dom;<br />
XdmfRoot root;<br />
XdmfDomain domain;<br />
XdmfGrid grid;<br />
XdmfTime time;<br />
XdmfTopology *topology;<br />
XdmfGeometry *geometry;<br />
XdmfAttribute nodedata;<br />
XdmfAttribute celldata;<br />
XdmfArray *array;<br />
<br />
Name = DemoConvertFortranString( FtnName );<br />
<br />
root.SetDOM(&dom);<br />
root.SetVersion(2.0);<br />
root.Build();<br />
<br />
// Domain<br />
root.Insert(&domain);<br />
<br />
// Grid<br />
grid.SetName("Demonstration Grid");<br />
domain.Insert(&grid);<br />
time.SetTimeType(XDMF_TIME_SINGLE);<br />
time.SetValue(0.001 * *Iteration);<br />
grid.Insert(&time);<br />
<br />
// Topology<br />
topology = grid.GetTopology();<br />
topology->SetTopologyType(XDMF_HEX);<br />
topology->SetNumberOfElements(*NumberOfHex);<br />
// Fortran is 1 based while c++ is 0 based so<br />
// Either subtract 1 from all connections or specify a BaseOffset<br />
topology->SetBaseOffset(1);<br />
// If you haven't assigned an XdmfArray, GetConnectivity() will create one.<br />
array = topology->GetConnectivity();<br />
array->SetNumberOfElements(*NumberOfHex * 8);<br />
array->SetValues(0, Conns, *NumberOfHex * 8);<br />
// C++ string hocus pocus.<br />
// We're actually building the string in FullName[] but were using streams.<br />
// the DatasetName will be Demo_00001.h5:/Conns.<br />
DataName.seekp(0);<br />
DataName << Name << "_" << setw(5) << setfill('0') << *Iteration << ".h5:/Conns" << ends;<br />
// Where the data will actually be written<br />
array->SetHeavyDataSetName(FullName);<br />
<br />
<br />
// Geometry<br />
geometry = grid.GetGeometry();<br />
geometry->SetGeometryType(XDMF_GEOMETRY_XYZ);<br />
geometry->SetNumberOfPoints(*NumberOfPoints);<br />
array = geometry->GetPoints();<br />
array->SetNumberType(XDMF_FLOAT64_TYPE);<br />
array->SetValues(0, Points, *NumberOfPoints * 3);<br />
DataName.seekp(0);<br />
DataName << Name << "_" << setw(5) << setfill('0') << *Iteration << ".h5:/Points" << ends;<br />
array->SetHeavyDataSetName(FullName);<br />
<br />
<br />
// Node Data<br />
nodedata.SetName("Node Scalar");<br />
nodedata.SetAttributeCenter(XDMF_ATTRIBUTE_CENTER_NODE);<br />
nodedata.SetAttributeType(XDMF_ATTRIBUTE_TYPE_SCALAR);<br />
array = nodedata.GetValues();<br />
array->SetNumberType(XDMF_FLOAT64_TYPE);<br />
array->SetNumberOfElements(*NumberOfPoints);<br />
array->SetValues(0, NodeData, *NumberOfPoints);<br />
DataName.seekp(0);<br />
DataName << Name << "_" << setw(5) << setfill('0') << *Iteration << ".h5:/NodeData" << ends;<br />
array->SetHeavyDataSetName(FullName);<br />
<br />
<br />
<br />
// Cell Data<br />
celldata.SetName("Cell Scalar");<br />
celldata.SetAttributeCenter(XDMF_ATTRIBUTE_CENTER_CELL);<br />
celldata.SetAttributeType(XDMF_ATTRIBUTE_TYPE_SCALAR);<br />
array = celldata.GetValues();<br />
array->SetNumberType(XDMF_FLOAT64_TYPE);<br />
array->SetNumberOfElements(*NumberOfHex);<br />
array->SetValues(0, CellData, *NumberOfHex);<br />
DataName.seekp(0);<br />
DataName << Name << "_" << setw(5) << setfill('0') << *Iteration << ".h5:/CellData" << ends;<br />
array->SetHeavyDataSetName(FullName);<br />
<br />
<br />
// Attach and Write<br />
grid.Insert(&nodedata);<br />
grid.Insert(&celldata);<br />
// Build is recursive ... it will be called on all of the child nodes.<br />
// This updates the DOM and writes the HDF5<br />
root.Build();<br />
// Write the XML<br />
DataName.seekp(0);<br />
DataName << Name << "_" << setw(5) << setfill('0') << *Iteration << ".xmf" << ends;<br />
dom.Write(FullName);<br />
}<br />
}<br />
<br />
Now we modify the Original Fortran code to call our new 'C' wrapper subroutine '''XdmfWrite()'''<br />
<br />
Original :<br />
KICKER = NITER<br />
DO 1000 ITER = 1, NITER<br />
CALL CellData( IDIM, JDIM, KDIM, ITER, KICKER, XYZ, CCVALUES)<br />
WRITE ( IUNIT, * ) CCVALUES<br />
1000 CONTINUE<br />
CLOSE ( IUNIT )<br />
C<br />
END<br />
<br />
Modified :<br />
INHEX = ( IDIM - 1 ) * ( JDIM - 1 ) * ( KDIM - 1 )<br />
INPNT = IDIM * JDIM * KDIM<br />
KICKER = NITER<br />
DO 1000 ITER = 1, NITER<br />
CALL CellData( IDIM, JDIM, KDIM, ITER, KICKER, XYZ, CCVALUES)<br />
WRITE ( IUNIT, * ) CCVALUES<br />
'''CALL XDMFWRITE( 'Demo', ITER, INPNT, INHEX, XYZ, ICONN, NCVALUES, CCVALUES)'''<br />
1000 CONTINUE<br />
CLOSE ( IUNIT )<br />
C<br />
END<br />
<br />
The program now produces one HDF5 file and one XML file for each iteration. Here is one<br />
of the XML output files :<br />
<br />
<?xml version="1.0" ?><br />
<!DOCTYPE Xdmf SYSTEM "Xdmf.dtd" []><br />
<Xdmf xmlns:xi="http://www.w3.org/2003/XInclude" Version="2"><br />
<Domain><br />
<Grid Name="Demonstration Grid" GridType="Uniform"><br />
<Topology TopologyType="Hexahedron" NumberOfElements="1680 " BaseOffset="1"><br />
<DataItem Dimensions="13440 " NumberType="Float" Precision="4" Format="HDF">Demo_00004.h5:/Conns</DataItem><br />
</Topology><br />
<Geometry GeometryType="XYZ"><br />
<DataItem Dimensions="6435 " NumberType="Float" Precision="4" Format="HDF">Demo_00004.h5:/Points</DataItem><br />
</Geometry><br />
<Time TimeType="Single" Value="0.004"/><br />
<Attribute Name="Node Scalar" AttributeType="Scalar" Center="Node"><br />
<DataItem Dimensions="2145 " NumberType="Float" Precision="4" Format="HDF">Demo_00004.h5:/NodeData</DataItem><br />
</Attribute><br />
<Attribute Name="Cell Scalar" AttributeType="Scalar" Center="Cell"><br />
<DataItem Dimensions="1680 " NumberType="Float" Precision="4" Format="HDF">Demo_00004.h5:/CellData</DataItem><br />
</Attribute><br />
</Grid><br />
</Domain><br />
</Xdmf><br />
<br />
The final step would be to group<br />
all of these together so we could animate them over time. Instead of duplicating the XML in another file for<br />
each grid, we can use a little XML magic to pull them together :<br />
<?xml version="1.0" ?><br />
<!DOCTYPE Xdmf SYSTEM "Xdmf.dtd" []><br />
<Xdmf xmlns:xi="http://www.w3.org/2001/XInclude" Version="2.0"><br />
<Domain><br />
<Grid GridType="Collection" CollectionType="Temporal"><br />
<xi:include href="Demo_00001.xmf" xpointer="xpointer(//Xdmf/Domain/Grid)" /><br />
<xi:include href="Demo_00002.xmf" xpointer="xpointer(//Xdmf/Domain/Grid)" /><br />
<xi:include href="Demo_00003.xmf" xpointer="xpointer(//Xdmf/Domain/Grid)" /><br />
<xi:include href="Demo_00004.xmf" xpointer="xpointer(//Xdmf/Domain/Grid)" /><br />
<xi:include href="Demo_00005.xmf" xpointer="xpointer(//Xdmf/Domain/Grid)" /><br />
<xi:include href="Demo_00006.xmf" xpointer="xpointer(//Xdmf/Domain/Grid)" /><br />
<xi:include href="Demo_00007.xmf" xpointer="xpointer(//Xdmf/Domain/Grid)" /><br />
<xi:include href="Demo_00008.xmf" xpointer="xpointer(//Xdmf/Domain/Grid)" /><br />
<xi:include href="Demo_00009.xmf" xpointer="xpointer(//Xdmf/Domain/Grid)" /><br />
<xi:include href="Demo_00010.xmf" xpointer="xpointer(//Xdmf/Domain/Grid)" /><br />
</Grid><br />
</Domain><br />
</Xdmf><br />
<br />
This uses XInclude and XPointer terminology to create a '''Temporal Collection''' Grid that consists <br />
of the first (in our case, the only) grid in each file. This XML file could be generated programmtically<br />
or by a post processing script.</div>Dave.demarlehttps://www.xdmf.org/index.php?title=Write_Xdmf&diff=114Write Xdmf2014-08-19T19:15:51Z<p>Dave.demarle: /* Writing Xdmf */</p>
<hr />
<div>== Writing Xdmf ==<br />
<br />
<pre style="color: red">Note code snippets on this page are from version 2 or 1 and need updating for xdmf 3.</pre><br />
<br />
Xdmf can be generated in many different manners. Using the low level HDF5 library and print statements <br />
is certainly one of them. Utilizing the XDMF API, however, provides some convenient advantages. Suppose we wanted <br />
to generate an XDMF dataset of a co-rectilinear mesh with scalar values at each node<br />
<br />
from Xdmf import *<br />
<br />
d = XdmfDOM() <br />
<br />
root = XdmfRoot()<br />
root.SetDOM(d)<br />
root.SetVersion(2.2) # Change the Version number because we can<br />
root.Build()<br />
# Information<br />
i = XdmfInformation() # Arbitrary Name=Value Facility<br />
i.SetName("SampleLocation")<br />
i.SetValue("4")<br />
root.Insert(i) # XML DOM is used as the keeper of the structure<br />
# Insert() creates an XML node and inserts it under<br />
# the parent<br />
# Domain<br />
dm = XdmfDomain()<br />
root.Insert(dm)<br />
# Grid<br />
g = XdmfGrid()<br />
g.SetName("Structured Grid")<br />
# Topology<br />
t = g.GetTopology()<br />
t.SetTopologyType(XDMF_3DCORECTMESH)<br />
t.GetShapeDesc().SetShapeFromString('10 20 30')<br />
# Geometry<br />
geo = g.GetGeometry()<br />
geo.SetGeometryType(XDMF_GEOMETRY_ORIGIN_DXDYDZ)<br />
geo.SetOrigin(1, 2, 3)<br />
geo.SetDxDyDz(0.1, 0.2, 0.3)<br />
dm.Insert(g)<br />
# Attribute<br />
attr = XdmfAttribute()<br />
attr.SetName("Pressure")<br />
attr.SetAttributeCenter(XDMF_ATTRIBUTE_CENTER_NODE);<br />
attr.SetAttributeType(XDMF_ATTRIBUTE_TYPE_SCALAR);<br />
p = attr.GetValues()<br />
p.SetShapeFromString("10 20 30")<br />
p.Generate(0.0, 1.0, 0, p.GetNumberOfElements() - 1)<br />
g.Insert(attr)<br />
# Update XML and Write Values to DataItems<br />
root.Build() # DataItems > 100 values are heavy<br />
print d.Serialize() # prints to stdout <br />
<br />
d.Write('SMesh.xmf') # write to file<br />
<br />
<br />
<br />
Would result in the Light Data XML to be written to the file Smesh.xmf and the Heavy data<br />
to be written to Xdmf.h5.<br />
<br />
<?xml version="1.0" ?><br />
<!DOCTYPE Xdmf SYSTEM "Xdmf.dtd" []><br />
<Xdmf xmlns:xi="http://www.w3.org/2003/XInclude" Version="2.2"><br />
<Information Name="SampleLocation" Value="4"/><br />
<Domain><br />
<Grid Name="Structured Grid" GridType="Uniform"><br />
<Topology TopologyType="3DCORECTMesh" NumberOfElements="10 20 30 "/><br />
<Geometry GeometryType="ORIGIN_DXDYDZ"><br />
<DataItem Dimensions="3 " NumberType="Float" Precision="4" Format="XML"><br />
1 2 3<br />
</DataItem><br />
<DataItem Dimensions="3 " NumberType="Float" Precision="4" Format="XML"><br />
0.1 0.2 0.3<br />
</DataItem><br />
</Geometry><br />
<Attribute Name="Pressure" AttributeType="Scalar" Center="Cell"><br />
<DataItem Dimensions="6000 " NumberType="Float" Precision="4" Format="HDF">Xdmf.h5:/Data</DataItem><br />
</Attribute><br />
</Grid><br />
</Domain><br />
</Xdmf><br />
<br />
Now suppose the HDF5 already existed or we wanted to write the HDF5 files in a specific manner.<br />
All XdmfElements have a SetDataXml() method which takes a raw XML string. When the element is<br />
built, the XML is blindly copied in and the writing of HeavyData is skipped.<br />
<br />
#!/usr/bin/env python<br />
<br />
from Xdmf import *<br />
<br />
# Example of How to Generate Xdmf<br />
# The Heavy Data for the Attribute is written separately<br />
<br />
# Write H5 Data<br />
arr = XdmfArray()<br />
arr.SetNumberType(XDMF_FLOAT64_TYPE)<br />
arr.SetShapeFromString("10 20 30")<br />
arr.Generate(0.0, 1.0, 0, arr.GetNumberOfElements() - 1)<br />
h5 = XdmfHDF()<br />
h5.CopyType(arr)<br />
h5.CopyShape(arr)<br />
h5.Open('XdmfByHand.h5:/Mydata', 'w')<br />
h5.Write(arr)<br />
h5.Close()<br />
# Use XdmfValuesHDF to generate the appropriate<br />
# Xdmf XML from and existing HDF5 dataset<br />
dv = XdmfValuesHDF()<br />
DataXml = dv.DataItemFromHDF('XdmfByHand.h5:/Mydata')<br />
#<br />
# Now build the tree of objects<br />
d = XdmfDOM()<br />
<br />
root = XdmfRoot()<br />
root.SetDOM(d)<br />
root.SetVersion(2.2) # Change the Version number because we can<br />
root.Build()<br />
# Information<br />
i = XdmfInformation() # Arbitrary Name=Value Facility<br />
i.SetName("SampleLocation")<br />
i.SetValue("4")<br />
root.Insert(i) # XML DOM is used as the keeper of the structure<br />
# Insert() creates an XML node and inserts it under<br />
# the parent<br />
# Domain<br />
dm = XdmfDomain()<br />
root.Insert(dm)<br />
# Grid<br />
g = XdmfGrid()<br />
g.SetName("Structured Grid")<br />
# Topology<br />
t = g.GetTopology()<br />
t.SetTopologyType(XDMF_3DCORECTMESH)<br />
t.GetShapeDesc().SetShapeFromString('10 20 30')<br />
# Geometry<br />
geo = g.GetGeometry()<br />
geo.SetGeometryType(XDMF_GEOMETRY_ORIGIN_DXDYDZ)<br />
geo.SetOrigin(1, 2, 3)<br />
geo.SetDxDyDz(0.1, 0.2, 0.3)<br />
dm.Insert(g)<br />
# Attribute<br />
attr = XdmfAttribute()<br />
attr.SetName("Pressure")<br />
attr.SetAttributeCenter(XDMF_ATTRIBUTE_CENTER_NODE);<br />
attr.SetAttributeType(XDMF_ATTRIBUTE_TYPE_SCALAR);<br />
# Insert the raw XML<br />
attr.SetDataXml(DataXml)<br />
g.Insert(attr)<br />
# Update XML and Write Values to DataItems<br />
root.Build() # DataItems > 100 values are heavy<br />
print d.Serialize() # prints to stdout <br />
<br />
d.Write('SMesh.xmf') # write to file<br />
<br />
This results in identical XML with just the name of the HDF5 dataset changed. <br />
~</div>Dave.demarlehttps://www.xdmf.org/index.php?title=XDMF_API&diff=113XDMF API2014-08-19T19:15:13Z<p>Dave.demarle: </p>
<hr />
<div>[[Image:XdmfLogo1.gif]]<br />
<br />
<br />
<pre style="color: red">Note code snippets on this page are from version 2 or 1 and need updating for xdmf 3.</pre><br />
<br />
'''XDMF API'''<br />
<br />
<br />
While use of the XDMF API is not necessary to produce or consume valid XDMF datasets, there are many convenience features that make it attractive. The XDMF library give access to a C++ class library that is also wrapped for access from scripting languages like Python.<br />
<br />
<br />
All XDMF Objects are derived from XdmfObject. Via this object, debug information can be turned on or off for each object or globally for all objects. The methods DebugOn/Off() and GlobalDebugOn/Off() perform these functions respectively.<br />
<br />
Most examples here are written in Python for clarity.<br />
<br />
'''XdmfDOM'''<br />
<br />
To understand access to XDMF data, understanding of the XdmfDOM is critical. XDMF uses the libxml2 library to parse and generate XML documents. XdmfDOM is a slightly higher abstraction of the Document Object Model (DOM). The DOM is an in-memory tree structure that represents the XML file. Nodes of the tree are added, deleted, queried and serialized. The low level libxml2 nodes are typedefed as XdmfXmlNode. <br />
<br />
The XdmfDOM can parse strings or files :<br />
Status = XdmfDOM.Parse(MyXMLString)<br />
or<br />
Status = XdmfDOM.Parse(<nowiki>"</nowiki>MyXMLFile.xmf<nowiki>"</nowiki>)<br />
<br />
As with many XDMF objects, status is either XDMF_SUCCESS or XDMF_FAIL which is defined in XdmfObject.h.<br />
<br />
Once the XML has been parsed into the DOM, the tree can be navigated and modified. There are several useful query mechanisms in XdmfDOM. The first method finds the n<nowiki></nowiki>th instance of an element below a parent node :<br />
<br />
XdmfXmlNode FindElement (<br />
XdmfConstString TagName, <br />
XdmfInt32 Index=0, <br />
XdmfXmlNode Node=NULL, <br />
XdmfInt32 IgnoreInfo=1<br />
)<br />
<br />
If Node==NULL the root node is assumed to be the desired parent node. IgnoreInfo allows for all "Information" elements to be ignored. For example, to find the third Grid element under the Domain element :<br />
<br />
DomainNode = XdmfDOM.FindElemet("Domain") <nowiki>#</nowiki> Take all defaults<br />
GridNode = XdmfDOM.FindElement("Grid", 2, DomainNode) <nowiki>#</nowiki> Index is zero based <br />
<br />
By utilizing the XPath functionality of libxml2, the same Grid element can be found by :<br />
GridNode = XdmfDOM.FindElementByPath("/Xdmf/Domain/Grid[3]") <nowiki>#</nowiki> XPath is 1 based<br />
<br />
Once the desired node is found, it can be queried and modified :<br />
NumberOfChildElements = XdmfDOM.GetNumberOfChildren(GridNode)<br />
Name = XdmfDOM.GetAttribute(GridNode, "Name")<br />
SubGrid = XdmfDOM.InsertNew(GridNode, "Grid")<br />
Status = XdmfDOM.Set(SubGrid, "Name", "My SubGrid")<br />
<br />
And finally written back out :<br />
XmlString = XdmfDOM.Serialize(GridNode)<br />
or<br />
Status = XdmfDOM.Write("MyFile.xmf")<br />
<br />
'''XdmfElement'''<br />
<br />
Each element type in an XDMF XML file has a corresponding XDMF object implementation. All of these are children of XdmfElement. Each XdmfElement must be provided with an XdmfDOM with which to operate. On input, <br />
the UpdateInformation() method will initialize the basic structure of the element <br />
from the XML without reading any HeavyData. The Update() method will access the HeavyData. Each derived object from XdmfElement (XdmfGrid for example) will override these methods.<br />
<br />
GridNode = DOM.FindElementByPath("/Xdmf/Domain/Grid[3]") <br />
Grid = XdmfGrid() <nowiki>#</nowiki> Create<br />
Grid.SetDOM(DOM)<br />
Grid.SetElement(GridNode)<br />
Grid.UpdateInformation() <nowiki>#</nowiki> Update Light Structure<br />
Grid.Update() <nowiki>#</nowiki> Read HeavyData<br />
<br />
Once the DOM has been set for an XdmfElement, there are convenience methods such as Set() and Get() which are equivalent to the XdmfDOM methods.<br />
GridName = Grid.Get(<nowiki>"</nowiki>Name<nowiki>"</nowiki>)<br />
Is the same as<br />
<br />
DOM = Grid.GetDOM()<br />
GridNode = Grid.GetElement()<br />
GridName = DOM.Get(GridNode, "Name")<br />
<br />
For output, the XdmfElement methods Insert() and Build() are used. Each derived object in XDMF will assure that only the proper type of element is inserted. For example, it is illegal to insert a Domain element directly below a Grid element. <br />
<br />
Info = XdmfInformation() <nowiki>#</nowiki> Arbitrary Name=Value Facility<br />
Info.SetName("Time")<br />
Info.SetValue("0.0123")<br />
Grid = XdmfGrid()<br />
Grid.Set("Name", "My Grid")<br />
Grid.Insert(Info)<br />
Grid.Build()<br />
<br />
Results in <br />
<br />
&lt;Grid Name="My Grid"&gt;<br />
&lt;Information Name="Time" Value="0.0123" /&gt;<br />
&lt;/Grid&gt;<br />
The Build() method is recursive so that Build() will automatically be called for all child elements.<br />
<br />
'''XdmfArray'''<br />
<br />
The XdmfArray class is a self describing data structure. It is derived from the XdmfDataDesc class that gives it number type, precision, and shape (rank and dimensions). Many XDMF classes require an XdmfArray as input to methods. The following C++ example demonstrates creating an interlaced XYZ array from three separate variables:<br />
<br />
float *x, *y, *z;<br />
XdmfInt64 total, dims<nowiki>[</nowiki>3<nowiki>]</nowiki>;<br />
XdmfArray <nowiki>*</nowiki>xyz = new XdmfArray;<br />
<br />
dims<nowiki>[</nowiki>0<nowiki>]</nowiki> = 10;<br />
dims<nowiki>[</nowiki>1<nowiki>]</nowiki> = 20;<br />
dims<nowiki>[</nowiki>2<nowiki>]</nowiki> = 30;<br />
total = 10 <nowiki>*</nowiki> 20 <nowiki>*</nowiki> 30;<br />
xyz->SetNumberType(XDMF_FLOAT64_TYPE)<br />
xyz->SetShape(3, dims); // KDim, JDim, IDim<br />
xyz->SetValues(0, x, total, 3, 1); // SetValues (XdmfInt64 Index, XdmfFloat64 <nowiki>*</nowiki>Values,<br />
// XdmfInt64 NumberOfValues, XdmfInt64 ArrayStride=1,<br />
// XdmfInt64 ValuesStride=1)<br />
xyz->SetValues(1, y, total, 3, 1);<br />
xyz->SetValues(2, z, total, 3, 1);<br />
<br />
When an XdmfArray is created, it is given a unique tag name. Array operations can be performed on XdmfArray data by using this name in an XdmfExpr(). The following Python program gives some examples.<br />
from Xdmf import *<br />
<br />
def Expression(*args) :<br />
e = ''<br />
for arg in args :<br />
if hasattr(arg, 'GetTagName') :<br />
e += arg.GetTagName() + ' '<br />
else :<br />
e += arg + ' '<br />
return XdmfExpr(e)<br />
<br />
if __name__ == '__main__' :<br />
a1 = XdmfArray()<br />
a1.SetNumberType(XDMF_FLOAT32_TYPE)<br />
a1.SetNumberOfElements(20)<br />
a1.Generate(1, 20)<br />
a2 = XdmfArray()<br />
a2.SetNumberType(XDMF_INT32_TYPE)<br />
a2.SetNumberOfElements(5)<br />
a2.Generate(2, 10)<br />
print 'a1 Values = ', a1.GetValues()<br />
print 'a1[2:10] = ' + Expression(a1 , '[ 2:10 ]').GetValues()<br />
print 'a2 Values = ', a2.GetValues()<br />
print 'a1[a2] = ' + Expression(a1 , '[', a2, ']').GetValues()<br />
print 'a1 + a2 = ' + Expression(a1 , ' + ', a2).GetValues()<br />
print 'a1 * a2 = ' + Expression(a1 , ' * ', a2).GetValues()<br />
a2.SetNumberType(XDMF_FLOAT32_TYPE)<br />
a2.SetNumberOfElements(20)<br />
a2.Generate(21, 40)<br />
print 'a2 Values = ', a2.GetValues()<br />
print 'a1 , a2 (Interlace) = ' + Expression(a1 , ' , ', a2).GetValues()<br />
print 'a1 , a2, a1 (Interlace) = ' + Expression(a1 , ' , ', a2, ' , ', a1).GetValues()<br />
print 'a1 ; a2 (Concat) = ' + Expression(a1 , ' ; ', a2).GetValues()<br />
print 'where(a1 > 10) = ' + Expression('Where( ', a1 , ' > 10)').GetValues()<br />
print 'a2[where(a1 > 10)] = ' + Expression(a2, '[Where( ', a1 , ' > 10)]').GetValues()<br />
<br />
<br />
While most of the functions are self explanatory the WHERE function is not. WHERE will return the indexes of the XdmfArray where a certain condition is true. In this example WHERE returns the indexes of XdmfArra<br />
y a1 where a1 is greater than 10. Notice that the XdmfExpr() function makes it easy to extract part of an XdmfArray.<br />
<br />
'''XdmfTime'''<br />
<br />
When UpdateInformation() gets called for a Grid, an XdmfTime object<br />
is added to the Grid with TimeType set to XDMF_TIME_UNSET. If there<br />
is a &lt;Time&gt; element in the Grid the object is populated. If the<br />
Grid is Non-Uniform (i.e. Collection, Tree), the children are updated<br />
as well. If the parent is<br />
TimeType="HyperSlab" then the child is XDMF_TIME_SINGLE with the<br />
appropriate value set.<br />
<br />
Methods :<br />
XdmfInt32 XdmfTime::Evaluate(XdmfGrid *Grid, XdmfArray *ArrayToFill = NULL, XdmfInt32 Descend = 0, XdmfInt32 Append = 0)<br />
<br />
This will populate the array with the valid times in the Grid. If Descend = 1 then it is recursive. If Append = 1 the values are appended to the given array not overwritten.<br />
<br />
XdmfInt32 XdmfTime::IsValid(XdmfFloat64 TimeMin, XdmfFloat64 TimeMax)<br />
<br />
this checks to see if the Time is entirely in Min/Max. Since this is<br />
a float comparison, I added an Epsilon member to XdmfTime with default<br />
value = 1e-7. This may be changed via XdmfTime::SetEpsilon()<br />
<br />
XdmfInt32 XdmfGrid::FindGridsInTimeRange(XdmfFloat64 TimeMin, XdmfFloat64 TimeMax, XdmfArray *ArrayToFill)<br />
<br />
This populates the array with the direct children that are entirely in min/max. For example if the range is<br />
0.0 to 0.5 with TimeMin=0.25 and TimeMax=1.25 this will return XDMF_FAIL.<br />
<br />
<br />
'''XdmfHDF'''<br />
<br />
In XDMF, Light data is stored in XML while the Heavy data is typically stored in an HDF5 file.<br />
The XdmfHDF class simplifies access to HDF5 data, it is also derived from XdmfDataDesc. The following Python code demonstrates its use :<br />
<br />
<br />
from Xdmf import <nowiki>*</nowiki><br />
<br />
Geometry = "-1.75 -1.25 0 -1.25 -1.25 0 -0.75 <br />
Connectivity = "3 2 5 1 .<br />
Values = "100 200 300 ..<br />
<br />
from Xdmf import *<br />
<br />
# Geometry<br />
GeometryArray = XdmfArray()<br />
GeometryArray.SetValues(0, Geometry)<br />
H5 = XdmfHDF()<br />
H5.CopyType(GeometryArray)<br />
H5.CopyShape(GeometryArray)<br />
# Open for Writing. This will truncate the file.<br />
H5.Open('Example1.h5:/Geometry', 'w')<br />
H5.Write(GeometryArray)<br />
H5.Close()<br />
<br />
# Coneectivity<br />
ConnectivityArray = XdmfArray()<br />
ConnectivityArray.SetValues(0, Connectivity)<br />
H5 = XdmfHDF()<br />
H5.CopyType(ConnectivityArray)<br />
H5.CopyShape(ConnectivityArray)<br />
# Open for Reading and Writing. This will NOT truncate the file.<br />
H5.Open('Example1.h5:/Connectivity', 'rw')<br />
H5.Write(ConnectivityArray)<br />
H5.Close()<br />
<br />
# Values<br />
ValueArray = XdmfArray()<br />
ValueArray.SetValues(0, Values)<br />
H5 = XdmfHDF()<br />
H5.CopyType(ValueArray)<br />
H5.CopyShape(ValueArray)<br />
# Open for Reading and Writing. This will NOT truncate the file.<br />
H5.Open('Example1.h5:/Values', 'rw')<br />
H5.Write(ValueArray)<br />
H5.Close()<br />
<br />
<br />
<br />
For reading, XdmfHDF will allocate an array if none is specified :<br />
Status = H5.Open("Example1.h5:/Values", "rw")<br />
ValueArray = H5.Read()<br />
<br />
'''Reading XDMF'''<br />
<br />
Putting all of this together, assume Points.xmf is a valid XDMF XML file with a single uniform Grid. Here is a Python example to read and print values.<br />
<br />
dom = XdmfDOM()<br />
dom.Parse("Points.xmf")<br />
<br />
ge = dom.FindElementByPath("/Xdmf/Domain/Grid")<br />
grid = XdmfGrid()<br />
grid.SetDOM(dom)<br />
grid.SetElement(ge)<br />
grid.UpdateInformation()<br />
grid.Update() <br />
<br />
top = grid.GetTopology()<br />
top.DebugOn()<br />
conn = top.GetConnectivity()<br />
print "Values = ", conn.GetValues()<br />
<br />
geo = grid.GetGeometry()<br />
points = geo.GetPoints()<br />
print "Geo Type = ", geo.GetGeometryTypeAsString(), " # Points = ", geo.GetNumberOfPoints()<br />
print "Points = ", points.GetValues(0, 6)<br />
<br />
'''Writing XDMF'''<br />
<br />
Using the Insert() and Build() methods, an XDMF dataset can be generated programmatically as well . Internally, as XDMF objects are inserted, the DOM is "decorated" with their pointers. In this manner, the api c<br />
an get a object from an node of the DOM if it has been created. For reading XDMF, this allows multiple references to the same DataItem not to result in additional IO. For writing, this allows Build() to work recursively.<br />
<br />
d = XdmfDOM()<br />
<br />
root = XdmfRoot()<br />
root.SetDOM(d)<br />
root.SetVersion(2.2) # Change the Version number because we can<br />
root.Build()<br />
# Information<br />
i = XdmfInformation() # Arbitrary Name=Value Facility<br />
i.SetName("Time")<br />
i.SetValue("0.0123")<br />
root.Insert(i) # XML DOM is used as the keeper of the structure<br />
# Insert() creates an XML node and inserts it under<br />
# the parent<br />
# Domain<br />
dm = XdmfDomain()<br />
root.Insert(dm)<br />
# Grid<br />
g = XdmfGrid()<br />
g.SetName("Structured Grid")<br />
# Topology<br />
t = g.GetTopology()<br />
t.SetTopologyType(XDMF_3DCORECTMESH)<br />
t.GetShapeDesc().SetShapeFromString('10 20 30')<br />
# Geometry<br />
geo = g.GetGeometry()<br />
geo.SetGeometryType(XDMF_GEOMETRY_ORIGIN_DXDYDZ)<br />
geo.SetOrigin(1, 2, 3)<br />
geo.SetDxDyDz(0.1, 0.2, 0.3)<br />
dm.Insert(g)<br />
# Attribute<br />
attr = XdmfAttribute()<br />
attr.SetName("Pressure")<br />
attr.SetAttributeCenter(XDMF_ATTRIBUTE_CENTER_CELL);<br />
attr.SetAttributeType(XDMF_ATTRIBUTE_TYPE_SCALAR);<br />
p = attr.GetValues()<br />
p.SetNumberOfElements(10 * 20 * 30)<br />
p.Generate(0.0, 1.0, 0, p.GetNumberOfElements() - 1)<br />
# If an array is given a HeavyDataSetName, that is<br />
# where it will be written<br />
p.setHeavyDataSetName('MyData.h5:/Pressure')<br />
g.Insert(attr)<br />
# Update XML and Write Values to DataItems<br />
root.Build() # DataItems > 100 values are heavy<br />
print d.Serialize() # prints to stdout<br />
d.Write('junk.xmf') # write to file</div>Dave.demarlehttps://www.xdmf.org/index.php?title=XDMF_API&diff=112XDMF API2014-08-19T19:14:41Z<p>Dave.demarle: </p>
<hr />
<div>[[Image:XdmfLogo1.gif]]<br />
<br />
<br />
<pre style="color: red">Note this code snippet is from version 2 or 1 and needs updating for xdmf3.</pre><br />
<br />
'''XDMF API'''<br />
<br />
<br />
While use of the XDMF API is not necessary to produce or consume valid XDMF datasets, there are many convenience features that make it attractive. The XDMF library give access to a C++ class library that is also wrapped for access from scripting languages like Python.<br />
<br />
<br />
All XDMF Objects are derived from XdmfObject. Via this object, debug information can be turned on or off for each object or globally for all objects. The methods DebugOn/Off() and GlobalDebugOn/Off() perform these functions respectively.<br />
<br />
Most examples here are written in Python for clarity.<br />
<br />
'''XdmfDOM'''<br />
<br />
To understand access to XDMF data, understanding of the XdmfDOM is critical. XDMF uses the libxml2 library to parse and generate XML documents. XdmfDOM is a slightly higher abstraction of the Document Object Model (DOM). The DOM is an in-memory tree structure that represents the XML file. Nodes of the tree are added, deleted, queried and serialized. The low level libxml2 nodes are typedefed as XdmfXmlNode. <br />
<br />
The XdmfDOM can parse strings or files :<br />
Status = XdmfDOM.Parse(MyXMLString)<br />
or<br />
Status = XdmfDOM.Parse(<nowiki>"</nowiki>MyXMLFile.xmf<nowiki>"</nowiki>)<br />
<br />
As with many XDMF objects, status is either XDMF_SUCCESS or XDMF_FAIL which is defined in XdmfObject.h.<br />
<br />
Once the XML has been parsed into the DOM, the tree can be navigated and modified. There are several useful query mechanisms in XdmfDOM. The first method finds the n<nowiki></nowiki>th instance of an element below a parent node :<br />
<br />
XdmfXmlNode FindElement (<br />
XdmfConstString TagName, <br />
XdmfInt32 Index=0, <br />
XdmfXmlNode Node=NULL, <br />
XdmfInt32 IgnoreInfo=1<br />
)<br />
<br />
If Node==NULL the root node is assumed to be the desired parent node. IgnoreInfo allows for all "Information" elements to be ignored. For example, to find the third Grid element under the Domain element :<br />
<br />
DomainNode = XdmfDOM.FindElemet("Domain") <nowiki>#</nowiki> Take all defaults<br />
GridNode = XdmfDOM.FindElement("Grid", 2, DomainNode) <nowiki>#</nowiki> Index is zero based <br />
<br />
By utilizing the XPath functionality of libxml2, the same Grid element can be found by :<br />
GridNode = XdmfDOM.FindElementByPath("/Xdmf/Domain/Grid[3]") <nowiki>#</nowiki> XPath is 1 based<br />
<br />
Once the desired node is found, it can be queried and modified :<br />
NumberOfChildElements = XdmfDOM.GetNumberOfChildren(GridNode)<br />
Name = XdmfDOM.GetAttribute(GridNode, "Name")<br />
SubGrid = XdmfDOM.InsertNew(GridNode, "Grid")<br />
Status = XdmfDOM.Set(SubGrid, "Name", "My SubGrid")<br />
<br />
And finally written back out :<br />
XmlString = XdmfDOM.Serialize(GridNode)<br />
or<br />
Status = XdmfDOM.Write("MyFile.xmf")<br />
<br />
'''XdmfElement'''<br />
<br />
Each element type in an XDMF XML file has a corresponding XDMF object implementation. All of these are children of XdmfElement. Each XdmfElement must be provided with an XdmfDOM with which to operate. On input, <br />
the UpdateInformation() method will initialize the basic structure of the element <br />
from the XML without reading any HeavyData. The Update() method will access the HeavyData. Each derived object from XdmfElement (XdmfGrid for example) will override these methods.<br />
<br />
GridNode = DOM.FindElementByPath("/Xdmf/Domain/Grid[3]") <br />
Grid = XdmfGrid() <nowiki>#</nowiki> Create<br />
Grid.SetDOM(DOM)<br />
Grid.SetElement(GridNode)<br />
Grid.UpdateInformation() <nowiki>#</nowiki> Update Light Structure<br />
Grid.Update() <nowiki>#</nowiki> Read HeavyData<br />
<br />
Once the DOM has been set for an XdmfElement, there are convenience methods such as Set() and Get() which are equivalent to the XdmfDOM methods.<br />
GridName = Grid.Get(<nowiki>"</nowiki>Name<nowiki>"</nowiki>)<br />
Is the same as<br />
<br />
DOM = Grid.GetDOM()<br />
GridNode = Grid.GetElement()<br />
GridName = DOM.Get(GridNode, "Name")<br />
<br />
For output, the XdmfElement methods Insert() and Build() are used. Each derived object in XDMF will assure that only the proper type of element is inserted. For example, it is illegal to insert a Domain element directly below a Grid element. <br />
<br />
Info = XdmfInformation() <nowiki>#</nowiki> Arbitrary Name=Value Facility<br />
Info.SetName("Time")<br />
Info.SetValue("0.0123")<br />
Grid = XdmfGrid()<br />
Grid.Set("Name", "My Grid")<br />
Grid.Insert(Info)<br />
Grid.Build()<br />
<br />
Results in <br />
<br />
&lt;Grid Name="My Grid"&gt;<br />
&lt;Information Name="Time" Value="0.0123" /&gt;<br />
&lt;/Grid&gt;<br />
The Build() method is recursive so that Build() will automatically be called for all child elements.<br />
<br />
'''XdmfArray'''<br />
<br />
The XdmfArray class is a self describing data structure. It is derived from the XdmfDataDesc class that gives it number type, precision, and shape (rank and dimensions). Many XDMF classes require an XdmfArray as input to methods. The following C++ example demonstrates creating an interlaced XYZ array from three separate variables:<br />
<br />
float *x, *y, *z;<br />
XdmfInt64 total, dims<nowiki>[</nowiki>3<nowiki>]</nowiki>;<br />
XdmfArray <nowiki>*</nowiki>xyz = new XdmfArray;<br />
<br />
dims<nowiki>[</nowiki>0<nowiki>]</nowiki> = 10;<br />
dims<nowiki>[</nowiki>1<nowiki>]</nowiki> = 20;<br />
dims<nowiki>[</nowiki>2<nowiki>]</nowiki> = 30;<br />
total = 10 <nowiki>*</nowiki> 20 <nowiki>*</nowiki> 30;<br />
xyz->SetNumberType(XDMF_FLOAT64_TYPE)<br />
xyz->SetShape(3, dims); // KDim, JDim, IDim<br />
xyz->SetValues(0, x, total, 3, 1); // SetValues (XdmfInt64 Index, XdmfFloat64 <nowiki>*</nowiki>Values,<br />
// XdmfInt64 NumberOfValues, XdmfInt64 ArrayStride=1,<br />
// XdmfInt64 ValuesStride=1)<br />
xyz->SetValues(1, y, total, 3, 1);<br />
xyz->SetValues(2, z, total, 3, 1);<br />
<br />
When an XdmfArray is created, it is given a unique tag name. Array operations can be performed on XdmfArray data by using this name in an XdmfExpr(). The following Python program gives some examples.<br />
from Xdmf import *<br />
<br />
def Expression(*args) :<br />
e = ''<br />
for arg in args :<br />
if hasattr(arg, 'GetTagName') :<br />
e += arg.GetTagName() + ' '<br />
else :<br />
e += arg + ' '<br />
return XdmfExpr(e)<br />
<br />
if __name__ == '__main__' :<br />
a1 = XdmfArray()<br />
a1.SetNumberType(XDMF_FLOAT32_TYPE)<br />
a1.SetNumberOfElements(20)<br />
a1.Generate(1, 20)<br />
a2 = XdmfArray()<br />
a2.SetNumberType(XDMF_INT32_TYPE)<br />
a2.SetNumberOfElements(5)<br />
a2.Generate(2, 10)<br />
print 'a1 Values = ', a1.GetValues()<br />
print 'a1[2:10] = ' + Expression(a1 , '[ 2:10 ]').GetValues()<br />
print 'a2 Values = ', a2.GetValues()<br />
print 'a1[a2] = ' + Expression(a1 , '[', a2, ']').GetValues()<br />
print 'a1 + a2 = ' + Expression(a1 , ' + ', a2).GetValues()<br />
print 'a1 * a2 = ' + Expression(a1 , ' * ', a2).GetValues()<br />
a2.SetNumberType(XDMF_FLOAT32_TYPE)<br />
a2.SetNumberOfElements(20)<br />
a2.Generate(21, 40)<br />
print 'a2 Values = ', a2.GetValues()<br />
print 'a1 , a2 (Interlace) = ' + Expression(a1 , ' , ', a2).GetValues()<br />
print 'a1 , a2, a1 (Interlace) = ' + Expression(a1 , ' , ', a2, ' , ', a1).GetValues()<br />
print 'a1 ; a2 (Concat) = ' + Expression(a1 , ' ; ', a2).GetValues()<br />
print 'where(a1 > 10) = ' + Expression('Where( ', a1 , ' > 10)').GetValues()<br />
print 'a2[where(a1 > 10)] = ' + Expression(a2, '[Where( ', a1 , ' > 10)]').GetValues()<br />
<br />
<br />
While most of the functions are self explanatory the WHERE function is not. WHERE will return the indexes of the XdmfArray where a certain condition is true. In this example WHERE returns the indexes of XdmfArra<br />
y a1 where a1 is greater than 10. Notice that the XdmfExpr() function makes it easy to extract part of an XdmfArray.<br />
<br />
'''XdmfTime'''<br />
<br />
When UpdateInformation() gets called for a Grid, an XdmfTime object<br />
is added to the Grid with TimeType set to XDMF_TIME_UNSET. If there<br />
is a &lt;Time&gt; element in the Grid the object is populated. If the<br />
Grid is Non-Uniform (i.e. Collection, Tree), the children are updated<br />
as well. If the parent is<br />
TimeType="HyperSlab" then the child is XDMF_TIME_SINGLE with the<br />
appropriate value set.<br />
<br />
Methods :<br />
XdmfInt32 XdmfTime::Evaluate(XdmfGrid *Grid, XdmfArray *ArrayToFill = NULL, XdmfInt32 Descend = 0, XdmfInt32 Append = 0)<br />
<br />
This will populate the array with the valid times in the Grid. If Descend = 1 then it is recursive. If Append = 1 the values are appended to the given array not overwritten.<br />
<br />
XdmfInt32 XdmfTime::IsValid(XdmfFloat64 TimeMin, XdmfFloat64 TimeMax)<br />
<br />
this checks to see if the Time is entirely in Min/Max. Since this is<br />
a float comparison, I added an Epsilon member to XdmfTime with default<br />
value = 1e-7. This may be changed via XdmfTime::SetEpsilon()<br />
<br />
XdmfInt32 XdmfGrid::FindGridsInTimeRange(XdmfFloat64 TimeMin, XdmfFloat64 TimeMax, XdmfArray *ArrayToFill)<br />
<br />
This populates the array with the direct children that are entirely in min/max. For example if the range is<br />
0.0 to 0.5 with TimeMin=0.25 and TimeMax=1.25 this will return XDMF_FAIL.<br />
<br />
<br />
'''XdmfHDF'''<br />
<br />
In XDMF, Light data is stored in XML while the Heavy data is typically stored in an HDF5 file.<br />
The XdmfHDF class simplifies access to HDF5 data, it is also derived from XdmfDataDesc. The following Python code demonstrates its use :<br />
<br />
<br />
from Xdmf import <nowiki>*</nowiki><br />
<br />
Geometry = "-1.75 -1.25 0 -1.25 -1.25 0 -0.75 <br />
Connectivity = "3 2 5 1 .<br />
Values = "100 200 300 ..<br />
<br />
from Xdmf import *<br />
<br />
# Geometry<br />
GeometryArray = XdmfArray()<br />
GeometryArray.SetValues(0, Geometry)<br />
H5 = XdmfHDF()<br />
H5.CopyType(GeometryArray)<br />
H5.CopyShape(GeometryArray)<br />
# Open for Writing. This will truncate the file.<br />
H5.Open('Example1.h5:/Geometry', 'w')<br />
H5.Write(GeometryArray)<br />
H5.Close()<br />
<br />
# Coneectivity<br />
ConnectivityArray = XdmfArray()<br />
ConnectivityArray.SetValues(0, Connectivity)<br />
H5 = XdmfHDF()<br />
H5.CopyType(ConnectivityArray)<br />
H5.CopyShape(ConnectivityArray)<br />
# Open for Reading and Writing. This will NOT truncate the file.<br />
H5.Open('Example1.h5:/Connectivity', 'rw')<br />
H5.Write(ConnectivityArray)<br />
H5.Close()<br />
<br />
# Values<br />
ValueArray = XdmfArray()<br />
ValueArray.SetValues(0, Values)<br />
H5 = XdmfHDF()<br />
H5.CopyType(ValueArray)<br />
H5.CopyShape(ValueArray)<br />
# Open for Reading and Writing. This will NOT truncate the file.<br />
H5.Open('Example1.h5:/Values', 'rw')<br />
H5.Write(ValueArray)<br />
H5.Close()<br />
<br />
<br />
<br />
For reading, XdmfHDF will allocate an array if none is specified :<br />
Status = H5.Open("Example1.h5:/Values", "rw")<br />
ValueArray = H5.Read()<br />
<br />
'''Reading XDMF'''<br />
<br />
Putting all of this together, assume Points.xmf is a valid XDMF XML file with a single uniform Grid. Here is a Python example to read and print values.<br />
<br />
dom = XdmfDOM()<br />
dom.Parse("Points.xmf")<br />
<br />
ge = dom.FindElementByPath("/Xdmf/Domain/Grid")<br />
grid = XdmfGrid()<br />
grid.SetDOM(dom)<br />
grid.SetElement(ge)<br />
grid.UpdateInformation()<br />
grid.Update() <br />
<br />
top = grid.GetTopology()<br />
top.DebugOn()<br />
conn = top.GetConnectivity()<br />
print "Values = ", conn.GetValues()<br />
<br />
geo = grid.GetGeometry()<br />
points = geo.GetPoints()<br />
print "Geo Type = ", geo.GetGeometryTypeAsString(), " # Points = ", geo.GetNumberOfPoints()<br />
print "Points = ", points.GetValues(0, 6)<br />
<br />
'''Writing XDMF'''<br />
<br />
Using the Insert() and Build() methods, an XDMF dataset can be generated programmatically as well . Internally, as XDMF objects are inserted, the DOM is "decorated" with their pointers. In this manner, the api c<br />
an get a object from an node of the DOM if it has been created. For reading XDMF, this allows multiple references to the same DataItem not to result in additional IO. For writing, this allows Build() to work recursively.<br />
<br />
d = XdmfDOM()<br />
<br />
root = XdmfRoot()<br />
root.SetDOM(d)<br />
root.SetVersion(2.2) # Change the Version number because we can<br />
root.Build()<br />
# Information<br />
i = XdmfInformation() # Arbitrary Name=Value Facility<br />
i.SetName("Time")<br />
i.SetValue("0.0123")<br />
root.Insert(i) # XML DOM is used as the keeper of the structure<br />
# Insert() creates an XML node and inserts it under<br />
# the parent<br />
# Domain<br />
dm = XdmfDomain()<br />
root.Insert(dm)<br />
# Grid<br />
g = XdmfGrid()<br />
g.SetName("Structured Grid")<br />
# Topology<br />
t = g.GetTopology()<br />
t.SetTopologyType(XDMF_3DCORECTMESH)<br />
t.GetShapeDesc().SetShapeFromString('10 20 30')<br />
# Geometry<br />
geo = g.GetGeometry()<br />
geo.SetGeometryType(XDMF_GEOMETRY_ORIGIN_DXDYDZ)<br />
geo.SetOrigin(1, 2, 3)<br />
geo.SetDxDyDz(0.1, 0.2, 0.3)<br />
dm.Insert(g)<br />
# Attribute<br />
attr = XdmfAttribute()<br />
attr.SetName("Pressure")<br />
attr.SetAttributeCenter(XDMF_ATTRIBUTE_CENTER_CELL);<br />
attr.SetAttributeType(XDMF_ATTRIBUTE_TYPE_SCALAR);<br />
p = attr.GetValues()<br />
p.SetNumberOfElements(10 * 20 * 30)<br />
p.Generate(0.0, 1.0, 0, p.GetNumberOfElements() - 1)<br />
# If an array is given a HeavyDataSetName, that is<br />
# where it will be written<br />
p.setHeavyDataSetName('MyData.h5:/Pressure')<br />
g.Insert(attr)<br />
# Update XML and Write Values to DataItems<br />
root.Build() # DataItems > 100 values are heavy<br />
print d.Serialize() # prints to stdout<br />
d.Write('junk.xmf') # write to file</div>Dave.demarlehttps://www.xdmf.org/index.php?title=Write_Xdmf&diff=111Write Xdmf2014-08-19T19:14:05Z<p>Dave.demarle: </p>
<hr />
<div>== Writing Xdmf ==<br />
<br />
<pre style="color: red">Note this code snippet is from version 2 or 1 and needs updating for xdmf3.</pre><br />
<br />
Xdmf can be generated in many different manners. Using the low level HDF5 library and print statements <br />
is certainly one of them. Utilizing the XDMF API, however, provides some convenient advantages. Suppose we wanted <br />
to generate an XDMF dataset of a co-rectilinear mesh with scalar values at each node<br />
<br />
from Xdmf import *<br />
<br />
d = XdmfDOM() <br />
<br />
root = XdmfRoot()<br />
root.SetDOM(d)<br />
root.SetVersion(2.2) # Change the Version number because we can<br />
root.Build()<br />
# Information<br />
i = XdmfInformation() # Arbitrary Name=Value Facility<br />
i.SetName("SampleLocation")<br />
i.SetValue("4")<br />
root.Insert(i) # XML DOM is used as the keeper of the structure<br />
# Insert() creates an XML node and inserts it under<br />
# the parent<br />
# Domain<br />
dm = XdmfDomain()<br />
root.Insert(dm)<br />
# Grid<br />
g = XdmfGrid()<br />
g.SetName("Structured Grid")<br />
# Topology<br />
t = g.GetTopology()<br />
t.SetTopologyType(XDMF_3DCORECTMESH)<br />
t.GetShapeDesc().SetShapeFromString('10 20 30')<br />
# Geometry<br />
geo = g.GetGeometry()<br />
geo.SetGeometryType(XDMF_GEOMETRY_ORIGIN_DXDYDZ)<br />
geo.SetOrigin(1, 2, 3)<br />
geo.SetDxDyDz(0.1, 0.2, 0.3)<br />
dm.Insert(g)<br />
# Attribute<br />
attr = XdmfAttribute()<br />
attr.SetName("Pressure")<br />
attr.SetAttributeCenter(XDMF_ATTRIBUTE_CENTER_NODE);<br />
attr.SetAttributeType(XDMF_ATTRIBUTE_TYPE_SCALAR);<br />
p = attr.GetValues()<br />
p.SetShapeFromString("10 20 30")<br />
p.Generate(0.0, 1.0, 0, p.GetNumberOfElements() - 1)<br />
g.Insert(attr)<br />
# Update XML and Write Values to DataItems<br />
root.Build() # DataItems > 100 values are heavy<br />
print d.Serialize() # prints to stdout <br />
<br />
d.Write('SMesh.xmf') # write to file<br />
<br />
<br />
<br />
Would result in the Light Data XML to be written to the file Smesh.xmf and the Heavy data<br />
to be written to Xdmf.h5.<br />
<br />
<?xml version="1.0" ?><br />
<!DOCTYPE Xdmf SYSTEM "Xdmf.dtd" []><br />
<Xdmf xmlns:xi="http://www.w3.org/2003/XInclude" Version="2.2"><br />
<Information Name="SampleLocation" Value="4"/><br />
<Domain><br />
<Grid Name="Structured Grid" GridType="Uniform"><br />
<Topology TopologyType="3DCORECTMesh" NumberOfElements="10 20 30 "/><br />
<Geometry GeometryType="ORIGIN_DXDYDZ"><br />
<DataItem Dimensions="3 " NumberType="Float" Precision="4" Format="XML"><br />
1 2 3<br />
</DataItem><br />
<DataItem Dimensions="3 " NumberType="Float" Precision="4" Format="XML"><br />
0.1 0.2 0.3<br />
</DataItem><br />
</Geometry><br />
<Attribute Name="Pressure" AttributeType="Scalar" Center="Cell"><br />
<DataItem Dimensions="6000 " NumberType="Float" Precision="4" Format="HDF">Xdmf.h5:/Data</DataItem><br />
</Attribute><br />
</Grid><br />
</Domain><br />
</Xdmf><br />
<br />
Now suppose the HDF5 already existed or we wanted to write the HDF5 files in a specific manner.<br />
All XdmfElements have a SetDataXml() method which takes a raw XML string. When the element is<br />
built, the XML is blindly copied in and the writing of HeavyData is skipped.<br />
<br />
#!/usr/bin/env python<br />
<br />
from Xdmf import *<br />
<br />
# Example of How to Generate Xdmf<br />
# The Heavy Data for the Attribute is written separately<br />
<br />
# Write H5 Data<br />
arr = XdmfArray()<br />
arr.SetNumberType(XDMF_FLOAT64_TYPE)<br />
arr.SetShapeFromString("10 20 30")<br />
arr.Generate(0.0, 1.0, 0, arr.GetNumberOfElements() - 1)<br />
h5 = XdmfHDF()<br />
h5.CopyType(arr)<br />
h5.CopyShape(arr)<br />
h5.Open('XdmfByHand.h5:/Mydata', 'w')<br />
h5.Write(arr)<br />
h5.Close()<br />
# Use XdmfValuesHDF to generate the appropriate<br />
# Xdmf XML from and existing HDF5 dataset<br />
dv = XdmfValuesHDF()<br />
DataXml = dv.DataItemFromHDF('XdmfByHand.h5:/Mydata')<br />
#<br />
# Now build the tree of objects<br />
d = XdmfDOM()<br />
<br />
root = XdmfRoot()<br />
root.SetDOM(d)<br />
root.SetVersion(2.2) # Change the Version number because we can<br />
root.Build()<br />
# Information<br />
i = XdmfInformation() # Arbitrary Name=Value Facility<br />
i.SetName("SampleLocation")<br />
i.SetValue("4")<br />
root.Insert(i) # XML DOM is used as the keeper of the structure<br />
# Insert() creates an XML node and inserts it under<br />
# the parent<br />
# Domain<br />
dm = XdmfDomain()<br />
root.Insert(dm)<br />
# Grid<br />
g = XdmfGrid()<br />
g.SetName("Structured Grid")<br />
# Topology<br />
t = g.GetTopology()<br />
t.SetTopologyType(XDMF_3DCORECTMESH)<br />
t.GetShapeDesc().SetShapeFromString('10 20 30')<br />
# Geometry<br />
geo = g.GetGeometry()<br />
geo.SetGeometryType(XDMF_GEOMETRY_ORIGIN_DXDYDZ)<br />
geo.SetOrigin(1, 2, 3)<br />
geo.SetDxDyDz(0.1, 0.2, 0.3)<br />
dm.Insert(g)<br />
# Attribute<br />
attr = XdmfAttribute()<br />
attr.SetName("Pressure")<br />
attr.SetAttributeCenter(XDMF_ATTRIBUTE_CENTER_NODE);<br />
attr.SetAttributeType(XDMF_ATTRIBUTE_TYPE_SCALAR);<br />
# Insert the raw XML<br />
attr.SetDataXml(DataXml)<br />
g.Insert(attr)<br />
# Update XML and Write Values to DataItems<br />
root.Build() # DataItems > 100 values are heavy<br />
print d.Serialize() # prints to stdout <br />
<br />
d.Write('SMesh.xmf') # write to file<br />
<br />
This results in identical XML with just the name of the HDF5 dataset changed. <br />
~</div>Dave.demarlehttps://www.xdmf.org/index.php?title=Read_Xdmf&diff=110Read Xdmf2014-08-19T19:12:14Z<p>Dave.demarle: </p>
<hr />
<div>== Reading XDMF Data ==<br />
<br />
[[Image:TwoHex.jpg]]<br />
<br />
The following Xdmf XML file is a simple example of a Uniform Grid that contains two Hexahedron that share a face.<br />
There are values centered at the nodes and at the cell centers. The values for geometry, connectivity, and scalars are<br />
all stored directly in the XML file.<br />
<br />
<?xml version="1.0" ?><br />
<!DOCTYPE Xdmf SYSTEM "Xdmf.dtd" []><br />
<br />
<br />
<Xdmf><br />
<Domain><br />
<Grid Name="TestGrid"><br />
<Topology Type="Hexahedron" NumberOfElements="2" ><br />
<DataItem Format="XML" DataType="Float"<br />
Dimensions="2 8"><br />
0 1 7 6 3 4 10 9<br />
1 2 8 7 4 5 11 10<br />
</DataItem><br />
</Topology><br />
<Geometry Type="XYZ"><br />
<DataItem Format="XML" DataType="Float" Precision="8"<br />
Dimensions="4 3 3"><br />
0.0 0.0 1.0<br />
1.0 0.0 1.0<br />
3.0 0.0 2.0<br />
<br />
0.0 1.0 1.0<br />
1.0 1.0 1.0<br />
3.0 2.0 2.0<br />
<br />
0.0 0.0 -1.0<br />
1.0 0.0 -1.0<br />
3.0 0.0 -2.0<br />
<br />
0.0 1.0 -1.0<br />
1.0 1.0 -1.0<br />
3.0 2.0 -2.0<br />
</DataItem><br />
</Geometry><br />
<Attribute Name="NodeValues" Center="Node"><br />
<DataItem Format="XML" DataType="Float" Precision="8"<br />
Dimensions="4 3" ><br />
100 200 300<br />
300 400 500<br />
300 400 500<br />
500 600 700<br />
</DataItem><br />
</Attribute><br />
<Attribute Name="CellValues" Center="Cell"><br />
<DataItem Format="XML" DataType="Float" Precision="8"<br />
Dimensions="2" ><br />
100 200<br />
</DataItem><br />
</Attribute><br />
</Grid><br />
</Domain><br />
</Xdmf><br />
<br />
The XML is stored in the file "MyGrid.xmf". The following Python program demonstrated parsing the XML and<br />
retrieving the data values.<br />
<br />
<pre style="color: red">Note this code snippet is from version 2 or 1 and needs updating for xdmf3.</pre><br />
<br />
from Xdmf import *<br />
dom = XdmfDOM()<br />
dom.Parse('MyGrid.xmf')<br />
# We now have a tree. Find the one and only Grid element<br />
ge = dom.FindElementByPath('/Xdmf/Domain/Grid')<br />
grid = XdmfGrid()<br />
grid.SetDOM(dom) <br />
grid.SetElement(ge)<br />
# Read Light Data<br />
grid.UpdateInformation()<br />
# Read Heavy Data which includes Topology and Geometry<br />
grid.Update()<br />
<br />
top = grid.GetTopology()<br />
conn = top.GetConnectivity()<br />
print 'Values = ', conn.GetValues()<br />
<br />
geo = grid.GetGeometry()<br />
points = geo.GetPoints()<br />
print 'Geo Type = ', geo.GetGeometryTypeAsString(), ' # Points = ', geo.GetNumberOfPoints()<br />
print 'Points = ', points.GetValues()<br />
# for each Attribute, print Light Data and Values<br />
for i in range(grid.GetNumberOfAttributes()) :<br />
attr = grid.GetAttribute(i)<br />
print 'Attribute ', i, ' Name = ', attr.Get('Name')<br />
# Attribute HeavyData is not Updated by default<br />
# there could potentially be many causing huge IO<br />
attr.Update()<br />
vals = attr.GetValues()<br />
print 'Values ', vals.GetValues()</div>Dave.demarlehttps://www.xdmf.org/index.php?title=Main_Page&diff=109Main Page2014-08-19T19:09:51Z<p>Dave.demarle: </p>
<hr />
<div>[[Image:XdmfLogo1.gif]]<br />
<br />
<span style='color:blue'><big>e<span style='color:red'>'''X'''</span>tensible <span style='color:red'>'''D'''</span>ata <span style='color:red'>'''M'''</span>odel and <span style='color:red'>'''F'''</span>ormat</big></span><br />
<br />
<br />
<br />
The need for a standardized method to exchange scientific data between High Performance Computing codes and tools lead to the development of the eXtensible Data Model and Format (XDMF) . Uses for XDMF range from a standard format used by HPC codes to take advantage of widely used visualization programs like ParaView, to a mechanism for performing coupled calculations using multiple, previously stand alone codes. <br />
<br />
Data format refers to the raw data to be manipulated. Information like number type ( float, integer, etc.), precision, location, rank, and dimensions completely describe the any dataset regardless of its size. The description of the data is also separate from the values themselves. We refer to the description of the data as '''Light''' data and the values themselves as '''Heavy''' data. Light data is small and can be passed between modules easily. Heavy data may be potentially enormous; movement needs to be kept to a minimum. Due to the different nature of heavy and light data, they are stored using separate mechanisms. Light data is stored using XML, Heavy data is typically stored using HDF5. While we could have chosen to store the light data using HDF5 attributes using XML does not require every tool to have access to the compiled HDF5 libraries in order to perform simple operations.<br />
<br />
Data model refers to the intended use of the data. For example, a three dimensional array of floating point vales may be the X,Y,Z geometry for a grid or calculated vector values. Without a data model, it is impossible to tell the difference. Since the data model only describes the data, it is purely light data and thus stored using XML. It is targeted at scientific simulation data concentrating on scalars, vectors, and tensors defined on some type of computational grid. Structured and Unstructured grids are described via their topology and geometry. Calculated, time varying data values are described as attributes of the grid. The actual values for the grid geometry, connectivity, and attribute values are contained in the data format. This separation of data format and model allows HPC codes to efficiently produce and store vales in a convenient manner without being encumbered by our data model which may be different from their internal arrangement.<br />
<br />
<br />
XDMF uses XML to store Light data and to describe the data Model. HDF5 is used to store Heavy data. The data Format is stored redundantly in both XML and HDF5. This allows tools to parse XML to determine the resources that will be required to access the Heavy data. <br />
<br />
The data model in XDMF stored in XML provides the knowledge of what is represented by the Heavy data. In this model, HPC data is viewed as a hierarchy of Domains. A Domain must contain at least one Grid. A Grid is the basic representation of both the geometric and computed/measured values. A Grid is considered to be a group of elements with Structured or Unstructured Topology and their associated values. In addition to the topology of the Grid, Geometry, specifying the X, Y, and Z positions of the Grid is required. Finally, a Grid may have one or more Attributes. Attributes are used to store any other value associated with the grid and may be referenced to the Grid or to individual cells that comprise the Grid. <br />
<br />
The concept of separating the light data from the heavy data is critical to the performance of this data model and format. HPC codes can read and write data in large, contiguous chunks that are natural to their internal data storage, to achieve optimal I/O performance. If codes were required to significantly re-arrange data prior to I/O operations, data locality, and thus performance, could be adversely affected, particularly on codes that attempt to make maximum use of memory cache. The complexity of the dataset is described in the light data portion, which is small and transportable. For example, the light data might specify a topology of one million hexaherda while the heavy data would contain the geometric XYZ values of the mesh and pressure values at the cell centers stored in large, contiguous arrays. This key feature will allow reusable tools to be built that do not put onerous requirements on HPC codes. Despite the complexity of the organization described in the XML below, the HPC code only needs to produce the three HDF5 datasets for geometry, connectivity, and pressure values.<br />
<br />
While not required, a C++ API is provided to read and write XDMF data. This API has also been wrapped so it is available from popular languages like Python, Tcl, and Java. The API is not necessary in order to produce or consume XDMF data. Currently several HPC codes that already produced HDF5 data, use native text output to produce the XML necessary for valid XDMF. <br />
<br />
'''More Detail'''<br />
<br />
*[[XDMF Model and Format]]<br />
<br />
*[[XDMF API]]<br />
<br />
'''How do I ...'''<br />
# [[Get Xdmf]]<br />
# [[Use XDMF from wrapped languages]]<br />
# [[Read Xdmf]]<br />
# [[Write Xdmf]]<br />
# [[Write from Fortran]]<br />
# [[Read from MySQL]]<br />
# [[Parallel IO with MPI]]<br />
<br />
'''Data Format Examples'''<br />
* The files for the xdmf3 regression test suite can be obtained from a VTK build tree in $BLDTREE/ExternalData/Testing/Data/XDMF<br />
* Generate or read in data to ParaView, and save it into XDMF format.<br />
* [http://www.paraview.org/Wiki/ParaView/Data_formats#Reading_a_time_varying_Raw_file_into_Paraview| time varying binary data dumps]<br />
* [[examples/imagedata | ImageData from h5 array]]<br />
<br />
'''History and Road Map'''<br />
* [[Version 1]]<br />
* [[Version 2]]<br />
* [[Version 3]]<br />
* [[V3_Road_Feature_Request|Feature Requests]]<br />
<br />
'''Mailing list'''<br />
* Join the Xdmf mailing list [http://www.kitware.com/cgi-bin/mailman/listinfo/xdmf here]<br />
<br />
'''Bug reports'''<br />
* To report a bug or request a feature, go to the [http://public.kitware.com/Bug Mantis Bugtracking system] and select Project:Xdmf from the dropdown list.<br />
<br />
=== web site administration ===<br />
<br />
'''Wiki Account'''<br />
* Please improve the pages! Send an email to Dave DeMarle at kitware.com with XDMF in the subject that includes your preferred user name and email address in the message body to do so.<br />
<br />
* [http://www.mediawiki.org/wiki/Help:Configuration_settings Configuration settings list]<br />
* [http://www.mediawiki.org/wiki/Help:FAQ MediaWiki FAQ]<br />
* [http://mail.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list]</div>Dave.demarlehttps://www.xdmf.org/index.php?title=Version_3&diff=108Version 32014-08-19T19:07:34Z<p>Dave.demarle: </p>
<hr />
<div>Version "3" of Xdmf can be obtained from:<br />
git://public.kitware.com/Xdmf2.git<br />
<br />
The initial plans for changes that went into version 3 are summarized on:<br />
[http://xdmf.org/index.php/Xdmf::New()]<br />
<br />
The overall goals included better performance and use of modern and more maintainable C++ programming idioms. This version adds a dependence on boost.<br />
<br />
Additionally, this version added support for Graph types and removed support for the SQL back end.</div>Dave.demarlehttps://www.xdmf.org/index.php?title=Version_2&diff=107Version 22014-08-19T19:05:54Z<p>Dave.demarle: </p>
<hr />
<div>Version "2" of Xdmf can be found at:<br />
<br />
git clone git://xdmf.org/Xdmf.git<br />
<br />
There are two important branches in the repository, "master" and "pv". The "pv" branch was restructured during the ParaView 4 release to update it to be compatible with VTK 6.x's modularized build system.<br />
<br />
The updates to Xdmf in version 2 are summarized in this paper:<br />
[http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADP023792]<br />
and this podcast [http://www.rce-cast.com/components/com_podcast/media/40RCE-xdmf.mp3]</div>Dave.demarlehttps://www.xdmf.org/index.php?title=Version_2&diff=106Version 22014-08-19T19:03:28Z<p>Dave.demarle: explain the "pv" branch.</p>
<hr />
<div>Version "2" of Xdmf can be found at:<br />
<br />
git clone git://xdmf.org/Xdmf.git<br />
<br />
There are two important branches in the repository, "master" and "pv". The "pv" branch was restructured during the ParaView 4 release to update it to be compatible with VTK 6.x's modularized build system.<br />
<br />
The updates to Xdmf in version 2 are summarized in this paper:<br />
[http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADP023792]</div>Dave.demarlehttps://www.xdmf.org/index.php?title=Main_Page&diff=105Main Page2014-08-19T18:59:17Z<p>Dave.demarle: </p>
<hr />
<div>[[Image:XdmfLogo1.gif]]<br />
<br />
<span style='color:blue'><big>e<span style='color:red'>'''X'''</span>tensible <span style='color:red'>'''D'''</span>ata <span style='color:red'>'''M'''</span>odel and <span style='color:red'>'''F'''</span>ormat</big></span><br />
<br />
<br />
<br />
The need for a standardized method to exchange scientific data between High Performance Computing codes and tools lead to the development of the eXtensible Data Model and Format (XDMF) . Uses for XDMF range from a standard format used by HPC codes to take advantage of widely used visualization programs like ParaView, to a mechanism for performing coupled calculations using multiple, previously stand alone codes. <br />
<br />
Data format refers to the raw data to be manipulated. Information like number type ( float, integer, etc.), precision, location, rank, and dimensions completely describe the any dataset regardless of its size. The description of the data is also separate from the values themselves. We refer to the description of the data as '''Light''' data and the values themselves as '''Heavy''' data. Light data is small and can be passed between modules easily. Heavy data may be potentially enormous; movement needs to be kept to a minimum. Due to the different nature of heavy and light data, they are stored using separate mechanisms. Light data is stored using XML, Heavy data is typically stored using HDF5. While we could have chosen to store the light data using HDF5 attributes using XML does not require every tool to have access to the compiled HDF5 libraries in order to perform simple operations.<br />
<br />
Data model refers to the intended use of the data. For example, a three dimensional array of floating point vales may be the X,Y,Z geometry for a grid or calculated vector values. Without a data model, it is impossible to tell the difference. Since the data model only describes the data, it is purely light data and thus stored using XML. It is targeted at scientific simulation data concentrating on scalars, vectors, and tensors defined on some type of computational grid. Structured and Unstructured grids are described via their topology and geometry. Calculated, time varying data values are described as attributes of the grid. The actual values for the grid geometry, connectivity, and attribute values are contained in the data format. This separation of data format and model allows HPC codes to efficiently produce and store vales in a convenient manner without being encumbered by our data model which may be different from their internal arrangement.<br />
<br />
<br />
XDMF uses XML to store Light data and to describe the data Model. HDF5 is used to store Heavy data. The data Format is stored redundantly in both XML and HDF5. This allows tools to parse XML to determine the resources that will be required to access the Heavy data. <br />
<br />
The data model in XDMF stored in XML provides the knowledge of what is represented by the Heavy data. In this model, HPC data is viewed as a hierarchy of Domains. A Domain must contain at least one Grid. A Grid is the basic representation of both the geometric and computed/measured values. A Grid is considered to be a group of elements with Structured or Unstructured Topology and their associated values. In addition to the topology of the Grid, Geometry, specifying the X, Y, and Z positions of the Grid is required. Finally, a Grid may have one or more Attributes. Attributes are used to store any other value associated with the grid and may be referenced to the Grid or to individual cells that comprise the Grid. <br />
<br />
The concept of separating the light data from the heavy data is critical to the performance of this data model and format. HPC codes can read and write data in large, contiguous chunks that are natural to their internal data storage, to achieve optimal I/O performance. If codes were required to significantly re-arrange data prior to I/O operations, data locality, and thus performance, could be adversely affected, particularly on codes that attempt to make maximum use of memory cache. The complexity of the dataset is described in the light data portion, which is small and transportable. For example, the light data might specify a topology of one million hexaherda while the heavy data would contain the geometric XYZ values of the mesh and pressure values at the cell centers stored in large, contiguous arrays. This key feature will allow reusable tools to be built that do not put onerous requirements on HPC codes. Despite the complexity of the organization described in the XML below, the HPC code only needs to produce the three HDF5 datasets for geometry, connectivity, and pressure values.<br />
<br />
While not required, a C++ API is provided to read and write XDMF data. This API has also been wrapped so it is available from popular languages like Python, Tcl, and Java. The API is not necessary in order to produce or consume XDMF data. Currently several HPC codes that already produced HDF5 data, use native text output to produce the XML necessary for valid XDMF. <br />
<br />
'''More Detail'''<br />
<br />
*[[XDMF Model and Format]]<br />
<br />
*[[XDMF API]]<br />
<br />
'''How do I ...'''<br />
# [[Get Xdmf]]<br />
# [[Read Xdmf]]<br />
# [[Write Xdmf]]<br />
# [[Write from Fortran]]<br />
# [[Read from MySQL]]<br />
# [[Parallel IO with MPI]]<br />
<br />
'''Data Format Examples'''<br />
* The files for the xdmf3 regression test suite can be obtained from a VTK build tree in $BLDTREE/ExternalData/Testing/Data/XDMF<br />
* Generate or read in data to ParaView, and save it into XDMF format.<br />
* [http://www.paraview.org/Wiki/ParaView/Data_formats#Reading_a_time_varying_Raw_file_into_Paraview| time varying binary data dumps]<br />
* [[examples/imagedata | ImageData from h5 array]]<br />
<br />
'''History and Road Map'''<br />
* [[Version 1]]<br />
* [[Version 2]]<br />
* [[Version 3]]<br />
* [[V3_Road_Feature_Request|Feature Requests]]<br />
<br />
'''Mailing list'''<br />
* Join the Xdmf mailing list [http://www.kitware.com/cgi-bin/mailman/listinfo/xdmf here]<br />
<br />
'''Bug reports'''<br />
* To report a bug or request a feature, go to the [http://public.kitware.com/Bug Mantis Bugtracking system] and select Project:Xdmf from the dropdown list.<br />
<br />
=== web site administration ===<br />
<br />
'''Wiki Account'''<br />
* Please improve the pages! Send an email to Dave DeMarle at kitware.com with XDMF in the subject that includes your preferred user name and email address in the message body to do so.<br />
<br />
* [http://www.mediawiki.org/wiki/Help:Configuration_settings Configuration settings list]<br />
* [http://www.mediawiki.org/wiki/Help:FAQ MediaWiki FAQ]<br />
* [http://mail.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list]</div>Dave.demarlehttps://www.xdmf.org/index.php?title=Main_Page&diff=104Main Page2014-08-19T18:58:55Z<p>Dave.demarle: </p>
<hr />
<div>[[Image:XdmfLogo1.gif]]<br />
<br />
<span style='color:blue'><big>e<span style='color:red'>'''X'''</span>tensible <span style='color:red'>'''D'''</span>ata <span style='color:red'>'''M'''</span>odel and <span style='color:red'>'''F'''</span>ormat</big></span><br />
<br />
<br />
<br />
The need for a standardized method to exchange scientific data between High Performance Computing codes and tools lead to the development of the eXtensible Data Model and Format (XDMF) . Uses for XDMF range from a standard format used by HPC codes to take advantage of widely used visualization programs like ParaView, to a mechanism for performing coupled calculations using multiple, previously stand alone codes. <br />
<br />
Data format refers to the raw data to be manipulated. Information like number type ( float, integer, etc.), precision, location, rank, and dimensions completely describe the any dataset regardless of its size. The description of the data is also separate from the values themselves. We refer to the description of the data as '''Light''' data and the values themselves as '''Heavy''' data. Light data is small and can be passed between modules easily. Heavy data may be potentially enormous; movement needs to be kept to a minimum. Due to the different nature of heavy and light data, they are stored using separate mechanisms. Light data is stored using XML, Heavy data is typically stored using HDF5. While we could have chosen to store the light data using HDF5 attributes using XML does not require every tool to have access to the compiled HDF5 libraries in order to perform simple operations.<br />
<br />
Data model refers to the intended use of the data. For example, a three dimensional array of floating point vales may be the X,Y,Z geometry for a grid or calculated vector values. Without a data model, it is impossible to tell the difference. Since the data model only describes the data, it is purely light data and thus stored using XML. It is targeted at scientific simulation data concentrating on scalars, vectors, and tensors defined on some type of computational grid. Structured and Unstructured grids are described via their topology and geometry. Calculated, time varying data values are described as attributes of the grid. The actual values for the grid geometry, connectivity, and attribute values are contained in the data format. This separation of data format and model allows HPC codes to efficiently produce and store vales in a convenient manner without being encumbered by our data model which may be different from their internal arrangement.<br />
<br />
<br />
XDMF uses XML to store Light data and to describe the data Model. HDF5 is used to store Heavy data. The data Format is stored redundantly in both XML and HDF5. This allows tools to parse XML to determine the resources that will be required to access the Heavy data. <br />
<br />
The data model in XDMF stored in XML provides the knowledge of what is represented by the Heavy data. In this model, HPC data is viewed as a hierarchy of Domains. A Domain must contain at least one Grid. A Grid is the basic representation of both the geometric and computed/measured values. A Grid is considered to be a group of elements with Structured or Unstructured Topology and their associated values. In addition to the topology of the Grid, Geometry, specifying the X, Y, and Z positions of the Grid is required. Finally, a Grid may have one or more Attributes. Attributes are used to store any other value associated with the grid and may be referenced to the Grid or to individual cells that comprise the Grid. <br />
<br />
The concept of separating the light data from the heavy data is critical to the performance of this data model and format. HPC codes can read and write data in large, contiguous chunks that are natural to their internal data storage, to achieve optimal I/O performance. If codes were required to significantly re-arrange data prior to I/O operations, data locality, and thus performance, could be adversely affected, particularly on codes that attempt to make maximum use of memory cache. The complexity of the dataset is described in the light data portion, which is small and transportable. For example, the light data might specify a topology of one million hexaherda while the heavy data would contain the geometric XYZ values of the mesh and pressure values at the cell centers stored in large, contiguous arrays. This key feature will allow reusable tools to be built that do not put onerous requirements on HPC codes. Despite the complexity of the organization described in the XML below, the HPC code only needs to produce the three HDF5 datasets for geometry, connectivity, and pressure values.<br />
<br />
While not required, a C++ API is provided to read and write XDMF data. This API has also been wrapped so it is available from popular languages like Python, Tcl, and Java. The API is not necessary in order to produce or consume XDMF data. Currently several HPC codes that already produced HDF5 data, use native text output to produce the XML necessary for valid XDMF. <br />
<br />
'''More Detail'''<br />
<br />
*[[XDMF Model and Format]]<br />
<br />
*[[XDMF API]]<br />
<br />
'''How do I ...'''<br />
# [[Get Xdmf]]<br />
# [[Read Xdmf]]<br />
# [[Write Xdmf]]<br />
# [[Write from Fortran]]<br />
# [[Read from MySQL]]<br />
# [[Parallel IO with MPI]]<br />
<br />
'''Data Format Examples'''<br />
* The files for the xdmf3 regression test suite can be obtained from a VTK build tree in $BLDTREE/ExternalData/Testing/Data/XDMF<br />
* Generate or read in data to ParaView, and save it into XDMF format.<br />
* [http://www.paraview.org/Wiki/ParaView/Data_formats#Reading_a_time_varying_Raw_file_into_Paraview| time varying binary data dumps]<br />
* [[examples/imagedata | ImageData from h5 array]]<br />
<br />
'''History and Road Map'''<br />
* [[Version 1]]<br />
* [[Version 2]]<br />
* [[Xdmf::New()|'''What's Next''']]<br />
* [[Version 3]]<br />
* [[V3_Road_Feature_Request|Feature Requests]]<br />
<br />
'''Mailing list'''<br />
* Join the Xdmf mailing list [http://www.kitware.com/cgi-bin/mailman/listinfo/xdmf here]<br />
<br />
'''Bug reports'''<br />
* To report a bug or request a feature, go to the [http://public.kitware.com/Bug Mantis Bugtracking system] and select Project:Xdmf from the dropdown list.<br />
<br />
=== web site administration ===<br />
<br />
'''Wiki Account'''<br />
* Please improve the pages! Send an email to Dave DeMarle at kitware.com with XDMF in the subject that includes your preferred user name and email address in the message body to do so.<br />
<br />
* [http://www.mediawiki.org/wiki/Help:Configuration_settings Configuration settings list]<br />
* [http://www.mediawiki.org/wiki/Help:FAQ MediaWiki FAQ]<br />
* [http://mail.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list]</div>Dave.demarlehttps://www.xdmf.org/index.php?title=Version_3&diff=103Version 32014-08-19T18:57:57Z<p>Dave.demarle: Created page with "Version "3" of Xdmf can be obtained from: git://public.kitware.com/Xdmf2.git The initial plans for changes that went into version 3 are summarized on: [http://xdmf.org/index...."</p>
<hr />
<div>Version "3" of Xdmf can be obtained from:<br />
git://public.kitware.com/Xdmf2.git<br />
<br />
The initial plans for changes that went into version 3 are summarized on:<br />
[http://xdmf.org/index.php/Xdmf::New()]<br />
<br />
Additionally, this version added support for Graph types.</div>Dave.demarlehttps://www.xdmf.org/index.php?title=Version_2&diff=102Version 22014-08-19T18:54:58Z<p>Dave.demarle: </p>
<hr />
<div>Version "2" of Xdmf can be found at:<br />
<br />
git clone git://xdmf.org/Xdmf.git<br />
<br />
The updates to Xdmf in version 2 are summarized in this paper:<br />
[http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADP023792]</div>Dave.demarlehttps://www.xdmf.org/index.php?title=Version_1&diff=101Version 12014-08-19T18:52:28Z<p>Dave.demarle: Created page with "Version "1" of xdmf can be obtained via: cvs -d :pserver:anonymous@public.kitware.com:/cvsroot/Xdmf login cvs -d :pserver:anonymous@public.kitware.com:/cvsroot/Xdmf checkou..."</p>
<hr />
<div>Version "1" of xdmf can be obtained via:<br />
<br />
cvs -d :pserver:anonymous@public.kitware.com:/cvsroot/Xdmf login<br />
cvs -d :pserver:anonymous@public.kitware.com:/cvsroot/Xdmf checkout Xdmf</div>Dave.demarlehttps://www.xdmf.org/index.php?title=Version_2&diff=100Version 22014-08-19T18:45:42Z<p>Dave.demarle: Created page with "version "2" of Xdmf can be found at: git clone git://xdmf.org/Xdmf.git"</p>
<hr />
<div>version "2" of Xdmf can be found at:<br />
git clone git://xdmf.org/Xdmf.git</div>Dave.demarlehttps://www.xdmf.org/index.php?title=Main_Page&diff=99Main Page2014-08-19T18:37:31Z<p>Dave.demarle: </p>
<hr />
<div>[[Image:XdmfLogo1.gif]]<br />
<br />
<span style='color:blue'><big>e<span style='color:red'>'''X'''</span>tensible <span style='color:red'>'''D'''</span>ata <span style='color:red'>'''M'''</span>odel and <span style='color:red'>'''F'''</span>ormat</big></span><br />
<br />
<br />
<br />
The need for a standardized method to exchange scientific data between High Performance Computing codes and tools lead to the development of the eXtensible Data Model and Format (XDMF) . Uses for XDMF range from a standard format used by HPC codes to take advantage of widely used visualization programs like ParaView, to a mechanism for performing coupled calculations using multiple, previously stand alone codes. <br />
<br />
Data format refers to the raw data to be manipulated. Information like number type ( float, integer, etc.), precision, location, rank, and dimensions completely describe the any dataset regardless of its size. The description of the data is also separate from the values themselves. We refer to the description of the data as '''Light''' data and the values themselves as '''Heavy''' data. Light data is small and can be passed between modules easily. Heavy data may be potentially enormous; movement needs to be kept to a minimum. Due to the different nature of heavy and light data, they are stored using separate mechanisms. Light data is stored using XML, Heavy data is typically stored using HDF5. While we could have chosen to store the light data using HDF5 attributes using XML does not require every tool to have access to the compiled HDF5 libraries in order to perform simple operations.<br />
<br />
Data model refers to the intended use of the data. For example, a three dimensional array of floating point vales may be the X,Y,Z geometry for a grid or calculated vector values. Without a data model, it is impossible to tell the difference. Since the data model only describes the data, it is purely light data and thus stored using XML. It is targeted at scientific simulation data concentrating on scalars, vectors, and tensors defined on some type of computational grid. Structured and Unstructured grids are described via their topology and geometry. Calculated, time varying data values are described as attributes of the grid. The actual values for the grid geometry, connectivity, and attribute values are contained in the data format. This separation of data format and model allows HPC codes to efficiently produce and store vales in a convenient manner without being encumbered by our data model which may be different from their internal arrangement.<br />
<br />
<br />
XDMF uses XML to store Light data and to describe the data Model. HDF5 is used to store Heavy data. The data Format is stored redundantly in both XML and HDF5. This allows tools to parse XML to determine the resources that will be required to access the Heavy data. <br />
<br />
The data model in XDMF stored in XML provides the knowledge of what is represented by the Heavy data. In this model, HPC data is viewed as a hierarchy of Domains. A Domain must contain at least one Grid. A Grid is the basic representation of both the geometric and computed/measured values. A Grid is considered to be a group of elements with Structured or Unstructured Topology and their associated values. In addition to the topology of the Grid, Geometry, specifying the X, Y, and Z positions of the Grid is required. Finally, a Grid may have one or more Attributes. Attributes are used to store any other value associated with the grid and may be referenced to the Grid or to individual cells that comprise the Grid. <br />
<br />
The concept of separating the light data from the heavy data is critical to the performance of this data model and format. HPC codes can read and write data in large, contiguous chunks that are natural to their internal data storage, to achieve optimal I/O performance. If codes were required to significantly re-arrange data prior to I/O operations, data locality, and thus performance, could be adversely affected, particularly on codes that attempt to make maximum use of memory cache. The complexity of the dataset is described in the light data portion, which is small and transportable. For example, the light data might specify a topology of one million hexaherda while the heavy data would contain the geometric XYZ values of the mesh and pressure values at the cell centers stored in large, contiguous arrays. This key feature will allow reusable tools to be built that do not put onerous requirements on HPC codes. Despite the complexity of the organization described in the XML below, the HPC code only needs to produce the three HDF5 datasets for geometry, connectivity, and pressure values.<br />
<br />
While not required, a C++ API is provided to read and write XDMF data. This API has also been wrapped so it is available from popular languages like Python, Tcl, and Java. The API is not necessary in order to produce or consume XDMF data. Currently several HPC codes that already produced HDF5 data, use native text output to produce the XML necessary for valid XDMF. <br />
<br />
'''More Detail'''<br />
<br />
*[[XDMF Model and Format]]<br />
<br />
*[[XDMF API]]<br />
<br />
'''How do I ...'''<br />
# [[Get Xdmf]]<br />
# [[Read Xdmf]]<br />
# [[Write Xdmf]]<br />
# [[Write from Fortran]]<br />
# [[Read from MySQL]]<br />
# [[Parallel IO with MPI]]<br />
<br />
'''Data Format Examples'''<br />
* The files for the xdmf3 regression test suite can be obtained from a VTK build tree in $BLDTREE/ExternalData/Testing/Data/XDMF<br />
* Generate or read in data to ParaView, and save it into XDMF format.<br />
* [http://www.paraview.org/Wiki/ParaView/Data_formats#Reading_a_time_varying_Raw_file_into_Paraview| time varying binary data dumps]<br />
* [[examples/imagedata | ImageData from h5 array]]<br />
<br />
'''History and Road Map'''<br />
* [[Version 1]]<br />
* [[Version 2]]<br />
* [[Xdmf::New()|'''What's Next''']]<br />
* [[Version 3]]<br />
* [[V3_Road_Feature_Request|Feature Requests]]<br />
<br />
'''Mailing list'''<br />
* Join the Xdmf mailing list [http://www.kitware.com/cgi-bin/mailman/listinfo/xdmf here]<br />
<br />
'''Bug reports'''<br />
* To report a bug or request a feature, go to the [http://public.kitware.com/Bug Mantis Bugtracking system] and select Project:Xdmf from the dropdown list.<br />
<br />
=== web site administration ===<br />
<br />
'''Wiki Account'''<br />
* To edit these pages, send an email to Dave DeMarle at kitware.com with XDMF in the subject that includes your preferred user name and email address in the message body.<br />
<br />
* [http://www.mediawiki.org/wiki/Help:Configuration_settings Configuration settings list]<br />
* [http://www.mediawiki.org/wiki/Help:FAQ MediaWiki FAQ]<br />
* [http://mail.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list]</div>Dave.demarlehttps://www.xdmf.org/index.php?title=Examples/imagedata&diff=98Examples/imagedata2014-08-19T18:26:04Z<p>Dave.demarle: Created page with "The following will read in an array of floats from h5 with the values associated with the points. <?xml version="1.0" ?> <!DOCTYPE Xdmf SYSTEM "Xdmf.dtd" []> <Xdmf xmlns:x..."</p>
<hr />
<div>The following will read in an array of floats from h5 with the values associated with the points.<br />
<br />
<?xml version="1.0" ?><br />
<!DOCTYPE Xdmf SYSTEM "Xdmf.dtd" []><br />
<Xdmf xmlns:xi="http://www.w3.org/2003/XInclude" Version="2.2"><br />
<Domain><br />
<Grid Name="Particle Images" GridType="Uniform"><br />
<Topology TopologyType="3DCORECTMesh" Dimensions="400 300 300"/><br />
<Geometry GeometryType="ORIGIN_DXDYDZ"><br />
<DataItem Name="Origin" Dimensions="3" NumberType="Float" Precision="4" Format="XML"><br />
0 0 0<br />
</DataItem><br />
<DataItem Name="Spacing" Dimensions="3" NumberType="Float"<br />
Precision="4" Format="XML"><br />
1 1 1<br />
</DataItem><br />
</Geometry><br />
<Attribute Name="second 0" AttributeType="Scalar" Center="Node"><br />
<DataItem Format="HDF" NumberType="UInt" Precision="2" Dimensions="400 300 300">test.hdf:/images/0/image</DataItem><br />
</Attribute><br />
</Grid><br />
</Domain><br />
</Xdmf><br />
<br />
The following will read in an array of floats from h5 with the values associated with the cells.<br />
<br />
<?xml version="1.0" ?><br />
<!DOCTYPE Xdmf SYSTEM "Xdmf.dtd" []><br />
<Xdmf xmlns:xi="http://www.w3.org/2003/XInclude" Version="2.2"><br />
<Domain><br />
<Grid Name="Particle Images" GridType="Uniform"><br />
<Topology TopologyType="3DCORECTMesh" Dimensions="401 301 301"/><br />
<Geometry GeometryType="ORIGIN_DXDYDZ"><br />
<DataItem Name="Origin" Dimensions="3" NumberType="Float" Precision="4" Format="XML"><br />
0 0 0<br />
</DataItem><br />
<DataItem Name="Spacing" Dimensions="3" NumberType="Float"<br />
Precision="4" Format="XML"><br />
1 1 1<br />
</DataItem><br />
</Geometry><br />
<Attribute Name="second 0" AttributeType="Scalar" Center="Cell"><br />
<DataItem Format="HDF" NumberType="UInt" Precision="2" Dimensions="400 300 300">test.hdf:/images/0/image</DataItem><br />
</Attribute><br />
</Grid><br />
</Domain><br />
</Xdmf></div>Dave.demarlehttps://www.xdmf.org/index.php?title=Main_Page&diff=97Main Page2014-08-19T18:14:08Z<p>Dave.demarle: start updating to xdmf3 and adding more useful content</p>
<hr />
<div>[[Image:XdmfLogo1.gif]]<br />
<br />
<span style='color:blue'><big>e<span style='color:red'>'''X'''</span>tensible <span style='color:red'>'''D'''</span>ata <span style='color:red'>'''M'''</span>odel and <span style='color:red'>'''F'''</span>ormat</big></span><br />
<br />
<br />
<br />
The need for a standardized method to exchange scientific data between High Performance Computing codes and tools lead to the development of the eXtensible Data Model and Format (XDMF) . Uses for XDMF range from a standard format used by HPC codes to take advantage of widely used visualization programs like ParaView, to a mechanism for performing coupled calculations using multiple, previously stand alone codes. <br />
<br />
Data format refers to the raw data to be manipulated. Information like number type ( float, integer, etc.), precision, location, rank, and dimensions completely describe the any dataset regardless of its size. The description of the data is also separate from the values themselves. We refer to the description of the data as '''Light''' data and the values themselves as '''Heavy''' data. Light data is small and can be passed between modules easily. Heavy data may be potentially enormous; movement needs to be kept to a minimum. Due to the different nature of heavy and light data, they are stored using separate mechanisms. Light data is stored using XML, Heavy data is typically stored using HDF5. While we could have chosen to store the light data using HDF5 attributes using XML does not require every tool to have access to the compiled HDF5 libraries in order to perform simple operations.<br />
<br />
Data model refers to the intended use of the data. For example, a three dimensional array of floating point vales may be the X,Y,Z geometry for a grid or calculated vector values. Without a data model, it is impossible to tell the difference. Since the data model only describes the data, it is purely light data and thus stored using XML. It is targeted at scientific simulation data concentrating on scalars, vectors, and tensors defined on some type of computational grid. Structured and Unstructured grids are described via their topology and geometry. Calculated, time varying data values are described as attributes of the grid. The actual values for the grid geometry, connectivity, and attribute values are contained in the data format. This separation of data format and model allows HPC codes to efficiently produce and store vales in a convenient manner without being encumbered by our data model which may be different from their internal arrangement.<br />
<br />
<br />
XDMF uses XML to store Light data and to describe the data Model. HDF5 is used to store Heavy data. The data Format is stored redundantly in both XML and HDF5. This allows tools to parse XML to determine the resources that will be required to access the Heavy data. <br />
<br />
The data model in XDMF stored in XML provides the knowledge of what is represented by the Heavy data. In this model, HPC data is viewed as a hierarchy of Domains. A Domain must contain at least one Grid. A Grid is the basic representation of both the geometric and computed/measured values. A Grid is considered to be a group of elements with Structured or Unstructured Topology and their associated values. In addition to the topology of the Grid, Geometry, specifying the X, Y, and Z positions of the Grid is required. Finally, a Grid may have one or more Attributes. Attributes are used to store any other value associated with the grid and may be referenced to the Grid or to individual cells that comprise the Grid. <br />
<br />
The concept of separating the light data from the heavy data is critical to the performance of this data model and format. HPC codes can read and write data in large, contiguous chunks that are natural to their internal data storage, to achieve optimal I/O performance. If codes were required to significantly re-arrange data prior to I/O operations, data locality, and thus performance, could be adversely affected, particularly on codes that attempt to make maximum use of memory cache. The complexity of the dataset is described in the light data portion, which is small and transportable. For example, the light data might specify a topology of one million hexaherda while the heavy data would contain the geometric XYZ values of the mesh and pressure values at the cell centers stored in large, contiguous arrays. This key feature will allow reusable tools to be built that do not put onerous requirements on HPC codes. Despite the complexity of the organization described in the XML below, the HPC code only needs to produce the three HDF5 datasets for geometry, connectivity, and pressure values.<br />
<br />
While not required, a C++ API is provided to read and write XDMF data. This API has also been wrapped so it is available from popular languages like Python, Tcl, and Java. The API is not necessary in order to produce or consume XDMF data. Currently several HPC codes that already produced HDF5 data, use native text output to produce the XML necessary for valid XDMF. <br />
<br />
'''More Detail'''<br />
<br />
*[[XDMF Model and Format]]<br />
<br />
*[[XDMF API]]<br />
<br />
'''How do I ...'''<br />
# [[Get Xdmf]]<br />
# [[Read Xdmf]]<br />
# [[Write Xdmf]]<br />
# [[Write from Fortran]]<br />
# [[Read from MySQL]]<br />
# [[Parallel IO with MPI]]<br />
<br />
'''Examples'''<br />
* [[examples/imagedata | ImageData from h5 array]]<br />
<br />
'''History and Road Map'''<br />
* [[Version 1]]<br />
* [[Version 2]]<br />
* [[Xdmf::New()|'''What's Next''']]<br />
* [[Version 3]]<br />
* [[V3_Road_Feature_Request|Feature Requests]]<br />
<br />
'''Mailing list'''<br />
* Join the Xdmf mailing list [http://www.kitware.com/cgi-bin/mailman/listinfo/xdmf here]<br />
<br />
'''Bug reports'''<br />
* To report a bug or request a feature, go to the [http://public.kitware.com/Bug Mantis Bugtracking system] and select Project:Xdmf from the dropdown list.<br />
<br />
'''Wiki Account'''<br />
* To edit these pages, send an email to Dave DeMarle at kitware.com with XDMF in the subject that includes your preferred user name and email address in the message body.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
* [http://www.mediawiki.org/wiki/Help:Configuration_settings Configuration settings list]<br />
* [http://www.mediawiki.org/wiki/Help:FAQ MediaWiki FAQ]<br />
* [http://mail.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list]</div>Dave.demarlehttps://www.xdmf.org/index.php?title=Main_Page&diff=89Main Page2013-02-25T17:33:36Z<p>Dave.demarle: Undo revision 88 by Special:Contributions/Dave.demarle (User talk:Dave.demarle)</p>
<hr />
<div>[[Image:XdmfLogo1.gif]]<br />
<br />
<span style='color:blue'><big>e<span style='color:red'>'''X'''</span>tensible <span style='color:red'>'''D'''</span>ata <span style='color:red'>'''M'''</span>odel and <span style='color:red'>'''F'''</span>ormat</big></span><br />
<br />
<br />
<br />
The need for a standardized method to exchange scientific data between High Performance Computing codes and tools lead to the development of the eXtensible Data Model and Format (XDMF) . Uses for XDMF range from a standard format used by HPC codes to take advantage of widely used visualization programs like ParaView, to a mechanism for performing coupled calculations using multiple, previously stand alone codes. <br />
<br />
Data format refers to the raw data to be manipulated. Information like number type ( float, integer, etc.), precision, location, rank, and dimensions completely describe the any dataset regardless of its size. The description of the data is also separate from the values themselves. We refer to the description of the data as '''Light''' data and the values themselves as '''Heavy''' data. Light data is small and can be passed between modules easily. Heavy data may be potentially enormous; movement needs to be kept to a minimum. Due to the different nature of heavy and light data, they are stored using separate mechanisms. Light data is stored using XML, Heavy data is typically stored using HDF5. While we could have chosen to store the light data using HDF5 attributes using XML does not require every tool to have access to the compiled HDF5 libraries in order to perform simple operations.<br />
<br />
Data model refers to the intended use of the data. For example, a three dimensional array of floating point vales may be the X,Y,Z geometry for a grid or calculated vector values. Without a data model, it is impossible to tell the difference. Since the data model only describes the data, it is purely light data and thus stored using XML. It is targeted at scientific simulation data concentrating on scalars, vectors, and tensors defined on some type of computational grid. Structured and Unstructured grids are described via their topology and geometry. Calculated, time varying data values are described as attributes of the grid. The actual values for the grid geometry, connectivity, and attribute values are contained in the data format. This separation of data format and model allows HPC codes to efficiently produce and store vales in a convenient manner without being encumbered by our data model which may be different from their internal arrangement.<br />
<br />
<br />
XDMF uses XML to store Light data and to describe the data Model. HDF5 is used to store Heavy data. The data Format is stored redundantly in both XML and HDF5. This allows tools to parse XML to determine the resources that will be required to access the Heavy data. <br />
<br />
The data model in XDMF stored in XML provides the knowledge of what is represented by the Heavy data. In this model, HPC data is viewed as a hierarchy of Domains. A Domain must contain at least one Grid. A Grid is the basic representation of both the geometric and computed/measured values. A Grid is considered to be a group of elements with Structured or Unstructured Topology and their associated values. In addition to the topology of the Grid, Geometry, specifying the X, Y, and Z positions of the Grid is required. Finally, a Grid may have one or more Attributes. Attributes are used to store any other value associated with the grid and may be referenced to the Grid or to individual cells that comprise the Grid. <br />
<br />
The concept of separating the light data from the heavy data is critical to the performance of this data model and format. HPC codes can read and write data in large, contiguous chunks that are natural to their internal data storage, to achieve optimal I/O performance. If codes were required to significantly re-arrange data prior to I/O operations, data locality, and thus performance, could be adversely affected, particularly on codes that attempt to make maximum use of memory cache. The complexity of the dataset is described in the light data portion, which is small and transportable. For example, the light data might specify a topology of one million hexaherda while the heavy data would contain the geometric XYZ values of the mesh and pressure values at the cell centers stored in large, contiguous arrays. This key feature will allow reusable tools to be built that do not put onerous requirements on HPC codes. Despite the complexity of the organization described in the XML below, the HPC code only needs to produce the three HDF5 datasets for geometry, connectivity, and pressure values.<br />
<br />
While not required, a C++ API is provided to read and write XDMF data. This API has also been wrapped so it is available from popular languages like Python, Tcl, and Java. The API is not necessary in order to produce or consume XDMF data. Currently several HPC codes that already produced HDF5 data, use native text output to produce the XML necessary for valid XDMF. <br />
<br />
'''More Detail'''<br />
<br />
*[[XDMF Model and Format]]<br />
<br />
*[[XDMF API]]<br />
<br />
'''How do I ...'''<br />
# [[Get Xdmf]]<br />
# [[Read Xdmf]]<br />
# [[Write Xdmf]]<br />
# [[Write from Fortran]]<br />
# [[Read from MySQL]]<br />
# [[Parallel IO with MPI]]<br />
<br />
'''What's Next'''<br />
* [[Xdmf::New()]]<br />
<br />
'''Mailing list'''<br />
* Join the Xdmf mailing list [http://www.kitware.com/cgi-bin/mailman/listinfo/xdmf here]<br />
'''Wiki Account'''<br />
* To edit these pages, send an email to Dave DeMarle with XDMF in the subject that includes your preferred user name and email address in the message body.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
* [http://www.mediawiki.org/wiki/Help:Configuration_settings Configuration settings list]<br />
* [http://www.mediawiki.org/wiki/Help:FAQ MediaWiki FAQ]<br />
* [http://mail.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list]</div>Dave.demarlehttps://www.xdmf.org/index.php?title=Main_Page&diff=88Main Page2013-02-25T17:32:00Z<p>Dave.demarle: Reverted edits by Dave.demarle (Talk); changed back to last version by Dave.partyka</p>
<hr />
<div>[[Image:XdmfLogo1.gif]]<br />
<br />
<span style='color:blue'><big>e<span style='color:red'>'''X'''</span>tensible <span style='color:red'>'''D'''</span>ata <span style='color:red'>'''M'''</span>odel and <span style='color:red'>'''F'''</span>ormat</big></span><br />
<br />
<br />
<br />
The need for a standardized method to exchange scientific data between High Performance Computing codes and tools lead to the development of the eXtensible Data Model and Format (XDMF) . Uses for XDMF range from a standard format used by HPC codes to take advantage of widely used visualization programs like ParaView, to a mechanism for performing coupled calculations using multiple, previously stand alone codes. <br />
<br />
Data format refers to the raw data to be manipulated. Information like number type ( float, integer, etc.), precision, location, rank, and dimensions completely describe the any dataset regardless of its size. The description of the data is also separate from the values themselves. We refer to the description of the data as '''Light''' data and the values themselves as '''Heavy''' data. Light data is small and can be passed between modules easily. Heavy data may be potentially enormous; movement needs to be kept to a minimum. Due to the different nature of heavy and light data, they are stored using separate mechanisms. Light data is stored using XML, Heavy data is typically stored using HDF5. While we could have chosen to store the light data using HDF5 attributes using XML does not require every tool to have access to the compiled HDF5 libraries in order to perform simple operations.<br />
<br />
Data model refers to the intended use of the data. For example, a three dimensional array of floating point vales may be the X,Y,Z geometry for a grid or calculated vector values. Without a data model, it is impossible to tell the difference. Since the data model only describes the data, it is purely light data and thus stored using XML. It is targeted at scientific simulation data concentrating on scalars, vectors, and tensors defined on some type of computational grid. Structured and Unstructured grids are described via their topology and geometry. Calculated, time varying data values are described as attributes of the grid. The actual values for the grid geometry, connectivity, and attribute values are contained in the data format. This separation of data format and model allows HPC codes to efficiently produce and store vales in a convenient manner without being encumbered by our data model which may be different from their internal arrangement.<br />
<br />
<br />
XDMF uses XML to store Light data and to describe the data Model. HDF5 is used to store Heavy data. The data Format is stored redundantly in both XML and HDF5. This allows tools to parse XML to determine the resources that will be required to access the Heavy data. <br />
<br />
The data model in XDMF stored in XML provides the knowledge of what is represented by the Heavy data. In this model, HPC data is viewed as a hierarchy of Domains. A Domain must contain at least one Grid. A Grid is the basic representation of both the geometric and computed/measured values. A Grid is considered to be a group of elements with Structured or Unstructured Topology and their associated values. In addition to the topology of the Grid, Geometry, specifying the X, Y, and Z positions of the Grid is required. Finally, a Grid may have one or more Attributes. Attributes are used to store any other value associated with the grid and may be referenced to the Grid or to individual cells that comprise the Grid. <br />
<br />
The concept of separating the light data from the heavy data is critical to the performance of this data model and format. HPC codes can read and write data in large, contiguous chunks that are natural to their internal data storage, to achieve optimal I/O performance. If codes were required to significantly re-arrange data prior to I/O operations, data locality, and thus performance, could be adversely affected, particularly on codes that attempt to make maximum use of memory cache. The complexity of the dataset is described in the light data portion, which is small and transportable. For example, the light data might specify a topology of one million hexaherda while the heavy data would contain the geometric XYZ values of the mesh and pressure values at the cell centers stored in large, contiguous arrays. This key feature will allow reusable tools to be built that do not put onerous requirements on HPC codes. Despite the complexity of the organization described in the XML below, the HPC code only needs to produce the three HDF5 datasets for geometry, connectivity, and pressure values.<br />
<br />
While not required, a C++ API is provided to read and write XDMF data. This API has also been wrapped so it is available from popular languages like Python, Tcl, and Java. The API is not necessary in order to produce or consume XDMF data. Currently several HPC codes that already produced HDF5 data, use native text output to produce the XML necessary for valid XDMF. <br />
<br />
'''More Detail'''<br />
<br />
*[[XDMF Model and Format]]<br />
<br />
*[[XDMF API]]<br />
<br />
'''How do I ...'''<br />
# [[Get Xdmf]]<br />
# [[Read Xdmf]]<br />
# [[Write Xdmf]]<br />
# [[Write from Fortran]]<br />
# [[Read from MySQL]]<br />
# [[Parallel IO with MPI]]<br />
<br />
'''What's Next'''<br />
# [[Xdmf::New()]]<br />
<br />
'''Mailing list'''<br />
# Join the Xdmf mailing list [http://www.kitware.com/cgi-bin/mailman/listinfo/xdmf here]<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
* [http://www.mediawiki.org/wiki/Help:Configuration_settings Configuration settings list]<br />
* [http://www.mediawiki.org/wiki/Help:FAQ MediaWiki FAQ]<br />
* [http://mail.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list]</div>Dave.demarlehttps://www.xdmf.org/index.php?title=Main_Page&diff=87Main Page2013-02-25T17:20:17Z<p>Dave.demarle: </p>
<hr />
<div>[[Image:XdmfLogo1.gif]]<br />
<br />
<span style='color:blue'><big>e<span style='color:red'>'''X'''</span>tensible <span style='color:red'>'''D'''</span>ata <span style='color:red'>'''M'''</span>odel and <span style='color:red'>'''F'''</span>ormat</big></span><br />
<br />
<br />
<br />
The need for a standardized method to exchange scientific data between High Performance Computing codes and tools lead to the development of the eXtensible Data Model and Format (XDMF) . Uses for XDMF range from a standard format used by HPC codes to take advantage of widely used visualization programs like ParaView, to a mechanism for performing coupled calculations using multiple, previously stand alone codes. <br />
<br />
Data format refers to the raw data to be manipulated. Information like number type ( float, integer, etc.), precision, location, rank, and dimensions completely describe the any dataset regardless of its size. The description of the data is also separate from the values themselves. We refer to the description of the data as '''Light''' data and the values themselves as '''Heavy''' data. Light data is small and can be passed between modules easily. Heavy data may be potentially enormous; movement needs to be kept to a minimum. Due to the different nature of heavy and light data, they are stored using separate mechanisms. Light data is stored using XML, Heavy data is typically stored using HDF5. While we could have chosen to store the light data using HDF5 attributes using XML does not require every tool to have access to the compiled HDF5 libraries in order to perform simple operations.<br />
<br />
Data model refers to the intended use of the data. For example, a three dimensional array of floating point vales may be the X,Y,Z geometry for a grid or calculated vector values. Without a data model, it is impossible to tell the difference. Since the data model only describes the data, it is purely light data and thus stored using XML. It is targeted at scientific simulation data concentrating on scalars, vectors, and tensors defined on some type of computational grid. Structured and Unstructured grids are described via their topology and geometry. Calculated, time varying data values are described as attributes of the grid. The actual values for the grid geometry, connectivity, and attribute values are contained in the data format. This separation of data format and model allows HPC codes to efficiently produce and store vales in a convenient manner without being encumbered by our data model which may be different from their internal arrangement.<br />
<br />
<br />
XDMF uses XML to store Light data and to describe the data Model. HDF5 is used to store Heavy data. The data Format is stored redundantly in both XML and HDF5. This allows tools to parse XML to determine the resources that will be required to access the Heavy data. <br />
<br />
The data model in XDMF stored in XML provides the knowledge of what is represented by the Heavy data. In this model, HPC data is viewed as a hierarchy of Domains. A Domain must contain at least one Grid. A Grid is the basic representation of both the geometric and computed/measured values. A Grid is considered to be a group of elements with Structured or Unstructured Topology and their associated values. In addition to the topology of the Grid, Geometry, specifying the X, Y, and Z positions of the Grid is required. Finally, a Grid may have one or more Attributes. Attributes are used to store any other value associated with the grid and may be referenced to the Grid or to individual cells that comprise the Grid. <br />
<br />
The concept of separating the light data from the heavy data is critical to the performance of this data model and format. HPC codes can read and write data in large, contiguous chunks that are natural to their internal data storage, to achieve optimal I/O performance. If codes were required to significantly re-arrange data prior to I/O operations, data locality, and thus performance, could be adversely affected, particularly on codes that attempt to make maximum use of memory cache. The complexity of the dataset is described in the light data portion, which is small and transportable. For example, the light data might specify a topology of one million hexaherda while the heavy data would contain the geometric XYZ values of the mesh and pressure values at the cell centers stored in large, contiguous arrays. This key feature will allow reusable tools to be built that do not put onerous requirements on HPC codes. Despite the complexity of the organization described in the XML below, the HPC code only needs to produce the three HDF5 datasets for geometry, connectivity, and pressure values.<br />
<br />
While not required, a C++ API is provided to read and write XDMF data. This API has also been wrapped so it is available from popular languages like Python, Tcl, and Java. The API is not necessary in order to produce or consume XDMF data. Currently several HPC codes that already produced HDF5 data, use native text output to produce the XML necessary for valid XDMF. <br />
<br />
'''More Detail'''<br />
<br />
*[[XDMF Model and Format]]<br />
<br />
*[[XDMF API]]<br />
<br />
'''How do I ...'''<br />
# [[Get Xdmf]]<br />
# [[Read Xdmf]]<br />
# [[Write Xdmf]]<br />
# [[Write from Fortran]]<br />
# [[Read from MySQL]]<br />
# [[Parallel IO with MPI]]<br />
<br />
'''What's Next'''<br />
* [[Xdmf::New()]]<br />
<br />
'''Mailing list'''<br />
* Join the Xdmf mailing list [http://www.kitware.com/cgi-bin/mailman/listinfo/xdmf here]<br />
'''Wiki Account'''<br />
* To edit these pages, send an email to Dave DeMarle with XDMF in the subject that includes your preferred user name and email address in the message body.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
* [http://www.mediawiki.org/wiki/Help:Configuration_settings Configuration settings list]<br />
* [http://www.mediawiki.org/wiki/Help:FAQ MediaWiki FAQ]<br />
* [http://mail.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list]</div>Dave.demarlehttps://www.xdmf.org/index.php?title=XDMF_Model_and_Format&diff=86XDMF Model and Format2011-10-28T19:17:29Z<p>Dave.demarle: </p>
<hr />
<div>[[Image:XdmfLogo1.gif]]<br />
<br />
The need for a standardized method to exchange scientific data between High Performance Computing codes and tools lead to the development of ''the eXtensible Data Model and Format'' (''XDMF'') . Uses for XDMF range from a standard format used by HPC codes to take advantage of widely used visualization programs like ParaView and EnSight, to a mechanism for performing coupled calculations using multiple, previously stand alone codes. <br />
<br />
XDMF categorizes data by two main attributes; size and function. Data can be ''Light'' (typically less than about a thousand values) or ''Heavy'' (megabytes, terabytes, etc.). In addition to raw values, data can refer to ''Format'' (rank and dimensions of an array) or ''Model'' (how that data is to be used. i.e. XYZ coordinates vs. Vector components).<br />
<br />
XDMF uses XML to store Light data and to describe the data Model. Either HDF5 or binary files can be used to store Heavy data. The data Format is stored redundantly in both XML and HDF5. This allows tools to parse XML to determine the resources that will be required to access the Heavy data. <br />
For the binary Heavy data option, the xml must list a filename where the binary data is stored.<br />
<br />
While not required, a C++ API is provided to read and write '''XDMF''' data. This API has also been wrapped so it is available from popular languages like Python, Tcl, and Java. The API is not necessary in order to produce or consume XDMF data. Currently several HPC codes that already produced HDF5 data, use native text output to produce the XML necessary for valid XDMF. <br />
<br />
'''XML'''<br />
The eXtensible Markup Language (XML) format is widely used for many purposes and is well documented at many sites. There are numerous open source parsers available for XML. The XDMF API takes advantage of the libxml2 parser to provide the necessary functionality. Without going into too much detail, XDMF views XML as a "personalized HTML" with some special rules. It it case sensitive and is made of three major components : elements, entities, and processing information. In XDMF we<nowiki>'</nowiki>re primarily concerned with the elements. These elements follow the basic form :<br />
<br />
&lt;ElementTag<br />
AttributeName="AttributeValue"<br />
AttributeName="AttributeValue"<br />
... &gt;<br />
''CData''<br />
&lt;/ElementTag&gt;<br />
<br />
<br />
Each element begins with a &lt;tag&gt; and ends with a &lt;/tag&gt;. Optionally there can be several "Name=Value" pairs which convey additional information. Between the &lt;tag&gt; and the &lt;/tag&gt; there can be other &lt;tag&gt;&lt;/tag&gt; pairs and/or character data (CData). CData is typically where the values are stored; like the actual text in an HTML document. The XML parser in the XDMF API parses the XML file and builds a tree structure in memory to describe its contents. This tree can be queried, modified, and then "serialized" back into XML.<br />
<br />
Comments in XML start with a "&lt;!--" and end with a "--&gt;". So &lt;!--This is a Comment --&gt;.<br />
<br />
XML is said to be "well formed" if it is syntactically correct. That means all of the quotes match, all elements have end elements, etc. XML is said to be "valid" if it conforms to the ''Schema'' or ''DTD'' defined at the head of the document. For example, the schema might specify that element type A can contain element B but not element C. Verifying that the provided XML is well formed and/or valid are functions typically performed by the XML parser. Additionally XDMF takes advantage of two major extensions to XML :<br />
<br />
'''XInclude'''<br />
As opposed to entity references in XML(which is a basic substitution mechanism), XInclude allows for the inclusion of files that are not well formed XML. This means that with XInclude the included file could be well formed XML or perhaps a flat text file of values. The syntax looks like this :<br />
<br />
<br />
<br />
'''&lt;Xdmf Version="2.0" xmlns:xi="<nowiki>[http://www.w3.org/2001/XInclude]</nowiki>"&gt;'''<br />
'''&lt;xi:include href="Example3.xmf"/&gt;'''<br />
'''&lt;/Xdmf&gt;'''<br />
<br />
<br />
<br />
the xmlns:xi establishes a namespace xi. Then anywhere within the Xdmf element, xi:include will pull in the URL.<br />
<br />
'''XPath'''<br />
<br />
This allows for elements in the XML document and the API to reference specific elements in a document. For example :<br />
<br />
The first Grid in the first Domain<br />
'''/Xdmf/Domain/Grid'''<br />
The tenth Grid .... XPath is one based.<br />
'''/Xdmf/Domain/Grid<nowiki>[</nowiki>10<nowiki>]</nowiki>'''<br />
The first grid with an attribute ''Name'' which has a value of ''"Copper Plate"''<br />
'''/Xdmf/Domain/Grid<nowiki>[</nowiki>@Name="Copper Plate"<nowiki>]</nowiki>'''<br />
<br />
All valid XDMF must appear between the &lt;Xdmf&gt; and the &lt;/Xdmf&gt; tags. So a minimal (empty) XDMF XML file would be :<br />
<br />
'''&lt;?xml version="1.0" ?&gt;'''<br />
'''&lt;!DOCTYPE Xdmf SYSTEM "Xdmf.dtd" <nowiki>[</nowiki><nowiki>]</nowiki>&gt;'''<br />
'''&lt;Xdmf Version="2.0"&gt;'''<br />
'''&lt;/Xdmf&gt;'''<br />
<br />
While there exists an Xdmf DTD and a Schema they are only necessary for validating parsers. For performance reasons, validation is typically disabled.<br />
<br />
'''XDMF Elements'''<br />
<br />
The organization of XDMF begins with the ''Xdmf'' element. So that parsers can distinguish from previous versions of XDMF, there exists a ''Version'' attribute (currently at 2.0). Any element in XDMF can have a ''Name'' attribute or have a ''Reference'' attribute. The Name attribute becomes important for grids while the Reference attribute is used to take advantage of the XPath facility (more detail on this later). Xdmf elements contain one or more ''Domain'' elements (computational domain). There is seldom motivation to have more than one Domain. <br />
<br />
A Domain can have one or more ''Grid'' elements. Each Grid contains a ''Topology'', ''Geometry'', and zero or more ''Attribute'' elements. Topology specifies the connectivity of the grid while Geometry specifies the location of the grid nodes. Attribute elements are used to specify values such as scalars and vectors that are located at the node, edge, face, cell center, or grid center. <br />
<br />
To specify actual values for connectivity, geometry, or attributes, XDMF defines a ''DataItem'' element. A DataItem can provide the actual values or provide the physical storage (which is typically an HDF5 file).<br />
<br />
'''XdmfItem'''<br />
<br />
There are six different types of DataItems :<br />
# '''Uniform''' - this is the default. A single array of values.<br />
# '''Collection''' - a one dimension array of DataItems<br />
# '''Tree''' - a hierarchical structure of DataItems<br />
# '''HyperSlab''' - contains two data items. The first selects the start, stride and count indexes of the second DataItem.<br />
# '''Coordinates''' - contains two DataItems. The first selects the parametric coordinates of the second DataItem.<br />
# '''Function''' - calculates an expression.<br />
<br />
'''Uniform '''<br />
<br />
The simplest type is Uniform that specifies a single array. As with all XDMF elements, there are reasonable defaults wherever possible. So the simplest DataItem would be :<br />
<br />
'''&lt;DataItem Dimensions="3"&gt;'''<br />
'''1.0 2.0 3.0'''<br />
'''&lt;/DataItem&gt;'''<br />
<br />
Since no ''ItemType'' has been specified, Uniform has been assumed. The default ''Format'' is XML and the default ''NumberType'' is a 32 bit floating point value. So the fully qualified DataItem for the same data would be :<br />
<br />
'''&lt;DataItem ItemType="Uniform"'''<br />
'''Format="XML"'''<br />
'''NumberType="Float" Precision="4"'''<br />
'''Rank="1" Dimensions="3"&gt;'''<br />
'''1.0 2.0 3.0'''<br />
'''&lt;/DataItem&gt;'''<br />
<br />
Since it is only practical to store a small amount of data values in the XML, production codes typically write their data to HDF5 and specify the location in XML. HDF5 is a hierarchical, self describing data format. So an application can open an HDF5 file without any prior knowledge of the data and determine the dimensions and number type of all the arrays stored in the file. XDMF requires that this information also be stored redundantly in the XML so that applications need not have access to the actual heavy data in order to determine storage requirements.<br />
<br />
For example, suppose an application stored a three dimensional array of pressure values at each iteration into an HDF5 file. The XML might be :<br />
<br />
'''&lt;DataItem ItemType="Uniform"'''<br />
'''Format="HDF"'''<br />
'''NumberType="Float" Precision="8"'''<br />
'''Dimensions="64 128 256"&gt;'''<br />
'''OutputData.h5:/Results/Iteration 100/Part 2/Pressure'''<br />
'''&lt;/DataItem&gt;'''<br />
<br />
Alternatively, an application may store its data in binary files. In this case the XML might be.<br />
<br />
'''&lt;DataItem ItemType="Uniform"'''<br />
'''Format="Binary"'''<br />
'''Dimensions="64 128 256"&gt;'''<br />
'''PressureFile.bin'''<br />
'''&lt;/DataItem&gt;'''<br />
<br />
Dimensions are specified with the slowest varying dimension first (i.e. KJI order). The HDF filename can be fully qualified, if it is not it is assumed to be located in the current directory or the same directory as the XML file. <br />
<br />
'''Collection and Tree'''<br />
<br />
Collections are Trees with only a single level. This is such a frequent occurrence that it was decided to make a Collection a separate type in case the application can optimize access. Collections and Trees have DataItem elements as children. The leaf nodes are Uniform DataItem elements :<br />
<br />
'''&lt;DataItem Name="Tree Example" ItemType="Tree"&gt;'''<br />
'''&lt;DataItem ItemType="Tree"&gt;'''<br />
'''&lt;DataItem Name="Collection 1" ItemType="Collection"&gt;'''<br />
'''&lt;DataItem Dimensions="3"&gt;'''<br />
'''1.0 2.0 3.0'''<br />
'''&lt;/DataItem&gt;'''<br />
'''&lt;DataItem Dimensions="4"&gt;'''<br />
'''4 5 6 7'''<br />
'''&lt;/DataItem&gt;'''<br />
'''&lt;/DataItem&gt;'''<br />
'''&lt;/DataItem&gt;'''<br />
'''&lt;DataItem Name="Collection 2" ItemType="Collection"&gt;'''<br />
'''&lt;DataItem Dimensions="3"&gt;'''<br />
'''7 8 9'''<br />
'''&lt;/DataItem&gt;'''<br />
'''&lt;DataItem Dimensions="4"&gt;'''<br />
'''10 11 12 13'''<br />
'''&lt;/DataItem&gt;'''<br />
'''&lt;/DataItem&gt;'''<br />
'''&lt;DataItem ItemType="Uniform"'''<br />
'''Format="HDF"'''<br />
'''NumberType="Float" Precision="8"'''<br />
'''Dimensions="64 128 256"&gt;'''<br />
'''OutputData.h5:/Results/Iteration 100/Part 2/Pressure'''<br />
'''&lt;/DataItem&gt;'''<br />
'''&lt;/DataItem&gt;'''<br />
<br />
This DataItem is a tree with three children. The first child is another tree that contains a collection of two uniform DataItem elements. The second child is a collection with two uniform DataItem elements. The third child is a uniform DataItem. <br />
<br />
'''HyperSlab and Coordinate'''<br />
<br />
A ''HyperSlab'' specifies a subset of some other DataItem. The slab is specified by giving the start, stride, and count of the values in each of the target DataItem dimensions. For example, given a dataset MyData.h5:/XYZ that is 100x200x300x3, we could describe a region starting at <nowiki>[</nowiki>0,0,0,0<nowiki>]</nowiki>, ending at <nowiki>[</nowiki>50, 100, 150, 2<nowiki>]</nowiki> that includes every other plane of data with the HyperSlab DataItem <br />
<br />
'''&lt;DataItem ItemType="HyperSlab"'''<br />
'''Dimensions="25 50 75 3"'''<br />
'''Type="HyperSlab"&gt;'''<br />
'''&lt;DataItem'''<br />
'''Dimensions="3 4"''' <br />
'''Format="XML"&gt;'''<br />
'''0 0 0 0 '''<br />
'''2 2 2 1 '''<br />
'''25 50 75 3'''<br />
'''&lt;/DataItem&gt;'''<br />
'''&lt;DataItem'''<br />
'''Name="Points"'''<br />
'''Dimensions="100 200 300 3"'''<br />
'''Format="HDF"&gt;'''<br />
'''MyData.h5:/XYZ'''<br />
'''&lt;/DataItem&gt;'''<br />
'''&lt;/DataItem&gt;'''<br />
<br />
Notice that the first DataItem specified Start, Stride and Count for each dimension of the second DataItem. Suppose, instead that we only wish to specify the first Y data value from the DataItem and the last X value. This can be accomplished by providing the parametric coordinates of the desired values and using the ''Coordinates'' ItemType.<br />
<br />
'''&lt;DataItem ItemType="HyperSlab"'''<br />
'''Dimensions="2"'''<br />
'''Type="HyperSlab"&gt;'''<br />
'''&lt;DataItem'''<br />
'''Dimensions="2 4"'''<br />
'''Format="XML"&gt;'''<br />
'''0 0 0 1'''<br />
'''99 199 299 0'''<br />
'''&lt;/DataItem&gt;'''<br />
'''&lt;DataItem'''<br />
'''Name="Points"'''<br />
'''Dimensions="100 200 300 3"'''<br />
'''Format="HDF"&gt;'''<br />
'''MyData.h5:/XYZ'''<br />
'''&lt;/DataItem&gt;'''<br />
'''&lt;/DataItem&gt;'''<br />
<br />
The first Y value is index 1 of item 0,0,0 while the last X value is index 0 of item 99, 199, 299. The dimensionality of the specified coordinates must match that of the target DataItem. <br />
<br />
'''Function'''<br />
<br />
''Function'' ItemType specifies some operation on the children DataItem elements. The elements are referenced by $X where X is the zero based index of the child. For example, the following DataItem would add the two children DataItem elements together in a value by value operation resulting in the values 5.1, 7.2 and 9.3 :<br />
<br />
'''&lt;DataItem ItemType="Function" '''<br />
'''Function="$0 + $1"'''<br />
'''Dimensions="3"&gt;'''<br />
'''&lt;DataItem Dimensions="3"&gt;'''<br />
'''1.0 2.0 3.0'''<br />
'''&lt;/DataItem&gt;'''<br />
'''&lt;DataItem Dimensions="3"&gt;'''<br />
'''4.1 5.2 6.3'''<br />
'''&lt;/DataItem&gt;'''<br />
'''&lt;/DataItem&gt;'''<br />
<br />
The function description can be arbitrarily complex and contain SIN, COS, TAN, ACOS, ASIN, ATAN, LOG, EXP, ABS, and SQRT. In addition, there are the JOIN() and WHERE() expressions. JOIN can concatenate or interlace arrays while WHERE() can extract values where some condition is true. In the following examples we take advantage of the XPath facility to reference DataItem elements that have been previously specified :<br />
<br />
Add the value 10 to every element<br />
<br />
'''&lt;DataItem Name="MyFunction" ItemType="Function"'''<br />
''' Function="10 + $0"&gt;'''<br />
''' &lt;DataItem Reference="/Xdmf/DataItem<nowiki>[</nowiki>1<nowiki>]</nowiki>" /&gt;'''<br />
''' &lt;/DataItem&gt;''' <br />
<br />
Multiply two arrays (element by element) and take the absolute value<br />
<br />
''' &lt;DataItem ItemType="Function"'''<br />
''' Function="ABS($0 <nowiki>*</nowiki> $1)"&gt;'''<br />
''' &lt;DataItem Reference="/Xdmf/DataItem<nowiki>[</nowiki>1<nowiki>]</nowiki>" /&gt;'''<br />
''' &lt;DataItem Reference="/Xdmf/DataItem<nowiki>[</nowiki>2<nowiki>]</nowiki>" /&gt;'''<br />
''' &lt;/DataItem&gt;'''<br />
<br />
Select element 5 thru 15 from the first DataItem<br />
<br />
''' &lt;DataItem ItemType="Function"'''<br />
''' Function="$0<nowiki>[</nowiki>5:15<nowiki>]</nowiki>"&gt;'''<br />
''' &lt;DataItem Reference="/Xdmf/DataItem<nowiki>[</nowiki>1<nowiki>]</nowiki>" /&gt;'''<br />
''' &lt;/DataItem&gt;'''<br />
<br />
Concatenate two arrays<br />
<br />
''' &lt;DataItem ItemType="Function"'''<br />
''' Function="JOIN($0 ; $1)"&gt;'''<br />
''' &lt;DataItem Reference="/Xdmf/DataItem<nowiki>[</nowiki>1<nowiki>]</nowiki>" /&gt;'''<br />
''' &lt;DataItem Reference="/Xdmf/DataItem<nowiki>[</nowiki>2<nowiki>]</nowiki>" /&gt;'''<br />
''' &lt;/DataItem&gt;'''<br />
<br />
Interlace 3 arrays (Useful for describing vectors from scalar data)<br />
<br />
''' &lt;DataItem ItemType="Function"'''<br />
''' Function="JOIN($0 , $1, $2)"&gt;'''<br />
''' &lt;DataItem Reference="/Xdmf/DataItem<nowiki>[</nowiki>1<nowiki>]</nowiki>" /&gt;'''<br />
''' &lt;DataItem Reference="/Xdmf/DataItem<nowiki>[</nowiki>2<nowiki>]</nowiki>" /&gt; '''<br />
''' &lt;DataItem Reference="/Xdmf/DataItem<nowiki>[</nowiki>3<nowiki>]</nowiki>" /&gt;'''<br />
''' &lt;/DataItem&gt;'''<br />
<br />
'''Grid'''<br />
<br />
The DataItem element is used to define the data format portion of XDMF. It is sufficient to specify fairly complex data structures in a portable manner. The data model portion of XDMF begins with the ''Grid'' element. A Grid is a container for information related to 2D and 3D points, structured or unstructured connectivity, and assigned values.<br />
<br />
The Grid element now has a GridType attribute. Valid GridTypes are :<br />
# '''Uniform''' - a homogeneous single grid (i.e. a pile of triangles)<br />
# '''Collection''' - an array of Uniform grids all with the same Attributes<br />
# '''Tree''' - a hierarchical group<br />
# '''SubSet ''' - a portion of another Grid<br />
<br />
Uniform Grid elements are the simplest type and must contain a ''Topology'' and ''Geometry'' element. If GridType is Collection, a<br />
CollectionType can be specified as either "Spatial" or "Temporal".<br />
Just like the DataItem element, Tree and Collection Grid elements contain other Grid elements as children :<br />
<br />
'''&lt;Grid Name="Car Wheel" GridType="Tree"&gt;'''<br />
'''&lt;Grid Name="Tire" GridType="Uniform"&gt;'''<br />
'''&lt;Topology ...'''<br />
'''&lt;Geometry ...'''<br />
'''&lt;/Grid&gt;'''<br />
'''&lt;Grid Name="Lug Nuts" GridType="Collection"&gt;'''<br />
'''&lt;Grid Name="Lug Nut 0" GridType="Uniform"'''<br />
'''&lt;Topology ....'''<br />
'''&lt;Geometry ...'''<br />
'''&lt;/Grid&gt;'''<br />
'''&lt;Grid Name="Lug Nut 1" GridType="Uniform"'''<br />
'''&lt;Topology ...'''<br />
'''&lt;Geometry ...'''<br />
'''&lt;/Grid&gt;'''<br />
'''&lt;Grid Name="Lug Nut 2" GridType="Uniform"'''<br />
'''&lt;Topology ...'''<br />
'''&lt;Geometry ...'''<br />
'''&lt;/Grid&gt;'''<br />
'''&lt;/Grid&gt;'''<br />
'''.'''<br />
'''.'''<br />
'''.''' <br />
<br />
A SubSet GridType is used to define a portion of another grid or define new attributes on the grid. This allows users to share the geometry and topology of another grid, the attributes from the original grid are not assigned. The Section attribute of a SubSet can be ''DataItem'' or ''All'' :<br />
<br />
''' &lt;Grid Name="Portion" GridType="Subset" Section="DataItem"&gt;'''<br />
''&lt;!-- Select 2 cells from another grid. Which 2 are defined by the DataItem --&gt;''<br />
''' &lt;DataItem''' <br />
''' DataType="Int"'''<br />
''' Dimensions="2"'''<br />
''' Format="XML"&gt;'''<br />
''' 0 2'''<br />
''' &lt;/DataItem&gt;'''<br />
''' &lt;Grid Name="Target" Reference="XML"&gt;'''<br />
''' /Xdmf/Domain/Grid<nowiki>[</nowiki>@Name="Main Grid"<nowiki>]</nowiki>'''<br />
''' &lt;/Grid&gt;'''<br />
''' &lt;Attribute Name="New Values" Center="Cell"&gt;'''<br />
''' &lt;DataItem Format="XML" Dimensions="2"&gt;'''<br />
''' 100 150'''<br />
''' &lt;/DataItem&gt;'''<br />
''' &lt;/Attribute&gt;'''<br />
''' &lt;/Grid&gt;'''<br />
'''Or '''<br />
''' &lt;Grid Name="Portion" GridType="Subset" Section="All"&gt;'''<br />
''&lt;!-- Select the entire grid and add an attribute --&gt;''<br />
''' &lt;Grid Name="Target" Reference="XML"&gt;'''<br />
''' /Xdmf/Domain/Grid<nowiki>[</nowiki>@Name="Main Grid"<nowiki>]</nowiki>'''<br />
''' &lt;/Grid&gt;'''<br />
''' &lt;Attribute Name="New Values" Center="Cell"&gt;'''<br />
''' &lt;DataItem Format="XML" Dimensions="3"&gt;'''<br />
''' 100 150 200'''<br />
''' &lt;/DataItem&gt;'''<br />
''' &lt;/Attribute&gt;'''<br />
''' &lt;/Grid&gt;'''<br />
<br />
'''Topology'''<br />
<br />
The Topology element describes the general organization of the data. This is the part of the computational grid that is invariant with rotation, translation, and scale. For structured grids, the connectivity is implicit. For unstructured grids, if the connectivity differs from the standard, an Order may be specified. Currently, the following Topology cell types are defined :<br />
<br />
'''Linear'''<br />
* Polyvertex - a group of unconnected points<br />
* Polyline - a group of line segments<br />
* Polygon<br />
* Triangle<br />
* Quadrilateral<br />
* Tetrahedron<br />
* Pyramid<br />
* Wedge<br />
* Hexahedron<br />
'''Quadratic'''<br />
* Edge_3 - Quadratic line with 3 nodes<br />
* Tri_6<br />
* Quad_8<br />
* Tet_10<br />
* Pyramid_13<br />
* Wedge_15<br />
* Hex_20<br />
'''Arbitrary'''<br />
* Mixed - a mixture of unstructured cells<br />
'''Structured'''<br />
* 2DSMesh - Curvilinear<br />
* 2DRectMesh - Axis are perpendicular<br />
* 2DCoRectMesh - Axis are perpendicular and spacing is constant<br />
* 3DSMesh<br />
* 3DRectMesh<br />
* 3DCoRectMesh<br />
<br />
There is a ''NodesPerElement'' attribute for the cell types where it is not implicit. For example, to define a group of Octagons, set TopologyType="Polygon" and NodesPerElement="8". For structured grid topologies, the connectivity is implicit. For unstructured topologies the Topology element must contain a DataItem that defines the connectivity :<br />
<br />
'''&lt;Topology TopologyType="Quadrilateral" NumberOfElements="2" &gt;'''<br />
'''&lt;DataItem Format="XML" DataType="Int" Dimensions="2 4"&gt;'''<br />
'''0 1 2 3'''<br />
'''1 6 7 2'''<br />
'''&lt;/DataItem&gt;'''<br />
'''&lt;/Topology&gt;'''<br />
<br />
The connectivity defines the indexes into the XYZ geometry that define the cell. In this example, the two quads share an edge defined by the line from node 1 to node 2. A Topology element can define ''Dimensions'' or ''NumberOfElements''; this is just added for clarity.<br />
<br />
Mixed topologies must define the cell type of every element. If that cell type does not have an implicit number of nodes, that must also be specified. In this example, we define a topology of three cells consisting of a Tet (cell type 6) a Polygon (cell type 3) and a Hex (cell type 9) :<br />
<br />
'''&lt;Topology TopologyType="Mixed" NumberOfElements="3" &gt;'''<br />
'''&lt;DataItem Format="XML" DataType="Int" Dimensions="20"&gt;'''<br />
'''6 0 1 2 7'''<br />
'''3 4 4 5 6 7'''<br />
'''9 8 9 10 11 12 13 14 15'''<br />
'''&lt;/DataItem&gt;'''<br />
'''&lt;/Topology&gt;''' <br />
<br />
Notice that the Polygon must define the number of nodes (4) before its connectivity. The cell type numbers are defined in the API documentation.<br />
<br />
'''Geometry'''<br />
<br />
The Geometry element describes the XYZ values of the mesh. The important attribute here is the organization of the points. The default is XYZ; an X,Y, and Z for each point starting at parametric index 0. Possible organizations are :<br />
<br />
* '''XYZ''' - Interlaced locations<br />
* '''XY''' - Z is set to 0.0<br />
* '''X_Y_Z''' - X,Y, and Z are separate arrays<br />
* '''VXVYVZ''' - Three arrays, one for each axis<br />
* '''ORIGIN_DXDYDZ''' - Six Values : Ox,Oy,Oz + Dx,Dy,Dz<br />
<br />
The following Geometry element defines 8 points :<br />
<br />
'''&lt;Geometry GeometryType="XYZ"&gt;'''<br />
'''&lt;DataItem Format="XML" Dimensions="2 4 3"&gt;'''<br />
'''0.0 0.0 0.0'''<br />
'''1.0 0.0 0.0'''<br />
'''1.0 1.0 0.0'''<br />
'''0.0 1.0 0.0''' <br />
'''0.0 0.0 2.0'''<br />
'''1.0 0.0 2.0'''<br />
'''1.0 1.0 2.0'''<br />
'''0.0 1.0 2.0'''<br />
'''&lt;/DataItem&gt;'''<br />
'''&lt;/Geometry&gt;'''<br />
<br />
Together with the Grid and Topology element we now have enough to define a full XDMF XML file that defines two quadrilaterals that share an edge (notice not all points are used):<br />
<br />
'''&lt;?xml version="1.0" ?&gt;'''<br />
'''&lt;!DOCTYPE Xdmf SYSTEM "Xdmf.dtd" <nowiki>[</nowiki><nowiki>]</nowiki>&gt;'''<br />
<br />
'''&lt;Xdmf Version="2.0" xmlns:xi="<nowiki>[http://www.w3.org/2001/XInclude]</nowiki>"&gt;'''<br />
'''&lt;Domain&gt;'''<br />
'''&lt;Grid Name="Two Quads&gt;'''<br />
'''&lt;Topology TopologyType="Quadrilateral" NumberOfElements="2" &gt;'''<br />
'''&lt;DataItem Format="XML" '''<br />
'''DataType="Int"'''<br />
'''Dimensions="2 4"&gt;'''<br />
'''0 1 2 3'''<br />
'''1 6 7 2'''<br />
'''&lt;/DataItem&gt;'''<br />
'''&lt;/Topology&gt;'''<br />
'''&lt;Geometry GeometryType="XYZ"&gt;'''<br />
'''&lt;DataItem Format="XML" Dimensions="2 4 3"&gt;'''<br />
'''0.0 0.0 0.0'''<br />
'''1.0 0.0 0.0'''<br />
'''1.0 1.0 0.0'''<br />
'''0.0 1.0 0.0'''<br />
'''0.0 0.0 2.0'''<br />
'''1.0 0.0 2.0'''<br />
'''1.0 1.0 2.0'''<br />
'''0.0 1.0 2.0'''<br />
'''&lt;/DataItem&gt;'''<br />
'''&lt;/Geometry&gt;'''<br />
'''&lt;/Grid&gt;'''<br />
'''&lt;/Domain&gt;'''<br />
'''&lt;/Xdmf&gt;'''<br />
<br />
It is valid to have DataItem elements to be direct children of the Xdmf or Domain elements. This could be useful if several Grids share the same Geometry but have separate Topology :<br />
<br />
'''&lt;?xml version="1.0" ?&gt;'''<br />
'''&lt;!DOCTYPE Xdmf SYSTEM "Xdmf.dtd" <nowiki>[</nowiki><nowiki>]</nowiki>&gt;'''<br />
<br />
'''&lt;Xdmf Version="2.0" xmlns:xi="<nowiki>[http://www.w3.org/2001/XInclude</nowiki>]"&gt;'''<br />
'''&lt;Domain&gt;'''<br />
'''&lt;DataItem Name="Point Data" Format="XML" Dimensions="2 4 3"&gt;'''<br />
'''0.0 0.0 0.0'''<br />
'''1.0 0.0 0.0'''<br />
'''1.0 1.0 0.0'''<br />
'''0.0 1.0 0.0'''<br />
'''0.0 0.0 2.0'''<br />
'''1.0 0.0 2.0'''<br />
'''1.0 1.0 2.0'''<br />
'''0.0 1.0 2.0'''<br />
'''&lt;/DataItem&gt;'''<br />
'''&lt;Grid Name="Two Quads&gt;'''<br />
'''&lt;Topology Type="Quadrilateral" NumberOfElements="2" &gt;'''<br />
'''&lt;DataItem Format="XML" '''<br />
'''DataType="Int"'''<br />
'''Dimensions="2 4"&gt;'''<br />
'''0 1 2 3'''<br />
'''1 6 7 2'''<br />
'''&lt;/DataItem&gt;'''<br />
'''&lt;/Topology&gt;'''<br />
'''&lt;Geometry Type="XYZ"&gt;'''<br />
'''&lt;DataItem Reference="XML"&gt;'''<br />
'''/Xdmf/Domain/DataItem<nowiki>[</nowiki>@Name="Point Data"<nowiki>]</nowiki>'''<br />
'''&lt;/DataItem&gt;'''<br />
'''&lt;/Geometry&gt;'''<br />
'''&lt;/Grid&gt;'''<br />
'''&lt;/Domain&gt;'''<br />
'''&lt;/Xdmf&gt;'''<br />
<br />
'''Attribute'''<br />
<br />
The Attribute element defines values associated with the mesh. Currently the supported types of values are :<br />
<br />
* '''Scalar'''<br />
* '''Vector'''<br />
* '''Tensor''' - 9 values expected<br />
* '''Tensor6''' - a symmetrical tensor<br />
* '''Matrix ''' - an arbitrary NxM matrix<br />
These values can be centered on :<br />
* '''Node'''<br />
* '''Edge'''<br />
* '''Face'''<br />
* '''Cell'''<br />
* '''Grid'''<br />
<br />
A Grid centered Attribute might be something like "Material Type" where the value is constant everywhere in the grid. Edge and Face centered values are defined, but do not map well to many visualization systems. Typically Attributes are assigned on the Node :<br />
<br />
'''&lt;Attribute Name="Node Values" Center="Node"&gt;'''<br />
'''&lt;DataItem Format="XML" Dimensions="6 4"&gt;'''<br />
'''100 200 300 400'''<br />
'''500 600 600 700'''<br />
'''800 900 1000 1100'''<br />
'''1200 1300 1400 1500'''<br />
'''1600 1700 1800 1900'''<br />
'''2000 2100 2200 2300'''<br />
'''&lt;/DataItem&gt;'''<br />
'''&lt;/Attribute&gt;'''<br />
Or assigned to the cell centers :<br />
'''&lt;Attribute Name="Cell Values" Center="Cell"&gt;'''<br />
'''&lt;DataItem Format="XML" Dimensions="3"&gt;'''<br />
''' 3000 2000 1000'''<br />
''' &lt;/DataItem&gt;'''<br />
'''&lt;/Attribute&gt;'''<br />
<br />
'''Time'''<br />
<br />
The '''Time''' element is a child of the '''Grid''' element and specifies the temporal information for the grid. The type of time element is defined by the '''TimeType''' attribute of the element. Valid TimeTypes are :<br />
* '''Single''' - A single time value for the entire grid<br />
* '''HyperSlab''' - Start, Stride, Count<br />
* '''List''' - A list of discrete times<br />
* '''Range''' - Min, Max<br />
<br />
So in the simplest form, specifying a single time :<br />
'''&lt;Time Value="0.1" /&gt;'''<br />
<br />
For a more complex situation, consider a grid with GridType="Collection" which contains a set 100 children grids written every 1usec of simulation time :<br />
&lt;Time TimeType="HyperSlab"&gt;<br />
&lt;DataItem Format="XML" NumberType="Float" Dimensions="3"&gt;<br />
0.0 0.000001 100<br />
&lt;/DataItem&gt;<br />
&lt;/Time&gt;<br />
<br />
For a collection of grids not written at regular intervals :<br />
&lt;Time TimeType="List"&gt;<br />
&lt;DataItem Format="XML" NumberType="Float" Dimensions="7"&gt;<br />
0.0 0.1 0.5 1.0 1.1 10.0 100.5<br />
&lt;/DataItem&gt;<br />
&lt;/Time&gt;<br />
<br />
For data which is valid not at a discrete time but within a range :<br />
&lt;Time TimeType="Range"&gt;<br />
&lt;DataItem Format="XML" NumberType="Float" Dimensions="2"&gt;<br />
0.0 0.5<br />
&lt;/DataItem&gt;<br />
&lt;/Time&gt;<br />
<br />
'''Information'''<br />
<br />
There is regularly code or system specific information that needs to be stored with the data that does not map to the current data model. There is an ''Information'' element. This is intended for application specific information that can be ignored. A good example might be the bounds of a grid for use in visualization. Information elements have a Name and Value attribute. If Value is nonexistent the value is in the CDATA of the element :<br />
<br />
'''&lt;Information Name="XBounds" Value="0.0 10.0"/&gt;'''<br />
'''&lt;Information Name="Bounds"&gt; 0.0 10.0 100.0 110.0 200.0 210.0 &lt;/Information&gt;'''<br />
<br />
Several items can be addressed using the ''Information'' element like time, units, descriptions, etc. without polluting the XDMF schema. If some of these get used extensively they may be promoted to XDMF elements in the future.<br />
<br />
'''XML Element (Xdmf ClassName) and Default XML Attributes'''<br />
<br />
* Attribute (XdmfAttribute)<br />
Name (no default)<br />
AttributeType <span style='color:red'>Scalar</span> | Vector | Tensor | Tensor6 | Matrix | GlobalID<br />
Center <span style='color:red'>Node</span> | Cell | Grid | Face | Edge<br />
<br />
* DataItem (XdmfDataItem)<br />
Name (no default)<br />
ItemType <span style='color:red'>Uniform</span> | Collection | tree | HyperSlab | coordinates | Function<br />
Dimensions (no default) in KJI Order<br />
NumberType <span style='color:red'>Float</span> | Int | UInt | Char | UChar<br />
Precision 1 | <span style='color:red'>4</span> | 8<br />
Format <span style='color:red'>XML</span> | HDF | Binary<br />
Endian <span style='color:red'>Native</span> | Big | Little (applicable only to Binary format)<br />
Compression <span style='color:red'>Raw</span>|Zlib|BZip2 (applicable only to Binary format and depend on xdmf configuration)<br />
Seek <span style='color:red'>0</span> (number of bytes to skip, applicable only to Binary format with Raw compression)<br />
<br />
* Domain (XdmfDomain)<br />
Name (no default)<br />
<br />
* Geometry (XdmfGeometry)<br />
GeometryType <span style='color:red'>XYZ</span> | XY | X_Y_Z | VxVyVz | Origin_DxDyDz<br />
<br />
* Grid (XdmfGrid)<br />
Name (no default)<br />
GridType <span style='color:red'>Uniform</span> | Collection | Tree | Subset<br />
CollectionType <span style='color:red'>Spatial</span> | Temporal (Only Meaningful if GridType="Collection")<br />
Section <span style='color:red'>DataItem</span> | All (Only Meaningful if GridType="Subset")<br />
<br />
* Information (XdmfInformation)<br />
Name (no default)<br />
Value (no default)<br />
<br />
* Xdmf (XdmfRoot)<br />
Version <span style='color:red'>Current Version</span> | *<br />
<br />
* Topology (XdmfTopology)<br />
Name (no default)<br />
TopologyType Polyvertex | Polyline | Polygon |<br />
Triangle | Quadrilateral | Tetrahedron | Pyramid| Wedge | Hexahedron |<br />
Edge_3 | Triagle_6 | Quadrilateral_8 | Tetrahedron_10 | Pyramid_13 |<br />
Wedge_15 | Hexahedron_20 |<br />
Mixed |<br />
2DSMesh | 2DRectMesh | 2DCoRectMesh |<br />
3DSMesh | 3DRectMesh | 3DCoRectMesh<br />
NodesPerElement (no default) Only Important for Polyvertex, Polygon and Polyline<br />
NumberOfElement (no default)<br />
OR<br />
Dimensions (no default)<br />
Order each cell type has its own default<br />
BaseOffset <span style='color:red'>0</span> | #<br />
<br />
* Time<br />
TimeType <span style='color:red'>Single</span> | HyperSlab | List | Range<br />
Value (no default - Only valid for TimeType="Single")</div>Dave.demarle