From: Axel Kohlmeyer (
Date: Tue Jun 27 2006 - 19:53:00 CDT

On Wed, 28 Jun 2006, Brett Pemberton wrote:

BP> John,


BP> The situation (as it has been explained to me by the VMD user) is that
BP> he wishes to use vmd to interact with a namd job running on our cluster.
BP> Since the compute nodes aren't accessible to his PC, he must ssh to the
BP> head node of the cluster, and run VMD there, where it can talk to the
BP> namd job.

not necessarily. you could also tunnel the IMD (=interactive MD)
connection through an ssh tunnel (there should be a tutorial for
IMD somewhere on the VMD homepage that should you get you started
and then you only need to know the port to forward to the cluster).
that connection should be comparatively low throughput compared
to the graphics and you (or your 'customer') has the additional
benefit of getting the full acceleration of the graphics card.

the GLX transport layer on linux is not very reliable and
tunneling this through ssh is (currently) asking for trouble.
in the rare cases where it worked for me, i had to have the
_same_ (i.e. identical to the version number) driver on both


BP> The cluster head node is the machine with the ati card. His (and my)
BP> machines both have nvidia cards.
BP> VMD tells me
BP> Info) Multithreading available, 2 CPUs detected.
BP> Info) OpenGL renderer: GeForce FX 5200/AGP/SSE2
BP> Info) GLSL rendering mode is NOT available.
BP> Info) Textures: 2-D (4096x4096), 3-D (512x512x512), Multitexture (4)
BP> This is the same, whether I use ssh X forwarding, or allow VMD to
BP> connect to my X server remotely.
BP> thanks,
BP> / Brett
BP> On Tue, 2006-06-27 at 17:15 -0500, John Stone wrote:
BP> > Hi,
BP> > In general it's not usually a good idea to run VMD through SSH,
BP> > as the graphics performance will be terrible (independent of the
BP> > other problems you're having). If you want to run remotely, I'd
BP> > recommend using a normal X connection instead of tunnelling through
BP> > ssh, if you care about speed and must display remotely. In the specific
BP> > situation you've got, VMD should be detecting the ATI driver on
BP> > the remote display and automatically limiting itself to prevent
BP> > problems due to bugs in the ATI driver, but it's possible that
BP> > this isn't happening for some reason. Can you send me the startup
BP> > messages you get from VMD when it remote displays to the ATI box?
BP> > If you're using the MESA ATI driver on the ATI box, that may be
BP> > the source of trouble, but I should be able to tell from your
BP> > startup messages what's going on there.
BP> >
BP> > Thanks,
BP> > John Stone
BP> >
BP> >
BP> > On Tue, Jun 27, 2006 at 03:52:41PM +1000, Brett Pemberton wrote:
BP> > > Sorry for the semi-repost, but I've subbed to ask more about an email in
BP> > > the archives.
BP> > >
BP> > >
BP> > >
BP> > > I'm experiencing the exact same problems, running vmd remotely over ssh.
BP> > > Machine with VMD is an ibm e326, x86_64, running Fedora Core 5. Host
BP> > > machine (fails on many) in my case, is an i386 running FC5 as well.
BP> > >
BP> > > The host machine has an nvidia card, with the nvidia drivers. The vmd
BP> > > machine has an ati card with no 3rd party drivers installed.
BP> > >
BP> > > setting "VMDSIMPLEGRAPHICS 1" as suggested does work, however I'd like
BP> > > to avoid that.
BP> > >
BP> > > Can you please advise how I can "change drivers", as mentioned in the
BP> > > post?
BP> > >
BP> > > thanks,
BP> > >
BP> > > / Brett
BP> > >
BP> > >
BP> > > --
BP> > > Brett Pemberton - VPAC Systems Programmer
BP> > > - (03) 9925 4899
BP> >
BP> >
BP> >

Axel Kohlmeyer
   Center for Molecular Modeling   --   University of Pennsylvania
Department of Chemistry, 231 S.34th Street, Philadelphia, PA 19104-6323
tel: 1-215-898-1582,  fax: 1-215-573-6233,  office-tel: 1-215-898-5425
If you make something idiot-proof, the universe creates a better idiot.