View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0002971 | OpenFOAM | Bug | public | 2018-06-04 16:37 | 2018-06-27 08:30 |
Reporter | joseph@n04-138.net | Assigned To | chris | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Platform | OpenFOAM 5.0 in Docker Container | OS | Ubuntu | OS Version | 16.04 LTS |
Summary | 0002971: OpenFoam Docker with pvserver to remote paraview | ||||
Description | I have been using native OpenFOAM on Ubuntu server for several years. We just added a few more large servers and have transitioned to use OpenFOAM in a Docker Container. The host is a 32 processor / 256GB RAM host with lots of disk space. I have installed OpenFOAM Docker per the instructions. I have run the demos and they all work fine. We do not have X-11 on the server - it is a compute host only. The issue I am having is traversing out of the docker container to remote hosts with pvserver and paraview. My analysis configuration is a Mac workstation with native paraview thorough a VPN to the server (accessed via ssh only) and then into pvserver running in the docker container. I have read various sites on reverse connection, server port, ... but can not find the correct way to go across the VPN and through to a the docker client with pvserver. It seems like it should be trivial but I can't find a solution. Any suggestions are appreciated. Joe. | ||||
Steps To Reproduce | Open OpenFOAM docker session and run pvserver with various options. Attempt client server connection from remote paraview session. | ||||
Additional Information | Using Mac OSX native version of paraview 5.4.0 and 5.0 version of OpenFOAM docker from the download site. | ||||
Tags | docker, paraview, pvserver, ubuntu | ||||
|
I was able to get traverse the network with the following command in the docker container: pvserver -rc --client-host=XXX.XXX.XXX.XXX --server-port=PPPP --use-offscreen-rendering where XXX.XXX.XXX.XXX is the IP address and PPPP is the port number. The server side gives the following error: Connecting to client (reverse connection requested)... Connection URL: csrc://XXX.XXX.XXX.XXX:PPPP ERROR: In /home/ubuntu/OpenFOAM/ThirdParty-dev/ParaView-5.4.0/ParaViewCore/ClientServerCore/Core/vtkTCPNetworkAccessManager.cxx, line 315 vtkTCPNetworkAccessManager (0x12f2900): Failed to connect to XXX.XXX.XXX.XXX:PPPP ERROR: In /home/ubuntu/OpenFOAM/ThirdParty-dev/ParaView-5.4.0/ParaViewCore/ClientServerCore/Core/vtkTCPNetworkAccessManager.cxx, line 328 vtkTCPNetworkAccessManager (0x12f2900): ********************************************************************** Connection failed during handshake. This can happen for the following reasons: 1. Connection dropped during the handshake. 2. vtkSocketCommunicator::GetVersion() returns different values on the two connecting processes (Current value: 100). 3. ParaView handshake strings are different on the two connecting processes (Current value: paraview.5.4.renderingbackend.opengl). ********************************************************************** However, on the paraview client I get the following error: ERROR: In /Users/kitware/buildbot-slave/8275bd07/source-paraview/ParaViewCore/ClientServerCore/Core/vtkTCPNetworkAccessManager.cxx, line 413 vtkTCPNetworkAccessManager (0x60000046fd40): ********************************************************************** Connection failed during handshake. This can happen for the following reasons: 1. Connection dropped during the handshake. 2. vtkSocketCommunicator::GetVersion() returns different values on the two connecting processes (Current value: 100). 3. ParaView handshake strings are different on the two connecting processes (Current value: paraview.5.4.renderingbackend.opengl2). ********************************************************************** I am not sure if this is a compilation error or if it has something to do with the system attempting to render on the headless server. Any thoughts? |
|
@joseph@n04-138.net I removed the IP address and port number from your last message to keep that information private to you. |
|
Another update. I received the following feedback from paraview support: "The bad news is that it looks like your pvserver was built with the OpenGL backend (Current value: paraview.5.4.renderingbackend.opengl) while your client was built with the OpenGL2 backend (Current value: paraview.5.4.renderingbackend.opengl2). These need to both be built with the same backend. OpenGL2 is the modern backend, so I would recommend rebuilding pvserver with the OpenGL2 backend and trying again." The suggestion is to rebuild paraview/pvserver ... in the docker distribution from openfoam.org so that it is compatible with the standard OSX paraview releases. Just to verify I installed the Mac docker openfoam version on my Mac and ran it locally. I used openfoam5-macos -p and then ran pvserver in the docker instantiation on the Mac. When I linked back to the Mac native paraview it gave me the same OpenGL version error. As far as I can tell the paraview/pvserver in the standard docker release of openfoam5 does use a different version of OpenGL. Are there any suggestions on how to recompile paraview/pvserver in the docker container to use the OpenGL2 version rather than the version it was compiled with? Thanks - Joe. |
|
The Docker build uses the paraviewopenfoam54 packs for Ubuntu: https://openfoam.org/download/5-0-ubuntu/ Those packs are built with OpenGL because we find it provides an installation of ParaView that runs under the broadest range of deployments, e.g. on a local machine, via remote desktop, with hardware rendering, with software rendering. With OpenGL2, we find there are version incompatibilities between ParaView libraries and system-installed libraries on Ubuntu (e.g. 16.04) such as VTK, OSMesa and swrast. You could build OpenFOAM and ParaView from sources: https://openfoam.org/download/source/ ... which is configured by default to use OpenGL2. But I would sound a note of caution because of the server relying on software rendering, which involves the issue of library incompatibilities. For post-processing large parallel data sets, we look for solutions that do not require massive GBs of RAM for visualisation that vastly exceeds the need for running the CFD. We therefore concentrate on maintaining and developing the automated, parallelised post-processing tools which can generate VTK files of patch surfaces, isosurfaces, cutting planes and streamlines which can then be processed cheaply in serial in ParaView: https://cfd.direct/openfoam/user-guide/post-processing-cli (see 6.2.1.11 Visualisation tools) |
|
ParaView compilation query. No more help can be provided from the OpenFOAM team. |
Date Modified | Username | Field | Change |
---|---|---|---|
2018-06-04 16:37 | joseph@n04-138.net | New Issue | |
2018-06-04 16:37 | joseph@n04-138.net | Tag Attached: docker | |
2018-06-04 16:37 | joseph@n04-138.net | Tag Attached: paraview | |
2018-06-04 16:37 | joseph@n04-138.net | Tag Attached: pvserver | |
2018-06-04 16:37 | joseph@n04-138.net | Tag Attached: ubuntu | |
2018-06-05 01:06 | joseph@n04-138.net | Note Added: 0009702 | |
2018-06-05 08:41 | chris | Note Edited: 0009702 | |
2018-06-05 08:45 | chris | Note Added: 0009703 | |
2018-06-06 20:16 | joseph@n04-138.net | Note Added: 0009713 | |
2018-06-07 08:52 | chris | Note Added: 0009717 | |
2018-06-27 08:30 | chris | Assigned To | => chris |
2018-06-27 08:30 | chris | Status | new => closed |
2018-06-27 08:30 | chris | Resolution | open => fixed |
2018-06-27 08:30 | chris | Note Added: 0009835 |