PUNC (Portable Understructure for Numerical Computing) is a small standard collection of software libraries for numerical computing. The PUNC collection includes reference implementations of the standard (dense matrix) linear algebra tools BLAS and LAPACK, and also includes some newer (sparse matrix) linear algebra tools ARPACK, SuperLU, CgCode, and PMG. PUNC also provides some additional basic infrastructure such as the standard F2C header and corresponding library (libF2C), to support the use of F2C'd FORTRAN codes, and some other standard tools used to build numerical simulation software, such as the HDF5 library. While most of the libraries included in PUNC are completely stand-alone, and are the reference implementations developed by the individual library authors, PUNC also provides some Object-oriented C wrappers (written by the FETK developers) for use with Object-oriented C/C++ codes such as FETK . This is accomplished by building PUNC on top of FETK 's MALOC library.
PUNC installs it self minimally, in that if it can find a vendor-supplied version of one of its libraries, it does not build that particular library (unless the installer overrides the configuration and forces PUNC to build a particular library that already exists on the platform). At the end of the PUNC installation, you have a reference collection of the standard numerical software libraries listed above, formed from a combination of any vendor or hand-tuned libraries it found on your platform, together with any additional libraries that were built by PUNC during installation.
PUNC 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, PUNC 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). PUNC is easily buildable from source on any UNIX-like system, and uses a GNU autoconf build environment.
Detailed information about PUNC can be found in the User's Guide and Programmers's Guide.
While PUNC 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 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:
PUNC is copyrighted, but is redistributable in source and binary form under the following license. The PUNC source and binary code can be downloaded from the following locations:
PUNC uses the low-level abstraction library MALOC, which must be installed before installing PUNC.
What is PUNC and what does PUNC stand for?
See the Overview.
How to I obtain a copy of the PUNC binaries and/or source code?
See the Obtaining PUNC section.
I managed to get a copy of "punc-VERSION.[i386|src|tar].[rpm|gz]"; how do I now install PUNC?
See the Installation Instructions.
You gave me a "patch.gz" file to fix a bug in PUNC; how do I apply the patch?
To apply patches to upgrade PUNC 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 punc-VERSION.tar.gz file as described in the installation instructions. To apply the patch, cd into the directory containing the root PUNC directory (called "punc" after unpacking punc-VERSION.tar.gz) and execute the "patch" program as follows (the patch program exists on most UNIX machines):
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 PUNC (in directory punc_1.0 for example) to version 1.1 of PUNC (e.g. in directory punc_1.1), I would normally type the following:
I really don't know what I'm doing; how to I get more documentation for PUNC?
The User's Guide and the Programmers's Guide contain all of the PUNC documentation.
Why did you develop PUNC? Can't you just use BLAS and possibly LAPACK?
Yes, we definitely need to use LAPACK (built on the BLAS). However, modern PDE simulation codes involve applying, inverting, or analyzing the spectral properties of very large sparse matrices, so modern sparse matrix libraries that have much of the capabilities of LAPACK must be use. LAPACK was an update to LINPACK (direct methods and factorizations for dense and banded matrices) and EISPACK (methods for computing the eigenpairs of dense and banded matrices). SuperLU and ARPACK can be viewed as providing these same general capabilities (respectively but for sparse matrices. CgCode and PMG (two choices out of a number that could have been made) provide additional capabilities not in any of the other libraries, namely the iterative solution of large sparse linear systems using CG-type methods and Multilevel methods.
One often needs to use many or most of these tools for the development of numerical PDE simulation software, but it is often quite complex to install all of these packages and to be certain that they are working as designed on the particular platform. PUNC basically provides three things: (1) reference implementations of these libraries to flesh out your computing platform; (2) convenient portable configuration and installation of some or all of the libraries; and (3) additional basic infrastructure for using these libraries together and with other software.
What is in all of these subdirectories? Where exactly is "PUNC"?
PUNC consists of several (class) libraries from which you will call routines to handle your application. You simply link your application to the PUNC static or shared library. The MC package automatically looks for the PUNC libraries as part of its Autoconf configuration process.
punc
|
------------------------
/ | | | \
config doc examples src tools
The src directory has the additional subdirectory structure:
src
|
-----------------------------------------------------
/ | | | | | | | | \
aaa_inc aaa_lib base blas lapack arpack superlu cgcode pmg vf2c
Within each library source directory is an additional subdirectory,
"punc". The "punc" 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 PUNC.
The following is a brief description of each subdirectory of the package.
punc - The entire PUNC package
punc/config - GNU Autoconf scripts and non-unix config files
punc/doc - PUNC documentation
punc/examples - Complex examples and data files for using PUNC
punc/src - PUNC source code (all source and headers)
punc/src/aaa_inc - Header installation tools
punc/src/aaa_lib - Library installation tools
punc/src/*/punc - The PUNC headers (API)
punc/src/base - Source for M. Holst's BASE (PUNC foundation headers)
punc/src/pmg - Source for M. Holst's PMG (Parallel MultiGrid)
punc/src/blas - Source for Reference Implementation of BLAS
punc/src/lapack - Source for Reference Implementation of LAPACK
punc/src/arpack - Source for Reference Implementation of ARPACK
punc/src/superlu - Source for Reference Implementation of SuperLU
punc/src/cgcode - Source for Reference Implementation of CgCode
punc/src/vf2c - Source for Reference Implementation of F2C
punc/tools - Some binary tools for use with PUNC
Okay, I seem to have installed PUNC correctly; how do I actually use it now?
Using PUNC is pretty simple; it is a very object-oriented implementation, although it is written in C. It is actually written in an object-oriented way using a subset of ANSI/Standard C, sometimes referred to as Clean OO C. Clean C refers to 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).
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 PUNC is developed.)
ANSI-C ======> base
======> vf2c
======> superlu
F2C+ANSI-C ==> blas
==> lapack
==> arpack
==> cgcode
==> pmg
Wait! I have a bunch of other questions, such as:
Available distribution formats
PUNC is distributed in both binary format (as a binary RPM file punc-VERSION.i386.rpm for i386-based versions of Linux) and in source format (as a source RPM file punc-VERSION.src.rpm and as a gzipped tar file "punc-VERSION.tar.gz").
Installation using the binary RPM file
The following rpm command will install all of the PUNC headers and libraries into /usr/local/include and /usr/local/lib, and will install the PUNC documentation into /usr/share/doc/packages/punc:
rpm -Uvh punc-VERSION.i386.rpm
Installation and rebuilding from sources using the source RPM file
The following rpm command will unpack the source rpm file "punc-VERSON.src.rpm" into the PUNC gzipped tar file containing the sources called "punc-VERSION.tar.tar.gz" and into a small RPM spec file called "punc-VERSON.spec":
rpm -Uvh punc-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 punc-VERSION.spec
Rebuilding binary and source RPM files from the gzipped tar file
The PUNC sources contain the RPM spec file "punc-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 punc-VERSION.tar.gz
The result will be the corresponding source and binary rpm files,
named "punc-VERSON.src.rpm" and "punc-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 PUNC 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 punc-VERSION.tar.gz | tar xvf -
PUNC is essentially a portable low-level numerical software library
which was assembled to support the development of MC (Manifold Code), a
multilevel adaptive finite element "kernel". MC is designed to be easily
extended through the use of extension packages which are constructed on top
of MC, which itself is written on top of PUNC and MALOC. The installation
instructions PUNC, MC, and related software are identical to the instructions
below for PUNC.
Building the package using the GNU "configure" shell script and "make"
The "configure" shell script in the "punc" directory (the toplevel directory created when you unpacked the PUNC tar.gz 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 PUNC 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 PUNC in a separate directory from the
source tree as follows:
gzip -dc punc-VERSION.tar.gz | tar xvf -
mkdir punc_build
cd punc_build
../punc/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 PUNC for all the systems at the same time, you simply make an additional subdirectory in the main PUNC 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 PUNC source tree.
Platform-specific information
Below is some platform-specific build/usage information for PUNC.
Things should work as described above.
Things should work as described above.
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"
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"
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;make install" procedure above with no errors, the PUNC library (libpunc.a and/or libpunc.so) is installed into the specified installation directory. You can also build some useful tools that employ the PUNC library by cd-ing into the "tools" subdirectory and repeating the "configure;make;make install" procedure.
Using PUNC on a parallel computer
PUNC provides abstractions to both INET sockets and MPI for communication support in parallel computing software; this is done through the use of the underlying MALOC library. See the MALOC documentation for more details.
Getting PUNC 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).
Have your system administrator install MPI in a proper system directory so that PUNC (and other AUTOCONF-based codes) can find it!
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
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
PUNC should compile without error.
PUNC (Portable Understructure for Numerical Computing) 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 PUNC (see the credits list below).
PUNC (Portable Understructure for Numerical Computing)
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
PUNC was designed to be a portable collection of standard numerical
libraries for use in the development of MC (Manifold Code), an adaptive
multilevel finite element package also developed by
Michael Holst.
PUNC 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).
PUNC 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 PUNC; 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\ 02111-1307 USA.
PUNC was initially released under the GNU GPL (GNU General Public License. What this means is that like all GNU softare, PUNC is freely redistributable in source code form following the rules outlined in the text of the GNU GPL.
Credits
Below is a credits list for the people that have contributed to PUNC 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: punc/* -- The package structure D: punc/acconfig.h -- The platform abstraction information D: punc/configure.in -- The GNU autoconf/automake structure D: punc/config/* -- The GNU autoconf/automake shell scripts D: punc/doc/* -- The package documentation D: punc/examples/* -- The package examples D: punc/src/aaa_inc/* -- Library header build structure D: punc/src/aaa_lib/* -- Static and shared library build structure D: punc/src/base/* -- M. Holst's PUNC Foundation headers D: punc/src/pmg/* -- M. Holst's PMG D: punc/src/blas/* -- Reference implementation of BLAS D: punc/src/lapack/* -- Reference implementation of LAPACK D: punc/src/arpack/* -- Reference implementation of ARPACK D: punc/src/superlu/* -- Reference implementation of SuperLU D: punc/src/cgcode/* -- Reference implementation of CgCode D: punc/src/vf2c/* -- Reference implementation of F2C D: punc/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: punc/punc.spec -- RPM support (for building src/binary RPMs) S: Department of Computer Science S: University of Illinois S: Urbana, IL 61801 USA
Contacting the Author
If you have questions or comments about PUNC, please feel free to contact me at mholst@cam.ucsd.edu.
This version of PUNC is distributed under the following guidelines:
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.
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.