[Paraview] Particles-in-Cells: Two XDMF files?
Hi ParaView mailing list, we are adding paraview/xdmf support to our particle-in-cell code PIConGPU [1] right now. To start with the general topology: The particle in cell algorithm stores field data (scalars and vectors) on a grid, in the simplest case a 3DCoRectMesh. In between the mesh points live particles, described with a Polyvertex topology. The problem that now arises: we would like to describe both grid and polyvertex data in the *same xdmf file*. Doing so, e.g. by combining them on the Domain level in two separate Temporal Collections causes ParaView to refuse volume-rendering the fields (not available in the drop down menu). Adding two Domains to one file causes ParaView to omit the second data domain during load. Adding both grid types in the same Temporal Collection causes a crash. Do we really have to write two xdmf files or did we miss a point? A snippet of our data structures, stored in a hdf5 file per time step: ?xml version=1.0 ? Xdmf Domain Grid CollectionType=Temporal GridType=Collection Name=Grids Grid GridType=Uniform Name=Grid_0_0 Topology Dimensions=256 768 256 TopologyType=3DCoRectMesh/ Geometry Type=ORIGIN_DXDYDZ DataItem Dimensions=3 Format=XML0.0 0.0 0.0/DataItem DataItem Dimensions=3 Format=XML1.0 1.0 1.0/DataItem /Geometry Attribute Name=fields/Density_e DataItem Dimensions=256 768 256 Format=HDF NumberType=Float Precision=4h5_0.h5:Density_e/DataItem /Attribute /Grid !-- -- /Grid /Domain /Xdmf and the particles: Xdmf Domain Grid CollectionType=Temporal GridType=Collection Name=Polys Grid GridType=Uniform Name=Poly_0_0 Topology NodesPerElement=94109696 TopologyType=Polyvertex/ Attribute Name=particles/e/weighting DataItem Dimensions=94109696 Format=HDF NumberType=Float Precision=4h5_0.h5:weighting/DataItem /Attribute Time TimeType=Single Value=0/ Attribute AttributeType=Vector Name=particles/e/momentum DataItem Dimensions=94109696 3 Function=JOIN($0,$1,$2) ItemType=Function DataItem Dimensions=94109696 Format=HDF NumberType=Float Precision=4h5_0.h5:momentum/x/DataItem DataItem Dimensions=94109696 Format=HDF NumberType=Float Precision=4h5_0.h5:momentum/y/DataItem DataItem Dimensions=94109696 Format=HDF NumberType=Float Precision=4h5_0.h5:momentum/z/DataItem /DataItem /Attribute /Grid !-- -- /Grid /Domain /Xdmf Best regards and thanks for your Feedback, Axel Huebl [1] http://picongpu.hzdr.de -- . . Axel Huebl - Diploma Student. . a.hu...@hzdr.de - Phone +49 351 260 3582 . .https://www.hzdr.de/crp. . . . Computational Radiation Physics . . Laser Particle Acceleration Division . . Helmholtz-Zentrum Dresden - Rossendorf e.V. . . . . Bautzner Landstrasse 400, 01328 Dresden . . POB 510119, D-01314 Dresden . . Vorstand: Prof. Dr.Dr.h.c. R. Sauerbrey . . Prof. Dr.Dr.h.c. P. Joehnk . . VR 1693 beim Amtsgericht Dresden . . smime.p7s Description: S/MIME Cryptographic Signature ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] Particles-in-Cells: Two XDMF files?
Hey, did anyone else try combining a mesh and a polydata data set in *one* xdmf file with paraview before? Best, Axel On 24.02.2014 15:45, Huebl, Axel wrote: Hi ParaView mailing list, we are adding paraview/xdmf support to our particle-in-cell code PIConGPU [1] right now. To start with the general topology: The particle in cell algorithm stores field data (scalars and vectors) on a grid, in the simplest case a 3DCoRectMesh. In between the mesh points live particles, described with a Polyvertex topology. The problem that now arises: we would like to describe both grid and polyvertex data in the *same xdmf file*. Doing so, e.g. by combining them on the Domain level in two separate Temporal Collections causes ParaView to refuse volume-rendering the fields (not available in the drop down menu). Adding two Domains to one file causes ParaView to omit the second data domain during load. Adding both grid types in the same Temporal Collection causes a crash. Do we really have to write two xdmf files or did we miss a point? A snippet of our data structures, stored in a hdf5 file per time step: ?xml version=1.0 ? Xdmf Domain Grid CollectionType=Temporal GridType=Collection Name=Grids Grid GridType=Uniform Name=Grid_0_0 Topology Dimensions=256 768 256 TopologyType=3DCoRectMesh/ Geometry Type=ORIGIN_DXDYDZ DataItem Dimensions=3 Format=XML0.0 0.0 0.0/DataItem DataItem Dimensions=3 Format=XML1.0 1.0 1.0/DataItem /Geometry Attribute Name=fields/Density_e DataItem Dimensions=256 768 256 Format=HDF NumberType=Float Precision=4h5_0.h5:Density_e/DataItem /Attribute /Grid !-- -- /Grid /Domain /Xdmf and the particles: Xdmf Domain Grid CollectionType=Temporal GridType=Collection Name=Polys Grid GridType=Uniform Name=Poly_0_0 Topology NodesPerElement=94109696 TopologyType=Polyvertex/ Attribute Name=particles/e/weighting DataItem Dimensions=94109696 Format=HDF NumberType=Float Precision=4h5_0.h5:weighting/DataItem /Attribute Time TimeType=Single Value=0/ Attribute AttributeType=Vector Name=particles/e/momentum DataItem Dimensions=94109696 3 Function=JOIN($0,$1,$2) ItemType=Function DataItem Dimensions=94109696 Format=HDF NumberType=Float Precision=4h5_0.h5:momentum/x/DataItem DataItem Dimensions=94109696 Format=HDF NumberType=Float Precision=4h5_0.h5:momentum/y/DataItem DataItem Dimensions=94109696 Format=HDF NumberType=Float Precision=4h5_0.h5:momentum/z/DataItem /DataItem /Attribute /Grid !-- -- /Grid /Domain /Xdmf Best regards and thanks for your Feedback, Axel Huebl [1] http://picongpu.hzdr.de -- . . Axel Huebl - Diploma Student. . a.hu...@hzdr.de - Phone +49 351 260 3582 . .https://www.hzdr.de/crp. . . . Computational Radiation Physics . . Laser Particle Acceleration Division . . Helmholtz-Zentrum Dresden - Rossendorf e.V. . . . . Bautzner Landstrasse 400, 01328 Dresden . . POB 510119, D-01314 Dresden . . Vorstand: Prof. Dr.Dr.h.c. R. Sauerbrey . . Prof. Dr.Dr.h.c. P. Joehnk . . VR 1693 beim Amtsgericht Dresden . . smime.p7s Description: S/MIME Cryptographic Signature ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
[Paraview] Config OSMesa Software Rendering
Hi ParaView list, I am trying to set up a offscreen rendering setup with the current ParaView master (g5493984) and OSMesa. The target platform is a CPU-only cluster with several nodes, each containing four sockels with AMD Bulldozer CPUs (64 physical cores per node). I get everything up and running in parallel, connections via rc work perfectly and I can load my data. But the problems start with rendering the data. Do you have any recommendations which versions of OSMesa and llvmpipe are tested and stable? The recommendations in the wiki http://www.paraview.org/Wiki/ParaView/ParaView_And_Mesa_3D#OSMesa.2C_Mesa_without_graphics_hardware http://www.paraview.org/Wiki/ParaView/Users_Guide/Parallel_Rendering Look a bit outdated to me. E.g. - Mesa 9.2.5 (and newer versions) already split libgl and libglu which versions are recommended? - does OSMesa Gallium llvmpipe run with llvm X.Y (e.g. 3.3) ? - what do I have to set for the DISPLAY environment with OSMesa ? - is it necessary/forbidden to have a X11 server running in that setup (on the server nodes)? - I am confused if the mentioned SOFTWARE_DEPTH_BITS=31 bug is already fixed in mesa - are some of my dependencies (OpenMPI, gcc, python) too new/old ? I configured the server side with a whole bunch of flags now: cmake -DCMAKE_INSTALL_PREFIX=$HOME/bin/paraview-4.1.0-1008-g5493984 \ -DPARAVIEW_BUILD_QT_GUI=OFF -DBUILD_TESTING=OFF \ -DCMAKE_BUILD_TYPE=Debug -DPARAVIEW_ENABLE_CATALYST=OFF \ -DPARAVIEW_ENABLE_PYTHON=ON -DPARAVIEW_USE_MPI=ON \ -DPARAVIEW_USE_SYSTEM_MPI4PY=ON -DVTK_USE_X=OFF \ -DOPENGL_INCLUDE_DIR=$MESA_ROOT/include \ -DOSMESA_INCLUDE_DIR=$MESA_ROOT/include -DVTK_OPENGL_HAS_OSMESA=ON \ -DOPENGL_gl_LIBRARY=IS-NOTFOUND \ -DOPENGL_glu_LIBRARY=$MESA_ROOT/lib/libGLU.so \ -DOSMESA_LIBRARY=$MESA_ROOT/lib/libOSMesa.so -DVTK_USE_OFFSCREEN=ON \ -DPARAVIEW_BUILD_PLUGIN_AdiosReader=ON \ -DVTK_Group_MPI=ON -DVTK_Group_Imaging=ON -DVTK_Group_Rendering=ON \ -DVTK_XDMF_USE_MPI=ON -DXDMF_BUILD_MPI=ON \ -GNinja ~/src/ParaView and I am starting my servers with mpiexec -npernode 8 -n 32 `which pvserver` --use-offscreen-rendering \ -sp=$NUM_PORT -rc -ch=$HEAD_NODE and used the following separately compiled dependencies: - python 2.7.5 - icet 2.1.1 (probably compiled again by paraview) - gcc 4.8.2 - OpenMPI 1.7.4 (with infiniband support) - cmake 2.8.10 I tried a couple of flags for more than two weeks, three different OSMesa versions, environment tweaks, ... but never ended up with a stable setup (as soon as server side rendering kicks in). I can trigger that by loading a sphere, setting the remote/local rendering threshold to 0MB. and usually end up with an error in OpenGLInit (see attached). Do you have any ideas? Best regards, Axel Huebl -- Axel Huebl Diploma Student Phone +49 351 260 3582 https://www.hzdr.de/crp Computational Radiation Physics Laser Particle Acceleration Division Helmholtz-Zentrum Dresden - Rossendorf e.V. Bautzner Landstrasse 400, 01328 Dresden POB 510119, D-01314 Dresden Vorstand: Prof. Dr.Dr.h.c. R. Sauerbrey Prof. Dr.Dr.h.c. P. Joehnk VR 1693 beim Amtsgericht Dresden pvserver:14882 terminated with signal 11 at PC=7ffa825f2b1f SP=7fff658441b8. Backtrace: /lib/x86_64-linux-gnu/libc.so.6(+0x92b1f)[0x7ffa825f2b1f] /lib/x86_64-linux-gnu/libc.so.6(+0x7d700)[0x7ffa825dd700] /lib/x86_64-linux-gnu/libc.so.6(vsscanf+0x60)[0x7ffa825d18c0] /lib/x86_64-linux-gnu/libc.so.6(_IO_sscanf+0x87)[0x7ffa825bd3f7] /home/huebl/bin/paraview-4.1.0-1008-g5493984/lib/paraview-4.1/libvtkRenderingOpenGL-pv4.1.so.1(_ZN25vtkOpenGLExtensionManager20ReadOpenGLExtensionsEv+0x200)[0x7ffa77166ec0] /home/huebl/bin/paraview-4.1.0-1008-g5493984/lib/paraview-4.1/libvtkRenderingOpenGL-pv4.1.so.1(_ZN25vtkOpenGLExtensionManager6UpdateEv+0x4b)[0x7ffa7716611b] /home/huebl/bin/paraview-4.1.0-1008-g5493984/lib/paraview-4.1/libvtkRenderingOpenGL-pv4.1.so.1(_ZN25vtkOpenGLExtensionManager18ExtensionSupportedEPKc+0x17)[0x7ffa77160f47] /home/huebl/bin/paraview-4.1.0-1008-g5493984/lib/paraview-4.1/libvtkRenderingOpenGL-pv4.1.so.1(_ZN21vtkOpenGLRenderWindow17OpenGLInitContextEv+0x4a)[0x7ffa771aacaa] /home/huebl/bin/paraview-4.1.0-1008-g5493984/lib/paraview-4.1/libvtkRenderingOpenGL-pv4.1.so.1(_ZN21vtkOpenGLRenderWindow10OpenGLInitEv+0xd)[0x7ffa771a96bd] /home/huebl/bin/paraview-4.1.0-1008-g5493984/lib/paraview-4.1/libvtkRenderingOpenGL-pv4.1.so.1(_ZN23vtkOSOpenGLRenderWindow5StartEv+0xd)[0x7ffa7726835d] /home/huebl/bin/paraview-4.1.0-1008-g5493984/lib/paraview-4.1/libvtkRenderingCore-pv4.1.so.1(_ZN15vtkRenderWindow14DoStereoRenderEv+0x10)[0x7ffa890bd690] /home/huebl/bin/paraview-4.1.0-1008-g5493984/lib/paraview-4.1/libvtkRenderingCore-pv4.1.so.1(_ZN15vtkRenderWindow10DoFDRenderEv+0x6c7)[0x7ffa890bea77] /home/huebl/bin/paraview-4.1.0-1008-g5493984/lib/paraview-4.1/libvtkRenderingCore-pv4.1.so.1(_ZN15vtkRenderWindow10DoAARenderEv+0x80d)[0x7ffa890be35d] /home/huebl/bin/paraview-4.1.0
Re: [Paraview] Config OSMesa Software Rendering
Interesting but somehow it helps to write all the problems and steps up again. I fixed the issue(s) now as follows: - tried a pvbatch example (parallelSphere.py) and fixed the python install first, by setting: -DPYTHON_INCLUDE_DIR=$PYTHON_ROOT/include/python2.7 -DPYTHON_LIBRARY=$PYTHON_ROOT/lib/libpython2.7.so for CMake's FindPythonLib module (our system has several parallel installed python versions, some in system paths -.- ). - one has to set a bunch of entries in LD_LIBRARY_PATH and PYTHONPATH, that were: export LD_LIBRARY_PATH= $LD_LIBRARY_PATH:$PVHOME/lib/paraview-4.1 export LD_LIBRARY_PATH= $LD_LIBRARY_PATH:$PVHOME/lib/paraview-4.1/site-packages/paraview/ export LD_LIBRARY_PATH= $LD_LIBRARY_PATH:$PVHOME/lib/paraview-4.1/site-packages/paraview/vtk/ export LD_LIBRARY_PATH= $LD_LIBRARY_PATH:$PVHOME/lib/paraview-4.1/site-packages/vtk export PYTHONPATH= $PVHOME/lib/paraview-4.1/site-packages:$PYTHONPATH export PYTHONPATH= $PVHOME/lib/paraview-4.1/site-packages/paraview:$PYTHONPATH export PYTHONPATH= $PVHOME/lib/paraview-4.1/site-packages/paraview/vtk:$PYTHONPATH export PYTHONPATH= $PVHOME/lib/paraview-4.1/site-packages/vtk:$PYTHONPATH - realized libgl and x11 libs were still linked, e.g. in: ldd $BUILD/lib/paraview-4.1/libvtkRenderingOpenGL-pv4.1.so \ | grep -i gl changing the CMake flags to -DOPENGL_gl_LIBRARY:PATH= helped (with my old setting it auto-set the systems libgl.so during config). My full CMake flags are now (with the same dependencies as below): cmake \ -DCMAKE_INSTALL_PREFIX=$HOME/bin/paraview-4.1.0-1008-g5493984 \ -DPARAVIEW_BUILD_QT_GUI=OFF -DBUILD_TESTING=OFF \ -DCMAKE_BUILD_TYPE=Debug -DPARAVIEW_ENABLE_CATALYST=OFF \ -DPARAVIEW_ENABLE_PYTHON=ON \ -DPYTHON_INCLUDE_DIR=$PYTHON_ROOT/include /python2.7 \ -DPYTHON_LIBRARY=$PYTHON_ROOT/lib/libpython2.7.so \ -DPARAVIEW_USE_MPI=ON-DPARAVIEW_USE_SYSTEM_MPI4PY=ON \ -DVTK_USE_X=OFF-DOPENGL_INCLUDE_DIR=$MESA_ROOT/include \ -DOSMESA_INCLUDE_DIR=$MESA_ROOT/include \ -DVTK_OPENGL_HAS_OSMESA=ON -DOPENGL_gl_LIBRARY:PATH= \ -DOPENGL_glu_LIBRARY=$MESA_ROOT/lib/libGLU.so\ -DOSMESA_LIBRARY=$MESA_ROOT/lib/libOSMesa.so \ -DVTK_USE_OFFSCREEN=ON-DPARAVIEW_BUILD_PLUGIN_AdiosReader=ON \ -DVTK_Group_MPI=ON -DVTK_Group_Imaging=ON -DVTK_Group_Rendering=ON \ -DVTK_XDMF_USE_MPI=ON -DXDMF_BUILD_MPI=ON \ -GNinja ~/src/ParaView Finally it's one issue left that prevents me from rendering my data in Paraview itself. Paraview - Source Sphere - Filter - Clean to Grid and Volume Rendering gives me a ERROR: src/ParaView/VTK/Filters/Parallel/vtkPKdTree.cxx, line 295 vtkPKdTree (0x6022160) (process 0) NumberOfDatasets = 0, cannot determine volume bounds. (same for my xdmf/hdf5 data sets). Best regards, Axel Huebl On 05.07.2014 13:47, Huebl, Axel wrote: Hi ParaView list, I am trying to set up a offscreen rendering setup with the current ParaView master (g5493984) and OSMesa. The target platform is a CPU-only cluster with several nodes, each containing four sockels with AMD Bulldozer CPUs (64 physical cores per node). I get everything up and running in parallel, connections via rc work perfectly and I can load my data. But the problems start with rendering the data. Do you have any recommendations which versions of OSMesa and llvmpipe are tested and stable? The recommendations in the wiki http://www.paraview.org/Wiki/ParaView/ParaView_And_Mesa_3D#OSMesa.2C_Mesa_without_graphics_hardware http://www.paraview.org/Wiki/ParaView/Users_Guide/Parallel_Rendering Look a bit outdated to me. E.g. - Mesa 9.2.5 (and newer versions) already split libgl and libglu which versions are recommended? - does OSMesa Gallium llvmpipe run with llvm X.Y (e.g. 3.3) ? - what do I have to set for the DISPLAY environment with OSMesa ? - is it necessary/forbidden to have a X11 server running in that setup (on the server nodes)? - I am confused if the mentioned SOFTWARE_DEPTH_BITS=31 bug is already fixed in mesa - are some of my dependencies (OpenMPI, gcc, python) too new/old ? I configured the server side with a whole bunch of flags now: cmake -DCMAKE_INSTALL_PREFIX=$HOME/bin/paraview-4.1.0-1008-g5493984 \ -DPARAVIEW_BUILD_QT_GUI=OFF -DBUILD_TESTING=OFF \ -DCMAKE_BUILD_TYPE=Debug -DPARAVIEW_ENABLE_CATALYST=OFF \ -DPARAVIEW_ENABLE_PYTHON=ON -DPARAVIEW_USE_MPI=ON \ -DPARAVIEW_USE_SYSTEM_MPI4PY=ON -DVTK_USE_X=OFF \ -DOPENGL_INCLUDE_DIR=$MESA_ROOT/include \ -DOSMESA_INCLUDE_DIR=$MESA_ROOT/include -DVTK_OPENGL_HAS_OSMESA=ON \ -DOPENGL_gl_LIBRARY=IS-NOTFOUND \ -DOPENGL_glu_LIBRARY=$MESA_ROOT/lib/libGLU.so \ -DOSMESA_LIBRARY=$MESA_ROOT/lib/libOSMesa.so -DVTK_USE_OFFSCREEN=ON \ -DPARAVIEW_BUILD_PLUGIN_AdiosReader=ON \ -DVTK_Group_MPI=ON -DVTK_Group_Imaging=ON -DVTK_Group_Rendering=ON \ -DVTK_XDMF_USE_MPI=ON -DXDMF_BUILD_MPI
[Paraview] XDMF Join Strided: Memory Footprint
Hi, I am experiencing a huge temporal memory usage by loading xdmf/hdf5 data strided with join (see attached file). While loading the join-ed data set, the memory usage pops up to very high levels and when it is finished (the gui starts to react again) it shrinks down to around few percent of it. I am loading the Function=JOIN(...) set with striding 8 8 8 with paraview which makes me wonder if the striding might get ignored for the initial load period? I tested the same by loading the individual components of the vector field, each with striding, and using the Calculator filter to generate the vector field. By that the memory usage stays at a low footprint all the time. Best regards, Axel Huebl -- Axel Huebl Diploma Student Phone +49 351 260 3582 https://www.hzdr.de/crp Computational Radiation Physics Laser Particle Acceleration Division Helmholtz-Zentrum Dresden - Rossendorf e.V. Bautzner Landstrasse 400, 01328 Dresden POB 510119, D-01314 Dresden Vorstand: Prof. Dr.Dr.h.c. R. Sauerbrey Prof. Dr.Dr.h.c. P. Joehnk VR 1693 beim Amtsgericht Dresden join.xmf Description: audio/xmf smime.p7s Description: S/MIME Cryptographic Signature ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/paraview
Re: [Paraview] Config OSMesa Software Rendering
Ok the NumberOfDatasets = 0, cannot determine volume bounds can be circumvented by a CleanToGrid filter or any other filter that projects the Image data to an UnstructuredGrid. Paraview can still not render non-cubic cells / ImageData / XDMF-3DCoRectMesh naively? Best regards, Axel Huebl On 06.07.2014 11:59, Huebl, Axel wrote: Interesting but somehow it helps to write all the problems and steps up again. I fixed the issue(s) now as follows: - tried a pvbatch example (parallelSphere.py) and fixed the python install first, by setting: -DPYTHON_INCLUDE_DIR=$PYTHON_ROOT/include/python2.7 -DPYTHON_LIBRARY=$PYTHON_ROOT/lib/libpython2.7.so for CMake's FindPythonLib module (our system has several parallel installed python versions, some in system paths -.- ). - one has to set a bunch of entries in LD_LIBRARY_PATH and PYTHONPATH, that were: export LD_LIBRARY_PATH= $LD_LIBRARY_PATH:$PVHOME/lib/paraview-4.1 export LD_LIBRARY_PATH= $LD_LIBRARY_PATH:$PVHOME/lib/paraview-4.1/site-packages/paraview/ export LD_LIBRARY_PATH= $LD_LIBRARY_PATH:$PVHOME/lib/paraview-4.1/site-packages/paraview/vtk/ export LD_LIBRARY_PATH= $LD_LIBRARY_PATH:$PVHOME/lib/paraview-4.1/site-packages/vtk export PYTHONPATH= $PVHOME/lib/paraview-4.1/site-packages:$PYTHONPATH export PYTHONPATH= $PVHOME/lib/paraview-4.1/site-packages/paraview:$PYTHONPATH export PYTHONPATH= $PVHOME/lib/paraview-4.1/site-packages/paraview/vtk:$PYTHONPATH export PYTHONPATH= $PVHOME/lib/paraview-4.1/site-packages/vtk:$PYTHONPATH - realized libgl and x11 libs were still linked, e.g. in: ldd $BUILD/lib/paraview-4.1/libvtkRenderingOpenGL-pv4.1.so \ | grep -i gl changing the CMake flags to -DOPENGL_gl_LIBRARY:PATH= helped (with my old setting it auto-set the systems libgl.so during config). My full CMake flags are now (with the same dependencies as below): cmake \ -DCMAKE_INSTALL_PREFIX=$HOME/bin/paraview-4.1.0-1008-g5493984 \ -DPARAVIEW_BUILD_QT_GUI=OFF -DBUILD_TESTING=OFF \ -DCMAKE_BUILD_TYPE=Debug -DPARAVIEW_ENABLE_CATALYST=OFF \ -DPARAVIEW_ENABLE_PYTHON=ON \ -DPYTHON_INCLUDE_DIR=$PYTHON_ROOT/include /python2.7 \ -DPYTHON_LIBRARY=$PYTHON_ROOT/lib/libpython2.7.so \ -DPARAVIEW_USE_MPI=ON-DPARAVIEW_USE_SYSTEM_MPI4PY=ON \ -DVTK_USE_X=OFF-DOPENGL_INCLUDE_DIR=$MESA_ROOT/include \ -DOSMESA_INCLUDE_DIR=$MESA_ROOT/include \ -DVTK_OPENGL_HAS_OSMESA=ON -DOPENGL_gl_LIBRARY:PATH= \ -DOPENGL_glu_LIBRARY=$MESA_ROOT/lib/libGLU.so\ -DOSMESA_LIBRARY=$MESA_ROOT/lib/libOSMesa.so \ -DVTK_USE_OFFSCREEN=ON-DPARAVIEW_BUILD_PLUGIN_AdiosReader=ON \ -DVTK_Group_MPI=ON -DVTK_Group_Imaging=ON -DVTK_Group_Rendering=ON \ -DVTK_XDMF_USE_MPI=ON -DXDMF_BUILD_MPI=ON \ -GNinja ~/src/ParaView Finally it's one issue left that prevents me from rendering my data in Paraview itself. Paraview - Source Sphere - Filter - Clean to Grid and Volume Rendering gives me a ERROR: src/ParaView/VTK/Filters/Parallel/vtkPKdTree.cxx, line 295 vtkPKdTree (0x6022160) (process 0) NumberOfDatasets = 0, cannot determine volume bounds. (same for my xdmf/hdf5 data sets). Best regards, Axel Huebl On 05.07.2014 13:47, Huebl, Axel wrote: Hi ParaView list, I am trying to set up a offscreen rendering setup with the current ParaView master (g5493984) and OSMesa. The target platform is a CPU-only cluster with several nodes, each containing four sockels with AMD Bulldozer CPUs (64 physical cores per node). I get everything up and running in parallel, connections via rc work perfectly and I can load my data. But the problems start with rendering the data. Do you have any recommendations which versions of OSMesa and llvmpipe are tested and stable? The recommendations in the wiki http://www.paraview.org/Wiki/ParaView/ParaView_And_Mesa_3D#OSMesa.2C_Mesa_without_graphics_hardware http://www.paraview.org/Wiki/ParaView/Users_Guide/Parallel_Rendering Look a bit outdated to me. E.g. - Mesa 9.2.5 (and newer versions) already split libgl and libglu which versions are recommended? - does OSMesa Gallium llvmpipe run with llvm X.Y (e.g. 3.3) ? - what do I have to set for the DISPLAY environment with OSMesa ? - is it necessary/forbidden to have a X11 server running in that setup (on the server nodes)? - I am confused if the mentioned SOFTWARE_DEPTH_BITS=31 bug is already fixed in mesa - are some of my dependencies (OpenMPI, gcc, python) too new/old ? I configured the server side with a whole bunch of flags now: cmake -DCMAKE_INSTALL_PREFIX=$HOME/bin/paraview-4.1.0-1008-g5493984 \ -DPARAVIEW_BUILD_QT_GUI=OFF -DBUILD_TESTING=OFF \ -DCMAKE_BUILD_TYPE=Debug -DPARAVIEW_ENABLE_CATALYST=OFF \ -DPARAVIEW_ENABLE_PYTHON=ON -DPARAVIEW_USE_MPI=ON \ -DPARAVIEW_USE_SYSTEM_MPI4PY=ON -DVTK_USE_X=OFF \ -DOPENGL_INCLUDE_DIR=$MESA_ROOT
Re: [Paraview] Nvidia K20x on cluster
To add to that question: is the PISTON / Dax support in Paraview already a stable alternative to avoid X11 at all? Thanks, Axel On 07.07.2014 16:36, Felipe Bordeu wrote: Hello, We have a computer (node in a cluster) with 2 Nvidia K20x GPUs (plus a chipset for low-end visu). Is It possible to use these GPUs to accelerate ParaView visualization even if theses cards don't have a video output??? I know how to use the pvserver/paraview. But my problem is about the X11 configuration. If I put a 'Section Screen' for these cards in the xorg.conf, nvidia complains that these cards don't have outputs. and if I eliminate the 'Screen' section, the card are not available. (tried display :0, 0:0 1:0...) Any Ideas?? Thanks Felipe smime.p7s Description: S/MIME Cryptographic Signature ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/paraview
Re: [Paraview] Nvidia K20x on cluster
Oh that's actually not true for the full k20 series. the k20m (server modules) should support switching, the k20c (workstations) might not. https://devtalk.nvidia.com/default/topic/528048/k20-gpu-operation-mode-support/ https://devtalk.nvidia.com/default/topic/534299/tesla-k20c-or-k20m-/ Probably the K20Xm should still allow to set it to ALL_ON - can you confirm that? Good luck! Axel On 08.07.2014 12:55, Huebl, Axel wrote: I think that is true for most cards, but K20 series should still support to switch the GPU Operation Mode (GOM) via nvidia-settings: http://blogs.fau.de/zeiser/2013/09/09/xserver-virtualgl-on-nvidia-k20m-gpgpus/ nvidia-smi --gom=0 [...] (0 = ALL_ON) Best, Axel On 08.07.2014 11:33, Felipe Bordeu wrote: Thanks but... K20x are only a cuda card, no graphics support. info from : http://comments.gmane.org/gmane.comp.video.opengl.virtualgl.user/1003 End of History Felipe Le 08/07/2014 08:37, Albina, Frank a écrit : IMHO, the issue is that you need to tell the NVIDIA driver that a screen will be connected at any time to the GPU, but you need to supply the driver with the screen data via a custom EDID file, like so in your xorg.conf file: Section Device Identifier Device0 [...] Option CustomEDID DFP-0:/etc/X11/edid-DELL_P2212H.bin Option ConnectedMonitor DFP-0 EndSection Section Screen Identifier Screen0 Device Device0 MonitorMonitor0 DefaultDepth24 [...] EndSection Hope this helps. Frank. -Original Message- From: ParaView [mailto:paraview-boun...@paraview.org] On Behalf Of Felipe Bordeu Sent: Montag, 7. Juli 2014 16:37 To: Paraview Mailing list (to use with ec-nantes) Subject: [Paraview] Nvidia K20x on cluster Hello, We have a computer (node in a cluster) with 2 Nvidia K20x GPUs (plus a chipset for low-end visu). Is It possible to use these GPUs to accelerate ParaView visualization even if theses cards don't have a video output??? I know how to use the pvserver/paraview. But my problem is about the X11 configuration. If I put a 'Section Screen' for these cards in the xorg.conf, nvidia complains that these cards don't have outputs. and if I eliminate the 'Screen' section, the card are not available. (tried display :0, 0:0 1:0...) Any Ideas?? Thanks Felipe ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/paraview ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/paraview ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/paraview -- Axel Huebl Diploma Student Phone +49 351 260 3582 https://www.hzdr.de/crp Computational Radiation Physics Laser Particle Acceleration Division Helmholtz-Zentrum Dresden - Rossendorf e.V. Bautzner Landstrasse 400, 01328 Dresden POB 510119, D-01314 Dresden Vorstand: Prof. Dr.Dr.h.c. R. Sauerbrey Prof. Dr.Dr.h.c. P. Joehnk VR 1693 beim Amtsgericht Dresden smime.p7s Description: S/MIME Cryptographic Signature ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/paraview
[Paraview] Render View: Edit View Options Gone?
Hi, is the Button for changing lightning, Edit View Options, in the Render View gone in the current master (g5493984) ? The 4.1 release still has that option. Best, Axel smime.p7s Description: S/MIME Cryptographic Signature ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/paraview
Re: [Paraview] Render View: Edit View Options Gone?
Ah, there it is! Left Panel Properties - Advanced (gear). Thank you, Axel On 08.07.2014 17:01, Utkarsh Ayachit wrote: Yes, Edit View Options is gone. You can still change the lights from the Properties Panel. It's an advanced property, so make sure you have the gear toggled. Check these posts out: http://www.kitware.com/blog/home/post/621 http://www.kitware.com/blog/home/post/673 http://www.kitware.com/blog/home/post/491 Utkarsh On Tue, Jul 8, 2014 at 9:56 AM, Huebl, Axel a.hu...@hzdr.de wrote: Hi, is the Button for changing lightning, Edit View Options, in the Render View gone in the current master (g5493984) ? The 4.1 release still has that option. Best, Axel ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/paraview -- Axel Huebl Diploma Student Phone +49 351 260 3582 https://www.hzdr.de/crp Computational Radiation Physics Laser Particle Acceleration Division Helmholtz-Zentrum Dresden - Rossendorf e.V. Bautzner Landstrasse 400, 01328 Dresden POB 510119, D-01314 Dresden Vorstand: Prof. Dr.Dr.h.c. R. Sauerbrey Prof. Dr.Dr.h.c. P. Joehnk VR 1693 beim Amtsgericht Dresden smime.p7s Description: S/MIME Cryptographic Signature ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/paraview
Re: [Paraview] what if you have two qt-installations?
Dear Bertwim, have you tried prepending/setting the CMAKE_PREFIX_PATH to your qt5 install dir? Best, Axel On 05.08.2014 18:07, B.W.H. van Beest wrote: Hi Burien, thanks for responding. I have done you suggested, but to no avail. Somehow, the path to the executable qmake is not sufficient to determine all the other QT5 libraries. Having said that, in one of the by now many attempts to get paraview configured, I found that indeed the correct QT5 libraries were selected. That build, however failed (missing symbol, cannot remember which one). In trying to correct this is, the wrong QT5 libraries were selected by ccmake. I just cannot figure out how this cmake thing works, or what I can do to force it. Any suggestions? Kind Regards, Bertwim On 08/04/2014 10:04 PM, Burlen Loring wrote: system install may be first in the linker search path. have you checked? If that's it: rm your build, and in addition to QT_QMAKE_EXECUTABLE, prepend export your qt install paths to LD_LIBRARY_PATH and PATH before you run cmake. Each time when you run PV do the same. On 08/04/2014 12:01 PM, B.W.H. van Beest wrote: Hello, On my system, I have 2 installations of QT5. One is the distribution that comes with my linux distribution (qt5.1.1.openSuSe 13.1), the other one is a more recent version (5.3.1), which I downloaded and installed in a different location. Using ccmake, setting the QT version to 5, as well as setting QT_QMAKE_EXECUTABLE to qmake of the new location, I still see that ccmake selects of number of qt5-libraries that belong to the old SUSE-distribution, (e.g. libQt5Declarative.so, but many more, in fact). I can build paraview, though, and it even seems to work (smoketest), but at program exit it segfaults. I wonder how I can tell cmake to configure for 1 qt version. Surely, I don't need to change all the entries by hand? Thanks in advance Bertwim -- Axel Huebl Diploma Student Phone +49 351 260 3582 https://www.hzdr.de/crp Computational Radiation Physics Laser Particle Acceleration Division Helmholtz-Zentrum Dresden - Rossendorf e.V. Bautzner Landstrasse 400, 01328 Dresden POB 510119, D-01314 Dresden Vorstand: Prof. Dr.Dr.h.c. R. Sauerbrey Prof. Dr.Dr.h.c. P. Joehnk VR 1693 beim Amtsgericht Dresden smime.p7s Description: S/MIME Cryptographic Signature ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/paraview
Re: [Paraview] what if you have two qt-installations?
Dear Bertwim, good to hear that. sorry - CMAKE_PREFIX_PATH is an environment variable like PATH and LD_LIBRARY_PATH to hint install directories to CMake modules. The compile error still looks like something got mixed - can you try again with the CMAKE_PREFIX_PATH hint? Did you verify all advanced variables set from the FindQt module with ccmake? Best, Axel On 05.08.2014 21:37, B.W.H. van Beest wrote: Dear Axel, No I haven't. To follow-up on your suggestion, I ran ccmake again to set this parameter. No CMAKE_PREFIX_PATH is in the list! What I did try -and what did make a difference, was not only prepending the path to qt5/lib to LD_LIBRARY_PATH, but also ensuring that qt/bin was first in $PATH. This indeed has the result that all libQt5 directories found were the correct ones. Maybe that amounts to the same? However, Now I have a different compile error: CMakeFiles/QtTesting.dir/pqNativeFileDialogEventPlayer.cxx.o: In function `pqNativeFileDialogEventPlayer::start()': pqNativeFileDialogEventPlayer.cxx:(.text+0x263): undefined reference to `qt_filedialog_existing_directory_hook' pqNativeFileDialogEventPlayer.cxx:(.text+0x285): undefined reference to `qt_filedialog_open_filename_hook' pqNativeFileDialogEventPlayer.cxx:(.text+0x2a7): undefined reference to `qt_filedialog_open_filenames_hook' pqNativeFileDialogEventPlayer.cxx:(.text+0x2b4): undefined reference to `qt_filedialog_save_filename_hook' CMakeFiles/QtTesting.dir/pqNativeFileDialogEventPlayer.cxx.o: In function `pqNativeFileDialogEventPlayer::stop()': etc. Any ideas? On 08/05/2014 08:38 PM, Huebl, Axel wrote: Dear Bertwim, have you tried prepending/setting the CMAKE_PREFIX_PATH to your qt5 install dir? Best, Axel On 05.08.2014 18:07, B.W.H. van Beest wrote: Hi Burien, thanks for responding. I have done you suggested, but to no avail. Somehow, the path to the executable qmake is not sufficient to determine all the other QT5 libraries. Having said that, in one of the by now many attempts to get paraview configured, I found that indeed the correct QT5 libraries were selected. That build, however failed (missing symbol, cannot remember which one). In trying to correct this is, the wrong QT5 libraries were selected by ccmake. I just cannot figure out how this cmake thing works, or what I can do to force it. Any suggestions? Kind Regards, Bertwim On 08/04/2014 10:04 PM, Burlen Loring wrote: system install may be first in the linker search path. have you checked? If that's it: rm your build, and in addition to QT_QMAKE_EXECUTABLE, prepend export your qt install paths to LD_LIBRARY_PATH and PATH before you run cmake. Each time when you run PV do the same. On 08/04/2014 12:01 PM, B.W.H. van Beest wrote: Hello, On my system, I have 2 installations of QT5. One is the distribution that comes with my linux distribution (qt5.1.1.openSuSe 13.1), the other one is a more recent version (5.3.1), which I downloaded and installed in a different location. Using ccmake, setting the QT version to 5, as well as setting QT_QMAKE_EXECUTABLE to qmake of the new location, I still see that ccmake selects of number of qt5-libraries that belong to the old SUSE-distribution, (e.g. libQt5Declarative.so, but many more, in fact). I can build paraview, though, and it even seems to work (smoketest), but at program exit it segfaults. I wonder how I can tell cmake to configure for 1 qt version. Surely, I don't need to change all the entries by hand? Thanks in advance Bertwim -- Axel Huebl Diploma Student Phone +49 351 260 3582 https://www.hzdr.de/crp Computational Radiation Physics Laser Particle Acceleration Division Helmholtz-Zentrum Dresden - Rossendorf e.V. Bautzner Landstrasse 400, 01328 Dresden POB 510119, D-01314 Dresden Vorstand: Prof. Dr.Dr.h.c. R. Sauerbrey Prof. Dr.Dr.h.c. P. Joehnk VR 1693 beim Amtsgericht Dresden smime.p7s Description: S/MIME Cryptographic Signature ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/paraview
Re: [Paraview] what if you have two qt-installations?
Hm, looks like the cleanest way to get it running is to remove default installations of qt from the system path(s) and to specificity only one specific installation via environment flags. (I am suggesting something that can be achieved with a module system, e.g. on a cluster) Alternatively you can try to scratch all the advanced flags together that are still wrong and set them by hand. What does this tell me? Yep, but basically it is still an environment problem. Best, Axel On 07.08.2014 03:05, B.W.H. van Beest wrote: Hi Axel, setting CMAKE_PREFIX_PATH does not make a difference. The special variables left that have a reference to the wrong qt installation are QT_QT3SUPPORT_LIBRARY and QT3SUPPORT_LIBRARY_RELEASE variables. Qt5 does no longer provide Qt4 support . Also QT_QTCORE_LIBRARY and QT_QDBUS and QT_GUI_LIBRARY_ are wrong The correspinding HEADER-varinant are ok, though. What does this tell me? Regards, Bertwim On 08/06/2014 11:34 AM, Huebl, Axel wrote: Dear Bertwim, good to hear that. sorry - CMAKE_PREFIX_PATH is an environment variable like PATH and LD_LIBRARY_PATH to hint install directories to CMake modules. The compile error still looks like something got mixed - can you try again with the CMAKE_PREFIX_PATH hint? Did you verify all advanced variables set from the FindQt module with ccmake? Best, Axel On 05.08.2014 21:37, B.W.H. van Beest wrote: Dear Axel, No I haven't. To follow-up on your suggestion, I ran ccmake again to set this parameter. No CMAKE_PREFIX_PATH is in the list! What I did try -and what did make a difference, was not only prepending the path to qt5/lib to LD_LIBRARY_PATH, but also ensuring that qt/bin was first in $PATH. This indeed has the result that all libQt5 directories found were the correct ones. Maybe that amounts to the same? However, Now I have a different compile error: CMakeFiles/QtTesting.dir/pqNativeFileDialogEventPlayer.cxx.o: In function `pqNativeFileDialogEventPlayer::start()': pqNativeFileDialogEventPlayer.cxx:(.text+0x263): undefined reference to `qt_filedialog_existing_directory_hook' pqNativeFileDialogEventPlayer.cxx:(.text+0x285): undefined reference to `qt_filedialog_open_filename_hook' pqNativeFileDialogEventPlayer.cxx:(.text+0x2a7): undefined reference to `qt_filedialog_open_filenames_hook' pqNativeFileDialogEventPlayer.cxx:(.text+0x2b4): undefined reference to `qt_filedialog_save_filename_hook' CMakeFiles/QtTesting.dir/pqNativeFileDialogEventPlayer.cxx.o: In function `pqNativeFileDialogEventPlayer::stop()': etc. Any ideas? On 08/05/2014 08:38 PM, Huebl, Axel wrote: Dear Bertwim, have you tried prepending/setting the CMAKE_PREFIX_PATH to your qt5 install dir? Best, Axel On 05.08.2014 18:07, B.W.H. van Beest wrote: Hi Burien, thanks for responding. I have done you suggested, but to no avail. Somehow, the path to the executable qmake is not sufficient to determine all the other QT5 libraries. Having said that, in one of the by now many attempts to get paraview configured, I found that indeed the correct QT5 libraries were selected. That build, however failed (missing symbol, cannot remember which one). In trying to correct this is, the wrong QT5 libraries were selected by ccmake. I just cannot figure out how this cmake thing works, or what I can do to force it. Any suggestions? Kind Regards, Bertwim On 08/04/2014 10:04 PM, Burlen Loring wrote: system install may be first in the linker search path. have you checked? If that's it: rm your build, and in addition to QT_QMAKE_EXECUTABLE, prepend export your qt install paths to LD_LIBRARY_PATH and PATH before you run cmake. Each time when you run PV do the same. On 08/04/2014 12:01 PM, B.W.H. van Beest wrote: Hello, On my system, I have 2 installations of QT5. One is the distribution that comes with my linux distribution (qt5.1.1.openSuSe 13.1), the other one is a more recent version (5.3.1), which I downloaded and installed in a different location. Using ccmake, setting the QT version to 5, as well as setting QT_QMAKE_EXECUTABLE to qmake of the new location, I still see that ccmake selects of number of qt5-libraries that belong to the old SUSE-distribution, (e.g. libQt5Declarative.so, but many more, in fact). I can build paraview, though, and it even seems to work (smoketest), but at program exit it segfaults. I wonder how I can tell cmake to configure for 1 qt version. Surely, I don't need to change all the entries by hand? Thanks in advance Bertwim -- Axel Huebl Diploma Student Phone +49 351 260 3582 https://www.hzdr.de/crp Computational Radiation Physics Laser Particle Acceleration Division Helmholtz-Zentrum Dresden - Rossendorf e.V. Bautzner Landstrasse 400, 01328 Dresden POB 510119, D-01314 Dresden Vorstand: Prof. Dr.Dr.h.c. R. Sauerbrey Prof. Dr.Dr.h.c. P. Joehnk VR 1693 beim Amtsgericht Dresden smime.p7s Description: S/MIME
Re: [Paraview] A Forward Connection Over two ssh Tunnel
Dear Ehsan, I use a similar setup as Burlen, tunneling twice over a login node to our cluster's head node. It also needs `GatewayPorts clientspecified` in the head node's sshd_config to work with maximum comfort. Feel free to check our wiki: https://github.com/ComputationalRadiationPhysics/picongpu/wiki/ParaView Best, Axel On 18.08.2014 22:43, Burlen Loring wrote: Hi Utkarsh, Sure I can do that. Burlen On 08/18/2014 01:36 PM, Utkarsh Ayachit wrote: Burlen, Very cool. When you get the chance, mind updating the Wiki? Thanks Utkarsh On Mon, Aug 18, 2014 at 12:37 PM, Burlen Loring blor...@lbl.gov wrote: Hi Ehsan, As Utkarsh says you need to use a reverse connection. I suggest ncat instead of portfwd because portfwd is a long dead project with no support and it's failed to compile on some systems I used. Here's a schematic of the setup [work station] [ login node] [ compute node ] [ paraview ]-- ssh -R --[ ncat + ncat -l ]-[ pvserver -rc ] in more detail: in your pvsc on the client ssh -R ${PORT}:localhost:${PORT} ${LOGIN_HOST} ... on the login node in a shell script referenced by the client's pvsc: let LOGIN_PORT=${PORT}+1 ncat -l ${LOGIN_HOST} ${LOGIN_PORT} --sh-exec=ncat localhost $PORT qsub ... on the compute node in your batch script mpirun ... pvserver --reverse-connection --client-host ${LOGIN_HOST} --server-port ${LOGIN_PORT} ... You could skip ncat if you have control over the sshd config, you need to enable GatewayPorts. Burlen On 08/18/2014 08:18 AM, Utkarsh Ayachit wrote: It does boil down to using reverse connection and setting up recursive tunnels so that the pvserver and tunnel back to the client. See the following on the need for portfwd and how it could potentially be helpful here. http://www.paraview.org/Wiki/Reverse_connection_and_port_forwarding#Reverse_Connection_over_a_Reverse_ssh_Tunnel_with_portfwd On Mon, Aug 18, 2014 at 11:15 AM, ehsan saei ehsan.s...@gmail.com wrote: Dear Utkarsh, Thanks for your respond. I tried the section : A forward connection over an ssh tunnel but it doesn't work. The problem is that I have to ssh to one system and then ssh to the cluster again and finally I can submit a job. Do you have any other suggestions? thanks in advance, Ehsan On Mon, Aug 18, 2014 at 4:29 PM, Utkarsh Ayachit utkarsh.ayac...@kitware.com wrote: This may be of help: http://www.paraview.org/Wiki/Reverse_connection_and_port_forwarding Utkarsh On Mon, Aug 18, 2014 at 5:52 AM, ehsan saei ehsan.s...@gmail.com wrote: Hi all, I'm new to paraview. I try to run pvserver on a cluster. The problem is that I need to ssh twice to get access to the cluster. To use pvserver I submit a job on the cluster and then I run pvserver using the command mpirun -np 12 pvserver then I pick the name and port from terminal and use it in paraview client. but paraview can't find the pvserver. Is there any way to establish a connection via these two ssh tunnels? Thanks in advance, Ehsan ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/paraview ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/paraview ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/paraview ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/paraview -- Axel Huebl Diploma Student Phone +49 351 260 3582 https://www.hzdr.de/crp Computational Radiation Physics Laser Particle Acceleration Division Helmholtz-Zentrum Dresden - Rossendorf e.V. Bautzner Landstrasse 400, 01328 Dresden POB 510119, D-01314 Dresden Vorstand: Prof. Dr.Dr.h.c. R. Sauerbrey Prof. Dr.Dr.h.c. P. Joehnk VR 1693 beim Amtsgericht Dresden smime.p7s Description: S/MIME Cryptographic Signature
Re: [Paraview] A Forward Connection Over two ssh Tunnel
Thanks! Sure, you can link it. Just tell me if you spot some improvements. Our stand-alone pvsc file does some more automated and rather dark magic to build the described the tunnels up with one click. Its linked there too. Axel On 19.08.2014 05:56, Utkarsh Ayachit wrote: Very cool! Thanks for sharing, Axel. It will be nice to link this page from the Wiki as a reference/example, if that's okay. Utkarsh On Mon, Aug 18, 2014 at 6:12 PM, Huebl, Axel a.hu...@hzdr.de wrote: Dear Ehsan, I use a similar setup as Burlen, tunneling twice over a login node to our cluster's head node. It also needs `GatewayPorts clientspecified` in the head node's sshd_config to work with maximum comfort. Feel free to check our wiki: https://github.com/ComputationalRadiationPhysics/picongpu/wiki/ParaView Best, Axel On 18.08.2014 22:43, Burlen Loring wrote: Hi Utkarsh, Sure I can do that. Burlen On 08/18/2014 01:36 PM, Utkarsh Ayachit wrote: Burlen, Very cool. When you get the chance, mind updating the Wiki? Thanks Utkarsh On Mon, Aug 18, 2014 at 12:37 PM, Burlen Loring blor...@lbl.gov wrote: Hi Ehsan, As Utkarsh says you need to use a reverse connection. I suggest ncat instead of portfwd because portfwd is a long dead project with no support and it's failed to compile on some systems I used. Here's a schematic of the setup [work station] [ login node] [ compute node ] [ paraview ]-- ssh -R --[ ncat + ncat -l ]-[ pvserver -rc ] in more detail: in your pvsc on the client ssh -R ${PORT}:localhost:${PORT} ${LOGIN_HOST} ... on the login node in a shell script referenced by the client's pvsc: let LOGIN_PORT=${PORT}+1 ncat -l ${LOGIN_HOST} ${LOGIN_PORT} --sh-exec=ncat localhost $PORT qsub ... on the compute node in your batch script mpirun ... pvserver --reverse-connection --client-host ${LOGIN_HOST} --server-port ${LOGIN_PORT} ... You could skip ncat if you have control over the sshd config, you need to enable GatewayPorts. Burlen On 08/18/2014 08:18 AM, Utkarsh Ayachit wrote: It does boil down to using reverse connection and setting up recursive tunnels so that the pvserver and tunnel back to the client. See the following on the need for portfwd and how it could potentially be helpful here. http://www.paraview.org/Wiki/Reverse_connection_and_port_forwarding#Reverse_Connection_over_a_Reverse_ssh_Tunnel_with_portfwd On Mon, Aug 18, 2014 at 11:15 AM, ehsan saei ehsan.s...@gmail.com wrote: Dear Utkarsh, Thanks for your respond. I tried the section : A forward connection over an ssh tunnel but it doesn't work. The problem is that I have to ssh to one system and then ssh to the cluster again and finally I can submit a job. Do you have any other suggestions? thanks in advance, Ehsan On Mon, Aug 18, 2014 at 4:29 PM, Utkarsh Ayachit utkarsh.ayac...@kitware.com wrote: This may be of help: http://www.paraview.org/Wiki/Reverse_connection_and_port_forwarding Utkarsh On Mon, Aug 18, 2014 at 5:52 AM, ehsan saei ehsan.s...@gmail.com wrote: Hi all, I'm new to paraview. I try to run pvserver on a cluster. The problem is that I need to ssh twice to get access to the cluster. To use pvserver I submit a job on the cluster and then I run pvserver using the command mpirun -np 12 pvserver then I pick the name and port from terminal and use it in paraview client. but paraview can't find the pvserver. Is there any way to establish a connection via these two ssh tunnels? Thanks in advance, Ehsan ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/paraview ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/paraview ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/paraview ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe
Re: [Paraview] A Forward Connection Over two ssh Tunnel
Burlen, thanks you pointed that out, I totally agree. I will give it a try next time! Axel On 19.08.2014 20:56, Burlen Loring wrote: One thing to be aware of is the additional overhead of ssh compared to something like ncat or portfwd. ssh encrypts/unencrypts it's data which adds unnecessary overhead. I ran the 2 ssh tunnel solution at nersc for a while on Hopper. The performance was noticeably better with ncat which pipes data through untouched. The issue in large part because of the heavy loading and heavy network traffic on mom nodes where second tunnel ran. this is cray thing, you may not notice the difference between ssh and ncat on a typical cluster or if the system is not hammered by 1000's of simultaneous users as ours are. Still I think ncat is the best practice. On 08/18/2014 08:56 PM, Utkarsh Ayachit wrote: Very cool! Thanks for sharing, Axel. It will be nice to link this page from the Wiki as a reference/example, if that's okay. Utkarsh On Mon, Aug 18, 2014 at 6:12 PM, Huebl, Axel a.hu...@hzdr.de wrote: Dear Ehsan, I use a similar setup as Burlen, tunneling twice over a login node to our cluster's head node. It also needs `GatewayPorts clientspecified` in the head node's sshd_config to work with maximum comfort. Feel free to check our wiki: https://github.com/ComputationalRadiationPhysics/picongpu/wiki/ParaView Best, Axel On 18.08.2014 22:43, Burlen Loring wrote: Hi Utkarsh, Sure I can do that. Burlen On 08/18/2014 01:36 PM, Utkarsh Ayachit wrote: Burlen, Very cool. When you get the chance, mind updating the Wiki? Thanks Utkarsh On Mon, Aug 18, 2014 at 12:37 PM, Burlen Loring blor...@lbl.gov wrote: Hi Ehsan, As Utkarsh says you need to use a reverse connection. I suggest ncat instead of portfwd because portfwd is a long dead project with no support and it's failed to compile on some systems I used. Here's a schematic of the setup [work station] [ login node] [ compute node ] [ paraview ]-- ssh -R --[ ncat + ncat -l ]-[ pvserver -rc ] in more detail: in your pvsc on the client ssh -R ${PORT}:localhost:${PORT} ${LOGIN_HOST} ... on the login node in a shell script referenced by the client's pvsc: let LOGIN_PORT=${PORT}+1 ncat -l ${LOGIN_HOST} ${LOGIN_PORT} --sh-exec=ncat localhost $PORT qsub ... on the compute node in your batch script mpirun ... pvserver --reverse-connection --client-host ${LOGIN_HOST} --server-port ${LOGIN_PORT} ... You could skip ncat if you have control over the sshd config, you need to enable GatewayPorts. Burlen On 08/18/2014 08:18 AM, Utkarsh Ayachit wrote: It does boil down to using reverse connection and setting up recursive tunnels so that the pvserver and tunnel back to the client. See the following on the need for portfwd and how it could potentially be helpful here. http://www.paraview.org/Wiki/Reverse_connection_and_port_forwarding#Reverse_Connection_over_a_Reverse_ssh_Tunnel_with_portfwd On Mon, Aug 18, 2014 at 11:15 AM, ehsan saei ehsan.s...@gmail.com wrote: Dear Utkarsh, Thanks for your respond. I tried the section : A forward connection over an ssh tunnel but it doesn't work. The problem is that I have to ssh to one system and then ssh to the cluster again and finally I can submit a job. Do you have any other suggestions? thanks in advance, Ehsan On Mon, Aug 18, 2014 at 4:29 PM, Utkarsh Ayachit utkarsh.ayac...@kitware.com wrote: This may be of help: http://www.paraview.org/Wiki/Reverse_connection_and_port_forwarding Utkarsh On Mon, Aug 18, 2014 at 5:52 AM, ehsan saei ehsan.s...@gmail.com wrote: Hi all, I'm new to paraview. I try to run pvserver on a cluster. The problem is that I need to ssh twice to get access to the cluster. To use pvserver I submit a job on the cluster and then I run pvserver using the command mpirun -np 12 pvserver then I pick the name and port from terminal and use it in paraview client. but paraview can't find the pvserver. Is there any way to establish a connection via these two ssh tunnels? Thanks in advance, Ehsan ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/paraview ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/paraview ___ Powered by www.kitware.com Visit other Kitware open-source projects