Issue with the Catalyst2/CxxImageDataExample

In Situ Support
1

When I run the Catalyst2/CxxImageDataExample with the following script I’m getting errors with ParaView master.

# script-version: 2.0
# Catalyst state generated using paraview version 5.9.0

#### import the simple module from the paraview
from paraview.simple import *
#### disable automatic camera reset on 'Show'
paraview.simple._DisableFirstRenderCameraReset()

# ----------------------------------------------------------------
# setup the data processing pipelines
# ----------------------------------------------------------------

# create a new 'Wavelet'
grid = TrivialProducer(registrationName='grid')

# ----------------------------------------------------------------
# setup extractors
# ----------------------------------------------------------------

# create extractor
vTI1 = CreateExtractor('VTI', grid, registrationName='VTI1')
# trace defaults for the extractor.
# init the 'VTI' selected for 'Writer'
vTI1.Writer.FileName = 'grid_%.6ts.pvti'

# ----------------------------------------------------------------
# restore active source
SetActiveSource(vTI1)
# ----------------------------------------------------------------

# ------------------------------------------------------------------------------
# Catalyst options
from paraview import catalyst
options = catalyst.Options()
options.GlobalTrigger = 'TimeStep'
options.CatalystLiveTrigger = 'TimeStep'

# ------------------------------------------------------------------------------
if __name__ == '__main__':
    from paraview.simple import SaveExtractsUsingCatalystOptions
    # Code for non in-situ environments; if executing in post-processing
    # i.e. non-Catalyst mode, let's generate extracts using Catalyst options
    SaveExtractsUsingCatalystOptions(options)

The error I’m getting is:

(   2.440s) [pvbatch         ]vtkCompositeDataPipelin:155    ERR| vtkPVCompositeDataPipeline (0x22c9720): Can not execute simple algorithm vtkXMLPImageDataWriter without output ports
2

Remember the Catalyst2 always produces vtkPartitionedDataset (or recently vtkParitionedDataSetCollection). VTI is not the supported output format for that. You need to use vtpd (or vtpdc), if I recall the extensions correctly.

3

Okay, a couple of things are confusing here:

  • The example should probably be named something like CxxPartitionedImageDataExample or something like that, instead of CxxImageDataExample.
  • The comment at the top of FEDriver.cxx is the following but needs to be updated to be specify that the output is not an unstructured grid but a vtkPartitionedDataset of vtkImageDatas:
// Example of a C++ adaptor for a simulation code
// where the simulation code has a fixed topology
// grid. We treat the grid as an unstructured
// grid even though in the example provided it
// would be best described as a vtkImageData.
// Also, the points are stored in an inconsistent
// manner with respect to the velocity vector.
// This is purposefully done to demonstrate
// the different approaches for getting data
// into Catalyst. Note that through configuration
// that the driver can be run without linking
// to Catalyst.

Also, I created a Catalyst script called mywriter.py (1.8 KB) through the ParaView GUI that uses a VTPD writer and it isn’t working in parallel for this example. The meta-file is wrong for the file index attribute (note that I ran this with 4 MPI processes):

    <DataSet index="0" file="grid_000000/grid_000000_0.vti"/>
    <DataSet index="1" file="grid_ RangeMin="0" RangeMax="0">

After this I looked to see if there are any Catalyst V2 tests that aren’t driven by pvpython or pvbatch but instead driven by something that looks like a simulation code and couldn’t find any. It was only a brief check so maybe I’m wrong on this. In any case, I strongly believe a set of Catalyst V2 tests need to be included in ParaView that are built only against the Catalyst API but run against ParaView Catalyst. To say it a different way, the test executable CMake code shouldn’t have any find_package(ParaView ...) in it, only find_package(catalyst ...). I can create a gitlab issue for this if needed.

4

Indeed. For the most part there were just a quick copy paste of the older examples as I was rushing to get stuff done to wrap up the Catalyst 2.0 initial work last year. Cleanups are indeed in order.

5

There’s a better solution for Catalyst 2.0. See !4532. Specifically, this commit.
This avoids dependence on Python entirely and hence more flexible.

6

I’m not so sure that that’s a better solution. We had a non-Python full grid output mechanism for Catalyst 1.0 in the ParaView: vtkCPXMLPWriterPipeline Class Reference class and I don’t know of anyone that actually used it. The gridwriter.py script was very simple and worked the same way that other things worked in Catalyst and so users weren’t required to remember other command line arguments and special strings to output their full data. All they had to remember was an output frequency and that was something that they were used to dealing with already with Catalyst workflows. So IMO simplicity is the way to go here. Redundancy isn’t bad in this situation either in having a Python solution that many folks, myself included, will be very happy with and a non-Python solution.

7

I am utterly confused. Is there any use-case that gridwriter.py solves that the builtin in pipeline doesn’t? If not, I don’t see any need to support a Python version. Furthermore, this version of the hardcoded pipeline is even better than the vtkCPXMLWriterPipeline since it handles all supported writers. Also, vtkCPXMLWriterPipeline needed explicit support to be built into the adaptor. This is no longer the case with the hardcoded pipelines. It’s just a matter of passing a different json.

8

We used the defacto, simple write_vtm.py (gridwriter.py equiv) as an example of the most simple ParaView Catalyst script with some simple options like compression. It seems that if Catalyst 2.0 contains an option to simply write a simple dataset, the next example we supply to users would be the same thing with some extra controls and maybe a simple pipeline that generates ghost cells → Cell to Point → aggregate → write data. I guess the first tutorial would use the initial dump with the builtiin writer to produce the more advanced python catalyst script. This would be more simple than bundling a python script that is required on the initial run for some user. That said, I think there is some value in Andy’s request as it provides a (the most simple) example of a catalyst script. --John’s 2 cents.