# Initializing a new pipeline during a run with ParaView Catalyst
**URL:** https://discourse.paraview.org/t/initializing-a-new-pipeline-during-a-run-with-paraview-catalyst/17550
**Category:** In Situ Support
**Created:** [May 5, 2026, 8:20pm UTC](https://discourse.paraview.org/t/initializing-a-new-pipeline-during-a-run-with-paraview-catalyst/17550 "2026-05-05T20:20:41Z")
**Posts on this page:** 8
**Page:** 1
### Author:  [@Alexandre\_Minot](https://discourse.paraview.org/u/Alexandre_Minot)
#### Post date: [May 5, 2026, 8:20pm UTC](https://discourse.paraview.org/t/initializing-a-new-pipeline-during-a-run-with-paraview-catalyst/17550/1 "2026-05-05T20:20:41Z")
Dear all,
As far as I can tell, we cannot initialize a new Catalyst pipeline during a run. `catalyst_initialize()` can only be called once, and that’s the place where we tell ParaView about our scripts.
It would be useful for me to be able to add scripts after I have called catalyst\_initialize(). From a quick glance at the `vtkInSituInitializationHelper` I don’t see any fundamental problem with adding a pipeline mid-run.
Any thoughts?
---
### Author:  [@Louis\_Gombert](https://discourse.paraview.org/u/Louis_Gombert)
#### Post date: [May 6, 2026, 8:03am UTC](https://discourse.paraview.org/t/initializing-a-new-pipeline-during-a-run-with-paraview-catalyst/17550/2 "2026-05-06T08:03:10Z")
Would calling `catalyst_finalize` and then `catalyst_initialize` again with different scripts work? I haven’t tried though.
---
### Author:  [@Alexandre\_Minot](https://discourse.paraview.org/u/Alexandre_Minot)
#### Post date: [May 6, 2026, 12:57pm UTC](https://discourse.paraview.org/t/initializing-a-new-pipeline-during-a-run-with-paraview-catalyst/17550/3 "2026-05-06T12:57:45Z")
I would not mind doing that, but currently this does not work. The second initialize is still ignored by ParaView (and ParaView warns that initialize cannot be called again).
---
### Author:  [@Louis\_Gombert](https://discourse.paraview.org/u/Louis_Gombert)
#### Post date: [May 6, 2026, 1:12pm UTC](https://discourse.paraview.org/t/initializing-a-new-pipeline-during-a-run-with-paraview-catalyst/17550/4 "2026-05-06T13:12:49Z")
If we were to handle this case by changing ParaView, it would be better to call `catalyst_finalize` first and make everything clean (reset static variables basically) for the next `catalyst_initialize` call to work properly. Would you mind opening an issue on the GitLab tracker?
---
### Author:  [@Alexandre\_Minot](https://discourse.paraview.org/u/Alexandre_Minot)
#### Post date: [May 6, 2026, 1:22pm UTC](https://discourse.paraview.org/t/initializing-a-new-pipeline-during-a-run-with-paraview-catalyst/17550/5 "2026-05-06T13:22:18Z")
Louis,
Thanks for your quick responses. Here is the issue: [https://gitlab.kitware.com/paraview/paraview/-/work\_items/23273](https://gitlab.kitware.com/paraview/paraview/-/work_items/23273)
---
### Author:  [@Jeff\_Lee](https://discourse.paraview.org/u/Jeff_Lee)
#### Post date: [May 12, 2026, 12:43am UTC](https://discourse.paraview.org/t/initializing-a-new-pipeline-during-a-run-with-paraview-catalyst/17550/6 "2026-05-12T00:43:19Z")
I would be against allowing re-initialize unless a very clear use-case were presented. The design is that catalyst follows the adaptor/simulation lifecycle. There is nothing preventing registration of all the possible pipelines you would want to use up-front, and then selectively executing them
```auto
auto pipelines = state["pipelines"];
pipelines.append().set("forces"); // every step, cheap
if (timestep % 100 == 0) {
pipelines.append().set("vorticity"); // every 100 steps, expensive
}
if (timestep % 1000 == 0) {
pipelines.append().set("screenshots"); // every 1000 steps, very expensive
}
```
By default, if state/pipelines isnt populated catalyst executes all of the registered pipelines. Maybe I am missing the actual use-case you have in mind.
---
### Author:  [@Alexandre\_Minot](https://discourse.paraview.org/u/Alexandre_Minot)
#### Post date: [May 12, 2026, 1:42pm UTC](https://discourse.paraview.org/t/initializing-a-new-pipeline-during-a-run-with-paraview-catalyst/17550/7 "2026-05-12T13:42:07Z")
Right, all pipelines must be registered up front, so no pipelines can be added during the simulation. We can start registered pipelines later in the simulation but we cannot register them during the simulation.
A simple use case is “I forgot to register a pipeline.” A more realistic use case is something like “Looking at the slices being generated, this area seems interesting, I wish I could add a contour of vorticity here”. Indeed, the ability to gain insights during the simulation is one of the advantage of in-situ processing compared to post-processing.
> [@Jeff\_Lee](#):
>
> The design is that catalyst follows the adaptor/simulation lifecycle.
That’s actually why I’m asking. We allow users to change inputs to our software during the simulation. So adding a slice during the simulation is in line with our simulation life cycle. I would like to offer that feature to our users, which is why I am asking for a matching Catalyst feature.
There _are_ ways of doing this currently. We can register empty slots and fill them later with a real pipeline. We can also register a single pipeline that is just a daemon, and the daemon takes care of monitoring user inputs and adding and deleting pipelines. ParaView supports this, the question is what is the best way to do it through Catalyst?
I’m not necessarily asking for a re-initialize. I’m asking for an add/delete interface. The how is up to you. If we do it through a re-initialize, that works for me. (I don’t really need a delete, since as you say, you can simply stop executing an existing pipeline, but that would be cleaner).
I do think that the concept of _finalize cleans up everything_, and _initialize can be called again_ is easy to understand for user-developers.
---
### Author:  [@Alexandre\_Minot](https://discourse.paraview.org/u/Alexandre_Minot)
#### Post date: [May 26, 2026, 7:16pm UTC](https://discourse.paraview.org/t/initializing-a-new-pipeline-during-a-run-with-paraview-catalyst/17550/8 "2026-05-26T19:16:04Z")
A solution for this was merged in master: [https://gitlab.kitware.com/paraview/paraview/-/merge\_requests/7792#note\_1816562](https://gitlab.kitware.com/paraview/paraview/-/merge_requests/7792#note_1816562)