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.

_makeBlockMesh(r: armi.reactor.reactors.Reactor, indexMap) → xml.etree.ElementTree.Element[source]
_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.