Alas, there are still bugs and inconsistancies in VMD. Following is a list of known problems and a description of how to work around them.
  • DEC Alpha support: At long last, the VMD source compiles on DEC Alpha systems. VMD still has a small number of runtime problems due to fact it is not 100% 64-bit-clean yet. We will not be shipping pre-compiled versions of VMD for the DEC Alpha machines until we fix these problems.
  • The OpenGL versions of VMD use the standard GLX routines to ask for a visual that supports stereoscopic display. VMD then proceeds to use the standard GLX mechanisms for performing buffer swaps on the stereo visual. Some SGI systems will return a visual that supports a special form of stereo requiring special handling (i.e. the normal GLX calls have no effect). VMD does not presently contain the code necessary to support these systems.
  • Versions of VMD built with the XForms 0.88 libraries do not respond to changes in the light enable/disable box in the display form. This problem occurs with versions of VMD compiled with xforms 0.88 and possibly others. Versions of VMD built with the older 0.81 version of xforms do not have this problem, but there were other problems which necessitated the upgrade to xforms 0.88. The FLTK builds of VMD do not have these problems, but are not ready for general use yet.
  • There are a small number of rendering bugs in VMD related to the connections between tubes and beta sheets, and between tubes in the "cartoon" representation. These will hopefully be fixed in the release version of VMD 1.2. (there are tiny gaps between the end of tubes, sheets, or cartoons in some circumstances)
  • Mesa cannot, to our knowledge, support stereoscopic display due to the lack of a full GLX implementation. GLX is the X server extension that handles hardware double buffering, stereoscopic display, and vertical retrace synchronization. Future versions of Mesa may include a complete implementation of GLX, which would allow true double buffering and stereoscopic display.
  • The depth cue and antialias commands don't work -- neither the text commands nor the buttons in the display form control the depth cue and antialias settings in any deterministic fashion. The cause of these problems has been determined, and they are being addressed for future releases of VMD.
  • Reading some DCD files with fixed atoms doesn't work -- this appears to be a problem with our DCD reader, which was written in C to read a Fortran-written binary data file. It could be a problem with the reverse-engineering of the format, or perhaps a difference in formats between different machines.
    Workaround: either:
    • don't use fixed atoms in the DCD file
    -or-
    • write the DCD file into a set of PDB files with a simple numeric extension (eg, "s.pdb.1", "s.pdb.2", ...) then read them in by hand or with a script, such as:
      proc read_converted_dcdfile {basename num {molid top}} {
          set mol [molinfo $molid get id]
          for {set i 1} {$i <= $num} {incr i} {
              animate read pdb "$basename.$i" $mol.$i
          }
      }
      
  • Changing some of the atom information (secondary structure classification, beta and occupancy values, etc.) doesn't update the graphics display automatically. Workaround: press the "Apply Changes" button on the graphics form.
  • Reading records of type 7 (triangle normals) from a Raster3D input script (such as the one produced from 'ungrasp') doesn't work because VMD mistakenly expects a non-existent RGB color triplet at the end of the line.
    Workaround: Use the following awk script to convert the records.
    cat inputfile.r3d | awk 'flg == 0 {print} flg==1 {print $0, "0 0 0";
       flg=0} /^7/ && NF ==1 {flg=1}' > outputfile.r3d
    
    This has a slight chance of modifying the header information, so double check that before you use it.
  • The colors aren't the same between VMD and Raster3D. Raster3D uses the square root of the RGB value of an object. VMD doesn't compute that factor, so the output Raster3D files will have an RGB which needs to be squared, and the RGB values of a Raster3D input file will need to be, er.., square-root'ed.