ParaView issueshttps://gitlab.kitware.com/paraview/paraview/-/issues2023-03-15T13:17:55-04:00https://gitlab.kitware.com/paraview/paraview/-/issues/21816[Feature Request] Ship ParaView with a mangled VTK2023-03-15T13:17:55-04:00Julien Fausty[Feature Request] Ship ParaView with a mangled VTK## Problem Statement
When including ParaView into applications that already compile and link to VTK, collisions between ParaView's VTK version and the application's can occur at runtime leading to a crash if the VTK versions are incompa...## Problem Statement
When including ParaView into applications that already compile and link to VTK, collisions between ParaView's VTK version and the application's can occur at runtime leading to a crash if the VTK versions are incompatible.
As an example, this can happen when using ParaView's `Catalyst` implementation in a code that already links to an external system VTK.
## Proposed Solution
Given that it is much more likely for another application that already links VTK to develop a dependency on ParaView than it is for ParaView to develop a dependency on another application using VTK, it seems only natural that it should be ParaView's responsibility to mangle its internal VTK libraries using the relatively new `VTK_ABI_NAMESPACE` feature developed in https://gitlab.kitware.com/vtk/vtk/-/merge_requests/8993 (discourse here: https://discourse.vtk.org/t/new-feature-in-vtk-vtk-abi-namespace/9421).
This functionality wraps all of VTK in a compile time defined namespace. The symbols are then "sealed" against collision.
Thoughts?https://gitlab.kitware.com/paraview/paraview/-/issues/21735Catalyst: Set Breakpoint doesn't work2024-01-23T04:15:58-05:00Lucas GivordCatalyst: Set Breakpoint doesn't workOn paraview 5.11, breakpoints setted are ignore when we start a live simulation.
---
Step to reproduce:
- compile `CxxFullExample` in `Examples/Catalyst2`
- add in the `catalyst_options` (to be able to connect the simulation with para...On paraview 5.11, breakpoints setted are ignore when we start a live simulation.
---
Step to reproduce:
- compile `CxxFullExample` in `Examples/Catalyst2`
- add in the `catalyst_options` (to be able to connect the simulation with paraview) :
```py
from paraview import catalyst
options = catalyst.Options()
options.EnableCatalystLive = 1
```
- start paraview, click on `Connect...` inside `Catalyst` toolbar
- click on `Set Breakpoint` and set the value to 3.
- start the simulation
```
bin/CxxFullExample ../catalyst_pipeline.py
```
the simulation will never stop at the end of the 3 time step.
---
Note that the `Pause Simulation` works well.https://gitlab.kitware.com/paraview/paraview/-/issues/22242Catalyst-ParaView implementation crashes with external ptr to GPU memory (CUDA)2023-11-08T21:09:07-05:00Francois MazenCatalyst-ParaView implementation crashes with external ptr to GPU memory (CUDA)When using a conduit node containing values set as an external pointer to a GPU allocated memory, then ParaView-Catalyst implementation crashes.
To reproduce:
- Download and unzip this small project: [catalyst-cuda-master.zip](/uploads...When using a conduit node containing values set as an external pointer to a GPU allocated memory, then ParaView-Catalyst implementation crashes.
To reproduce:
- Download and unzip this small project: [catalyst-cuda-master.zip](/uploads/413e7cfa597cd55db61281b217975d08/catalyst-cuda-master.zip)
- Create a build folder in the source and configure with cmake, then build the software
- Set environment variable `CATALYST_IMPLEMENTATION_NAME=paraview`
- Set environment variable `CATALYST_IMPLEMENTATION_PATHS=/path/to/catalyst/paraview/lib/folder`
- Launch the `catalyst_gpu` executable
- Crash in `vtkDataArrayPrivate::AllValuesMinAndMax` => not OK!
A simple workaround is to use `cudaMallocManaged` instead of `cudaMalloc` on the simulation side, but a generic solution could be implemented on the ParaView side to handle GPU memory pointers and make explicit copy to RAM before processing it. Ascent seems to implement such a logic with their [MagicMemory functions](https://github.com/Alpine-DAV/ascent/blob/f1ecfb3336bc57657a3ced9ab506e43acb202710/src/libs/ascent/runtimes/expressions/ascent_memory_manager.cpp#L451).
Thanks to @jfavre for the initial issue report and @louis.gombert for the minimal test case!https://gitlab.kitware.com/paraview/paraview/-/issues/21823Catalyst 2: Live Trigger do not update pipeline2023-11-08T21:14:22-05:00Nicolas VuailleCatalyst 2: Live Trigger do not update pipeline### Problem
In Catlyst 2 the `CatalystLiveTrigger` is not used to trigger the pipeline update. Only extractors do.
When `CatalystLiveTrigger.Frequency` has a match, the conduit sources should be updated with current time.
This is not th...### Problem
In Catlyst 2 the `CatalystLiveTrigger` is not used to trigger the pipeline update. Only extractors do.
When `CatalystLiveTrigger.Frequency` has a match, the conduit sources should be updated with current time.
This is not the case, as mentioned in [vtkCPPythonScriptV2Helper::DoLive]( https://gitlab.kitware.com/paraview/paraview/-/blob/d66f44fee151a548a3fa48d2041667debb910231/Clients/PythonCatalyst/vtkCPPythonScriptV2Helper.cxx#L724).
### Workaround
To update the live visu when no extractor is updating, one may add this method in the python script:
```python
def catalyst_execute(info):
global grid
grid.UpdatePipeline(info.time)
```
Where `grid` is the input source of the pipeline. The pipeline will be then updated depending on the `GlobalTrigger.Frequency` option.i
### Testing
I used the Catalyst2/CxxFullExample with the following custom script [cata.py](/uploads/53f80991df89dd7f3fd2bf76eb191ff7/cata.py).
In this script, a PNG extractor is created with `Frequency=4`, Live is enabled.https://gitlab.kitware.com/paraview/paraview/-/issues/21760Allow Conduit information to be made available in ParaView Catalyst Python sc...2023-11-08T21:14:55-05:00Andrew BauerAllow Conduit information to be made available in ParaView Catalyst Python scriptsParaView Catalyst Python scripts should have a mechanism in order to allow the Python script to access the Conduit information passed through the Catalyst V2 API. This would allow the Python script to access information passed through Co...ParaView Catalyst Python scripts should have a mechanism in order to allow the Python script to access the Conduit information passed through the Catalyst V2 API. This would allow the Python script to access information passed through Conduit for doing programmatic things inside of the Python script. As an example, it may be useful to determine all of the channels available in `gridwriter.py` so that the proper channel name can be passed set for the registrationName. Currently the channel name is hard-coded. Another example is being able to change the Python processing pipeline based on information passed through the Catalyst V2 API.https://gitlab.kitware.com/paraview/paraview/-/issues/14800No consistency for Catalyst generated scripts and state files with regards to...2020-05-06T05:14:07-04:00Kitware RobotNo consistency for Catalyst generated scripts and state files with regards to floating point number formatting**This issue was created automatically from an original [Mantis Issue](http://paraview.org/Bug/view.php?id=14800). Further discussion may take place here.**
---
Bob Kares sent an email with:
Why is there no consistency in the output...**This issue was created automatically from an original [Mantis Issue](http://paraview.org/Bug/view.php?id=14800). Further discussion may take place here.**
---
Bob Kares sent an email with:
Why is there no consistency in the output format used for numbers that appear in the Catalyst generated .py script? For example, one of my palettes uses a data range -2e+10 to 2e+10. When I look at what the Catalyst plugin generates by default, the CreatePiecewiseFunction line generated by the Catalyst plugin has -20000000000 and 20000000000. Sometimes "e" format is used instead, but I can’t really discern what the rule is.
This same problem occurs in the state files ParaView writes out. This is
more than a cosmetic issues because it makes data values you know are
there hard to find with a text editor.https://gitlab.kitware.com/paraview/paraview/-/issues/13909Cleanup references to CoProcessing/Catalyst2023-06-15T09:24:34-04:00Kitware RobotCleanup references to CoProcessing/Catalyst**This issue was created automatically from an original [Mantis Issue](http://paraview.org/Bug/view.php?id=13909). Further discussion may take place here.**
---
Clean up the status of CoProcessing/Catalyst to merge the two. We don't wa...**This issue was created automatically from an original [Mantis Issue](http://paraview.org/Bug/view.php?id=13909). Further discussion may take place here.**
---
Clean up the status of CoProcessing/Catalyst to merge the two. We don't want it to look like we have 2 separate tools
- Update source code
- Update Wikis/documentationhttps://gitlab.kitware.com/paraview/paraview/-/issues/13019improved coprocessing functionality2020-05-04T05:00:49-04:00Kitware Robotimproved coprocessing functionality**This issue was created automatically from an original [Mantis Issue](http://paraview.org/Bug/view.php?id=13019). Further discussion may take place here.**
---
As the coprocessing tools move forward, there needs to really be 3 modes o...**This issue was created automatically from an original [Mantis Issue](http://paraview.org/Bug/view.php?id=13019). Further discussion may take place here.**
---
As the coprocessing tools move forward, there needs to really be 3 modes of use with the user able to switch between any of them. The 3 modes are:
1) batch -- the user specifies some pipelines to be executed at certain intervals. This is currently supported in paraview.
2) interactive with simulation code being stalled -- the user can change the current pipeline (including parameters of filters in the pipeline), add new pipelines, remove old pipelines with data from the simulation. The simulation code waits for the user to specify that they're done with the data and/or pipelines before control is returned to the simulation code.
3) interactive with simulation code continuing running -- same as above except that while the user is interacting with the data and/or pipelines, the simulation code keeps running. when the user is satisfied with the pipelines they can push that information back to the simulation code to be used the next time coprocessing is to be performed.https://gitlab.kitware.com/paraview/paraview/-/issues/22513Memory leaks when using ParaView Catalyst2024-03-08T07:27:33-05:00Spiros TsalikisMemory leaks when using ParaView Catalyst```
=================================================================
==17446==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 4180894 byte(s) in 2337 object(s) allocated from:
#0 0x4dfba8 in __interceptor_malloc /usr/peo...```
=================================================================
==17446==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 4180894 byte(s) in 2337 object(s) allocated from:
#0 0x4dfba8 in __interceptor_malloc /usr/people/shared/tools/centos/6/llvm/build_files/6.0.0/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:88
#1 0x7fa495cc0cad in PyMem_RawMalloc /home/foo/Downloads/Python-3.7.0/build/../Objects/obmalloc.c:503:12
#2 0x7fa495cc0cad in _PyObject_Malloc /home/foo/Downloads/Python-3.7.0/build/../Objects/obmalloc.c:1560
Direct leak of 160 byte(s) in 2 object(s) allocated from:
#0 0x5175d8 in operator new(unsigned long) /usr/people/shared/tools/centos/6/llvm/build_files/6.0.0/llvm/projects/compiler-rt/lib/asan/asan_new_delete.cc:92
#1 0x7fa4bd3bcc2d in catalyst_conduit_node_create (/usr/people/shared/tools/centos/7/catalyst/HPCX/2.0.0/lib64/libcatalyst.so.3+0xedc2d)
#2 0x6080000655d7 (<unknown module>)
Direct leak of 64 byte(s) in 1 object(s) allocated from:
#0 0x4dfba8 in __interceptor_malloc /usr/people/shared/tools/centos/6/llvm/build_files/6.0.0/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:88
#1 0x7fa4b25470cb (<unknown module>)
Direct leak of 64 byte(s) in 2 object(s) allocated from:
#0 0x4dfba8 in __interceptor_malloc /usr/people/shared/tools/centos/6/llvm/build_files/6.0.0/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:88
#1 0x7fa495dd1294 in PyThread_allocate_lock /home/foo/Downloads/Python-3.7.0/build/../Python/thread_pthread.h:257:21
Direct leak of 12 byte(s) in 1 object(s) allocated from:
#0 0x442048 in strdup /usr/people/shared/tools/centos/6/llvm/build_files/6.0.0/llvm/projects/compiler-rt/lib/asan/asan_interceptors.cc:407
#1 0x7fa4a08f89de in vtkloguru::init(int&, char**, vtkloguru::Options const&) (/usr/people/shared/tools/centos/7/paraview/HPCX/paraview/5.11.0-mesa/lib64/catalyst/libcatalyst-paraview.so+0x87a69de)
Direct leak of 8 byte(s) in 1 object(s) allocated from:
#0 0x442048 in strdup /usr/people/shared/tools/centos/6/llvm/build_files/6.0.0/llvm/projects/compiler-rt/lib/asan/asan_interceptors.cc:407
#1 0x7fa4a08f93a6 in vtkloguru::set_thread_name(char const*) (/usr/people/shared/tools/centos/7/paraview/HPCX/paraview/5.11.0-mesa/lib64/catalyst/libcatalyst-paraview.so+0x87a73a6)
Direct leak of 1 byte(s) in 1 object(s) allocated from:
#0 0x442558 in __strdup /usr/people/shared/tools/centos/6/llvm/build_files/6.0.0/llvm/projects/compiler-rt/lib/asan/asan_interceptors.cc:423
#1 0x7fa4b094a7f0 (<unknown module>)
Indirect leak of 1361576 byte(s) in 1124 object(s) allocated from:
#0 0x4dfba8 in __interceptor_malloc /usr/people/shared/tools/centos/6/llvm/build_files/6.0.0/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:88
#1 0x7fa495cc0cad in PyMem_RawMalloc /home/foo/Downloads/Python-3.7.0/build/../Objects/obmalloc.c:503:12
#2 0x7fa495cc0cad in _PyObject_Malloc /home/foo/Downloads/Python-3.7.0/build/../Objects/obmalloc.c:1560
Indirect leak of 12508 byte(s) in 2 object(s) allocated from:
#0 0x4e0010 in realloc /usr/people/shared/tools/centos/6/llvm/build_files/6.0.0/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:107
#1 0x7fa495cde4f8 in resize_compact /home/foo/Downloads/Python-3.7.0/build/../Objects/unicodeobject.c:929:31
Indirect leak of 544 byte(s) in 1 object(s) allocated from:
#0 0x4dfba8 in __interceptor_malloc /usr/people/shared/tools/centos/6/llvm/build_files/6.0.0/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:88
#1 0x7fa495cc0edc in PyMem_RawMalloc /home/foo/Downloads/Python-3.7.0/build/../Objects/obmalloc.c:503:12
#2 0x7fa495cc0edc in _PyObject_Malloc /home/foo/Downloads/Python-3.7.0/build/../Objects/obmalloc.c:1560
#3 0x7fa495cc0edc in pymalloc_realloc /home/foo/Downloads/Python-3.7.0/build/../Objects/obmalloc.c:1882
#4 0x7fa495cc0edc in _PyObject_Realloc /home/foo/Downloads/Python-3.7.0/build/../Objects/obmalloc.c:1901
Indirect leak of 128 byte(s) in 2 object(s) allocated from:
#0 0x5175d8 in operator new(unsigned long) /usr/people/shared/tools/centos/6/llvm/build_files/6.0.0/llvm/projects/compiler-rt/lib/asan/asan_new_delete.cc:92
#1 0x7fa4bd3412ec in catalyst_conduit::Node::Node() (/usr/people/shared/tools/centos/7/catalyst/HPCX/2.0.0/lib64/libcatalyst.so.3+0x722ec)
#2 0x6080000655d7 (<unknown module>)
Indirect leak of 15 byte(s) in 1 object(s) allocated from:
#0 0x442558 in __strdup /usr/people/shared/tools/centos/6/llvm/build_files/6.0.0/llvm/projects/compiler-rt/lib/asan/asan_interceptors.cc:423
#1 0x7fa4b254713e (<unknown module>)
SUMMARY: AddressSanitizer: 5555974 byte(s) leaked in 3475 allocation(s).
```
```
cmake /usr/people/shared/tools/centos/7/paraview/installer/src/paraview/Examples -DCMAKE_BUILD_TYPE=ASAN -DOPENGL_xmesa_INCLUDE_DIR:PATH=IGNORE -DOPENGL_gl_LIBRARY:FILEPATH=IGNORE -DOSMESA_INCLUDE_DIR:PATH=$MESA_INC -DOSMESA_LIBRARY:FILEPATH=$MESA_LIB/libOSMesa.so -DCMAKE_INSTALL_PREFIX="/work/foo/cases/053_Catalyst_Standalone/001_Polyhedra/install/"
cd Catalyst2/CxxPolyhedra
make install
```
```
cmake /usr/people/shared/tools/centos/7/paraview/installer/src/paraview/Examples -DCMAKE_BUILD_TYPE=ASAN -DOPENGL_xmesa_INCLUDE_DIR:PATH=IGNORE -DOPENGL_gl_LIBRARY:FILEPATH=IGNORE -DOSMESA_INCLUDE_DIR:PATH=$MESA_INC -DOSMESA_LIBRARY:FILEPATH=$MESA_LIB/libOSMesa.so -DCMAKE_INSTALL_PREFIX="/work/foo/cases/053_Catalyst_Standalone/001_Polyhedra/install/" -DCMAKE_CXX_FLAGS_ASAN="-g -O3 -DNDEBUG -DASAN_ENABLED -fsanitize=address -fno-omit-frame-pointer"
```
```
./build/bin/CxxPolyhedraV2 catalyst_pipeline.py
```
[catalyst_pipeline.py](/uploads/939c786c80b9afd83b0d490c28067551/catalyst_pipeline.py)Spiros TsalikisSpiros Tsalikishttps://gitlab.kitware.com/paraview/paraview/-/issues/22436Aggregate Dataset Filter crashes in Catalyst2024-01-04T19:35:22-05:00W. Alan ScottAggregate Dataset Filter crashes in CatalystThe Aggregate dataset filter (I incorrectly reported as Redistribute Data Set Filter) is crashing in Catalyst API 1. Here is how to replicate.
* Run ParaView 5.11.0, remote server (16 ranks), Linux.
* Open g1s1. Apply.
* Merge Blocks. ...The Aggregate dataset filter (I incorrectly reported as Redistribute Data Set Filter) is crashing in Catalyst API 1. Here is how to replicate.
* Run ParaView 5.11.0, remote server (16 ranks), Linux.
* Open g1s1. Apply.
* Merge Blocks. (Aggregate dataset filter does not take multiblock data.)
* Aggregate dataset Filter. Number of target processes: 4. Apply.
* Extracts/ png.
* File/ Save State. Save as junkState.py file.
* pvbatch - I believe 16 ranks. junkState.py file.
* There will be a movie output of .png images.
* Going back to ParaView,
* File/ Save Catalyst State File
* Use this as the controlling script for a Catalyst run. This is primarily on Sparc, but has also been seen on Sierra.
* This will crash with an MPI error.
Note we don't think this is an MPI version issue, as other MPI areas of Catalyst work correctly.
I can't find a trace from Jeff, ask if needed.
As LANL has not seen this issue, this may need to be debugged at Sandia.
Contact is Jeff Mauldin.5.12.1 (Spring 2024)https://gitlab.kitware.com/paraview/paraview/-/issues/22358Catalyst: Need support for optionally creating meshes and/or variables in Con...2023-12-11T12:09:45-05:00Berk GeveciCatalyst: Need support for optionally creating meshes and/or variables in ConduitCurrently, every time Catalyst is called, it is expected that the simulation populates the Conduit data structures for ParaView to consume. This means that even if there are extractors with frequencies > 1 per time step, data is being co...Currently, every time Catalyst is called, it is expected that the simulation populates the Conduit data structures for ParaView to consume. This means that even if there are extractors with frequencies > 1 per time step, data is being converted every time, which may be costly. Even though it is possible to manage the frequency on the simulation side, this reduces the usefulness of having a frequency parameter for the extractors. Furthermore, different pipelines/extractors may need different meshes and/or variables and the current implementation is all or nothing because ParaView has no means to communicate what it needs to the simulation adaptor populating the Conduit tree.
@acbauerhttps://gitlab.kitware.com/paraview/paraview/-/issues/22334Image comparisons for Catalyst examples.2024-03-16T15:42:52-04:00Christos TsolakisImage comparisons for Catalyst examples.It would be nice to have image tests for catalyst 2.0 examples like we do for other parts of VTK and ParaView. Since these examples are build as external projects it is not clear to me how (and if) we can access the image comparison util...It would be nice to have image tests for catalyst 2.0 examples like we do for other parts of VTK and ParaView. Since these examples are build as external projects it is not clear to me how (and if) we can access the image comparison utilities from VTK.https://gitlab.kitware.com/paraview/paraview/-/issues/22140Particle Tracer fails to produce exploitable data in an in situ environment2023-05-17T16:24:53-04:00Yohann Bearzi (Kitware)Particle Tracer fails to produce exploitable data in an in situ environmentThe filter `Particle Tracer` (implementation is mostly in `vtkParticleTracerBase` in VTK) has a parameter `DisableResetCache` which is supposed to allow to run the filter in situ, i.e. a mode where each call to `UpdateTimeStep(double t)`...The filter `Particle Tracer` (implementation is mostly in `vtkParticleTracerBase` in VTK) has a parameter `DisableResetCache` which is supposed to allow to run the filter in situ, i.e. a mode where each call to `UpdateTimeStep(double t)` outputs a dataset at time `t`. However the filter fails to produce satisfactory outputs in this context.
There are a few reasons:
* Instead of relying on `vtkStreamingDemandDrivenPipeline::UPDATE_TIME_STEP()` to acquire the current time step, the filter gets the current timestep through `vtkDataObject::DATA_TIME_STEP()`, which is not correctly populated in the context I was running the filter (I will share the script below)
* When above point is fixed (correctly setting the timestep), one can get the expected output in situ, but there is a memory leak that originates from a mishandling of the attribute `vtkParticleTracer::FirstIteration`. It gets set to true and triggers a memory leaking path. If the attribute is left untouched, the output is wrong once again.
* The handling of `RequestInformation` and `RequestUpdateExtent` is questionable. They are setting a bunch of internal variables with a complicated algorithm which make it hard to untangle.
The Catalyst script [cata.py](/uploads/59ebea8702e3f9c74418441517871335/cata.py) I am using to test this is run using the `CxxFullExample` in ParaView. It runs a pipeline where one traces a particle on a random vector field. The script should output for each file a growing polyline.
Here is the patch [particle_tracer.diff](/uploads/caff78d253386b45e3ec7e69d0c58ee1/particle_tracer.diff) allowing to get a correct output with a leak. It needs to be used on top of vtk/vtk!10104 and paraview/paraview!6292
The filter should be refactored to make it work correctly in situ without leaking. In addition, it should rely on the key `vtkStreamingDemandDrivenPipeline::INCOMPLETE_TIME_STEPS()` instead of the manual parameter `DisableResetCache`.
There might be issues to discuss regarding backward compatibility. I have little faith we would be able to maintain it upon refactoring.https://gitlab.kitware.com/paraview/paraview/-/issues/22136Using Time Manager crashes Paraview when connected to Catalyst2023-11-08T21:11:22-05:00Louis GombertUsing Time Manager crashes Paraview when connected to CatalystHello, I have randomly found a crash in Paraview nightly build, which has to do with the time manager.
Here are the steps reproduce the crash :
- Open a time-varying dataset (for example `can.ex2`)
- Click on `Apply` to view it in th...Hello, I have randomly found a crash in Paraview nightly build, which has to do with the time manager.
Here are the steps reproduce the crash :
- Open a time-varying dataset (for example `can.ex2`)
- Click on `Apply` to view it in the main render view
- Display the new time manager (View > Time Manager)
- Start Catalyst (Catalyst > Connect)
- change the time to 0.11111 (for can.ex2) in the Time Manager using the drop-down menu
- manually change the view orientation in the render view using the mouse
- Click on the settings wheel of the time manager on the right of the panel
At this step, Paraview segfaults.
Environment : Linux Mint 21.1 x86_64, on latest binary Paraview nightly build
I can provide more information if needed.https://gitlab.kitware.com/paraview/paraview/-/issues/22109Provide option to disable automatic extractions when catalyst_execute is called2023-11-08T21:12:52-05:00Alexandre MinotProvide option to disable automatic extractions when catalyst_execute is calledTake the following python code from a possible ParaView Catalyst user script:
```
def catalyst_execute(info):
SaveExtractsUsingCatalystOptions(options)
```
This script will have extractors triggered twice. Once by the `SaveExtracts...Take the following python code from a possible ParaView Catalyst user script:
```
def catalyst_execute(info):
SaveExtractsUsingCatalystOptions(options)
```
This script will have extractors triggered twice. Once by the `SaveExtractsUsingCatalystOptions(options)` call, and once automatically by `internals.ExtractsController->Extract(internals.Extractors);` from `bool vtkCPPythonScriptV2Helper::CatalystExecute()`.
Could an option be provided to disable the second extract?
A bit of background as to why a user might want to manually trigger extractions. I my case, I use a for loop inside `def catalyst_execute` to show / save / hide objects in a single renderView. After my for loop, I get an unwanted write from the `internals.ExtractsController->Extract(internals.Extractors)`.
Many thanks,
Alexandrehttps://gitlab.kitware.com/paraview/paraview/-/issues/21767mesa (OSMesa) crashes with core dump in some cases (intel compiler) when buil...2023-12-06T14:36:08-05:00Jeff Mauldinmesa (OSMesa) crashes with core dump in some cases (intel compiler) when built with paraview-superbuild 5.11.0@cory.quammen @ben.boeckel @wascott
I have seen the issue I am about to describe on two different platforms at SNL, the cee platform and the ats1 HPC (mutrino). _Not_ on tlcc2 or cts1, where it looks like the same intel compiler versio...@cory.quammen @ben.boeckel @wascott
I have seen the issue I am about to describe on two different platforms at SNL, the cee platform and the ats1 HPC (mutrino). _Not_ on tlcc2 or cts1, where it looks like the same intel compiler version as ats1.
The issue is that I build ParaView/Catalyst 5.11.0 with superbuild, including osmesa for catalyst and then when I run catalyst I get a core dump. When I run the program via gdb I see that the location of the seg fault is in mesa.
When I build with the "module load sierra-devel" module, which uses the gcc compiler, I get no error. When I build with the "module load sierra/daily" module, which uses the intel compiler, I get this issue. Similarly, on ats1/mutrino, I get this error when I build with the "module load sierra-devel" (or other) module, which uses the intel compiler. When I additionally set the CC and CXX environment variables to point to gcc and g++ before building, I do not get the error.
In fact, on cee I can take the working libOSMesa.so from the sierra-devel build and drop it into the sierra/daily build and it works. I can get away with this because although the two setups use different mpi libraries, the libOSMesa doesn't use MPI and so doesn't create a confict.
Several observations:
The "broken" libOSMesa.so is about 21 megabytes in size, while the working one is about 19 megabytes in size on the cee platform.
I thought it might be problem with this particular mesa version, but we use the same mesa version in paraview 5.10.1 and it works (!).
On the cee platform, I can see significant differences between the osmesa ninja build file, one of which is that the working one (I think) specifies the use of OPENMP (not mpi, the parallel code thing I think), while the broken one does not. I'm talking about the .../superbuild/osmesa/src/build/build.ninja file which gets generated while configuring the osmesa build.5.12.1 (Spring 2024)https://gitlab.kitware.com/paraview/paraview/-/issues/21744Currently generated ParaView Catalyst Python scripts have no way to modify fi...2023-02-02T09:57:36-05:00Andrew BauerCurrently generated ParaView Catalyst Python scripts have no way to modify filter parameters during calls to CatalystI tested out the ability to set filter properties for Catalyst scripts that vary in time (e.g. having a slice filter output rotate as the simulation proceeds). With the currently GUI generated Catalyst Python scripts (using master on Ja...I tested out the ability to set filter properties for Catalyst scripts that vary in time (e.g. having a slice filter output rotate as the simulation proceeds). With the currently GUI generated Catalyst Python scripts (using master on Jan 18, 2023) the pipeline is created once by Catalyst and not called again. Try out the attached newslice.py script where I've added print statements. If sources in the pipeline were updated every in situ output then the print statement would be called. It would be good for users to be able to edit the GUI generated Catalyst Python scripts to allow filter properties to be updated during every Catalyst output step.
If I modify the Examples/Catalyst/SampleScripts/gridwriter.py script (also attached) and edit the DoCoProcessing() method I can get the slice normal to change with time. This gridwriter.py is the "old style" Catalyst script though and not generated through the GUI.
I think if there was some optional UpdateProperties() like method that was added to the Catalyst scripts where users could modify properties that would be a way to get around this issue. Here, UpdateProperties() would be called every time Catalyst was outputting extracts, images,etc.
[gridwriter.py](/uploads/f9326ff8e208a8cb13341c8dae416547/gridwriter.py)
[newslice.py](/uploads/e352eb44a96e301e1fa28ab56ef1bdbb/newslice.py)5.13 (Summer 2024)https://gitlab.kitware.com/paraview/paraview/-/issues/21742Optionally set state using dictionaries in traces and state files2024-03-26T13:44:10-04:00W. Alan ScottOptionally set state using dictionaries in traces and state filesAdd the option to set state using dictionaries in traces, ParaView python state and Catalyst state files. Make this option default off. An example was created by Cory as an original file and one using dictionaries. I will add the two ...Add the option to set state using dictionaries in traces, ParaView python state and Catalyst state files. Make this option default off. An example was created by Cory as an original file and one using dictionaries. I will add the two examples to this bug.5.13 (Summer 2024)https://gitlab.kitware.com/paraview/paraview/-/issues/21722Catalyst: two data pipes with two different scripts fails in coprocessing.py2024-03-27T10:37:25-04:00Jeff MauldinCatalyst: two data pipes with two different scripts fails in coprocessing.pyWhen using Catalyst, users will sometimes want to create different datasets to be sent to different catalyst python scripts. For example, in SPARC users might send surface/wall data to one script and volume/airflow data to a different sc...When using Catalyst, users will sometimes want to create different datasets to be sent to different catalyst python scripts. For example, in SPARC users might send surface/wall data to one script and volume/airflow data to a different script.
In ParaView 5.10 and 5.11.0 this capability fails. It worked in 5.9. The problem is in coprocessort.py. I am attaching my altered coprocessor.py which works. You can diff with the 5.11.0 Wrapping/Python/paraview/coprocessing.py to see the changes I had to make to get it to work. I don't insist on exactly these changes, but our ioss catalyst test suite (that Ben Boeckle can run on SNL HPCs like vortex and eclipse) will need to pass the related two pipe/two script tests.[coprocessing.py](/uploads/c9acb4266c3c5bf9d08ccf1edc931abc/coprocessing.py)
I also undid a change which disallowed multiple data pipes to have the same name. In our sierra catalyst implementation we have been using the same name ("input") for all incoming data pipes and it has worked fine. I don't absolutely have to have the capability to give multiple pipes the same name, but it would be nice to be warned formally about the change.5.11.1 (Winter 2023)https://gitlab.kitware.com/paraview/paraview/-/issues/21648Save Screenshot fails in Catalyst trace.2024-03-07T20:23:54-05:00W. Alan ScottSave Screenshot fails in Catalyst trace.My user created a Catalyst State file. It created three renderviews. He did an extract image for each of the renderviews, which worked correctly. Next, he used a trace to get the commands to save screenshot for all three renderviews a...My user created a Catalyst State file. It created three renderviews. He did an extract image for each of the renderviews, which worked correctly. Next, he used a trace to get the commands to save screenshot for all three renderviews at one time, cut and pasted that into the Catalyst State file, and ran that. Catalyst said the .png could not be written.
Error was:
```
[pvbatch.0 ] vtkPNGWriter.cxx:254 ERR| vtkPNGWriter (0x2a144d20): Unable to open file ./catalyst_output/panel_
{timestep:06d} {camera}
.png
[pvbatch.0 ] vtkImageWriter.cxx:481 ERR| vtkPNGWriter (0x2a144d20): Ran out of disk space; deleting file(s) already written
```5.13 (Summer 2024)