VMD-L Mailing List
From: Axel Kohlmeyer (akohlmey_at_gmail.com)
Date: Thu Dec 23 2010 - 04:01:03 CST
- Next message: leila karami: "conversion of gromacs trajectory file (xtc) to amber trajectory file (mdcrd)"
- Previous message: JC Gumbart: "Re: rmsd with 2 different structures using serial numbers"
- In reply to: Corenflos, Steven: "Bad Length and GLXBadLargeRequest errors"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
steve,
On Wed, Dec 22, 2010 at 4:57 PM, Corenflos, Steven <scorenfl_at_indiana.edu> wrote:
> The researchers in my lab are attempting to use the VMD 1.8.7 64-bit binary on an Ubuntu Linux 8.04 server. They connect to it via ssh with X-forwarding. They can't do it on their desktops because the high-atom systems they're modeling require the extra RAM of the server.
to a large degree, this can be adjusted by some changes in the
respective work flow. and either run VMD scripted and without
display or reduce the amount of data being processed interactively
and then transfer before processing (e.g. debug the scripts to be
run on the large data set with a small data set, or strip off unneeded
molecules from the trajectory before most of the analysis).
> I understand this is sub-optimal as that's a lot of information to send over the network but I'm not sure there's a better way to do it locally but using the resources of the remote machine. Any suggestions there would be appreciated.
it is _particularly_ suboptimal for the purpose of handling large
systems. all the "work" is being transferred via encapsulating
it into the X protocol and then offloaded to the OpenGL capability
of the individual X-server. i'd say that rather than having to upgrade
all client machines with high-end graphics, you'd be better off to
use mid-level graphics and add memory. that will also extend the
useful life of those machines.
have a look at virtualgl: http://www.virtualgl.org/
that would actually be much better for this kind of situation.
you only have to run a vnc viewer on the client machine
which would then be a true thin client (you could even run the
viewer as a java applet through a webbrowser)
> Unfortunately lately we've been getting errors and VMD seems unable to render what they need. The VMD window opens but is blank. Below is a sample of the output from VMD. Searching the mailing list I found one instance of these errors before and it said that it *may* be related to problems with the X server but I wasn't clear about the appropriate solution if that is the case.
GLX support (that is OpenGL over X) on linux has historically always been
spotty at best and never really worked well unless you had the exact same
libraries and hardware on both ends of the connection. it looks like you have
some really underpowered graphics on the client side and use the native
OpenGL support shipped with your distribution. the error messages come
from some protocol incompatibilities, but it is impossible to say without
being an expert from which end they originate, probably on both sides.
the first thing i would recommend to do is to update to the current nvidia
drivers and libraries (on both sides) and keep your fingers crossed.
but you'll probably be better off with the virtualgl solution, but that would
be a lot of work to set up and - again - requires some changes in the workflow.
even with the nvidia drivers, though, the nvs graphics chips would be
able to do much on very large systems.
cheers,
axel.
> Any help would be greatly appreciated!
> Thanks,
> -Steve
>
> user_at_remoteserver:~/L1$ vmd L1.pdb
> rlwrap: Command not found.
> Info) VMD for LINUXAMD64, version 1.8.7 (August 1, 2009)
> Info) http://www.ks.uiuc.edu/Research/vmd/
> Info) Email questions and bug reports to vmd_at_ks.uiuc.edu
> Info) Please include this reference in published work using VMD:
> Info) Humphrey, W., Dalke, A. and Schulten, K., `VMD - Visual
> Info) Molecular Dynamics', J. Molec. Graphics 1996, 14.1, 33-38.
> Info) -------------------------------------------------------------
> Info) Multithreading available, 8 CPUs detected.
> Info) Free system memory: 15173MB (94%)
> Info) No CUDA accelerator devices available.
> Warning) Detected X11 'Composite' extension: if incorrect display occurs
> Warning) try disabling this optional X server feature.
> Info) OpenGL renderer: Quadro NVS 290/PCI/SSE2
> Info) Features: STENCIL MDE MTX NPOT PP PS
> Info) GLSL rendering mode is NOT available.
> Info) Textures: 2-D (8192x8192), 3-D (2048x2048x2048), Multitexture (4)
> Info) File loading in progress, please wait.
> Info) Using plugin pdb for structure file L1.pdb
> Info) Using plugin pdb for coordinates from file L1.pdb
> Info) Determining bond structure from distance search ...
> Info) Finished with coordinate file L1.pdb.
> Info) Analyzing structure ...
> Info) Atoms: 7075
> Info) Bonds: 7171
> Info) Angles: 0 Dihedrals: 0 Impropers: 0 Cross-terms: 0
> Info) Bondtypes: 0 Angletypes: 0 Dihedraltypes: 0 Impropertypes: 0
> Info) Residues: 455
> Info) Waters: 0
> Info) Segments: 1
> Info) Fragments: 1 Protein: 1 Nucleic: 0
> XRequest.135: BadLength (poly request too large or internal Xlib length error) 0x5400091
> XRequest.135: GLXBadLargeRequest 0x2
> XRequest.135: BadLength (poly request too large or internal Xlib length error) 0x2
> XRequest.135: GLXBadLargeRequest 0x2
> XRequest.135: BadLength (poly request too large or internal Xlib length error) 0x2
> XRequest.135: BadLength (poly request too large or internal Xlib length error) 0x2
> XRequest.135: GLXBadLargeRequest 0x2
>
-- Dr. Axel Kohlmeyer akohlmey_at_gmail.com http://goo.gl/1wk0 Institute for Computational Molecular Science Temple University, Philadelphia PA, USA.
- Next message: leila karami: "conversion of gromacs trajectory file (xtc) to amber trajectory file (mdcrd)"
- Previous message: JC Gumbart: "Re: rmsd with 2 different structures using serial numbers"
- In reply to: Corenflos, Steven: "Bad Length and GLXBadLargeRequest errors"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]