# Catalyst 2.0: adding support for custom mesh blueprints
**URL:** https://discourse.paraview.org/t/catalyst-2-0-adding-support-for-custom-mesh-blueprints/7283
**Category:** Development
**Tags:** catalyst, proposal
**Created:** [May 24, 2021, 4:43pm UTC](https://discourse.paraview.org/t/catalyst-2-0-adding-support-for-custom-mesh-blueprints/7283 "2021-05-24T16:43:43Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@utkarsh.ayachit](https://discourse.paraview.org/u/utkarsh.ayachit)
#### Post date: [May 24, 2021, 4:43pm UTC](https://discourse.paraview.org/t/catalyst-2-0-adding-support-for-custom-mesh-blueprints/7283/1 "2021-05-24T16:43:43Z")
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](https://gsjaardema.github.io/seacas-docs/IOSystem.pdf). 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](https://kitware.github.io/paraview-docs/nightly/cxx/ParaViewCatalystBlueprint.html) already supports **channel/type** property which currently only suppose **`mesh`**. This will require adding support for another type, **`ioss`**.
---
### Author:  [@Andy\_Bauer](https://discourse.paraview.org/u/Andy_Bauer)
#### Post date: [May 24, 2021, 6:24pm UTC](https://discourse.paraview.org/t/catalyst-2-0-adding-support-for-custom-mesh-blueprints/7283/2 "2021-05-24T18:24:26Z")
No opinion yet but interested in seeing what you’re going to do and how this would work within the Catalyst ecosystem.
---
### Author:  [@utkarsh.ayachit](https://discourse.paraview.org/u/utkarsh.ayachit)
#### Post date: [May 24, 2021, 6:40pm UTC](https://discourse.paraview.org/t/catalyst-2-0-adding-support-for-custom-mesh-blueprints/7283/3 "2021-05-24T18:40:07Z")
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.
---
### Author:  [@berkgeveci](https://discourse.paraview.org/u/berkgeveci)
#### Post date: [May 24, 2021, 6:56pm UTC](https://discourse.paraview.org/t/catalyst-2-0-adding-support-for-custom-mesh-blueprints/7283/4 "2021-05-24T18:56:16Z")
This may be a good time to explore the relationship between Fides ([Fides User Guide — Fides documentation](https://fides.readthedocs.io/en/latest/)) 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?
---
### Author:  [@utkarsh.ayachit](https://discourse.paraview.org/u/utkarsh.ayachit)
#### Post date: [May 24, 2021, 8:47pm UTC](https://discourse.paraview.org/t/catalyst-2-0-adding-support-for-custom-mesh-blueprints/7283/5 "2021-05-24T20:47:17Z")
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.