Vtk and Finite Element Solutions

Jose Paulo Moitinho de Almeida moitinho at civil.ist.utl.pt
Thu Jan 13 11:09:27 EST 2000

I have prepared some considerations about using vtk to visualize solutions
obtained from the Finite Element Method. 

Better ideas, comments and suggestions are welcome.


We (me an my research group) are working on finite element formulations which
allow us to use general functions of (nearly) arbitrary degree. Simple examples
are wavelets, trigonometric functions or polynomials of degree 10 and above.

Vtk is an alternative to represent our solutions and it is probably an
alternative to represent other finite element solutions, but immediate
implementations are sub-optimal.

This text tries to discuss possible approaches to handle this problem. If all
goes well it may evolve to the background of some general implementation and to
an even better vtk ...

To put in context the problems that are in my mind while writing this text are
of the type "represent, using a colour table, the distribution of a scalar
field in a 3D domain". The text is supposed to be "neutral", but my viewpoint
may sometimes be biased towards solid mechanics. Please correct me if it
reduces the generality of the approach.


>From the vtk mailing lists I quote

> From: Will Schroeder <will.schroeder at kitware.com>
> Date: Fri, 14 May 1999 16:28:08 -0400
> Subject: Re: Visualization of 8-Node Finite Element
> Hi Gero-
> Currently there is no support for the quadratic 8-noded hex, or for
> that matter, any higher-order cells. We have considered extending vtk
> to support arbitrary order/complexity cell types, but nothing along
> these lines is close to production. This is one area of work for which
> we (Kitware) are currently seeking funding, with the intention of
> contributing back to vtk.
> What you may wish to do (and it's painful) is to uniformly subdivided
> your hex's as you convert them / read them into vtk. Any new nodal
> points you generate should use your analysis code to create the
> interpolated values.

There have been other messages regarding the implementation of QuadraticCells.

Information has also been provided that diffpack uses vtk for the
visualization of finite element solutions. Following the reference vtkinuse at
kitware http://www.ifi.uio.no/~xingca/vtk_diffpack/tcl_gui.html it seems that
it only uses linear cells/faces. Correct?


Using vtk to represent solutions obtained using the fem is a natural idea. If
the field to be represented is linear the solution is simple: an element is a
cell and the implementation is immediate.

When other functions, or to put it in another form, something else than 4
noded tetrahedra, are used some kind of approximation must be used to represent
the non-linear field inside the elements. This text tries to discuss possible

There is also the problem to be considered that though the "exact" solution is
normally continuous the finite element solution is normally discontinuous. 

a) Whether to smooth the solution must, in my opinion, be a choice of the
user, not a need imposed by the visualization tool.

b) Furthermore the solution may be discontinuous, different materials are the
simplest example, and a straightforward finite element solution visualization
using vtk will "forget" that.

The immediate solution here is to use a different actor for each
element/subdomain, but I think that this corresponds to a considerable 
burden. Am I right?


1) Implement specific "cells", eg 6 noded tetrahedra. Unless a simple "add-on"
technique is provided this is limitative when you want to insert new types of
elements. I think that it would get even trickier when the geometry mapping is
not linear.

2) Proceed following the line described in the message above. The problem here
is that you may get an exceedingly large number of cells, and many of them may
be useless, eg because the solution is nearly linear or the element is so small
that it corresponds to a voxel (or less). Of course you may want to zoom in
afterwards, or the solution may change and the field may become nonlinear.

3) Provide an enhanced cell which would use a user provided callback procedure
to compute the value of the function at a specific point. Something similar to
what vtkProgrammableAttributeDataFilter does, but using more points inside the
cell to do the coloring (how many? one per pixel/voxel?).

When elements of higher degree are used (or more complex functions, eg 
fundamental solutions) are used this may become very heavy because there may
be the need to recalculate the solution quite often.

4) Use for each element a new class which stores an enhanced hierarchical
representation of the cell.

Initially it corresponds to a cell, but it would: 

a) assess the quality of the representation that is being used;

b) if needed, subdivide the cell, compute and store within the hierarchical
model the value of the function at the new points (user provided procedure or
some default);

c) output the solution at the new points.

If the representation conditions change the hierarchical level that is used
may also change. For a zoom out this class would revert to a simpler
representation and for a zoom in a new subdivision would be computed, but only
if the class "considers" that there will be considerable error in the piecewise
linear approximation it is currently using.

5) More ideas ???


Though I prefer alternative 4) it "scares" me because it seems to involve too
much complexity. 

If the interaction with the renderer to know what "corresponds" to each
element is simple (part a) above), then it may be viable, but if I had an
answer to all problems I would start trying it now....

This is the private VTK discussion list.  Please keep messages on-topic.
Check the FAQ at: <http://www.automatrix.com/cgi-bin/vtkfaq>
To UNSUBSCRIBE, send message body containing "unsubscribe vtkusers" to
<majordomo at gsao.med.ge.com>.  For help, send message body containing
"info vtkusers" to the same address.     Live long and prosper.

More information about the vtkusers mailing list