This topic is halfway between general ParaView support in in-situ support, as it involves the generation of in-situ scripts using ParaView.
In recent versions or ParaView (at least 5.6 to current master), the ghost cell generator filter is not accessible (grayed out/inactive), using a multiblock (unstructured) dataset, while I seem to remember being able to access it a year or so ago.
Recently, a colleague had some artifacts using “cell data to point data” with Catalyst in a parallel run, while the issue did not appear with the EnSight reader (our Catalyst scripts being generated from EnSight format inputs in most cases).
Simply forcing a “generate ghost cells” in the Catalyst Python script seemed to do the trick and fix the issue, but I am unable to find/remember why the filter cannot be accesses from the ParaView GUI, even when not needed, so as to make it easier to insert in in Catalyst scripts or VTK scripts generated through the ParaView graphical interface (Qt/desktop in our case).
Is there a reason this filter is not accessible by default ? Is inserting it in an in-situ script a bad solution (i.e. are there hidden issues) ? I could try to force things at the Catalyst adaptor level (in C++), but generating ghost cells may be overkill (and costly) for cases where we simply need a few clips, while it seems needed for more complex operations (cell to point, gradients, streamlines, …)
Alan is correct in that the ghost cell generator doesn’t work with multiblock datasets. It was a bug in the original implementation to allow it to work with multiblock datasets (in parallel it can lock up pvserver or Catalyst and having it work sometimes is not exactly acceptable). If you really want to use the ghost cell generator filter with a multiblock dataset the workflow is to merge the blocks that you want the ghost cells for with the Merge Blocks filter first.
Alan: for your gitlab issue with making the ghost cell generator filter work with multiblock datasets. The thing that you have to be careful about is knowing which blocks are associated with each other in order to produce ghost cells for. That is, what block(s) on process 0 should match up with what block(s) on process 1 for having ghost cells computed, for a 2 MPI process job.
Thanks for the explination. Again, I suspect this will become irrelevant as we move away from multiblock datasets. Or, maybe the issue will just follow us to the next data format?
If all we need to do is to merge the blocs first, that is fine for now. I’ll see about adapting our Catalyst adapter when multiblock does go away. I assume it is safer to wait for for it to go away in the EnSight reader first, so that the structure we use most as original input to generate the pipeline in ParaView is similar to the one coming out of the adapter ?