DoGPack stands for Discontinuous Galerkin Package. It is a set of C++ libraries intended to be used by applications to solve hyperbolic partial differential equations. A typical DoGPack application solves a hyperbolic equation of the form

   q_t + div(f) = \psi.

The user is expected to supply the flux function f and the source term \psi as library callbacks.

Installation instructions can be found at

To obtain a fresh clone of the repository, use:

git clone https://[username] dogpack.git

or for faster transfer (requires .ssh configuration described below)

git clone

see `Installation Instructions', located on this page, or the main website for further details on how to obtain and install DoGPack.

Plotting options

DoGPack supports both MATLAB and Python plotting routines. All of these can be found in the


directory. The basic format requires the user to call the main plotting routines from an application directory. Local options, such as grid labels, axis options etc. are supplied by a single script defined by each application.

Class Hierarchy

DoGPack uses a class hierarchy for every 'application', which is a problem the user wishes to run. Similar to Clawpack [], all applications live under the apps tree, and common library routines live in lib.

The following tree describes the hierarchy of the 2D structured examples

lib/DogSolver <- DogSolverTB (inside DogSolver.h) <- DogSolverCart2 <- AppSolverCart2 <- AppSolver,

where '<-' means inherits from.

DogSolver and DogSolverTB classes provide a handful of pure virtual methods which must be defined by each derived class. For example, one such function is,

virtual double GetCFL(double dt)const=0;

Without the '=0' at the end, a derived class may choose to overide it, whereas in this case, each derived class must define each of these virtual methods.

Alongside each of the 'Solver' classes are a hierarchy of 'State' classes which contain information about all dynamic state variables. The idea of casting state variables into a class means that users should be able to revert back to previous states of the system, for example for restarts or rejecting time steps, and class encapsulation means that all relevant dynamic state variables should be self contained. For example, the following describes a 2D-structured example,

lib/DogState <- DogStateTB (inside DogState.h) <- DogStateCart2 <- AppStateCart2

DogSolver Class

TODO - write some notes on what the purpose of DogSolver is. Better yet, we should be writing more notes inside the header files ... (-DS)

<a name="Installation"></a> Installation Instructions =========================

To use the git transfer protocol you need to configure your ~/.ssh subdirectory properly as follows (see step 6 of ""):

=== need the following lines in your ~/.ssh/config file: ===
 User [username]
 IdentityFile ~/.ssh/id_rsa

and of course this means you need your ~/.ssh/id_rsa and ~/.ssh/ files set up, as described in "man ssh" and "man ssh-keygen":


Then copy and paste the contents of your new ~/.ssh/ into bitbucket's list of your SSH keys, accessible after logging into your bitbucket account by clicking on the tab with your name, selecting "Account", selecting "SSH keys" under "Account Settings", and pasting your public key into the SSH Key box.

The first option is to work with the repository directly using git.

A good source of information about git is the Pro Git book:

Before committing anything with git, you should edit your ~/.gitconfig file and ensure that your name and email are configured:

 name  = [username]
 email = []

An alternative interface to git is supplied by the easy-git (eg) script:

cd ~/bin # or wherever you want to put the shell script
# download the latest version from
curl -o eg
chmod +x eg

easy-git (eg) smooths the warts off the git interface and provides a svn-like interface. eg download and documentation is available at:

A third option is to use mercurial (hg) to work with the repository.

A good source of information about hg is available at:

If you wish to use hg to push to or pull from the git repository, you can do so by using hg-git.

Information is available from

and download is available from

Detailed information on installing and using hg-git follows:

# install hg-git using something like one of the following:
easy_install hg-git # fails on my mac. -eaj
fink update hg-git-py27 # worked on my mac. -eaj
# edit ~/.hgrc to enable hg-git by adding two lines to [extensions] section:
  hgext.bookmarks =
  hggit =
# if we were using github we could simply do the following:
#hg clone dogpack.hg
# and then we could push and pull directly from the local hg repository.
# Unfortunately bitbucket does not support hg-git, so we must
# create a bare git repository to serve as an intermediary:
git clone --mirror dogpack.mirror
# clone the bare repository
hg clone dogpack.bare dogpack.hg

# work with the hg clone:
cd dogpack.hg
[... do some work ...]
hg commit
# transfer the work to the intermediary
hg push
# transfer the work to the source tree
cd ../dogpack.bare
git push

# update the hg clone from the repository
git fetch --all
cd ../dogpack.hg
hg pull
hg update

By using hg hooks (e.g. the "outgoing" and "pre-pull" hooks you should be able to configure hg so that hg push and hg pull automatically cause "git push" and "get fetch --all" to be called in the local intermediary git repository.