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 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:

If the drivers don't work, there are two ways to handle the remote display issue. If you are doing remote display from another workstation, then solution 1 is probably best. From a cluster either can work: 1) 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. 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 either. 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. This requires two programs