The process of mesh generation represents a significant fraction of the effort in building a finite-element solution. Many people have an aversion to the very idea of mesh generation, possibly from encountering quirky and unreliable old programs. Some producers of finite-element software may capitalize on this sentiment by claiming that their program does not require meshes. Because this claim is misleading, I want to clarify some issues in the article.
These are the two basic approaches:
- Volumetric meshes (our choice). The solution space is divided in small volumes (elements). In our programs, the elements are conformal triangles in 2D and generalized boxes (hexahedrons) in 3D. Nodes are the intersections of element faces. The quantity of interest (e.g., potential in electrostatics) is defined at the nodes, which extend throughout the solution volume.
- Boundary meshes. The boundaries between physical regions are divided into areas (surface elements). Nodes, the intersections of the elements, are confined to the boundaries. Quantities of interest are calculated in the intervening volumes by taking sums over values at the surface nodes.
There are two main questions:
- Are boundary approaches mathematically better than volume methods?
- Is it easier to create boundary meshes than volume meshes?
My answers are Not necessarily and No.
To amplify, first consider mathematical effectiveness. When the media between boundaries are simple, homogenous materials, boundary methods require much less storage because there are fewer nodes. This advantage vanishes with complex materials like saturable iron. If every portion of a material has a different self-consistent property, then there must be boundaries between each portion of the medium. In this case, a boundary mesh would require about as much storage as a volume mesh. Furthermore, volume meshes have a significant advantage over boundary meshes in applications where extensive field calculations are required (as in our charged-particle orbit tracking codes Trak and OmniTrak). Such calculations are easy with a volume mesh, which has available values everywhere. It's simply a matter of collecting some local values near the point of interest and then making interpolations. On the other hand, each field calculation in a boundary-type solution involves a complex, weighted sum over a large number of surface nodes. As a result, each interpolation involves much more work.
Moving to the second issue, is it actually easier to generate a surface mesh than a volume mesh? The answer is no when you consider our mesh generation method. The 3D MetaMesh program initially fills the solution volume with a collection of box elements and then shifts nodes near boundaries to make the mesh conform to the surfaces. The initial fill procedure has no chance of error and involves negligible work. Almost all the effort is associated with the conformalization. The number of shifted nodes is about equal to the number of nodes that would be necessary to make a boundary mesh. In the end, the total number of operations are about the same.
To wrap up, although a volume mesh does require more storage, this is not a major drawback:
- A modern 64-bit with an installed memory of 8 GB or more can handle meshes with millions of nodes.
- The payoff for the extra stored values is high-efficiency field interpolation.
LINKS
