/vtk`)
---
### Author:  [@eudoxos](https://discourse.paraview.org/u/eudoxos)
#### Post date: [February 20, 2022, 11:16am UTC](https://discourse.paraview.org/t/catalyst-old-and-new-necessity-of-mpi/9005/3 "2022-02-20T11:16:45Z")
Thank you for the reply, that got me oriented. The `vtkDataObjectToConduit` source is a good inspiration, surprisingly simple; I might switch to generating just the arrays in my code and then build either vtk arrays or conduit objects from them, as needed (exporting to file or sending to Catalyst). I also understand now the pain of linking against ParaView when using old-style Catalyst and will go the way of using the new-style Catalyst.
One more clarification to get me started. I do `add_subdirectory` on `https://gitlab.kitware.com/paraview/catalyst.git` and link my code against `catalyst::catalyst`. Then in my code I can roughly follow [catalyst\_example\_about.cxx](https://gitlab.kitware.com/paraview/catalyst/-/blob/master/examples/about/catalyst_example_about.cxx), As I understand, the basic use (simpler than the `catalyst_example_about.cxx` - I can run simulation, but if I choose so, I can run with piping data to ParaView) would be (please let me know whether I am following the logic correctly):
1. call `catalyst_initialize(...)` with an empty node, without specifying any implementation or paths; that finds (with an appropriate `LD_LIBRARY_PATH`) the no-op implementation (`libcatalyst.so` from the catalyst.git repo, providing an implementation called `stub`).
2. If I want to use visualize ParaView for a particular run, then I will specify `LD_LIBRARY_PATH=/opt/paraview/lib` so that `catalyst_initialize` finds `libcatalyst.so` in the paraview installation. That implementation is also called `stub`.
How can the code recognize whether it is talking to a functional API or the no-op implementation (both called `stub`)? And then, is there an equivalent of `RequestDataDescription` of the legacy Catalyst API, querying whether the Catalyst pipeline is ready for new data?
Thanks!
P.S. in [Catalyst for Simulation Developers](https://catalyst-in-situ.readthedocs.io/en/latest/for_simulation_developers.html), the `find_package(catalyst VERSION 2.0 REQUIRED)` should be `find_package(catalyst 2.0 REQUIRED)`.
---
### Author:  [@nicolas.vuaille](https://discourse.paraview.org/u/nicolas.vuaille)
#### Post date: [February 21, 2022, 9:02am UTC](https://discourse.paraview.org/t/catalyst-old-and-new-necessity-of-mpi/9005/4 "2022-02-21T09:02:08Z")
First not that the [doc](https://catalyst-in-situ.readthedocs.io/en/latest/for_simulation_developers.html#catalyst-initialize) advise to use those environment variables instead of `LD_LIBRARY_PATH`:
- `CATALYST_IMPLEMENTATION_PATHS` to specify directories where to look
- `CATALYST_IMPLEMENTATION_NAME` to specify the impl name (like `stub` or `paraview`, not the full .so name)
If you want to use ParaView, you should use `CATALYST_IMPLEMENTATION_NAME=paraview` and not `stub`.
To check the used version, you should:
- create an empty node
- call `catalyst_about(node)`
- check for `catalyst_load/implementation` subnode. This will typically contains `stub` or `paraview`. The stub impl provides this nodes: [https://gitlab.kitware.com/paraview/catalyst/-/blob/master/src/catalyst/catalyst\_stub.cpp#L34](https://gitlab.kitware.com/paraview/catalyst/-/blob/master/src/catalyst/catalyst_stub.cpp#L34). And other implementation are encouraged to do the same.
Indeed, both `catalyst` and `paraview` repo can provide the `stub` implementation, but this is the same 🙂
And thanks for reporting the doc issue!
---
### Author:  [@eudoxos](https://discourse.paraview.org/u/eudoxos)
#### Post date: [February 21, 2022, 7:25pm UTC](https://discourse.paraview.org/t/catalyst-old-and-new-necessity-of-mpi/9005/5 "2022-02-21T19:25:26Z")
Thanks for the reply, one more step further 🙂
`LD_LIBRARY_PATH` was just for libcatalyst.so (linked against, and not in default ld.so lookup paths); then using `CATALYST_IMPLEMENTATION_PATHS` and `CATALYST_IMPLEMENTATION_NAME` I can indeed connect to the “paraview” implementation. Good.
Now, please correct me if I am wrong: I need to set `catalyst/scripts/script*` in the node passed to `catalyst_initialize` to setup live connection to a listening Paraview instance, as detailed in [CatalystPythonScriptV2](https://gitlab.kitware.com/paraview/paraview/-/blob/release/Utilities/Doxygen/pages/CatalystPythonScriptV2.md). Is there some easier way to accomplish that for trivial cases? Or can I pass the python script as string (as opposed to filename) for short pieces I can embed in the c++ code?
---
### Author:  [@nicolas.vuaille](https://discourse.paraview.org/u/nicolas.vuaille)
#### Post date: [February 22, 2022, 9:22am UTC](https://discourse.paraview.org/t/catalyst-old-and-new-necessity-of-mpi/9005/6 "2022-02-22T09:22:14Z")
Python code can only be passed as a filename, no direct code.
Note that you can setup writers directly from the conduit nodes, without python script. That is done in a `pipelines` node described in the [ParaView Blueprint documentation](https://kitware.github.io/paraview-docs/latest/cxx/ParaViewCatalystBlueprint.html)