Lighthouse has a new layout. Prefer the old one? Return to the old layout, and switch back any time from the link at the top of each page.

Write state vectors in split HDF5 format

#8

The function space can be implemented with tags on an iMesh state file. There are two viable options:

  1. For every entity in the expanded space, write a pair of tags, offset of the first dof and the number of dofs associated with this entity. The writer will then simply dump the expanded vector into an HDF5 file.
  • Pros:
    • multiple state vectors without duplicating the function space definition
    • the reader plugin is fairly simple because it will not have to know about the constraint matrix
    • the read operation for any given region (vtkStructuredGrid) is contiguous
  • Cons:
    • duplicates storage for vertex, edge, and face dofs
    • continuity is not inherent
  1. For every entity in global space, write the pair of tags. Then dump a global vector to the HDF5 file.
  • Pros:
    • multiple state vectors without duplicating the function space definition
    • no duplicate storage
    • continuity is inherent
  • Cons:
    • the reader plugin becomes more complex because the constraint matrix must be known
    • The reader plugin needs to apply (part of) the constraint matrix to populate a vtkStructured grid, the values in the state vector needed to apply these rows may involve a very discontiguous read. Handling this in parallel when making a movie of part of a domain sounds very hard.

My vote is for option 1.

Reported by Jed Brown · November 25th, 2008 @ 10:40 AM

State: new
Milestone: none
Assigned to: Jed Brown Jed Brown

Activity

  1. Jed Brown
    Jed Brown

    We now have a distinction between global, Dirichlet, and closure vectors. For low-order meshes, option 1 requires a lot of storage and isn't in the form we want to restart from a saved state. The closure vector is only lightly influenced by the domain decomposition so it is a natural candidate for the stored state. A proposed HDF5 file would have the structure

    • /dohp
      • /fs/N (many states, i.e. mesh topologies)
        • /file_name (MOAB mesh)
        • /global_closure_offset (tag name)
        • /boundaries/N (many boundaries)
          • /tag_name
          • /tag_values
      • /vec/N (many vectors)
        • /name
        • /bs (block size)
        • /time/M (many time-steps)
          • /fs (number in /dohp/fs with the correct topology)
          • /values (raw arrays, dumped either from rank 0 or with MPI-IO collective)
          • /coordinates (index of vector corresponding to the mesh geometry)

    The value at /dohp/vec/N/time/M/coordinates needs further definition, specifics depend on how this part gets implemented. If it is not given, the mesh geometry provided by MOAB should be used unperturbed.

    April 17th, 2009 @ 05:12 PM

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.