Skip to content
  • Past due by over 3 years Last updated about 3 years ago

    The strategy described for checkpointing files is also suitable, wi…

    The strategy described for checkpointing files is also suitable, with some minor extensions,
    for visualisation purposes. Visualisation software such as VisIt and Paraview uses the VTK
    toolkit for in-memory representation of fields and meshes. VTK recently implemented
    support for storage of finite element fields consisting of piecewise polynomials and
    piecewise discontinuous polynomials (up to degree 10) [1]. Firedrake supports this via the
    legacy VTU format, which requires one file per field per process. This format is not suited
    to high performance parallel filesystems, and additionally replicates the mesh data many
    times (writing two fields results in two copies of the mesh on disk).
    This can be addressed using the newer XDMF format. XDMF provides a standard way of
    separating the metadata which provides information about fields from the data itself, and
    communicating that (via VTK) to visualisation software. The Firedrake extensions required
    to support XDMF with the checkpointing scheme described above are:

    1. provide interpolation and renumbering routines from internal Firedrake ordering and
      basis functions to those supported by VTK;
    2. implement, in addition to dumping of HDF5 data, writing of the appropriate XDMF
      metadata. This provides, to visualisation software, the information necessary to find
      and then display fields in the HDF5 dump.

    100% complete
  • Past due by about 4 years Last updated about 3 years ago

    Firedrake uses the PETSc library to provide parallel mesh data stru…

    Firedrake uses the PETSc library to provide parallel mesh data structures. Recent
    improvements in PETSc provide parallel load and store of bare mesh objects utilising HDF5.
    On top of this mesh object, Firedrake stores finite element data (solution fields) by first
    associating some number of degrees of freedom to each topological entity of the mesh and
    providing a description of the associated basis functions. This description is captured in a
    FunctionSpace object. The solution field then provides a vector of degrees of freedom
    (DoFs) which are to be interpreted with the FunctionSpace at hand. For a checkpoint file
    to be self-contained and reusable, it must mirror this setup by providing:

    1. The full mesh topology (cells, faces, edges, vertices, and their connectivity)
    2. The degrees of freedom (values) for a given field
    3. The association of these values to the mesh entities
    4. Metadata indicating how to interpret the values (what the basis functions are).

    100% complete