VMD-L Mailing List

From: John Stone (johns_at_ks.uiuc.edu)
Date: Tue May 11 2004 - 13:10:40 CDT

Hi guys,
  Yes, I would guess that Surf ran his machine out of memory, and
even if it hadn't, he would have lost out when VMD went to read in the
resulting surface mesh etc. VMD doesn't have any internal limits on
the maximum number of atoms other than 32-bit integer indexing and a
maximum of 8 bonds per-atom. VMD will gladly render surface meshes
containing several million triangles, though your video card may not
be so happy about it. I made a huge MSMS surface of a 400,000 atom
virus capsid on a Sun V880z with a bunch of RAM earlier this spring.
You can see a small image of it in the top "spotlight" entry here:
  http://www.ks.uiuc.edu/Research/vmd/spotlight/

In rendering that image, my VMD 1.8.2 instance was using around 1.5
gigabytes of RAM. Since then, I have made some improvements
and bug fixes in VMD that greatly reduce the amount of memory required
to render such an image. With the latest test version of VMD 1.8.3,
I can now render the same virus capsid with a detailed MSMS representation
in 833MB of memory. Rendering the same structure using Surf would
probably require less memory as the MSMS surfaces store separate colors at
every vertex, whereas Surf only stores one color per triangle.

It is conceivable that VMD could be made to use even less memory
for large surfaces like these, but its difficult to do so without
dropping support for the CAVE, FreeVR, and other rendering systems
that require VMD to use shared memory geometry lists. To do this, we'd
have to use a single copy of the surface geometry in memory, right now
there are two, one maintained by the graphics code and one by the MSMS
interface. They are organized differently which is why there are two
copies of the surface data. One is organized for maximum OpenGL
rendering efficiency, and the other is space efficient and is organized
for fast updating when coloring methods are changed etc. At best though,
the most you could hope to save would be to reduce the VMD memory usage for
this structure to say 512MB or so. The MSMS surface created for this
400,000 atom virus capsid ends up as 882,000 OpenGL triangle strips,
with an average of 8 triangles per strip, for a grand total of just
over 7 million triangles. It takes 84 MBytes just to store a single
copy of the floating point coordinates for the triangle vertices, not
counting connectivity data, colors, triangle strip data replication, etc.

Clearly the best way to go for large virus capsids would be to use
symmetry operations to draw the 60 identical subunits from a single
instance of a much smaller number of atoms. This would save memory
for both the atom storage as well as the size of the resulting mesh
data. VMD's rendering code knows how to draw periodic cells already,
but we don't presently have an interface to let the user define their
own transformations, so there's not currently an easy way to exploit
it for this purpose. That'd definitely be the way to go for structures
like these viruses however, as it'd reduce the memory consumption by
a factor of 60, and the rendering performance would be as good or better
than for the full structure. Perhaps we can work in this direction
for a version of VMD subsequent to VMD 1.8.3.

  John Stone
  vmd_at_ks.uiuc.edu

On Tue, May 11, 2004 at 05:05:08PM +0200, Axel Kohlmeyer wrote:
> hmmm,
>
> asking to compute the SAS for so many atoms on
> such a small machine is asking for trouble.
> i'd guess your machine swapped itself to death.
>
> even if the computation of the SAS worked, it is
> unlikely, that your machine will survive the
> handling of the grid points. just the storage of
> the atoms coordinates in single precision floating
> point variables will eat over 40MB.
>
> it would be interesting to see, where the real
> internal limits of vmd in terms of grid points
> and number of atoms really are. perhaps john
> can comment on that.
>
>
> axel kohlmeyer
>
>
> > Max edge length = 1.200
> > Malloc of zero or illegal length!!
> > length = 0
> > Malloc of zero or illegal length!!
> > length = 0
> > ..............................find_sol_cons() warning: sol is
> > somewhat away from
> > vertex (0.001048).
> > .......................................find_sol_cons() warning: sol is
> > somewhat
> > away from vertex (0.001038).
> > find_sol_cons() warning: sol is somewhat away from
> > vertex (0.001904).
> > ...................find_sol_cons() warning: sol is somewhat
> > away from vertex (0.
> > 003807).
> > .................find_sol_cons() warning: sol is somewhat
> > away from vertex (0.00
> > 3555).
> > ...............find_sol_cons() warning: sol is somewhat away
> > from vertex (0.0018
> > 41).
> > ........................find_sol_cons() warning: sol is somewhat
> > away from verte
> > x (0.001221).
> > ........find_sol_cons() warning: sol is somewhat away
> > from vertex (0.002722).
> > ...find_sol_cons() warning: sol is somewhat away from
> > vertex (0.004053).
> > .........find_sol_cons() warning: sol is somewhat away
> > from vertex (0.003754).
> > ...find_sol_cons() warning: sol is somewhat away from
> > vertex (0.001486).
> > ..........find_sol_cons() warning: sol is somewhat away
> > from vertex (0.002303).
> > ..find_sol_cons() warning: sol is somewhat away from
> > vertex (0.001241).
> > ..............find_sol_cons() warning: sol is somewhat away
> > from vertex (0.00230
> > 0).
> > ..find_sol_cons() warning: sol is somewhat away from
> > vertex (0.010190).
> > .....find_sol_cons() warning: sol is somewhat away from
> > vertex (0.001572).
> > ..................find_sol_cons() warning: sol is somewhat
> > away from vertex (0.0
> > 02974).
> > .
> >
> >
> >
> >
> >
> >
>
> --
>
>
> =======================================================================
> Dr. Axel Kohlmeyer e-mail: axel.kohlmeyer_at_rub.de
> Lehrstuhl fuer Theoretische Chemie Phone: ++49 (0)234/32-26673
> Ruhr-Universitaet Bochum - NC 03/53 Fax: ++49 (0)234/32-14045
> D-44780 Bochum http://www.theochem.ruhr-uni-bochum.de/~axel.kohlmeyer/
> =======================================================================
> 

-- 
NIH Resource for Macromolecular Modeling and Bioinformatics
Beckman Institute for Advanced Science and Technology
University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801
Email: johns_at_ks.uiuc.edu                 Phone: 217-244-3349              
  WWW: http://www.ks.uiuc.edu/~johns/      Fax: 217-244-6078