Catalyst 2.0: adding support for custom mesh blueprints

Development
,
1

I don’t have a specific question for the forum here, but more of a description of my current approach for implementing a new Catalyst adaptor. Figured I’ll share it with the broader community and see if people have any specific thoughts / opinions about my approach.

I am currently adding support for the IOSS library to interface with Catalyst 2.0 so that all codes using IOSS can directly use Catalyst with ease. IOSS has a very well-defined data model. The underlying Database API – which is what I am looking into implementing to interface with Catalyst – is based on that data model. There are two ways going about implementing this database for Catalyst:

  1. We map the datastructures such that they can conform to the Conduit Mesh Blueprint and then pass that over to Calalyst.
  2. We create a new mesh blueprint, say IOSS Mesh Blueprint, that is more closely aligned with the Ioss data model.

I am leaning towards option 2 for following reasons:

  • avoids any data transformation to pass data to Catalyst – should give some performance benetit
  • since ParaView/VTK already has an Ioss reader, the reader can be easily taught to support this new database type that reads the Ioss datastructures serialized to Conduit node instead of a file on disk.

The ParaView Catalyst Blueprint already supports channel/type property which currently only suppose mesh. This will require adding support for another type, ioss.

2

No opinion yet but interested in seeing what you’re going to do and how this would work within the Catalyst ecosystem.

3

Cool. Honestly, I have no idea how this pans out either. But I think it’s worth experimenting. This can open up a new way of leveraging extensible IO libraries like IOSS, Adios for interfacing with Catalyst.

4

This may be a good time to explore the relationship between Fides (Fides User Guide — Fides documentation) and Catalyst 2.0. The Fides data model is in some way much more flexible than the blueprint approach, in the sense that it is defined using a combination of runtime (json) and compile time definitions (VTK-m). Whereas blueprint is all compile time AFAIK. Can we do something similar (or same) for Catalyst?

5

sigh! found a drawback with this approach. While a custom blueprint will work, it does require a custom “reader” on the Catalyst side. The IOSS API is deep-copy only thus put data into a database and reading back from it will cause a deep copy. I will discuss with the IOSS developers to see if there a way to extend the database API to support it.