Skip to content

Latest commit

 

History

History
53 lines (39 loc) · 1.83 KB

2022-10-31.md

File metadata and controls

53 lines (39 loc) · 1.83 KB

Binary Sparse Format Working Group Meeting #5 - October 31, 2022

Attendees

  • Ben Brock
  • Tim Davis
  • Jim Kitchen
  • Tim Mattson
  • Scott McMillan
  • Erik Welch
  • Isaac Virshup
  • Will Kimmerer

Agenda

  • Discuss auxiliary data, as well as next steps for formalizing the API.

Summary of Discussion

  • Tim presented the auxiliary data used in the SuiteSparse Matrix Collection.
    • These consist of various bits of metadata associated with one of
      1. The matrix as a whole (i.e. arbitrary ASCII)
      2. Rows/columns/vertices
      3. Edges (individual nonzeros)
    • In SuiteSparse, these are stored as separate documents within a tarball
    • Based on standardized data in MatrixMarket file, look for files (text, MatrixMarket) storing additional data.

Do we want to support auxiliary data?

Jim: yes, we can store these by nature of using a binary data container. Auxiliary data can simply be additional datasets in a nested namespace.

Isaac: one exception is data associated with individual edges, which is more tightly associated with nonzeros, so needs to be associated with matrix structure.

Erik's 2.0 proposal supports edge properties, essentially by allowing additional values arrays.

User-defined types: Tim presented SuiteSparse's user-defined type mechanism, which essentially stores the C struct along with metadata.

Should we store the types of indices/values in metadata? Jim: if container does not support all types, it becomes necessary to store additional type information. Example: bool (HDF5/NetCDF have no bool).

Are we ready to begin drafting spec document with some of the 1.0 details we have mostly crystallized? Yes.

Outcomes

  • Ben will create independent GitHub repo with binary sparse prototype parser.

  • Ben will continue to investigate NetCDF

  • Isaac will set up spec document using Bikeshed