With the new build system having landed, we’ve discussed internally what is to happen with the Catalyst Editions. The catalyze.py has not been updated for the new CMake code and after discussion of what should happen with it, we’ve decided to not do the work to update catalyze.py for the Spring release (5.7) in favor of a better solution for the Fall release (5.8).
Plan for Fall 2019
The plan going forward is to have a better split of modules within VTK and ParaView to make it easier to maintain for everyone involved. It will be easier for us because it won’t be a radically different source tree with a JSON description of what it should contain and for users because find_package(ParaView) will work for using a Catalyst Edition exactly as it works for everyone else using VTK and ParaView code (e.g., no worry that some class doesn’t exist in a given module that happens today).
For the Fall release, we plan on doing work along the following lines:
Split Reader classes from Writer classes. Since Catalyst Adaptors tend to only need file writers, this can reduce the number of dependencies required for an Adaptor build.
Refine the “grabbag” modules such as FiltersGeneral and ImagingCore into more meaningful modules. Right now, some modules have become the place for classes which do not fit easily in existing modules. The new build system makes it much easier to have narrower modules, so we will work to make that a reality.
This means that Catalyst Editions will essentially become a set of maintained CMake cache files for configuring a stock ParaView source tree to get the required bits. This will also make it easier to include one-off module additions when necessary instead of having to edit a JSON file and restart a build from absolute scratch.
Thanks for the update! I’ve certainly had a love/hate relationship with the Catalyst editions. Love to use them on some of the HPC systems when I don’t want to use all of the ParaView functionality but hated that many commits would unknowingly break Catalyst editions.
+1 to your statement that Catalyst operations tend to only need writes. Just this past week I was working on some in situ stuff though where statistical output is needed and the simulation code has a restart capability so that means being able to read in the previous in situ statistics output in order to continue the in situ statistics computation. Yes, I suppose we could combine the separate statistics output but that puts more effort on the analyst (and maybe we want to output that information in an image anyway).
Ok I just found this after experiencing build issues for Catalyst on the trunk. I am looking forward to having the new Catalyst CMake system. It would be nice though to have a dedicated tar.gz file with only the Catalyst source files like the way it was as this is much easier to deploy to HPC facilties that are not connected to the internet. Or at least to be able to build the Catalyst from a paraview.tar.gz file without an active internet connection.
In the mean time I will base my Catalyst work off of v5.6.x; currently I am working on creating a CGNS file writer that has to work in Catalyst.
The release source tarballs should certainly be buildable without an active internet connection. AFAIK, the only things requiring that would be the data files for testing which can either be turned off or provided using the ParaViewData tarball.
.
It’s ParaView Editions. I am putting together a blog post to clarify this.