MC User's Guide

0.1

Table of Contents

  1. Overview
  2. Information and Resources
  3. Obtaining MC
  4. Frequently Asked Questions
  5. Installation Instructions
  6. Author Information
  7. Copyright and Terms of Use
  8. GNU LGPL
NOTE: dummyThis documentation provides information about installation, configuration, and general usage of the MC libraries. Information about the programming interface provided by the MC software can be found in the Programmer's Guide.

Overview

MC (Manifold Code) is a small self-contained parallel adaptive multilevel finite element software package. MC is an adaptive multilevel finite element kernel designed to be used collaboratively with several related research tools such as MALOC, SG, and APBS. MC can be used as a small stand-alone adaptive multilevel finite element code, or it can be used with these other tools which extend the capabilities of MC in various ways. MC is designed to numerically approximate the solutions of covariant divergence-form second-order nonlinear elliptic systems of partial differential equations on domains with the structure of Riemannian two- and three-manifolds. To accomplish this task as accurately and efficiently as possible, MC employs simplex triangulations of the domain manifold, Petrov-Galerkin finite element methods, a posteriori error estimation, adaptive mesh refinement and un-refinement, continuation, Newton methods, multilevel methods, and a new low-communication approach in parallel adaptive finite element methods.

MC was designed primarily to simulate the large deformation nonlinear elastic behavior of complicated hyperelastic bodies, although it can also be used for problems such as the nonlinear Poisson-Boltzmann equation arising in biophysics, the drift-diffusion semiconductor equations, and the Hamiltonian and momentum constraints in the Einstein equations. Ongoing projects include extending MC to numerically evolve the Ricci flow equations in Geometry and the full Einstein equations in relativity physics. Examples of MC applied to some of these problems can be found in the MC gallery.

MC is a class library written in Clean OO C. "Clean" refers to the fact that the language is both legal C++ and legal ANSI/ISO/Standard C, and can be compiled with any standard C or C++ compiler. "OO" refers to the programming style employed -- object-oriented. An Clean OO C implementation consists of a set of "Objects" (Clean C structs) which are operated on by a collection of "methods" (Clean C subroutines) which always have a pointer to the Object as their first argument. This special argument is always written as "thee", analogous to the implicit "this" pointer in C++. (An Clean OO C implementation can be turned into a C++ implementation with a simple AWK/SED or Perl Script.) As a result of this Clean OO C implementation, MC can be used as a set of C++-like class libraries, it can be safely software engineered into other large software packages, and it can be built on just about any UNIX-like platform with either a C or a C++ compiler, including e.g. Linux, IRIX, and Win32. To use some of the graphics and parallel computing features, your platform must also have some form of standard INET sockets (WINSOCK will work). MC is easily buildable from source on any UNIX-like system, and uses a GNU autoconf build environment.

Unusual and interesting features of MC

The following design features of MC make it somewhat unusual and also quite general.

  • Abstraction of the PDE: you define your elliptic system only through a nonlinear weak form over a domain manifold, along with an associated linearization form, also defined everywhere on the domain manifold.
  • Abstraction of the domain: you define your domain manifold by giving a polyhedral representation of the topology, along with an abstract set of coordinate labels of your own interpretation, possibly consisting of multiple charts. MC works only with the topology of your domain (i.e., the connectivity of your polyhedral representation). The geometry of your domain manifold is provided only through your own form definitions, which contain the manifold metric information.
  • Dimension-independence: exactly the same code paths are taken for both two- and three-dimensional problems (as well as for higher-dimensional problems). To achieve this dimension-independence, MC employs the simplex as its fundemental geometrical object.

Geometry representation and manipulation in MC

The RInged VERtex (RIVER) datastructure is at the heart of the geometry engine in MC. This datastructure maintains a mesh of simplices in 2D or 3D with near minimal storage, and yet provides fast (constant- and linear-time) access to all information necessary for refinement, un-refinement, and discretization of an operator. This datastructure also allows the 2D and 3D cases to be treated in a uniform way, with one implementation covering both cases. An interesting feature of this datastructure is that the stuctures used for vertices, simplices, and edges are all of fixed size, so that a fast array-based implementation is possible, as opposed to a less-efficient list-based approach commonly taken for unstructured meshes. For an example illustrating how the datastructure, as well as all of the adaptivity algorithms using the datastructure, can be implemented entirely in an array-based language like FORTRAN or MATLAB, have a look at MCLite, which is a MATLAB version of MC for 2-manifolds.

Computational geometry primatives (such as computing determinants of small matrices to high precision) are quite difficult to implement robustly in floating point arithmetic. To avoid these types of problems in a robust yet efficient way in MC, all low-level geometric primatives are built on top of Jonathan Shewchuk's remarkable adaptive-precision geometric predicates.

Refinement and Un-refinment in MC

MC is based on the simplex, and for adaptive refinement it employs:

  • 2D bisection [longest edge (Rivara)]
  • 3D bisection [longest edge (Rivara) or marked edge (Arnold-Mukherjee/Bansch/ Joe-Liu/Maubach)]
Bisection is first used to refine a subset of the simplices in the mesh (selected according to some error estimates), and then bisection is used recursively on any non-conforming simplices produced, until a conforming mesh is obtained (finite termination of this procedure can be shown for each of the above refinement procedures). The code can also perform the following refinement procedures for uniform refine ments of a given simplex mesh:
  • 2D quadra-section [augmented regular (Bank)],
  • 3D octa-section [augmented regular (Bey/Ong/Zhang)]

Algebraic construction of the coarse problem is supported, in both the 2D and 3D fully unstructured settings. As a result, the underlying multilevel algorithm is provably convergent in the self-adjoint-positive case. The multilevel algorithm has provably optimal convergence properties under the standard regularity assumptions, and is nearly-optimal under very weak regularity assumptions. The user must define a sequence of an algebraic prolongation operators in a standard YSMP-row-wise matrix datastructure; MC then constructs the algebraic multilevel hierarchy from the prolongation operators. An automated construction of provably stable prolongation operators for use in the multilevel algorithms and in the two-level domain decomposition algorithms used in MC is under development.

Discretization in MC

A choice of piece-wise linear or piece-wise quadratic finite element basis functions are provided. The quadratic functions are provided mainly to avoid the locking problem when simulating near-incompressible elastic materials, and for dealing with the second derivative terms appearing in the Riemann tensor in the gravitational field equations. While MC provides standard linear and quadratic elements by default, the assembly procedure and linear algebra datastructures support a wide variety of element types; in particular, different element types may be used for different components of a coupled elliptic system.

Solution of nonlinear systems in MC

When a system of nonlinear finite element equations must be solved in the code (for the case of a nonlinear elliptic system, or during the implicit time-stepping evolution of a nonlinear evolution problem), a global inexact-Newton procedure is employed, where the linearization systems are solved by linear multilevel methods. Elliptic systems are solved using either a "Gummel" de-coupling procedure, or using a coupled Newton method. Solutions with folds or bifurcations are handled with natural parameter or pseudo-arclength continuation.

The two-layer "Clean OO C" implementation of MC

MC is a set of class libraries written in pure Clean OO C, and is therefore completely portable (from PC to iMac to CRAY). This portability is achieved through the use of a very small but powerful abstraction layer, called MALOC (Minimal Abstraction Layer for Object-oriented C). The MALOC class library layer provides abstract datatypes, memory management routines, timing routines, machine epsilon, access to UNIX and INET sockets, MPI, and so on. All things that can vary from one architecture to another are abstracted out of MC and placed in the MALOC layer. To port MC to a new architecture, only the small MALOC abstraction layer needs to be ported. (Porting MALOC usually means only typing: "./configure ; make")

As a result of this pure Clean OO C implementation, MC can be used as a set of C++-like class libraries, it can be safely software engineered into other large software packages, and it can be compiled on just about any UNIX-like platform with either a C or a C++ compiler, including e.g. Linux, IRIX, and WindowsNT. To use some of the graphics and parallel computing features in MC provided by the underlying MALOC library, your platform must also have some form of standard INET sockets (WINSOCK will work).

Using MC as a set of class libraries

MC can be used as a collection of class libraries from within another application code. One creates an MC object, and then simply applies the appropriate methods to the MC object (or its sub-objects). Each object maintains its own internal state, giving the class libraries the property of re-entrancy: several MC objects can be created and manipulated to solve different PDEs on different meshes within the same application at the same time. This can be used for example to construct Gummel-like iterations for elliptic systems.

Using MC through the MCshell

While MC can be used cleanly as a collection of class libraries, it can also be used entirely through the MCshell, which is a mostly Bourne-compatible command shell. The MCshell maintains an internal environment state, and can be used to execute MCshell scripts using a high-level MC manipulation language. All important features of the MC class libraries can be manipulated by using only the MCshell, so that MC can be used either interactively, or in batch mode by executing scripts. The MCshell produces a history file of the session, which can be re-executed to recreate the previous session exactly. In addition, MCshell scripts can be executed during an interactive session by using normal Bourne shell syntax (e.g., ". filename.mcsh"). If you have ever used a command shell under UNIX, then you will be able to easily get started using MC through the MCshell. (In fact, since the MCshell is mostly Bourne-shell compatible, you could actually use it as your UNIX login shell.)

Geomview and GMV graphics through pipes and sockets in MC

MC performs all I/O through an abstracted software I/O layer in MALOC, which provides access to files, pipes, UNIX domain sockets, and INET sockets. This allows several instances of MC to work collaboratively on a problem in a distributed memory computing environment, as well as to make use of the University of Minnesota's Geomview as the primary display utility. MC can produce OFF-compatible output for use by Geomview as file input, or it can write OFF output directly to pipes, UNIX domain sockets, or INET sockets.

A socket "bridging" utility called MC-bridge is provided with MC which bridges UNIX and INET sockets, so that MC executing on a remote machine can communicate with Geomview listening to a UNIX domain socket on the local machine, using INET sockets on the local and remote machines, and then an INET-to-UNIX domain socket bridge on the local machine. MC can also produce GMV-compatible output files for use in rendering displays of solution functions with GMV from Los Alamos National Laboratory.

A minimal Geomview clone called SG can be used with MC. It mimics most of the basic features of Geomview for displaying planar polygons. It can be hung on a UNIX domain socket like Geomview. Unlike Geomview, SG can also listen directly to INET sockets, and it will run on either X11 or Win32 platforms (such as Windows NT). In the case of Windows NT, SG uses the WINSOCK API for INET socket access. The graphics in SG is done in an entirely platform-independent manner using OpenGL. The window-system specific connection to X11 or Win32 is made through "WGL" extensions to Win32 under NT, or using the SGI "GLw" widget set on any X11 platform.

Parallel computing with MC

MC implements a new approach to the use of parallel computers with adaptive finite element methods, based on the idea of local a priori and local a posteriori error estimates. The algorithm has two interesting features: (1) almost no communication is required (no boundary exchanges), and (2) only a few lines of an existing sequential adaptive code must be changed in order to implement the parallel algorithm. The new algorithm was developed jointly with Randy Bank and is described in the following paper. The communication primatives required are quite simple, and can be implemented using sockets rather than a more serious communication library such as MPI. In either case, MC accesses INET sockets and/or MPI functions through the MALOC abstraction library, and as a result MC can be used in parallel on any heterogeneous collection of UNIX and/or WINSOCK platforms.


Information and Resources

Detailed information about MC can be found in the User's Guide and Programmers's Guide.

While MC is itself a self-contained software package, it is one of several components of FETK (the Finite Element ToolKit). FETK consists of the following components written in Clean OO C:

  • MALOC - Minimal Abstraction Layer for Object-oriented C programs.
  • PUNC - Portable Understructure for Numerical Computing.
  • SG - Socket Graphics mesh display tool (uses MALOC).
  • MC - Manifold Code finite element package (uses MALOC and PUNC).
  • MCX - MC eXtension libraries (uses MALOC, PUNC, and MC).

MALOC is self-contained, and requires only an ANSI-C compiler on a UNIX or Win32 platform. PUNC, SG, and MC are also self-contained, but rely on MALOC having been previously installed on the platform. Additional features of MC are enabled if PUNC is available, but PUNC is not required to build MC. The MC eXtension libraries MCX are constructed on top of MALOC and MC, and in order install and use MCX one must first correctly configure and install both MALOC and MC. MCX is made up of a number of individual libraries developed by members of our group, or contributed by one of a number of colleagues. More information about FETK can be found on the FETK website:


Obtaining MC

MC is copyrighted, but is redistributable in source and binary form under the following license.

(The MC source code will be available in Spring 2003.)


Frequently Asked Questions

What is MC and what does MC stand for?

See the Overview.

How to I obtain a copy of the MC binaries and/or source code?

See the Obtaining MC section.

I managed to get a copy of "mc-VERSION.[i386|src|tar].[rpm|gz]"; how do I now install MC?

See the Installation Instructions.

You gave me a "patch.gz" file to fix a bug in MC; how do I apply the patch?

To apply patches to upgrade MC to a new version, you first obtain the patch from me or my webpage as a single file with a name like "patch.gz". You apply the patch after you have unpacked the mc.tgz file as described above. To apply the patch, cd into the directory containing the root MC directory (called "mc" after unpacking mc.tgz) and execute the "patch" program as follows (the patch program exists on most UNIX machines):

  • gzip -cd patch.gz | patch -p0

Patch files are simply the output from a recursive "diff" that are used to represent all differences between two directory trees. For example, to create a patch representing the changes from version 1.0 of MC (in directory mc_1.0 for example) to version 1.1 of MC (e.g. in directory mc_1.1), I would normally type the following:

  • diff -r -u -N mc_1.0 mc_1.1 > patch1
  • gzip -v patch1
which would produce the gzipped patch file "patch1.gz". If you had previously installed version 1.0 of MC but would like to upgrade to version 1.1 of MC, you could just download the file "patch1.gz" and apply the changes using the program "patch" as above, rather than downloading and reinstalling the entire version 1.1 of MC.

I really don't know what I'm doing; how to I get more documentation for MC?

The User's Guide and the Programmers's Guide contain all of the MC documentation.

Why did you develop MC? There are many other finite element packages, right?

I wanted to solve some nonlinear elliptic and parabolic systems that arise in geometry and physics using adaptive finite element methods, as part of some projects I became involved in at Caltech in 1994. It quickly became clear that there were no publicly available software packages for handling some of the more difficult features of these problems (rapid nonlinearities, three spatial dimensions, systems, complex differential operators, and manifold domains requiring multiple charts).

I decided to try to build an adaptive multilevel finite element code based on the 2-simplex and the 3-simplex, for general coupled second-order nonlinear elliptic systems on 2- and 3-manifolds. The idea was to be as general, simple, and robust as possible; the only real restriction I made early on was that the principle part of the differential operator had to be in divergence form, so that piecewise linear finite elements had a chance of making sense. This has now loosened up a bit, due to the fact that the element itself has been abstracted out and placed in the domain of the user-defined code.

The design philosophy followed Randy Bank's two-dimensional finite element code PLTMG in many ways, with appropriate modifications to handle the three-dimensional case as transparently as possibly, always keeping in mind the need to handle general nonlinear systems on manifold domains.

Another reason that I wrote MC is that I find I don't really understand an algorithm until I implement it. In this sense, MC is an algorithm research tool that I have grown from scratch to allow me to experiment with adaptive multilevel finite element methods, numerical continuation methods, iterative methods for linear and nonlinear algebraic systems, and so forth. I use it in conjunction with MCLite (a 2D version of MC written entirely in the MATLAB language) for research and teaching.

What is in all of these subdirectories? Where exactly is "MC"?

MC consists of several (class) libraries from which you will call routines to handle your application. You will need to write a main driver program (and any supporting routines you need to define your problem) and then link to the libraries. Alternatively, you can use MC's builtin lexer/parser in an interactive session by starting up "mcsh", the MCshell. The MCshell looks and feels very much like bash (a superset of the bourne shell), and you can write small scripts to control almost everything in the MC class library, completely through the MCshell, without writing a line of C or C++.

As described in the file "INSTALL", you will build all of the libraries in one shot for your particular architecture, along with various test programs to verify that the various pieces are functioning correctly. The libraries end up in , and the header files are in subdirectories in .

After the build, you will be ready to work with your particular application main driver, and you just need to link to the libraries. Sample main drivers and makefiles are in the subdirectories. Things are setup for you to work completely in one of those directories. Of course, all you really have to do is link to the MC libraries, so you can use it how you like; the makefiles and drivers in just provide an example of how to get MC working correctly. I actually develop and use MC by working mainly from one of those subdirectories.

The following directory tree is created when you unpack the MC "mc.tgz" distribution file by following the instructions in the INSTALL document:

                                     mc
                                     |
                         ------------------------
                        /      |     |      |    \ 
                       config doc examples src tools
The src directory has the additional subdirectory structure for each library forming MC:
                                     src
                                      |
                        ----------------------------
                       /    |   |    |    |    |    \
                     aprx  bam base gem mcsh  nam  pde 
Within each library source directory is an additional subdirectory, "mc". The "mc" subdirectory contains public headers for the library, representing the library API; these headers will be installed in the specified header install directory during the install procedure after building MC.

The following is a brief description of each subdirectory of the package.

    mc             - The entire MC package
    mc/config      - GNU Autoconf scripts and non-unix config files
    mc/doc         - MC documentation
    mc/examples    - Complex examples and data files for using MC
    mc/src         - MC source code (all source and headers)
    mc/src/aaa_inc - Header installation tools
    mc/src/aaa_lib - Library installation tools
    mc/src/*/mc    - The MC headers (API)
    mc/src/aprx    - Source for M. Holst's APRX (APRoXimation Methods)
    mc/src/base    - Source for M. Holst's BASE (MC foundation headers)
    mc/src/bam     - Source for M. Holst's BAM  (Block Algebraic Methods)
    mc/src/gem     - Source for M. Holst's GEM  (Geometry Engine Methods)
    mc/src/mcsh    - Source for M. Holst's MCSH (The MC Shell)
    mc/src/nam     - Source for M. Holst's NAM  (Nonlinear Algebraic Methods)
    mc/src/pde     - Source for M. Holst's PDE  (Partial Diff. Equation)
    mc/tools       - Some binary tools for use with MC

Okay, I seem to have installed MC correctly; how do I actually use it now?

Using MC is pretty simple; it is a very object-oriented implementation, although it is written in C. It is actually written in an object-oriented form of "Clean C", which is the overlapping subset of ANSI/Standard C and C++, so you can compile the code as a legal C++ or ANSI/Standard C code. Using the code consists of constructing objects (represented by C structs) and manipulating these objects using appropriate methods (represented by C functions which follow a certain object-oriented prototype convention).

You provide the definition of your differential operator by providing a PDE object. This object contains several pieces of information, including information about the spatial dimension, number of unknowns per spatial point, and so on. This object must also contain pointers to the functions defining the various functions in your PDE, such as the weak form of your differential operator evaluated at a point, a linearization bilinear form evalulated at a point, and a dirichlet boundary function. By looking at the example files "mypde.c" in , you will see exactly how to construct this PDE object. Some example PDE definitions also appear in .

Once you have built this PDE object as in the example file pde.c, you then construct a MCsh object, which requires your PDE object as an input parameter. At this point, you can use appropriate methods to operate on the MCsh object to accomplish the solution of your PDE. The example drivers main.c in show how to call the more important methods to operate on the MCsh object, such as discretize your elliptic system with piecewise linear finite elements over 2- or 3-simplices, solve the discrete system, do a posteriori error estimation, mesh refinement, solve again, etc, in a way modeled after Randy Bank's two-dimensional code "PLTMG". The sample main driver main.c includes a single header file , which includes everything the MC package needs. The sample problem file mypde.c also includes this single header file, which provides the definition of the PDE object, as well as prototypes for the functions which the PDE object function pointers will point to.

Finally, you specify your manifold domain by using a particular MCsh method, giving the name of the mesh file as a parameter. The mesh file has a very simple format; there are example mesh files in the .

Rather than giving a more detailed explanation of the usage of MC here, it seems to me that the best way to see how it works is to study the example main program and supporting routines in the subdirectories; these are well-documented, and you should be able to modify the driver to handle your application. Or, simply start up mc, the MCshell.

What is the class hierarchy? How are the various libraries related?

Detailed information on the class relationships can be found in the Programmers's Guide. The following directed graph shows the class library dependencies. (This tends to evolve as MC is developed.)

   MALOC ==> base ==> gem ==> aprx ==> nam ==> mcsh
              ||              /\ /\
              ======> bam ====|| ||
                      /\         ||
                      ||         ||
                      ||         ==== pde (PDE is partially user-supplied)
                      ||
                     PUNC (if installed)

Wait! I have a bunch of other questions, such as:

  • What in tarnation is "Clean OO C"?
  • Why is MC written in Clean OO C rather than C++ or Objective-C?
  • Why is MC written on top of this other package with a weird name (MALOC)?
  • I want to extend MC and/or MALOC in some way; what is the "Coding Style"?
  • I wrote a cool extension; how do I get it included in MC and/or MALOC?
These and other related questions are addressed in the MALOC FAQ, which is distributed as the README file in the MALOC source distribution.

Installation Instructions

Available distribution formats

MC is distributed in both binary format (as a binary RPM file mc-VERSION.i386.rpm for i386-based versions of Linux) and in source format (as a source RPM file mc-VERSION.src.rpm and as a gzipped tar file "mc-VERSION.tar.gz").

Installation using the binary RPM file

The following rpm command will install all of the MC headers and libraries into /usr/local/include and /usr/local/lib, and will install the MC documentation into /usr/share/doc/packages/mc:

    rpm -Uvh mc-VERSION.i386.rpm

Installation and rebuilding from sources using the source RPM file

The following rpm command will unpack the source rpm file "mc-VERSON.src.rpm" into the MC gzipped tar file containing the sources called "mc-VERSION.tar.tar.gz" and into a small RPM spec file called "mc-VERSON.spec":

    rpm -Uvh mc-VERSION.src.rpm
The sources can then be unpacked and built using the directions for the gzipped tar file below. Alternatively, the following rpm command will do these steps for you:
    rpm -bp mc-VERSION.spec

Rebuilding binary and source RPM files from the gzipped tar file

The MC sources contain the RPM spec file "mc-VERSON.spec" in the root source directory; as a result, rebuilding the RPM files from sources can be done using the rpm command:

    rpm -ta mc-VERSION.tar.gz
The result will be the corresponding source and binary rpm files, named "mc-VERSON.src.rpm" and "mc-VERSION.i386.rpm". Normally, these files are written to /usr/src/redhat/SRPMS and /usr/src/redhat/RPMS respectively, but you must be logged in as root for these to work. The destination directories can be overriden using arguments to the rpm program (see the rpm manpage).

Installation and building from sources using the gzipped tar file

The following command will unpack MC into a number of subdirectories and files on any UNIX machine (and on any WinNT machine with the GNU-Win32 tools gzip and tar).

    gzip -dc mc.tgz | tar xvf -
MC is essentially a multilevel adaptive finite element "kernel". It is designed to be easily extended through the use of extension packages which are constructed on top of MC. The extension packages that I have written such such as MCgp (MC for Geometric PDEs) are also distributed as gzipped tar files (e.g. "mcgp.tgz"). The installation instructions for such extension packages are identical to the instructions below for the MC kernel (e.g., substitute "MCgp" for every occurance of "MC" below).

Building the package using the GNU "configure" shell script and "make"

The "configure" shell script in the "mc" directory (the toplevel directory created when you unpacked the MC tgz file) will build the entire package. This is a standard GNU autoconf-generated configuration script. For a list of the possible configuration options, type:

    ./configure --help
You should be able to build MC by simply typing:
    ./configure
    make
    make install
However, it is often advantageous to keep the original source directory pristine; the configure script can actually be run outside the source tree, which will keep all files created by the build outside the source tree. (This idea is related to the section below describing how to build binaries for multiple architectures at the same time using the same source tree, and requires that your version of make has the VPATH facility, such as GNU make.) For example, I build MC in a separate directory from the source tree as follows:
    gzip -dc mc.tgz | tar xvf -
    mkdir mc_build
    cd mc_build
    ../mc/configure
    make
    make install

Building binaries for multiple architectures in the same source directory

If you have a version of "make" that supports the VPATH facility (such as any recent version of GNU make), then you can build the package for multiple architectures in the same source directory (in fact, you can do the compiles at the same time without collisions). This is very useful if you have your home directory on an NFS volume that you share among multiple architectures, such as SGI, Linux, etc. To build MC for all the systems at the same time, you simply make an additional subdirectory in the main MC directory for each architecture, copy "configure" into it, "cd" into the subdirectory, and then install as above. For example, on a linux machine you would do the following:

    mkdir linux
    cp configure linux/.
    cd linux
    ./configure
    make
    make install
If you mount the same NFS home directory on for example an OpenStep box, you could at the same time do the following:
    mkdir next
    cp configure next/.
    cd next
    ./configure
    make
    make install
Again, both builds can actually be done outside the source tree rather than in a subdirectory of the source tree, as described in the previous section.

Building shared libraries rather than static libraries

(MIKE: give an overview of libtool.)

Rebuilding the configure script and the Makefile.in files

If for some reason you actually need to rebuild the configure script or the Makefile.in files using the GNU autoconf suite, you should read the block of documentation at the top of the configure.in file. The commentary I put there explains exactly how the GNU autoconf suite must be used and in what order, and exactly what files are produced at each step of the process. A script called "bootstrap" which automates this process is located in the config subdirectory of the MC source tree.

Platform-specific information

Below is some platform-specific build/usage information for MC.

  • Linux (Source: M. Holst, UCSD)

    Things should work as described above.

  • FreeBSD/NetBSD/OpenBSD (Source: M. Holst, UCSD)

    Things should work as described above.

  • OpenStep (Source: M. Holst, UCSD)

    Things should just work, but you may have to set the CC environment variable as follows before typing ./configure:

        export CC="/bin/cc"
    
    or you might need to use:
        export CC="/bin/cc -ObjC"
    

  • IRIX (Source: M. Holst, UCSD)

    If you are on a 64-bit IRIX box such as an Onyx, Octane, or Origin, set the CC environment variable as follows before typing ./configure:

        export CC="/bin/cc -64"
    
    If you are on a 32-bit IRIX box such as an O2 or Indy, set the CC environment variable as follows before typing ./configure:
        export CC="/bin/cc -32"
    

  • Win32 (Source: M. Holst, UCSD)

    Unless you have the Cygwin environment, you need to use one of the included project file collections for one of the commercially available ANSI C or C++ compilers for the Win32 environment.

What you end up with

Once the build completes via the configure/make procedure above with no errors, you will want to cd into an example directory to get started, e.g. "cd examples/generic" (or "cd mc/examples/generic"). In the example directories you will find:

    mypde.c    --> Example partial differential equation definition file
    mypde.h    --> The prototypes of the functions that you must provide
    myelm.c    --> Example element definition file
    main.c     --> compiled and linked with mypde.c to become --> mcsh
The "main.c" example uses MC's builtin-lexer/parser to parse commands in an interpreted interactive session I call the "MCshell", or "mcsh". You will want to start with mcsh by typing "./mcsh", which will fire up a shell that looks and feels like bash (a bourne-compatible command shell). Type "help" at the command prompt for help.

If mcsh works like it was designed, you won't need any more information to use MC. If you want to know more about the details of the numerical methods in MC, or about the implementation details such as the socket communication layer, have a look in for documentation.

Using MC on a parallel computer

MALOC provides abstractions to both INET sockets and MPI for communication support in parallel computing software. MC inherits this capability from the MALOC library. Control of the overall structure is accomplished through MCshell (enhanced MALOC-shell) scripts you write, or through calls to the MC library. (Going through the MCshell is much simpler, and you have access to all the communication possibilities through the MCshell.)

Several instances of MC can be used collaboratively in parallel through the use of either INET sockets or MPI. Control of the overall structure is accomplished through the MCshell scripts you write. You can also write your own main program and use the vmp library directly (using vmp's "Oracle" class is quite straightforward), but going through the MCshell is much simpler, and you have access to all the communication possibilities through the MCshell.

Several examples of scripts which perform parallel adaptive elliptic solves may be found in the subdirectory. To run one of the scripts and actually get some parallel computation to occur requires the following (e.g. for an MPI-based computation, using the MPICH startup environment):

  1. Build MC with MPI enabled; this is usually accomplished simply by giving an argument to the GNU configure script:
        ./configure --enable-mpi
    
    Note that if your installation of MPI is located in an unusual directory, then the configuration script may have trouble finding the MPI library (libmpi.a) or the MPI header file (mpi.h). If so, then MPI will not be enabled. The configure script prints out the state of affairs quite clearly as to whether it found the library and the header. If you have MPI and configure is not finding it, then read the section of this installation guide entitled "Getting MC to find your installation of MPI" for several different solutions.

  2. Copy one of the parallel MCshell scripts from into your working directory as "rc.mcsh".

    --Alternatively--

    Copy one of the parallel MCshell scripts from into some other directory that will contain all input and output files for your run as "rc.mcsh", AND then set the environment variable MCSH_HOME to that directory. If I wanted all file i/o to occur in the temporary directory /tmp/mc, I would place the following in my ~/.bash_profile file:

        export MCSH_HOME="/tmp/mc"
    
    and I would place the following in my ~/.ssh/environment file:
        MCSH_HOME=/tmp/mc
    
    (This last is required if you use ssh for your MPI remote shell.)

  3. Start up mcsh using MPICH's "mpirun" command as follows:
        mpirun -np 4 mcsh
    

  4. Sit back and wait for the processes to finish their work.

Getting MC to find your installation of MPI

If your installation of MPI is located in an unusual directory, then the configuration script may have trouble finding the MPI library (libmpi.a) or the MPI header file (mpi.h). Again, the configure script prints out the state of affairs quite clearly as to whether it found the library and the header. If you have MPI and configure is not finding it, then here are several possible solutions, each of which usually works. They are listed in preferred order (i.e. you should try Solution 1 first, and if that doesn't work try Solution 2, and so on).

  • Solution 1:

    Have your system administrator install MPI in a proper system directory so that MC (and other AUTOCONF-based codes) can find it!

  • Solution 2:
    1. Find the location of libmpi.a and mpi.h on your system, either by asking your sysadmin, poking around yourself, or (if you have it) using the "locate" utility:
          locate mpi.h
          locate libmpi.a
          locate libmpich.a
      
      On my Redhat6.2 Linux box, the following output is produced:
          bash:~% locate mpi.h
          /usr/share/mpi/include/mpi.h
          bash:~% locate libmpi.a
          bash:~% locate libmpich.a
          /usr/share/mpi/lib/libmpich.a
      
      Therefore the MPI header is installed as:
          /usr/share/mpi/include/mpi.h
      
      and the MPI library is installed as:
          /usr/share/mpi/lib/libmpich.a
      
    2. Before running the configure script, preset the FETK_MPI_INCLUDE and FETK_MPI_LIBRARY environment variables to point to the directories containing mpi.h and libmpi.a (or libmpich.a). Under bash, using the results from the example above, I would do this as follows:
          export FETK_MPI_INCLUDE=/usr/share/mpi/include
          export FETK_MPI_LIBRARY=/usr/share/mpi/lib
          ./configure --enable-mpi
          make clean; make; make install
      
      The configure script should now report that it successfully found the library and header and thus enabled MPI, and then MC should compile without error.

Debugging using the ElectricFence malloc debug library

To allow ElectricFence to intercept all calls to malloc, free, and related dynamic memory allocation system calls, simply run the configure script as follows:

    ./configure --enable-efence
    make clean; make; make install

Author Information

MC (Manifold Code, or Michael's Code) was conceived, designed, and implemented over several years by Michael Holst, beginning with an initial implementation in 1994. Various colleagues have contributed ideas and/or code to MC (see the credits list below).

    MC (Manifold Code)
    Copyright (C) 1994-2006

    Michael Holst               TELE:  (858) 534-4899
    Department of Mathematics   FAX:   (858) 534-5273
    UC San Diego, AP&M 5739     EMAIL: mholst@cam.ucsd.edu
    La Jolla, CA 92093 USA      WEB:   http://cam.ucsd.edu/~mholst
MC was designed to be the finite element kernel on top of a platform abstraction layer MALOC, and is usually used with a socket graphics tool called SG (both MALOC and SG were also developed by Michael Holst). MC was developed almost entirely on a home-grown 90Mhz Pentium PC running various flavors of Linux and [Free|Net|Open]BSD, using primarily GNU, BSD, and other free software development tools. Most of the development occurred during the hours of 10pm to 2am on a daily basis for several years, under heavy influence of Starbuck's coffee, with helpful advice provided by Mac and Mochi (two cats knowledgable in socket programming and numerical analysis).

MC is currently released under the GNU LGPL (GNU Lesser General Public License). What this means is that you may redistribute it and/or modify it under the terms of the GNU LGPL as published by the Free Software Foundation; either version 2.1 of the license, or (at your option) any later verison. You should have received a copy of the GNU LGPL with this distribution of MC; a copy can be found here. If you did not receive a copy of the GNU LGPL, please write to me and also write to: The Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 0211\ 1-1307 USA.

MC was initially released under the GNU GPL (GNU General Public License). W\ hat this means is that like all GNU softare, MALOC is freely redistributable in source code form following the rules outlined in the text of the GNU GPL.

Software included in the MC source code package

A complete roadmap to the source code forming the MC package can be found above. While the core MC classes were developed by Michael Holst, the following single file is currently also included with MC:

    mc/src/gem/pred.c    - J. Shewchuk's geometric "predicates.c"
Computational geometry primatives are quite difficult to implement robustly in floating point arithmetic; we use Jonathan Shewchuk's adaptive precision predicates for our low-level geometric primatives (basically for computing determinants of small matrices).

Credits

Below is a credits list for the people that have contributed to MC in one way or another. The fields below follow the credits file format used in the Linux kernel CREDITS file to allow for easy manipulation via shell scripts. The fields are as follows:

          N: name of contributor
          E: email address
          W: web address
          P: PGP key ID and fingerprint
          D: description of primary contributions
          S: snail-mail address
N: Michael Holst
E: mholst@cam.ucsd.edu
W: http://cam.ucsd.edu/~mholst
P: 1024/0xB5212DCD
D: mc/*                      -- The package structure
D: mc/acconfig.h             -- The platform abstraction information
D: mc/configure.in           -- The GNU autoconf/automake structure
D: mc/config/*               -- The GNU autoconf/automake shell scripts
D: mc/doc/*                  -- The package documentation
D: mc/examples/*             -- The package examples
D: mc/src/aaa_inc/*          -- Library header build structure
D: mc/src/aaa_lib/*          -- Static and shared library build structure
D: mc/src/base/*             -- Foundation headers
D: mc/src/aprx/*             -- M. Holst's APpRoXimation library
D: mc/src/bam/*              -- M. Holst's Basic Algebraic Methods library
D: mc/src/gem/*              -- M. Holst's GEometry Machine library
D: mc/src/mcsh/*             -- M. Holst's MCSHell library
D: mc/src/nam/*              -- M. Holst's Nonlinear Algebraic Methods library
D: mc/src/pde/*              -- M. Holst's PDE library
D: mc/tools/*                -- Tools built on the libraries
S: Department of Mathematics
S: UC San Diego, AP&M 5739
S: La Jolla, CA 92093 USA

N: Stephen Bond
E: sdbond@illinois.edu
D: mc/maloc.spec             -- RPM support (for building src/binary RPMs)
D: mc/src/bam/*              -- Improved matrix library (supports MG and HB)
S: Department of Computer Science
S: University of Illinois
S: Urbana, IL 61801 USA

Contacting the Author

If you have questions or comments about MC, please feel free to contact me at mholst@cam.ucsd.edu.


Copyright and Terms of Use

Please acknowledge your use of MC and FETK by citing:
  • M. Holst, Adaptive numerical treatment of elliptic systems on manifolds. Advances in Computational Mathematics, 15 (2001), pp. 139-191.

This version of MC is distributed under the following guidelines:

  • MC (Manifold Code)
    Copyright (C) 1994-2006 Michael Holst

    This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

    This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

    You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.


GNU LGPL

The LGPL (GNU Lesser General Public License) below is copyrighted by the Free Software Foundation. However, the instance of software that it refers to, my package in this case, is copyrighted by myself as the author of the package. Any additional software that I distribute with my software is copyrighted by the authors of those pieces of software (see the individual source files for author information). ---Michael Holst

                  GNU LESSER GENERAL PUBLIC LICENSE
                       Version 3, 29 June 2007

 Copyright (C) 2007 Free Software Foundation, Inc. 
 Everyone is permitted to copy and distribute verbatim copies
 of this license document, but changing it is not allowed.


  This version of the GNU Lesser General Public License incorporates
the terms and conditions of version 3 of the GNU General Public
License, supplemented by the additional permissions listed below.

  0. Additional Definitions. 

  As used herein, "this License" refers to version 3 of the GNU Lesser
General Public License, and the "GNU GPL" refers to version 3 of the GNU
General Public License.

  "The Library" refers to a covered work governed by this License,
other than an Application or a Combined Work as defined below.

  An "Application" is any work that makes use of an interface provided
by the Library, but which is not otherwise based on the Library.
Defining a subclass of a class defined by the Library is deemed a mode
of using an interface provided by the Library.

  A "Combined Work" is a work produced by combining or linking an
Application with the Library.  The particular version of the Library
with which the Combined Work was made is also called the "Linked
Version".

  The "Minimal Corresponding Source" for a Combined Work means the
Corresponding Source for the Combined Work, excluding any source code
for portions of the Combined Work that, considered in isolation, are
based on the Application, and not on the Linked Version.

  The "Corresponding Application Code" for a Combined Work means the
object code and/or source code for the Application, including any data
and utility programs needed for reproducing the Combined Work from the
Application, but excluding the System Libraries of the Combined Work.

  1. Exception to Section 3 of the GNU GPL.

  You may convey a covered work under sections 3 and 4 of this License
without being bound by section 3 of the GNU GPL.

  2. Conveying Modified Versions.

  If you modify a copy of the Library, and, in your modifications, a
facility refers to a function or data to be supplied by an Application
that uses the facility (other than as an argument passed when the
facility is invoked), then you may convey a copy of the modified
version:

   a) under this License, provided that you make a good faith effort to
   ensure that, in the event an Application does not supply the
   function or data, the facility still operates, and performs
   whatever part of its purpose remains meaningful, or

   b) under the GNU GPL, with none of the additional permissions of
   this License applicable to that copy.

  3. Object Code Incorporating Material from Library Header Files.

  The object code form of an Application may incorporate material from
a header file that is part of the Library.  You may convey such object
code under terms of your choice, provided that, if the incorporated
material is not limited to numerical parameters, data structure
layouts and accessors, or small macros, inline functions and templates
(ten or fewer lines in length), you do both of the following:

   a) Give prominent notice with each copy of the object code that the
   Library is used in it and that the Library and its use are
   covered by this License.

   b) Accompany the object code with a copy of the GNU GPL and this license
   document.

  4. Combined Works.

  You may convey a Combined Work under terms of your choice that,
taken together, effectively do not restrict modification of the
portions of the Library contained in the Combined Work and reverse
engineering for debugging such modifications, if you also do each of
the following:

   a) Give prominent notice with each copy of the Combined Work that
   the Library is used in it and that the Library and its use are
   covered by this License.

   b) Accompany the Combined Work with a copy of the GNU GPL and this license
   document.

   c) For a Combined Work that displays copyright notices during
   execution, include the copyright notice for the Library among
   these notices, as well as a reference directing the user to the
   copies of the GNU GPL and this license document.

   d) Do one of the following:

       0) Convey the Minimal Corresponding Source under the terms of this
       License, and the Corresponding Application Code in a form
       suitable for, and under terms that permit, the user to
       recombine or relink the Application with a modified version of
       the Linked Version to produce a modified Combined Work, in the
       manner specified by section 6 of the GNU GPL for conveying
       Corresponding Source.

       1) Use a suitable shared library mechanism for linking with the
       Library.  A suitable mechanism is one that (a) uses at run time
       a copy of the Library already present on the user's computer
       system, and (b) will operate properly with a modified version
       of the Library that is interface-compatible with the Linked
       Version. 

   e) Provide Installation Information, but only if you would otherwise
   be required to provide such information under section 6 of the
   GNU GPL, and only to the extent that such information is
   necessary to install and execute a modified version of the
   Combined Work produced by recombining or relinking the
   Application with a modified version of the Linked Version. (If
   you use option 4d0, the Installation Information must accompany
   the Minimal Corresponding Source and Corresponding Application
   Code. If you use option 4d1, you must provide the Installation
   Information in the manner specified by section 6 of the GNU GPL
   for conveying Corresponding Source.)

  5. Combined Libraries.

  You may place library facilities that are a work based on the
Library side by side in a single library together with other library
facilities that are not Applications and are not covered by this
License, and convey such a combined library under terms of your
choice, if you do both of the following:

   a) Accompany the combined library with a copy of the same work based
   on the Library, uncombined with any other library facilities,
   conveyed under the terms of this License.

   b) Give prominent notice with the combined library that part of it
   is a work based on the Library, and explaining where to find the
   accompanying uncombined form of the same work.

  6. Revised Versions of the GNU Lesser General Public License.

  The Free Software Foundation may publish revised and/or new versions
of the GNU Lesser General Public License from time to time. Such new
versions will be similar in spirit to the present version, but may
differ in detail to address new problems or concerns.

  Each version is given a distinguishing version number. If the
Library as you received it specifies that a certain numbered version
of the GNU Lesser General Public License "or any later version"
applies to it, you have the option of following the terms and
conditions either of that published version or of any later version
published by the Free Software Foundation. If the Library as you
received it does not specify a version number of the GNU Lesser
General Public License, you may choose any version of the GNU Lesser
General Public License ever published by the Free Software Foundation.

  If the Library as you received it specifies that a proxy can decide
whether future versions of the GNU Lesser General Public License shall
apply, that proxy's public statement of acceptance of any version is
permanent authorization for you to choose that version for the
Library.