I’ve built the CATALYST_RENDERING edition of Paraview 5.8 using the superbuild (rendering with off-screen mesa), and am successfully using it in conjunction with a software package to output slices to png during a simulation. I recently exported a catalyst script that uses the ResampleWithDataset filter instead of slicing, and now the script crashes.
To add to the picture, the stack trace ends with vtkPResampleWithDataset calling libvtkFiltersParallelDIY2-pv5.8-so.1. If I run on a single core, I don’t have issues…presumably because the serial version of ResampleWithDataset is being called?
Is anyone aware of this as an issue, or is this more likely to be a misconfiguration on my end between system openmpi and my Paraview build? Without getting into build troubleshooting, does anyone have any suggestions for starting points on tracking this down?
On a related note, is there a reference that defines the cmake defaults (or a feature list etc.) for the build editions?
UPDATE: I built another Paraview 5.8 without passing a build edition, verified that my catalyst scripts work both for slicing and single-core ResampleWithDataset, and that parallel ResampleWithDataset still crashes. I’m leaning toward this being a bug and deserving a report?
I ran with gdb on 2 processes and this is where it choked:
Thread 1 "naluX" received signal SIGSEGV, Segmentation fault.
0x00002aab203098d1 in (anonymous namespace)::RegularPartition::FindPointsInBounds(double const*, std::vector<(anonymous namespace)::Point, std::allocator<(anonymous namespace)::Point> >&) const ()
from /myhome/pv_install/install_pv_58_nalu_jul2020/catalyst/lib/libParaViewCatalystIossAdapter.so
And the “FindPointsInBounds” method does exist in vtkPResampleWithDataSet.cxx
Maybe I should move this over to the VTK discourse site?
Indeed seems like bug. As a first step, what I’d try to do is save out the data from the simulation in a dataset that be loaded in post-processing and then attempt to reproduce with a parallel pvserver. Is that reproducible? Is so that’d make it easier to track down the issue.
Thanks for the replies! Sorry for my slow response. I followed your advice and connected to the cluster after launching pvserver on a single core, and then on four cores. Unfortunately, the picture gets even murkier.
The “good” news is that neither the serial nor the parallel instances crash applying the ResampleWithDataset filter. Does this imply that there is an issue with our adaptor code and not with vtk/paraview?
The bad news is that the output (both serial and parallel, both decomposed and reconstructed case) are sampled in a way that produces a bunch of strange artifacts, the size of the artifacts being related to the dimensions of the recipient plane. I’m guessing this is an entirely separate issue and I’ll check bug reports and post about it some other time?
The simulation uses the Exodus-II file format if that is relevant. I’ve attached screenshots, all using the same simulation output files…the local ResampleWithDataset image was produced with a Windows version of 5.8.0. The rest are from my build on the cluster.
Any of this provide clues to where the issue might be? I’m still open to the possibility that there’s something off with my build. Verification of the initial catalyst-parallel-ResampleWithDataset issue from someone who isn’t me would probably be a good thing?
FYI: I’ve posted the artifact problem in the development section. It seems as though it is an issue of some difference between Intel and Gcc builds.
I’ll get my simulation code set up on the machine that has the Gcc build to see if the parallel-Catalyst-ResampleWithDataset issue happens in that build too.
