Surfaces

Hi,

Here are some remarks and ideas regarding surfaces. I’m working on
most of these items but I’m not sure yet how to add all this to the
surface dialog. I was thinking of adding an expert button to show more
advanced options.

All of these items involve computing cube values and I’m trying to
abstract this in a single class.

  • large molecules

Add lower resolutions, now we have Low = 0.36A. We could add Very Low
= 0.5A and Custom which enabled a QDoubleSpinBox next to the
resolution combobox. I already have this here and the spinbox is
updated when the resolution combobox changes. Resolutions below 1.5A
have atoms sticking out of the surface.

For large molecules, even a 1.0A resolution results in large meshes
which result in poor rendering performance. The mesh resolution is
currently taken from the vdw surface cube and I don’t know if it makes
sense to “decouple” this. My guess would be that atoms would stick out
again. I tried to change this but couldn’t get this to work (had some
problems with the normals I think). Another options would be to use a
mesh simplification algorithm but I have no experience with this.
Ideas are welcome :slight_smile:

  • electrostatic potential vdw surfaces

At the moment it is possible to color vdw surfaces by electrostatic
potential but the “color mixing” is primitive. I have just pushed a
patch to gerrit to improve the color transitions and some improvements
to the way the ESP is computed (i.e. include formal charges when
hydrogens are added). Some before after screenshots:

1CRN before: http://imagebin.org/110524
1CRN after: http://imagebin.org/110525
1DRF after: http://imagebin.org/110526

The current implementation computes the ESP for each vertex in the
surface mesh. It uses the NeighborList class with a 7A cut-off which
is too low for electrostatics. Considering all atoms would be possible
using QtConcurrent (and OpenCL) and a Cube from which vertex ESP is
interpolated (see below).

Use different charges (OBChargeModel).

  • other properties

Like ESP, other properties (e.g. lipophilicity, …) could be mapped
to surfaces.

  • solvent accessible surface

We could use an external program.
The oldest algorithm is “rolling” a probe sphere with radius 1.4A over
the vdw surface.
It’s possible to do this using a convolution in Fourier space
(requires 3D FFT with which I have little experience, interesting
approach though)
A Monte Carlo algorithm might be easy to implement
(QtConcurrent/OpenCL performance might be acceptable)
Less cavities reduces the mesh size.
Again, ideas are welcome…

  • OpenCL

I’ve written a class that makes it easy to run various OpenCL kernels
to compute Cube elements (e.g. vdw surface, esp, …) from atom data
(positions, radius, charge). The performance is very impressive here
(using Gefore GTX260) with a 25x speedup compared to the QtConcurrent
implementation. The class is OpenCL only at the moment but
QtConcurrent could be added to use this class for performing all atom
based cube computations mentioned in this mail. Although OpenCL could
be used for multi-core CPUs too, QtConcurrent isn’t an additional
dependency.

Are there any objections to adding OpenCL capabilities to the main
repository (through gerrit)? All OpenCL code would be optional of
course.

Cheers,
Tim

On Fri, 20 Aug 2010 15:21:52 +0100, Tim Vandermeersch
tim.vandermeersch@gmail.com wrote:

  • solvent accessible surface

We could use an external program.
The oldest algorithm is “rolling” a probe sphere with radius 1.4A over
the vdw surface.
It’s possible to do this using a convolution in Fourier space
(requires 3D FFT with which I have little experience, interesting
approach though)
A Monte Carlo algorithm might be easy to implement
(QtConcurrent/OpenCL performance might be acceptable)
Less cavities reduces the mesh size.
Again, ideas are welcome…

I’ve seen GEPOL93 used in a few places (e.g. ADF, Gaussian) - I’ve only
skimmed the paper, but it seems based on placing spheres around each atom
and then creating more spheres between atoms in an iterative sort of way.

The paper describing the algorithm:
http://onlinelibrary.wiley.com/doi/10.1002/jcc.540151009/abstract
The code:

-Ian Kirker

problems with the normals I think). Another options would be to use a
mesh simplification algorithm but I have no experience with this.
Ideas are welcome :slight_smile:

Well, Marcus works for “the marching cubes” people, so presumably he might be able to find some people to help with mesh simplification. There’s also MeshLab which is from the QuteMol people:
http://meshlab.sourceforge.net/

Use different charges (OBChargeModel).

  • other properties
    Like ESP, other properties (e.g. lipophilicity, …) could be mapped
    to surfaces.

Yes, I think we need a general mechanism to allow mapping property X to surface Y. For example, I’ve seen some cool work mapping the LUMO density onto the VdW surface for reactivity.

Are there any objections to adding OpenCL capabilities to the main
repository (through gerrit)? All OpenCL code would be optional of
course.

No, I think this would be an excellent development for 1.1. I commented previously on some work in VMD that allows computing orbitals using OpenCL and they often get much better performance. I think the cube/surface code is perfect for GPU processing. Some users may not benefit, but I think we’ve tried to make Avogadro forward-looking where possible.

I also think there are some QtOpenCL classes in the labs.

-Geoff

On Fri, Aug 20, 2010 at 6:06 PM, Geoffrey Hutchison
geoff.hutchison@gmail.com wrote:

problems with the normals I think). Another options would be to use a
mesh simplification algorithm but I have no experience with this.
Ideas are welcome :slight_smile:

Well, Marcus works for “the marching cubes” people, so presumably he might be able to find some people to help with mesh simplification. There’s also MeshLab which is from the QuteMol people:
http://meshlab.sourceforge.net/

I’ll look into this. I have some initial succes with generating SAS
(i.e. the mesh) but the interpolated normals are not always correct.

Use different charges (OBChargeModel).

  • other properties
    Like ESP, other properties (e.g. lipophilicity, …) could be mapped
    to surfaces.

Yes, I think we need a general mechanism to allow mapping property X to surface Y. For example, I’ve seen some cool work mapping the LUMO density onto the VdW surface for reactivity.

Can all properties you intend to use be expressed as a cube? I’d have
to check how the number of cube points relate to the number of
vertexes though. If there are less vertexes than cube points, it makes
sense to compute it for vertexes directly.

In any case, I think we should add a iso-surface type where the user
can specify a cube from the available cubes (This could be any kind of
cube: from file, vdw surface, ESP, …). There will be some overlap
but there are minor differences.

Surface Types:

  • Van der Waals: compute shape function cube → create iso-surface
    → optional coloring
  • Solvent Accessible: compute shape function cube → create
    iso-surface → optional coloring
  • Electrostatic Potential: Uses a cube from QM? If there is no cube
    available, we can compute one → iso-surfaces (red & blue) [color
    by should be disabled or hidden]
  • Iso-Surface: create iso-surface from user specified cube
    [additional combobox, hidden for other types] → optional coloring
    [only available in advanced mode?]

Color By:

  • Nothing: color set in engine
  • Electrostatic Potential: red - white - blue
  • new color types…
  • “Cube Names”: since this data can be anything, user specified colors
    might be nice [advanced mode?]

We currently have a Cube::VdW type but I think we should generalize
this to Cube::Shape with the convention that the data points are the
distance from the shape’s surface. Negative inside, positive outside.

It might be a good idea to store information about coloring somewhere.
The Mesh class seems an appropriate place. When available, the
information could be used by the surface engine to render a scale or
legend.

Are there any objections to adding OpenCL capabilities to the main
repository (through gerrit)? All OpenCL code would be optional of
course.

No, I think this would be an excellent development for 1.1. I commented previously on some work in VMD that allows computing orbitals using OpenCL and they often get much better performance. I think the cube/surface code is perfect for GPU processing. Some users may not benefit, but I think we’ve tried to make Avogadro forward-looking where possible.

Ok, once the code is ready for review I’ll push to gerrit.

I also think there are some QtOpenCL classes in the labs.

Yes, but since it is not part of Qt yet, it would be an additional
dependency. I’m currently using the cl.hpp C++ bindings.

-Geoff