| Both sides previous revision
Previous revision
Next revision
|
Previous revision
|
howto:remote_viz [2020/11/09 17:09]
ccrosby |
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. |
| |
| |
| - 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/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''. | - 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-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. | - 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. |
