swigweb/projects.ht

The SWIG Files

<p><img src="images/projects.png" alt="Projects">

<p>
SWIG is being used in an increasing number of applications, most of
which are related to research and development, prototyping, software testing,
and construction of specialized systems.  This page describes
some of the ways in which SWIG is currently being used. 

<p>
(Note : the
opinions expressed here do not necessarily reflect those of any
given employer or organization).

<hr>
<p>
David Beazley (dmb@viking.lanl.gov) and Peter Lomdahl (pxl@viking.lanl.gov)<br>

<p>
SWIG is being used to construct a Python interface to the <a
href="http://bifrost.lanl.gov/MD/MD.html">SPaSM</a> molecular dynamics
code at Los Alamos National Laboratory.  Currently this code is being
used to perform large-scale simulations of fracture, shock waves, and
dislocation dynamics. The system runs in parallel on a 12 processor
Sun Enterprise 4000 server and is implemented with MPI and Solaris
multithreading.  The Python interface is used to provide users with an
interactive data analysis, visualization, and prototyping environment.
Users can also interact with underlying C data structures and "steer"
computations as needed.  One of the advantages of SWIG is that it
allows interfaces to be easily constructed from existing code.  The
SPaSM system consists of nearly 300 C functions and the Python
interface is automatically generated during compilation.  This work
was recently featured on the cover of "Computers in Physics" (June,
1997).

<hr>
<p>
John Schmidt (jas@cs.utah.edu) <br>

<p>
I am using SWIG to integrate four stand alone software packages into a
unified system controlled by Tcl/Tk scripts.  The unified software
system is used to design and test defibrillation electrodes via
computer simulations of a human subject.  The individual software
pieces include: a visualization package written in C++ using
OpenInventor and Motif, an unstructured mesh generator written in C, a
Finite Element Solver written in C, and a segmentation software
written in C++ using OpenGL and Motif.  SWIG has been crucial to the
development of this project.  With SWIG, the integration of the
individual pieces was trivial.

<hr>
<p>
David Brydon (brydon@lanl.gov) <br>

<p>
We are using swig with python to retrieve, analyze, and visualize very
large data sets from ocean model simulations on parallel computers.
We have written C routines that access our data.  Graphics libraries
and Matlab are used to visualize the data.  We are very happy with the
flexible, programmable, powerful tool that results.

<hr> 	
<p>
Mike Weiblen (mew@paradigmsim.com) <br>

<p>
Paradigm sells modular C toolkits for developing visual
simulation/virtual reality graphics applications called Vega and another
for spatial audio simulation called AudioWorks.  I've used SWIG to wrap
Vega's and AW's APIs with Silicon Graphics' "sgitcl" to create "vgTcl"
and "awTcl".  Exploiting the power of interactive scripting languages,
they provide the full power of the APIs at runtime, without an
application developer having to anticipate flexibility a priori.  SWIG
has enabled our customers to interact with our toolkits in fundamentally
new ways.
<p>
Several years ago (I believe we discussed this stuff way back in 1994
;-), I created a set of C preprocessor macros that did SWIG-like
things.  It was a very tedious process, making it difficult to follow
changes to an evolving API, but it was useful for proof-of-concept. 
When SWIG 1.1B1 came out in October, I was generously given a R&amp;D budget
to reimplement my project in SWIG.  The project has been a resounding
success!  

<hr>
<p>
Jonah Lee (jonah@melab.uafsoe.alaska.edu)

<p>
[We're using SWIG for] wrapping up engineering applications using
finite element method including pre- and post-processing. My program
is somewhat general and is used to solve problems for engineering
materials--metals, polymers and ice-- undergoing plastic (permanent)
deformations. It's mainly used for rapid prototyping, development and
testing. The code runs on workstations, Cray Y-MPs and Cray T3E (when
I get there...  that is).

<hr>
<p>Jody Winston (jody@sccsi.com) 

<p>

I have used SWIG to wrap an API that controlled two stepper motors and
a CCD camera on a Linux system that gathered real time image data.  In
Windows, I wrapped an application's C++ API and used SWIG to embed a
Python (pywin) interpreter into the C++ application.  I also used SWIG
to wrap a FORTRAN API that was used to read and write data into a
custom data base.  
<p>
SWIG has allowed me to move the time critical code into C, C++, or
FORTRAN while having the application being controlled by Python.  I
can quickly embed an interpreter into an application.

<hr>
<p>
Peter Lister (p.lister@cranfield.ac.uk)<br>

<p>
I'm using [SWIG] for a Perl scriptable version of Van Jacobson's libpcap
packet capture library. I can now use Perl regular expressions to
process packets on the fly. My main reason is to extract information
from ARP packets and automatically maintain our database of IP/MAC
address mappings directly from perl rather than hacking the output of
arpwatch or tcpdump.

<hr>
<p>
Harald Singer (singer@itl.atr.co.jp)

<p>
[We are using SWIG for] wrapping C libraries  to Python for speech recognition research
at ATR Interpreting Telecommunications Laboratories.
<p>
We are working in a multi-vendor environment (HP-UX, OSF1, Linux,
SunOS, Solaris) and writing new applications has become very tedious.
Therefore, we decided to employ python, but at the same time we would
like to have access to our signal processing libraries etc. that were
and are still written in C.
<p>
The advantages of using Python become more evident every day. For
example, it was fairly easy to write a GUI using python/tk. We are
using this now for interactive error analysis. A typical scenario is
like this:

<ul>
<li> audio data is collected via microphone/AD (in Python) and sent to the
recognizer frame by frame. 

<li> the recognizer (C code) makes a decision about speech endpointing and
once it has discovered end of utterance does a callback to the
application (python/tk) with a word lattice as result.

<li> this word lattice is now displayed for the user in python/tk. 

<li> the user can now interactively rescore part of the lattices, look at
the detailed acoustic and language model scores, listen to parts of
the utterance, etc.
</ul>
<p>
SWIG helps us in taking away part of the error-prone task of making
the C routines accessible from python and has considerably improved
our efficiency.

<hr>
<p>
Dominique Dumont (domi@ss7serv.grenoble.hp.com)
<p>
I'm using SWIG to generate a perl5 API on top of HP's OpenCall TCAP
API. TCAP is the top protocol layer of HP's SS7 stack of telecom 
protocol. The perl5 API developemnt effort is a part of the systematic
testing approach we're implementing in the division. 
<p>
The usual way was to write test programs
in C. The main drawback being that developing and running the tests
consumes a lot of time. 
<p>
Now the goal is to write all (or at least most of) the test in perl
allowing a faster cycle time between modifying the API and testing
it. (We'll also be able to debug faster the test programs).
<p>
Perl's power also enables us to write test using oo methodology
(although the API is strictly procedural), thus we can easily develop 
complex test scenarios.
<p>
Hopefully (i.e. if we have some spare time), the next step will be to
combine Tk with Perl and SWIG so we'll be able to monitor with a user
friendly interface the progress of the test suite.

<hr>
<p>Daniel Michelson (Daniel.Michelson@smhi.se)

<p>
A collegue and I are using SWIG for two purposes, both of which
centre around the creation of a Python-based environment for analysis
and visualization of data from the Swedish national weather radar
network:
<ul>
<li> interfacing old code
<li> interfacing new, performance critical, code.
</ul>
<p>
We have a couple of other collegues, also at SMHI R&amp;D, who are working
in satellite-based remote sensing activities and who will be starting to
use SWIG in the near future for their purposes.

<hr>
<p>Roger Burnham (rburnham@cri-inc.com)

<p>
Thanks again for SWIG... Its fun, allows great productivity while 
avoiding much tedium...
<p>
The current application (there will be many spin-offs/variations) is 
in polarization microscopy.  We manufacture electronically 
controllable retarder plates, and along with a scientist at the 
Marine Biological Lab in Woods Hole have developed an algo/method 
that allows us to visualize a sample's retardance (direction and 
magnitude) over the whole image.  Conventional methods allow you to 
see this structure only along one axis at a time...  The main tools 
I'm using are Python/Tkinter/PIL/NumPy/SWIG.
<p>
So, I've use SWIG to:
<ul>
<li> Wrap a commercial serial communications DLL.
<li> Wrap a commercial frame grabber interface
<li> After prototyping in Python, I move compute intensive routines 
     into DLL's.
</ul>
Our apps are running under Win95.  I thought it was pretty cool to be 
able to control a frame grabber, display live/acquired images, all 
from within Python, within the same day I received the frame grabber 
SDK, never having dealt with such hardware before!

<hr>
<p>
Simon Gibson (gibson@dstc.qut.edu.au)
<p>

I have been using SWIG to create a Python interface for our
prototype implementation of GSSAPI. This is being done so
that we can incorporate security into the Hector project here
at DSTC. It also means that I can write Python application
programmes. Also now we have a standard interface to GSSAPI
and any implementation should be able to be plugged in.
<p>
Hector is described in an article in the January/February
1997 - Distributed Objects <a href="http://www.ddj.com/ddsbk/1997/1997.01/index.htm">Dr. Dobb's Sourcebook</a>.

<hr>
<p>
Mark Hammond (MHammond@skippinet.com.au)

<p>

I'm using [SWIG] to write a commericial application, which runs as an NT
service.  It uses the COM extensions to talk native MAPI to exchange
server, the service extensions to run unattended on NT, and the pipe, file
and event modules to manage the service control messages and named pipe
connections from clients.  All modules named above were generated by SWIG. 
The COM extensions will allow (once the .i file is up to it :-) any native
COM interface (ie, not IDispatch (eg, VB/Word/Excel) based) to be supported
by Python.

<hr>
<p> Michael Bell (michaelb@gold.net.au)

<p>
I've used SWIG on a Linux platform to create Python modules for
graphing and database access.
<p>
The PGPLOT Graphics Subroutine Library is a Fortran library by Tim
Pearson (tjp@astro.caltech.edu). I understand it is often used by
astronomers.  It may also be built into a C library.
<p>
I used SWIG to wrap the C library wrapping the Fortran library (!)
into a Python module, using some straightforward typemaps to convert
one and two dimensional Python Numeric arrays into the appropriate
pointers.  I haven't methodically tested the full functionality, but
everything I tried works just fine.
<p>
I've also used SWIG to wrap up a library of Fortran subroutines
developed within the Western Australian Department of Environmental
Protection to manage databases of time series meteorological and air
quality data.  I used SWIG to generate a simple shadow class which I
then extended further to make the interface nicer.
<p>
The original library provided, for instance, subroutines opendb(),
writdb(), readdb() and closdb().  My module, epadb.py, provides a
database class, epadb.DB, which is instantiated, d=epadb.DB().  The
database instance then provides methods d.open(), d.read(), d.write()
and d.close(), returning data as Python lists and arrays.
<p>
I'm particularly pleased that I managed to do these things with my
reading only knowledge of C, and lots of cutting and pasting.

<hr>
<p>
Soeren Henkel (soeren@hni.uni-paderborn.de)
<p>
We are currently in the process of redeveloping OOPUS, a system for
modeling plant systems and generate plant control software from a model.
(Don't ask what OOPUS stands for -it's a German acronym.) We decided to 
reimplement its user inteface using Tcl/Tk. OOPUS puts its models
into an OODBMS, namely POET. So we needed an integration of POET
(which is tightly coupled to C++) with Tcl/Tk, and we've successfully
done that with SWIG.

<hr>
<p>
Peter A. Tinker (patinker@msmail4.hac.com)
<p>
We're using SWIG to "glue" Tcl/Tk to custom and third-party libraries. In
particular, SWIG provides an elegant means for controlling Sense8
Corporation's WorldToolKit (WTK) virtual environment development system from a
Tk GUI. The result is highly portable code that is
independent of WTK's proprietary GUI yet allows access to virtually all WTK
functions from a Tcl script and/or a Tk GUI. This approach is
being used in a variety of projects involving advanced 3D visualization
on a variety of imcompatible systems.

<hr>
<p>
Peter-Pike Sloan (ppsloan@cs.utah.edu)
<p>
I have been using SWIG for several projects, mostly to streamline
working with OpenGL under Tcl/Tk.  Examples are a time-critical
framework for viewing Lumigraphs (basically a digital hologram) and a
proof of concept application for optimizing texture coordinates based
on relative importance (determined by analyzing the existing texture
and user specification.)  Using SWIG has dramatically reduced my
development time allowing me to develop code and debug state in an
interpreted environment (currently Tcl, but I think I am going to move
to Python).

<hr>
<p>
Chris Myers (myers@beamtech.com)
<p>
We at Beam Technologies, Inc. have used SWIG to begin developing an
interpreted Python interface to our PDESolve library.  PDESolve is a
C++ class library for formulating and solving partial differential
equations (using either finite difference methods or finite element
methods), and makes use of OO technology to present a high-level
symbolic interface to the programmer.  This makes the description of
PDE-based problems concise, and enables the embedding of PDE-based
models in larger computational frameworks (e.g., to do PDE-based
design optimization or coupled PDE-based systems).  SWIG has allowed
us very quickly to develop a prototype Python interface to that
library.  Such an interface holds the promise of: (1) allowing even
more rapid prototyping of models, (2) dynamic formulation of models
and solution methods, and (3) a method for conveniently integrating
PDESolve with other packages (i.e., through the Python substrate).
My hope is to make a Python-enabled PDESolve a tool for PDEs something
like what Matlab provides for linear algebra, i.e., a high-level,
interpreted environment for rapid prototyping and interactive
exploration, with an embedded programming language for scripting
complex codes.

<p>
And while I have been looking for a while for a powerful and
extensible interpreted language for use as a front-end to compile codes
(which Python is), SWIG has made the interfacing of that code vastly
easier than it would have been otherwise.  While we are still in the
prototyping stages of this overall approach, SWIG enabled us to get up
and running quickly with a Python interface to PDESolve, and
demonstrate the utility of such an approach for a complex C++ library
(something that SWIG was not originally designed to really tackle).

<hr>
<p>
Vladimir I.Ulogov (gandalf@starship.skyport.net)
<p>

SWIG is being used to create a Python interface to CLIPS expert system shell
inside my general research job under OODBMS DNET. This extention module
provide full control from Python environment to expert system: Change a
global valiables, register a fact, manipulation with agenda, fact lists,
modules, functions, classes and instances. You can dynamicaly create and
execute CLIPS commands using clips.RouteCommand function call. Module
interface are similar to CLIPS Advanced API, who described into CLIPS
documentation. All additional documentation, Python classes are distributed
too. Module was be tested on Windows/NT and SUN Solaris 2.4 host platforms,
CLIPS version: 6.04, Python version 1.4. This module consist about 270
functions. This job took 3 days of my job at october 1997.

<hr>
<p>
Pinhong Chen (phchenb@tsmc.com)
<p>
I got a page for
<a href="http://www-cad.eecs.berkeley.edu/~pinhong/scriptEDA"
>EDA applications</a>
using SWIG.

<hr>
<h3> Tools and Modules </h3>
The following tools and modules have been produced using SWIG
or are related to SWIG.

<ul>
<li><p><a href="http://www.thestuff.net/bob/projects/blade">BLADE</a>. A web publishing environment.

<li><p><a href="http://students.cs.byu.edu/~butler/jni/PyJava.html">PyJava</a>. Provides
Python access to Java methods (Kevin Butler). 

<li><p><a href="http://playground.sun.com/~bharat/pilotmgr.html">Pilot Manager</a>. Hook
your US Robotics PalmPilot up to your Sun workstation (Bharat Mediratta).

<li><p> <a href="http://www.mic.atr.co.jp/~gulliver/WTK/www">PyWTK</a>.  A Python
interface to the WorldToolKit (a virtual reality modeling toolkit). (Roberto Lopez Gulliver)

<li><p> A Python interface to
<a href="http://starship.python.net/crew/robind/index.html">BSD DB 2.7.x</a> (Robin Dunn).

<li><p><a href="http://alldunn.com/wxPython/index.html">wxPython</a>. A Python extension
module that encapsulates the wxWindows GUI classes.

<li><p> Net-Pcap.  A Perl interface to the libpcap library (Peter Lister).

<li><p> X11::Wcl. A Perl interface to the Widget Creation Library (Joe Buehler).

</ul>

<hr>
<h3> Other Application Areas </h3>

These are some of the application areas that I've heard about SWIG being
used (but don't have many details).

<ul>
<li> Semiconductor CAD.
<li> Databases.
<li> Remote sensing.
<li> Scientific visualization and simulation.
<li> Financial Modeling.
<li> Distributed and parallel computing.
<li> Distributed objects (use with CORBA).
<li> Software testing.
</ul>

<hr>
<h3> How are you using SWIG? </h3>

If you would like to list your project here, please
send e-mail to beazley@cs.uchicago.edu.