Possible ResampleWithDataset Bug in 5.8.0 Using Intel Compilers

Hi All,

I have two builds of paraview on the same machine. One was built with intel compilers, the other with gcc (see spec below). I’ve built some dependencies prior to the build using spack (hdf5, netcdf-c, python) but have done so using the respective compiler environments. I’m working with the Exodus-II file format, and forcing off-screen rendering.

Problem: If I use the slice filter on the domain, I get the expected result out of both. However, if I place a plane in the domain at the same location as the slice, and use the ResampleWithDataset filter, I find that the Intel-compiled code produces very unexpected results.

I’m launching the servers the exact same way, using a different server-port for each:
mpirun -np 8 ./pvserver --force-offscreen-rendering --mpi

I’ve also put my “Remote Render Threshold” to zero to ensure that rendering is taking place on the server machine.

If it’d be helpful, I can upload CMakeCache.txt files for each. Below are the flags I’m passing to CMake:

-DCMAKE_CXX_FLAGS:STRING='-Wl,--copy-dt-needed-entries'
-DCMAKE_C_FLAGS:STRING='-Wl,--copy-dt-needed-entries'
-DBUILD_TESTING:BOOL=OFF
-DCMAKE_BUILD_TYPE_paraview:STRING=Release
-DCMAKE_INSTALL_PREFIX:PATH=" + somewhere)
-DENABLE_paraviewsdk:BOOL=ON
-Dsuperbuild_download_location:PATH=" + somewhere)
-Dparaview_SOURCE_SELECTION:STRING=git
-Dparaview_GIT_TAG:STRING=v5.8.0
-Dparaview_SOURCE_DIR:PATH=" + somewhere)
-DENABLE_vtkm:BOOL=OFF
-DENABLE_python:BOOL=ON
-DENABLE_python3:BOOL=ON
-DUSE_SYSTEM_python3:BOOL=ON
-DENABLE_paraview:BOOL=ON
-DENABLE_png:BOOL=ON
-DENABLE_osmesa:BOOL=ON
-Dmesa_USE_SWR:BOOL=OFF 
-DENABLE_ospray:BOOL=ON
-DBUILD_SHARED_LIBS:BOOL=ON
-DBUILD_SHARED_LIBS_paraview=OFF
-DENABLE_mpi:BOOL=ON
-DPARAVIEW_USE_MPI:BOOL=ON
-DUSE_SYSTEM_mpi:BOOL=ON
-DENABLE_zlib:BOOL=ON
-DUSE_SYSTEM_zlib:BOOL=ON
-DENABLE_hdf5:BOOL=ON
-DUSE_SYSTEM_hdf5:BOOL=ON
-DENABLE_netcdf:BOOL=ON
-DUSE_SYSTEM_netcdf:BOOL=ON
-DPARAVIEW_ENABLE_MOTIONFX:BOOL=OFF
-DPARAVIEW_EXTRA_CMAKE_ARGUMENTS='-DVTK_MPI_NUMPROCS=4;-DVTK_MODULE_ENABLE_ParaView_PythonCatalyst=YES;-DVTK_MODULE_ENABLE_ParaView_Catalyst=YES;-DVTK_MODULE_ENABLE_ParaView_cgns=NO;-DVTK_MODULE_ENABLE_ParaView_VTKExtensionsCGNSReader=NO;-DVTK_MODULE_ENABLE_ParaView_VTKExtensionsCGNSWriter=NO'

Does anyone have any ideas or thoughts? Thanks so much for your time!

Oh and I also have another build on another machine (also using Intel 19.0.3.199) that does the same thing, but has SWR enabled. This came up in another topic trying to troubleshoot ResampleWithDataset in parallel using Catalyst, but it really seems like a separate issue. In the image below, “Remote” is the server running the Intel compiled pvserver.

Lets try to isolate the issue.

  1. Let’s try to reproduce the issue with as few pvserver ranks as possible. Ideally 1 or 2. If it’s a interpolation bug, it should show up with just a single rank. If it’s a data-exchange bug, it should show up with 2 ranks. Also keep the plane as small as possible to reproduce the issue too. That will make it easier to debug.
  2. Once the issue has been reproduced on the lowest set of ranks (and plane size), save the data in suitable vtk xml file. Let’s confirm that now if you open this data file in a gcc build (aka working), you still see the bug. This will confirm that it’s not a rendering issue but indeed a bug with the filter.

Thanks Utkarsh!

Single rank server produces the same output as the multiple rank server. This is a 50x50 resolution plane.

Saving as a .vtk file and opening on the gcc server, also single rank, gives the same output as well.

Interestingly if I set the plane resolution to the grid resolution (60x60 in y-z), output gets even more regular.

…and the same of 0.5x the grid resolution

Also I should say that I haven’t found any other obvious problems with the intel build…i.e. gradients, contouring with Q-Criterion, and more…all seem fine.

Another thing I tried was running the point->cell data filter before resampling, but that doesn’t change the output.

And finally, if I use the ResampleToImage filter at a resolution of 120x30x30, and then slice at the same location, I get something similar (below).

Thanks, @nate_develder. Thanks for narrowing down the issue. I’ve reported a bug here. I unfortunately don’t have much insight into why this would be happening, but definitely warrants some debugging.