Differences

This shows you the differences between two versions of the page.

--- howto:remote_viz [2019/05/22 10:21]
ccrosby [Getting a Virtual Desktop on a compute node]
+++ howto:remote_viz [2021/12/09 16:42] (current)
@@ Line 1: / Line 1: @@
 ====== Visualisation servers ======
 The visualization servers are intended for single-process pre- and post-processing only, as well as GUI monitoring of running jobs.  These servers are NOT intended for parallel processing or running compute tasks.  **The system administrators will terminate processes that do not fit the above description without warning.**  However, it is now possible to get a [[http://wiki.chpc.ac.za/howto:remote_viz#getting_a_virtual_desktop_on_a_compute_node|Virtual Desktop on a compute node]], where you can use the full capabilities of the compute node without restriction.
+====== How to Videos ======
+  - Basic ssh login : [[https://youtu.be/XEPZLtDf1Bw|ssh login to Lengau]]
+  - Setting up ssh keys : [[https://youtu.be/AfXtM7t4MGs|ssh keys]]
+  - Getting a VNC session on a visualization node : [[https://youtu.be/t3-Vc7zjxfQ|VizNode VNC session]]
+  - Getting a VNC session on a compute node : [[https://youtu.be/EDpB-pB08Vo|Compute Node VNC session]]
 ====== Remote Visualization ======
@@ Line 15: / Line 22: @@
 There is a default VNC server installed on chpcviz.  Do not use it. Use TurboVNC, which can be started with a command like this:
-/opt/TurboVNC/bin/vncserver :3 -geometry 1920x1080 -depth 24
+/apps/chpc/compmech/TurboVNC-2.2.5/bin/vncserver :3 -geometry 1920x1080 -depth 24
 === First time instructions ===
-However, the default startup script that TurboVNC supplies for your X-Windows session is faulty.  We are working on providing a better default, but in the meantime, please use the following interim work-around:
+TurboVNC by default sets up a startup file that selects the lightweight window manager Fluxbox.  If you are running TurboVNC on chpcviz1 or chpclic1 you can also use the friendlier window managers Mate or XFCE4.
-  * When starting up a VNC session for the first time on this system, start the default VNC server rather than TurboVNC.
-  * As with TurboVNC, the vncserver will ask you to specify a password if this is a first usage.
-  * You can immediately kill the vncserver, you only need its XWindows startup script as a template.
-  * Change directory into $HOME/.vnc
-  * ''cp xstartup xstartup.turbovnc''
-  * Open xstartup.turbovnc in your favourite editor, and change the file so that it looks like the example below.
-  * The reason for going through the above process is to make sure that xstart.turbovnc has the right permissions.  You can also just create the file in a text editor, and afterwards correct the permissions: ''chmod 0700 xstartup.turbovnc''
-  * **A word on Window managers**: Mate and Xfce4 provide desktops, with menus, etc. Fluxbox is a minimalist Window manager.  Fluxbox will start with a featureless black screen.  Click the right mouse button to get a menu from which you can start an Xterm.  You can resize windows with alt-right button.
-  * It is not strictly speaking necessary to start your desktop session with the vglrun wrapper, but doing so makes it unnecessary to use it when running OpenGL applications in the desktop session.
-  * Now start a TurboVNC session as per the usual manner.
-  * If you have trouble with your configuration, or you have forgotten your VNC password, simply delete the $HOME/.vnc directory and start over.
-Your xstartup.turbovnc file should look like this:
+Your $HOME/.vnc/xstartup.turbovnc file should look like this.  Please ensure that this file is executable.  You can do this with the command:  ''chmod o+x $HOME/.vnc/xstartup.turbovnc''
 <code>
 #!/bin/sh
@@ Line 52: / Line 48: @@
 The vncserver will continue running even after logging out. If you are no longer going to use it, please kill the server as follows:
-/opt/TurboVNC/bin/vncserver -kill :3
+/apps/chpc/compmech/TurboVNC-2.2.5/bin/vncserver -kill :3
 where :3 should be changed to whichever display the server has been running on.
+=== Troubleshooting ===
+A known problem is that the VNC server is not compatible with Python-3.7.  If you have a Python-3.7 module loaded in your environment, unload it first in order to start up the VNC server.
@@ Line 134: / Line 133: @@
 ===== Shut down the TurboVNC session when done =====
-/opt/TurboVNC/bin/vncserver -kill :3
+/apps/chpc/compmech/TurboVNC-2.2.3/bin/vncserver -kill :3
 will shut down the VNC server for display 3, freeing up resources for other users.
@@ Line 150: / Line 149: @@
 === Launch the VNC server ===
-Make sure that you have a suitable $HOME/.vnc/xstartup.turbovnc file:
+Make sure that you have a suitable $HOME/.vnc/xstartup.turbovnc file. The TurboVNC installation has been customized to generate a suitable version of this file be default when it is run for the first time, but if you have difficulties, ensure that it looks like this:
 <code>
@@ Line 164: / Line 163: @@
 Now launch the VNC server:
 <code>
-/apps/chpc/compmech/TurboVNC-2.2.1/bin/vncserver :1 -depth 24 -geometry 1800x1000
+/apps/chpc/compmech/TurboVNC-2.2.3/bin/vncserver :1 -depth 24 -geometry 1800x1000
 </code>
 Use a resolution that fits your display.  Make note of the compute node hostname.
+=== Launching the VNC server without an interactive node ===
+The process described above has an important vulnerability.  If you lose the interactive ssh session because of a network glitch, you will also lose the VNC session.  A better approach is to launch the VNC session from a normal PBS job script, which could look like this:
+<file bash runVNC.qsub>
+#!/bin/bash
+#PBS -l select=1:ncpus=4
+#PBS -q serial
+#PBS -l walltime=2:00:00
+#PBS -P MECH1234
+#PBS -o $HOME/vncsession.out
+#PBS -e $HOME/vncsession.err
+#PBS -m abe
+#PBS -M justsomeuser@gmail.com
+###  This following line will write the hostname of your compute node to the file hostname.txt
+hostname > hostname.txt
+/apps/chpc/compmech/TurboVNC-2.2.5/bin/vncserver :1 -depth 24 -geometry 1600x900
+sleep 2h
+/apps/chpc/compmech/TurboVNC-2.2.5/bin/vncserver -kill :1
+</file>
+Obviously customise this script to suit your own circumstances.  The above script will provide 4 cores for two hours.  DO NOT use more than 4 cores in the VNC session.  If you intend using a full compute node, use the smp queue and request 24 cores.  If you need more than 2 hours, specify the walltime as well as the sleep time accordingly.  Get the compute node hostname either by looking in the file hostname.txt or by by querying PBS: ''qstat -awu username'' will give you the jobnumbers of all your jobs (please substitute "username" with your OWN username).  ''qstat -n1 jobnumber'' will give you the hostname of the compute node(s) that you are using for that job.
 === Build an ssh tunnel to the compute node ===
@@ Line 174: / Line 197: @@
 </code>
 As usual, use **your** username and compute node, not jblogs and cnode1234!
 === Connect your VNC client ===
-Now, as before, fire up your VNC client, preferably TurboVNC, and connect to port 5901 (or 1 in VNC shorthand) on localhost.  Once connected, you will be confronted with a blank black screen.  Click your right mouse button to pop up a small menu, and select xterm, which will give you a small terminal.  You can resize the window by holding down the alt key and the right mouse button, and dragging the mouse.  Refer to the [[http://fluxbox.org|Fluxbox homepage]] if you need help with other operations.
+Now, as before, fire up your VNC client, preferably TurboVNC, and connect to port 5901 (or 1 in VNC shorthand) on localhost.  Once connected, you will be confronted with a blank grey screen.  Click your right mouse button to pop up a small menu, and select xterm, which will give you a small terminal.  You can resize the window by holding down the alt key and the right mouse button, and dragging the mouse.  Refer to the [[http://fluxbox.org|Fluxbox homepage]] if you need help with other operations.
 === Running Interactive Software ===
 Up to this point, the process has been basically identical to using a visualization node.  However, **the compute nodes do not support VirtualGL**, as they do not have dedicated graphics cards.  All is not lost however:
   - Software GUIs with menus, etc. will generally just work.
-  - Software linking dynamically to OpenGL libraries will probably work well with the chpc/compmech/mesa/19.0.4_swr module.  The currently installed Mesa-19.0.4 supports software rendering using either LLVMpipe or Intel's swr.  By default the module activates the LLVMpipe method, but this is easily changed: ''export GALLIUM_DRIVER=swr'' or ''export GALLIUM_DRIVER=llvmpipe''.  The advantage of the LLVMpipe implementation is that it supports a more recent version of OpenGL.
+  - Software linking dynamically to OpenGL libraries will probably work well with the chpc/compmech/mesa/20.2.2_swr or chpc/compmech/mesa/19.1.2_swr modules.  The currently installed Mesa-20.2.2 supports software rendering using either LLVMpipe or Intel's swr.  By default the module activates the LLVMpipe method, but this is easily changed: ''export GALLIUM_DRIVER=swr'' or ''export GALLIUM_DRIVER=llvmpipe''.
-  - Older programs, such as Paraview-4.3 ''/apps/chpc/compmech/CFD/ParaView-4.3.1-Linux-64bit/bin/paraview'' work very well with the Mesa-19.0.4 implementation.  More recent ParaView versions are built with --mesa-swr and --mesa-llvm support.  Although these work well with X-forwarding, they don't work in the VNC environment.  We are not sure why, but we are working on it.
+  - Older programs, such as Paraview-4.3 ''/apps/chpc/compmech/CFD/ParaView-4.3.1-Linux-64bit/bin/paraview'' work very well with the Mesa-20.2.2 implementation.  More recent ParaView versions are built with --mesa-swr and --mesa-llvm support.  Although these work well with X-forwarding, they don't work in the VNC environment.  We are not sure why, but we are working on it.
   - Some software vendors provide binaries that are statically linked to a Mesa library.  These will generally work, but may be a bit slow.
   - STARCCM+ has its own version of Mesa-SWR.  Use the command line options ''-mesa -rr -rrthreads N'' , where N is the number of cores that should be used for graphics rendering.  In this implementation, you can use up to 16 threads.
-=== Notes on OpenSWR ===
+=== Notes on Mesa Software Rendering ===
-Historically, Mesa software rendering has been a way of getting OpenGL-enabled software to work, albeit very slowly, on hardware without dedicated graphics-processing capabilities.  However, the [[http://www.openswr.org|OpenSWR]] framework makes full use of the sse and avx capabilities of modern CPUs to produce good rendering performance.   The alternative [[https://www.mesa3d.org/llvmpipe.html|LLVMpipe]] implementation has similar performance, and is available by default.
+Historically, Mesa software rendering has been a way of getting OpenGL-enabled software to work, albeit very slowly, on hardware without dedicated graphics-processing capabilities.  However, the [[http://www.openswr.org|OpenSWR]] framework makes full use of the sse and avx capabilities of modern CPUs to produce good rendering performance.   Recent versions of the alternative [[https://www.mesa3d.org/llvmpipe.html|LLVMpipe]] implementation have similar performance, and the ''apps/chpc/compmech/mesa/20.2.2_swr'' module defaults to LLVMpipe.

wiki.chpc.ac.za

User Tools

Site Tools

Differences

Page Tools