Paraview Reader Plugin is hanging on file open

(Andrey ) #1

Hello all,

I have written and AMR reader (inheriting from the vtkAMRBaseReader) for our in house code, but I cannot get Paraview to open the files.

I have compiled it two ways using the plugin and building and directly into VTK and updating the readers.xml file accordingly. But every time I try to open a file, it hangs. I put print statements in the SetFileName routine just to see if it even gets to that step and nothing gets printed out. I’m at a total loss since I don’t even have a way to debug it. Has anyone out there had a similar problem or know how to fix it?

Thank you

(Cory Quammen (Kitware)) #2

Could you provide some more details about how you are building the plugin and with what version of ParaView you are using, if you are using the binary from or have built your own, operating system as well.

(Andrey ) #3

Hi @cory.quammen

Yes, I am building my own version of paraview 5.6 and then having the Find_Package(paraview) find that version. I have also taken the source of paraview and added my C++ classes into VTK/IO/AMR and then modified the readers.xml in the ParaviewCore. I am building the server on linux (building with GUI components off and using OSMESA for off screen rendering) and then connecting via client server mode to it using both windows and linux binaries.

I have tested the reader using C++ code by giving it the filename and calling the Update routine and printing out the data structure. The results seem to be working so I’m suspecting my mistake is in my limited understanding of how the xml connections work in Paraview.

My xml and CMakeLists is attached. If you would like the source code as well, I can provide it to you as well.

Thank you very much for your response!

CMakeLists.txt (445 Bytes)
VelodyneAMRReader.xml (6.8 KB)
VelodyneAMRReaderClient.xml (108 Bytes)

(Andrey ) #4

Also, is there a good way to run pvserver in debug mode so I can at least have an idea where it’s hanging. Because right now the only thing I know is it’s before the SetFileName routine. But other that I’m completely stuck. Any help would appreciated

Thank you

(Mathieu Westphal) #5

Can you build paraview in Debug and run pvserver with gdb ?

(Andrey ) #6

Hi guys,

Thank you for the responses. So I have a new development with slightly more information. I set the PV_PLUGIN_DEBUG to 1 and I get the following reassuring message when I start the server:

loaded shared library successfully. Now trying to validate that it’s a ParaView plugin.
Plugin’s signature: paraviewplugin|GNU|5.6
Plugin signature verification successful. This is definitely a ParaView plugin compiled with correct compiler for correct ParaView version.

However, the second I connect to the server from the client side, I get the following messages (It let’s me connect just fine without having the PV_PLUGIN_DEBUG=1):

Server Side:
PV_PLUGIN_PATH: /opt/Software/paraview/corvid_readers/velAMR/5.6ERROR: In /home/shelf1/compile/visualization/src/paraview/VTK/Parallel/Core/vtkSocketCommunicator.cxx, line 808
vtkSocketCommunicator (0x218cdd0): Could not receive tag. 1

ERROR: In /home/shelf1/compile/visualization/src/paraview/VTK/Common/System/vtkSocket.cxx, line 567
vtkClientSocket (0x218cc60): Socket error in call to send. Broken pipe.

Client Side:
Wrong tag but don’t know how to handle it… 188971
Aborted (core dumped)

Has anyone encountered something like this before?

Sorry for posting feverishly on this post, this is just the last step in getting our code to work with Paraview, so I’m a bit desperate. Thank you all.

(Cory Quammen (Kitware)) #7

@Aandreyev The errors indicate there is a mismatch in expected sockets operations between the client and server. Are you loading the plugin on the server side as well? You need to.

(Andrey ) #8

Thanks @cory.quammen,

But it turned out that I had made a typo in the plugin by mistyping the content of the vtkTypeMacro. It compiled just fine, but was causing the hang. I am now working through some parallel issues on certain AMR meshes where it doesn’t look like the multiprocess controller isn’t dividing the mesh up.