| Both sides previous revision
Previous revision
Next revision
|
Previous revision
|
howto:remote_viz [2020/10/07 16:11]
ccrosby [Getting a Virtual Desktop on a compute node] |
howto:remote_viz [2021/12/09 16:42] (current)
|
| There is a default VNC server installed on chpcviz. Do not use it. Use TurboVNC, which can be started with a command like this: | There is a default VNC server installed on chpcviz. Do not use it. Use TurboVNC, which can be started with a command like this: |
| |
| /apps/chpc/compmech/TurboVNC-2.2.3/bin/vncserver :3 -geometry 1920x1080 -depth 24 | /apps/chpc/compmech/TurboVNC-2.2.5/bin/vncserver :3 -geometry 1920x1080 -depth 24 |
| |
| |
| 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. | 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. |
| |
| 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> | <code> |
| #!/bin/sh | #!/bin/sh |
| The vncserver will continue running even after logging out. If you are no longer going to use it, please kill the server as follows: | The vncserver will continue running even after logging out. If you are no longer going to use it, please kill the server as follows: |
| |
| /apps/chpc/compmech/TurboVNC-2.2.3/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. | 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. |
| |
| |
| #PBS -m abe | #PBS -m abe |
| #PBS -M justsomeuser@gmail.com | #PBS -M justsomeuser@gmail.com |
| /apps/chpc/compmech/TurboVNC-2.2.3/bin/vncserver :1 -depth 24 -geometry 1600x900 | ### 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 | sleep 2h |
| /apps/chpc/compmech/TurboVNC-2.2.3/bin/vncserver -kill :1 | /apps/chpc/compmech/TurboVNC-2.2.5/bin/vncserver -kill :1 |
| </file> | </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 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. | 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. |
| |
| |
| |
| === Connect your VNC client === | === 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 === | === 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: | 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 GUIs with menus, etc. will generally just work. |
| - Software linking dynamically to OpenGL libraries will probably work well with the chpc/compmech/mesa/19.1.2_swr module. The currently installed Mesa-19.1.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''. 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.1.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. | - 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. | - 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. | - 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. Recent versions of the alternative [[https://www.mesa3d.org/llvmpipe.html|LLVMpipe]] implementation have similar performance, and the ''apps/chpc/compmech/mesa/19.1.2_swr'' module defaults to LLVMpipe, because it supports more recent OpenGL features. | 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. |
| |
