Differences between revisions 3 and 4
Revision 3 as of 2017-01-27 13:27:49
Size: 5606
Editor: SteveLudtke
Comment:
Revision 4 as of 2017-06-22 14:10:52
Size: 5877
Editor: SteveLudtke
Comment:
Deletions are marked like this. Additions are marked like this.
Line 42: Line 42:
Note: This is not the only strategy for accomplishing this task. There are several other software solutions to this problem, some free, some not. IMHO this solution is the best by far as of late 2016. Note: There are several other software solutions to this problem, some free, some not. Some solutions, like NX and x2go have reported issue with OpenGL, such as displaying mirrored images or shifting annotations (like box locations in e2boxer) by 1/2 box size. These are bugs in the underlying remote display systems, and there are no solutions for these issues other than to use a system that isn't buggy. :^( IMHO the solution below is the best by far as of mid 2017.

EMAN2 on a remote computer

EMAN uses OpenGL for all of its graphical display windows. This is separate from the X-windows protocol which supports basic remote windowing operations. Even if remote EMAN works perfectly (including OpenGL) at your site, it may not be the best strategy for several reasons. There are two sections below. One on a good strategy for working on clusters, and the other on how to make remote OpenGL actually work.

Our recommended strategy for running the EMAN GUI tools on a cluster is "Don't": 1. Remote display of graphics-intensive windows using X-windows via SSH is slow and can be resource-intensive on the cluster head-node 2. Due to the way disks are shared on clusters, if you have a job running and use the GUI in the same project, there are some seemingly innocuous things which can cause jobs to crash and potentially mess other things up. These issues don't generally occur when running locally on a desktop machine. 3. If something untoward were to happen, you may not have a readily available backup of your project

There is a standard Unix tool called 'rsync' which permits you to duplicate an entire tree of folders and files either locally or on a remote machine. The beautiful thing about rsync is that it only copies files which have changed, so it is widely used for making efficient backups, etc.

Our suggested alternative strategy is: 1) perform all GUI work on a local workstation 2) rsync the whole project (or at least the necessary parts) to the cluster 3) use the GUI on the workstation to construct the command you need to run on the cluster (the 'Command' tab in the GUI will show this) 4) run your job via the normal queuing system on the cluster 5) any time you want to check the results with the GUI, rsync the project from the cluster back to your local machine. This can be done safely even while the job is running 6) If you need to modify things in the project locally and send the files back to the cluster, either make the changes on the cluster or make sure you:

  • wait for the cluster job to finish
  • rsync from the cluster back to the local machine
  • modify the local files as necessary
  • rsync the local files back to the cluster

rsync is pretty easy to use once you get the hang of the options. There are plenty of good resources on the web to learn about it. Consider the following situation:

  • project directory on my local machine: /home/stevel/myproject
  • home directory on cluster: cluster.bcm.edu:/raid/stevel

To rsync the project to the cluster. On the local maching:

cd /home/stevel
rsync -avr myproject stevel@cluster.bcm.edu:/raid/stevel

This will create a directory called /raid/stevel/myproject on cluster.bcm.edu. This may take some time the first time you run it, since it is copying everything in the project. There are variants to the command to only copy the necessary folders to run jobs (particles, sets, info), but you must really know what you're doing to try this without causing problems.

To rsync results back to the local machine, run this on the local machine:

cd /home/stevel
rsync -avr stevel@cluster.bcm.edu:/raid/stevel/myproject /home/stevel

Remote GUI Display with OpenGL

Note: There are several other software solutions to this problem, some free, some not. Some solutions, like NX and x2go have reported issue with OpenGL, such as displaying mirrored images or shifting annotations (like box locations in e2boxer) by 1/2 box size. These are bugs in the underlying remote display systems, and there are no solutions for these issues other than to use a system that isn't buggy. :^( IMHO the solution below is the best by far as of mid 2017.

This strategy can be used to share your work desktop with your laptop when traveling, or, if you don't like the idea above, display the GUI from a cluster head-node.

VNC is a linux remote desktop sharing solution. The shared desktop can be either the actual display on the computer doing the sharing, or a secondary virtual desktop,depending on configuration. VNC has the advantage of compressing data, so even over a LAN, you generally will get noticeably better performance than by tunneling X-windows over SSH. However, regular VNC doesn't support OpenGL. Luckily the US supercomputing centers put together a solution for this, so people could display openGL content rendered on their large computers from across the country.

To do this, you will need 3 things: On the remote computer:

On the local computer:

  • TurboVNC java client -or-
  • other VNC client (may not work as well)

Once you have installed these (you will need to follow their instructions to do this, and may need root access on the remote machine, though some clusters may already have both installed):

on the local machine:

ssh remote.machine.edu
vncserver -geometry 1920x1080

log out of the remote machine, then again on the local machine:

vncviewer -tunnel username@remote.machine.edu:1

This will open a remote desktop. Open a terminal window in the remote desktop. If you wish to be able to use OpenGL programs from the terminal, you then need to run:

vglrun bash

Of course you can replace 'bash' with whatever shell you like. From within that new shell you will be able to run OpenGL programs like e2display.py and have them work properly. You should also find that the display is much more interactive than a normal remote SSH session GUI.

If the vncviewer command above doesn't work, or you didn't install the client locally, this is an alternative:

ssh username@remote.machine.edu -L5901:localhost:5901

Then use your local VNC client to connect to: vnc://localhost:5901

EMAN2/Remote (last edited 2023-03-16 15:34:56 by SteveLudtke)