armi.bookkeeping.visualization.xdmf module¶
Support for dumping XDMF files.
XDMF is a data interchange format that
allows for separate representation of the data itself and a description of how those
data are to be interpreted. The data description (“light” data) lives in an XML file,
while the actual data (in our case, data to be plotted), as well as the data describing
the mesh (“hard” data) can be stored in HDF5 files, binary files, or embedded directly
into the XML file. In most cases, this allows for visualizing data directly out of an
ARMI database file. Using the XdmfDumper
will produce an XML file (with an .xdmf
extension) containing the description of data, as well as an HDF5 file containing the
mesh. Together with the input database, the .xdmf
file can be opened in a
visualization tool that supports XDMF.
Note
Paraview seems to have rather good support for XDMF, while VisIt does not. The main issue seems to be that VisIt does not properly render the general polyhedra that XDMF supports. Unfortunately, we __need__ to use this to show hexagonal geometries, since it’s the only way to get a hexagonal prism without splitting up the mesh into wedges. To do that would require splitting the parameter data, which would defeat the main benefit of using XMDF in the first place (to be able to plot out of the original Database file). Cartesian and R-X-Theta geometries in VisIt seem to work fine. Support for polyhedra is being tracked in #1287.
-
armi.bookkeeping.visualization.xdmf.
_getAttributesFromDataset
(d: h5py._hl.dataset.Dataset) → Dict[str, str][source]¶
-
class
armi.bookkeeping.visualization.xdmf.
XdmfDumper
(baseName: str, inputName: Optional[str] = None)[source]¶ Bases:
armi.bookkeeping.visualization.dumper.VisFileDumper
VisFileDumper implementation for XDMF format.
The general strategy of this dumper is to create a new HDF5 file that contains just the necessary mesh information for each dumped time step. The XML that describes/points to these data is stored internally as
ElementTree
objects until the end. When all time steps have been processed, these elements have time information added to them, and are collected into a “TemporalCollection” Grid and written to an.xdmf
file.-
__enter__
()[source]¶ Prepare to write states.
The dumper keeps track of
<Grid>
tags that need to be written into a Collection at the end. This also opens an auxiliary HDF5 file for writing meshes at each time step.
-
__exit__
(type, value, traceback)[source]¶ Finalize file writing.
This writes all of the
<Grid>
tags into a Collection for all time steps, and closes the input database and mesh-bearing HDF5 file.
-
static
_dedupTimes
(times: List[float]) → List[float][source]¶ Make sure that no two times are the same.
Duplicates will be resolved by bumping each subsequent duplicate time forward by some epsilon, cascading following duplicates by the same amount until no duplicates remain. This will fail in the case where there are already times that are within Ndup*epsilon of each other. In such cases, this function probably isn’t valid anyways.
-
dumpState
(r: armi.reactor.reactors.Reactor, includeParams: Optional[Set[str]] = None, excludeParams: Optional[Set[str]] = None)[source]¶ Produce a
<Grid>
for a single timestep, as well as supporting HDF5 datasets.
-
_collectObjectData
(objs: List[armi.reactor.composites.ArmiObject], timeGroupName, node: xml.etree.ElementTree.Element)[source]¶ Scan for things that look plottable in the input database.
“Plottable” things are anything that have int or float data, and the same number of elements as there are objects.
Warning
This makes some assumptions as to the structure of the database.
-
_makeAssemblyMesh
(r: armi.reactor.reactors.Reactor, indexMap) → xml.etree.ElementTree.Element[source]¶
-
static
_makeGenericMesh
(name: str, nCells: int, vertexData: h5py._hl.dataset.Dataset, topologyData: h5py._hl.dataset.Dataset) → xml.etree.ElementTree.Element[source]¶
-
_abc_impl
= <_abc_data object>¶
-
-
armi.bookkeeping.visualization.xdmf.
_getTopologyFromShape
(b: armi.reactor.blocks.Block, offset: int) → Tuple[int, List[int]][source]¶ Returns the number of vertices used to make the shape, and XDMF topology values.
The size of the XDMF topology values cannot be used directly in computing the next offset because it sometimes contains vertex indices __and__ sizing information.