TUMBLE (Triangular Unstructured Mesh with Beziers in a Lagrangian Environment)

0.1

Author:

Gary L. Miller (glmiller@cs.cmu.edu)

Todd Phillips (tp517@andrew.cmu.edu)

Mark J. Olah (mjo@andrew.cmu.edu)

Introduction

The TUMBLE package is a testbed for next-generation meshing technology. Its primary features are:

1. Fully Lagrangian framework (most meshing packages are Eulerian or Eulerian/Lagrangian hybrids)
2. Explicit boundary tracking
3. Curved elements - Currently TUMBLE uses a second order Bezier basis for both geometric and functional data.
4. Modern mesh manipulation algorithms with theoretical guarantee of correctness and optimality

Thus not only does TUMBLE deal with moving elements, but also with elements with a non-linear geometry. The concepts involved with moving (Lagrangian) meshes, and curved (Bezier) elements are relatively new and untested. Accordingly, the main use of the TUMBLE package is as a testbed for new algorithms and techniques relating to Lagrangian meshes, and meshes with Bezier elements.

The ultimate goals of the authors of TUMBLE are:

1. Producing a fully Lagrangian three dimensional meshing package
2. Providing tools for that package to be run on massively parallel machines
3. Providing sound theoretical results for the correctness and complexity of the underlying algorithms

In this light, we will attempt to provide links to relevent papers, which describe the theoretical results on which TUMBLE is based. The reader will see that nearly every data-structure and algorithm employed by the TUMBLE package is extensible to three dimensions, and also to a parallel computing framework. The main reason for the existence of TUMBLE is that while many algorithms and techniques usefull for Lagrangian meshing are known, their relationship within a complete and general meshing framework is not clear. TUMBLE will demonstrate the feasibility of the techniques in two-dimensions, where prototyping and computational costs are less, yet it will not loose sight of the ultimate, three dimensional goal.

For more information see the Detailed Introduction to TUMBLE.

Installation

See Installation.

Project Layout

With the goal of providing a flexible testbed for new meshing technology, the TUMBLE project is written partly in ruby and partly in C++. The authors feel that the RUBY language provides flexibility to an evolving program, while a C++ implementation provides fast and memory efficient data structures and algorithm implementations. The SWIG program is used by TUMBLE to provide a RUBY interface to the C++ classes. While for efficiency reasons, it is not possible to write all of the code in Ruby, the philosophy is that there are several horizontal breaks in the hierarchy of classes, where it makes sense to move from C++ to RUBY in order to gain flexibility.

The current implementation of TUMBLE has evolved from an initial all RUBY prototype which still works and receives bugfixes as they are discovered in the current code. This RUBY code is self-contained and has its own documentation.

Executables

TUMBLE has several frontend ruby scripts which are used to run experiments and debug the code, these are locate din the bin directory. The files use the ruby runtime frontend code which is located in the ruby/runtime directory. For complete descriptions of the programs and available option, see the files themselves.

1. tumble-debug.rb - A debugging program using a GLUT interface. Use the -i flag to input a mesh, and type 'h' to get a list of commands
2. tumble-run.rb - This is the main runtime engine, which parses an experiment description file, and creates, initializes, and runs an experiment. It archives all generated data to an mesh repository. See the file for commandline options.
3. tumble-view.rb - A GUI for the tumble-run.rb output files. See the file for commandline options. Press 'h' for the options menu in the program.
4. tumble2eps.rb - A program to convert a mesh to EPS format. Edit the file to control behavior.

Additional Packages

TUMBLE relays on several auxiliary packages of code written by external authors. These are the other packages under the src directory apart from TUMBLE itself. These are complied as shared libraries and TUMBLE is linked against them. Several of the libraries are for ruby support, and have ruby wrapper code automatically compiled with SWIG.

1. geopredicates - A set of numerically stable geometric predicates written by Jonathan Shewchuk. These are described here.
2. staticmesh - A meshing package written by Clemens Kadow, with extensions to curved elements by Todd Phillips. This package is used only when creating an initial mesh. It is buggy and much larger than our needs. It will hopfully be replaced shortly.
3. smooth - A package used to reposition the center ControlPoint of a BezierEdge to smooth out the edge. It was written by Alex Chuna.
4. picio - A small library used for dumping an OpenGL rendering to an image file (jpeg, tiff, or png).
5. opengl-ruby - An OpenGL wrapper for ruby.
6. glut-ruby - A GLUT wrapper for ruby.

Applications

As the TUMBLE project is currently supported by the SANGRIA project whose main goal is the simulation of blood flow, the primary application of TUMBLE up to this point has been Navier-Stokes fluid flow with explicit boundaries. NavierStokes is a excellent target application for TUMBLE, as in the Lagrangian framework, the problem is linear, while in an Eulerian framework, the problem is non-linear.

The NavierStokes solver package is part of the new frontend runtime engine. Accordingly running a simulation is as simple as creating a geometry and setting parmeters in the experiment configuration file. The C++ side of the NavierStokes package is contained in src/NavierStokes while the ruby side is contained in ruby/runtime/solvers/navierstokessolver.rb. The solver uses the PETSC package to solve the resulting system of linear equations.

Runtime Engine

TUMBLE has a Ruby frontend which is able to take in a specially formetted input file, describing an experiment, and use that file to create, initialize, run, and record data from an experiment. The key idea behind the runtime framework is that an experiment is broken up into 3 main objects.

1. Model - Responsible for physical shape and size of the experiment. A Model is a ruby class which can create an initial mesh with a set of parameters. It can also move a mesh given the correct velocity function to apply, and a timestep.
2. Cleaner - A Cleaner is a ruby class which applies top-level mesh algorithms to the mesh at each timestep to ensure the mesh stays well-shaped, well-size, and accurately represents the functions it carries.
3. Solver - A Solver is a ruby class that is responsible for the functional data stored on the mesh. It sprays down initial data, and it sets up and solves a linear system to obtain a sequence approximations to the solution of a differential equation describing the physical system.

This runtime framework is essentially one big application for TUMBLE, and there is no reason why all applications should fit under this one framework, although it is the authors hope that several different applications will fit nicely in this model, thus removeing much redundant code.

This portion of code is under active development and will be documented further in the future.

Users interested in running a quick demo, can use the bin/tumble-run.rb script along with one of the example experiment scripts in test/experiments. Providing the -v flag allows visualization. As an example:

$ export TUMBLE_DIR=path/to/tumble $ export TUMBLE_REPOS=path/to/mesh/repos $ cd $TUMBLE_DIR $ ./bin/tumble-run.rb -v -t 10 -i test/experiments/tube.exp

---