--- a/doc/sphinx/eilmer3.rst	Wed May 28 11:19:00 2014 +1000
+++ b/doc/sphinx/eilmer3.rst	Thu May 29 09:46:22 2014 +1000
@@ -31,7 +31,8 @@
 
 Typical build and run procedure
 -------------------------------
-The new 2D/3D code Eilmer3 is built from source into an installation directory ``$HOME/e3bin/``.
+The new 2D/3D code Eilmer3 is built from source into 
+an installation directory ``$HOME/e3bin/``.
 A typical build procedure (using the default ``TARGET=for_gnu``) might be::
 
   $ cd $HOME/cfcfd3/app/eilmer3/build
@@ -96,14 +97,13 @@
 
   $ ./cone20_run_mpi.sh  # exercise the MPI version of the code
 
-This should generate a postscript figure of the drag coefficient history
-about a sharp 20-degree cone and also put the VTK data file into the plot/
-subdirectory.
-It is not really necessary to make all of the subdirectories as shown above,
-however, that arrangement reflects the directory tree that PJ uses.
-If you want him to come and look at your simulation files when things go wrong,
-use the same.
-If not, use whatever hierarchy you like.
+This should generate a postscript figure of the drag coefficient
+history about a sharp 20-degree cone and also put the VTK data file
+into the plot/ subdirectory.  It is not really necessary to make all
+of the subdirectories as shown above, however, that arrangement
+reflects the directory tree that PJ uses.  If you want him to come and
+look at your simulation files when things go wrong, use the same.  If
+not, use whatever hierarchy you like.
 
 Summary of lines for your ``.bashrc`` file::
 
@@ -126,10 +126,11 @@
 
 Building and running on the Barrine cluster at UQ
 -------------------------------------------------
-The details of running simulations on any cluster computer will be specific 
-to the local configuration.  
-The Barrine cluster is run by the High-Performance Computing Unit at The University of Queensland 
-and is a much larger machine, with a little over 3000 cores, running SUSE Enterprise Linux.
+The details of running simulations on any cluster computer will be
+specific to the local configuration.  The Barrine cluster is run by
+the High-Performance Computing Unit at The University of Queensland
+and is a much larger machine, with a little over 3000 cores, running
+SUSE Enterprise Linux.
 
 Set up your environment by adding the following lines to your ``.bashrc`` file::
 
@@ -141,9 +142,9 @@
     export LUA_PATH=${HOME}/e3bin/?.lua
     export LUA_CPATH=${HOME}/e3bin/?.so
 
-Get yourself an interactive shell on a compute node so that you don't hammer the login node
-while compiling.  
-You won't make friends if you keep the login node excessively busy::
+Get yourself an interactive shell on a compute node so that you don't
+hammer the login node while compiling.  You won't make friends if you
+keep the login node excessively busy::
 
     $ qsub -I -A uq
 
@@ -157,7 +158,8 @@
 
     $ make clean
 
-To submit a job to PBS-Pro, which is the batch queue system on barrine, use the command::
+To submit a job to PBS-Pro, which is the batch queue system on barrine, 
+use the command::
 
     $ qsub script_name.sh
 
@@ -173,7 +175,8 @@
     echo "Begin MPI job..."
     date
     cd $PBS_O_WORKDIR
-    mpirun -np 24 $HOME/e3bin/e3mpi.exe --job=lehr --run --max-wall-clock=20000 > LOGFILE
+    mpirun -np 24 $HOME/e3bin/e3mpi.exe --job=lehr --run \
+    --max-wall-clock=20000 > LOGFILE
     echo "End MPI job."
     date
 
@@ -181,35 +184,35 @@
 This is the script input ``examples/eilmer3/2D/lehr-479/run_simulation.sh``.
 
 Here, we ask for 3 nodes with 8 cores each for a set of 24 MPI tasks.
-The medium nodes have 8 cores available, and we ask for all of them so that 
-we are reasonably sure that our job will not be in competition with another job 
-on the same nodes.
-Note the -A accounting option.  
-You will have to use an appropriate group name and you can determine 
-which groups you are part of with the ``groups`` command.
-Unlike SGE on Blackhole, we seem to need to change to the working directory 
-before running the simulation code.
-Finally, we have redirected the standard output from the main simulation 
-to the file LOGFILE so that we can monitor progress with the command::
+The medium nodes have 8 cores available, and we ask for all of them so
+that we are reasonably sure that our job will not be in competition
+with another job on the same nodes.  Note the -A accounting option.
+You will have to use an appropriate group name and you can determine
+which groups you are part of with the ``groups`` command.  Unlike SGE
+on Blackhole, we seem to need to change to the working directory
+before running the simulation code.  Finally, we have redirected the
+standard output from the main simulation to the file LOGFILE so that
+we can monitor progress with the command::
 
     $ tail -f LOGFILE
     
 Building and running the radiation transport solver
 ----------------------------------------------------
-While a flowfield calculation with coupled radiation can be performed via the single 
-processor version of eilmer3 (e3shared.exe), the radiation transport portion of such 
-calculations can often take a very long time to run.
-The obvious solution is to implement the radiation transport calculation in parallel.
-Due to the non-local nature of the radiation transport problem, however, for most 
-radiation transport models it is necessary to implement the parallelisation via the shared 
-memory multiprocessor approach.
-The radiation transport solver in eilmer3 has therefore been written to make use of the
-OpenMP API.
-As the Eilmer3 flowfield solver does not currently support an OpenMP build, the radiation
-transport solver can be built as a separate executable, e3rad.exe.
+While a flowfield calculation with coupled radiation can be performed
+via the single processor version of eilmer3 (e3shared.exe), the
+radiation transport portion of such calculations can often take a very
+long time to run.  The obvious solution is to implement the radiation
+transport calculation in parallel.  Due to the non-local nature of the
+radiation transport problem, however, for most radiation transport
+models it is necessary to implement the parallelisation via the shared
+memory multiprocessor approach.  The radiation transport solver in
+eilmer3 has therefore been written to make use of the OpenMP API.  As
+the Eilmer3 flowfield solver does not currently support an OpenMP
+build, the radiation transport solver can be built as a separate
+executable, e3rad.exe.
 
-The typical build procedure for the OpenMP version of the radiation transport solver using 
-the GNU compiler is::
+The typical build procedure for the OpenMP version of the radiation 
+transport solver using the GNU compiler is::
 
   $ cd $HOME/cfcfd3/app/eilmer3/build
   $ make TARGET=for_gnu_openmp e3rad
@@ -228,39 +231,38 @@
   $ make TARGET=for_intel_openmp e3rad
   $ make clean
   
-It should be noted that the e3mpi.exe executable is able to run radiation transport calculations 
-in parallel when either the "optically thin" or "tangent slab" models are implemented, however a specific 
-blocking layout is required for the "tangent slab" model.
-See the radiatively coupled Hayabusa simulation in $HOME/cfcfd3/examples/eilmer3/2D/hayabusa for 
-an example of this blocking layout.
+It should be noted that the e3mpi.exe executable is able to run
+radiation transport calculations in parallel when either the
+"optically thin" or "tangent slab" models are implemented, however a
+specific blocking layout is required for the "tangent slab" model.
+See the radiatively coupled Hayabusa simulation in
+$HOME/cfcfd3/examples/eilmer3/2D/hayabusa for an example of this
+blocking layout.
 
 When things go wrong
 --------------------
-Eilmer3 is a complex piece of software, 
-especially when all of the thermochemistry comes into play.
-There will be problems buried in the code and, (very) occasionally,
-you will expose them.
-We really do have some pride in this code and will certainly try to fix 
-anything that is broken, however, 
-we do this work essentially on our own time and that time is limited.
+Eilmer3 is a complex piece of software, especially when all of the
+thermochemistry comes into play.  There will be problems buried in the
+code and, (very) occasionally, you will expose them.  We really do
+have some pride in this code and will certainly try to fix anything
+that is broken, however, we do this work essentially on our own time
+and that time is limited.
 
 When you have a problem, there are a number of things that you can do 
 to minimize the duration and pain of debugging:
 
 #. Check the repository and be sure that you have the most recent
-   revision of the code.
-   This code collection is a work in progress and, in some cases,
-   you will not be the only one hitting a blatant bug.
-   It is likely that we or someone else has hit the same problem and,
-   if so, it may be fixed already.
-   The code changes daily in small ways.
-   This may sound chaotic, such that you should just stay with an old version,
-   however, we do try hard to not break things.
+   revision of the code.  This code collection is a work in progress
+   and, in some cases, you will not be the only one hitting a blatant
+   bug.  It is likely that we or someone else has hit the same problem
+   and, if so, it may be fixed already.  The code changes daily in
+   small ways.  This may sound chaotic, such that you should just stay
+   with an old version, however, we do try hard to not break things.
    In general, it is safest to work with the lastest revision.
 
-#. Put together a simple example that displays the problem.
-   This example should be as simple as possible so that there are not 
-   extra interactions that confuse us.
+#. Put together a simple example that displays the problem.  This
+   example should be as simple as possible so that there are not extra
+   interactions that confuse us.
 
 #. Provide a complete package of input files and output pictures.
    We should be able to run your simulation within a few minutes
@@ -303,30 +305,31 @@
 
   to the Section "ServerLayout" in ``/etc/X11/xorg.conf``
 
-* To use Paraview 3.6.1 on Ubuntu 9.04 or later,
-  it seems that we need to customize the look of the desktop 
-  by turning off the Visual Effects. 
+* To use Paraview 3.6.1 on Ubuntu 9.04 or later, it seems that we need
+  to customize the look of the desktop by turning off the Visual Effects.
   This setting can be found in the System->Preferences->Appearance menu.
 
-* To get Paraview Screenshot to behave,
-  uncheck "Use Offscreen Rendering for Screenshots" button
-  in the Edit->Settings ("Options") dialog.
+* To get Paraview Screenshot to behave, uncheck "Use Offscreen Rendering 
+  for Screenshots" button in the Edit->Settings ("Options") dialog.
   You will find the checkbutton under "Render View"->General.
 
 Transferring input files between machines
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 If you find you want to transfer just the input files between
-machines, ignoring the generated output files, you can do this by using the ``--exclude`` option
-for the ``rsync`` command. For example, to transfer just
-the input files of a directory
-called ``my-sim`` on a local machine to a remote machine, use::
+machines, ignoring the generated output files, you can do this by
+using the ``--exclude`` option for the ``rsync`` command. For example,
+to transfer just the input files of a directory called ``my-sim`` on a
+local machine to a remote machine, use::
 
- $ rsync -av --exclude=flow --exclude=grid --exclude=hist --exclude=heat --exclude=plot my-sim/ remote:my-sim
+ $ rsync -av --exclude=flow --exclude=grid --exclude=hist --exclude=heat \
+ --exclude=plot my-sim/ remote:my-sim
 
-If you find you are using this often, you can define an alias as appropriate for your
-shell. In BASH, I add the following line to my ``.bashrc`` file::
+If you find you are using this often, you can define an alias as
+appropriate for your shell. In BASH, I add the following line to my
+``.bashrc`` file::
 
- alias rsync-eilmer="rsync -av --progress --exclude=flow --exclude=grid --exclude=hist --exclude=heat --exclude=plot"
+ alias rsync-eilmer="rsync -av --progress --exclude=flow --exclude=grid \
+ --exclude=hist --exclude=heat --exclude=plot"
 
 Then I can use do the above transfer by issuing the following command::
  

--- a/doc/sphinx/getting-started.rst	Wed May 28 11:19:00 2014 +1000
+++ b/doc/sphinx/getting-started.rst	Thu May 29 09:46:22 2014 +1000
@@ -89,9 +89,12 @@
 #. gcc-c++
 #. m4
 #. openmpi
-#. openmpi-devel (to use openmpi on Fedora, :ref:`the module must be loaded <label-openmpi-fedora>`)
+#. openmpi-devel 
+   (to use openmpi on Fedora, 
+   :ref:`the module must be loaded <label-openmpi-fedora>`)
 #. gcc-gfortran
-#. libgfortran.i686, glibc-devel.i686 and libgcc.i686 (to compile the 32-bit CEA code on 64-bit Fedora)
+#. libgfortran.i686, glibc-devel.i686 and libgcc.i686 
+   (to compile the 32-bit CEA code on 64-bit Fedora)
 #. swig
 #. python-devel
 #. numpy

--- a/doc/sphinx/intro.rst	Wed May 28 11:19:00 2014 +1000
+++ b/doc/sphinx/intro.rst	Thu May 29 09:46:22 2014 +1000
@@ -63,10 +63,11 @@
 Peter A. Jacobs;
 Ingo Jahn;
 Chris James;
+Xin Kang;
 Matthew McGilvray, University of Oxford;
-Andrew Pastrello;
 Paul J. Petrie-Repar, RPM-Turbo, Brisbane;
-Daniel Potter, DLR, Goettingen;
+Daniel Potter, CSIRO, Newcastle;
+Jason (Kan) Qin;
 Anand Veeraragavan;
 Carlos de Miranda Ventura;
 Han Wei;
@@ -94,6 +95,7 @@
 Michael N. Macrossan;
 Andrew M. McGhee, Brisbane;
 Brendan O'Flaherty, WBM Pty Ltd, Brisbane;
+Andrew Pastrello;
 Leon Prucha;
 Emilie Sauret;
 Michael Scott; 

--- a/doc/sphinx/poshax3.rst	Wed May 28 11:19:00 2014 +1000
+++ b/doc/sphinx/poshax3.rst	Thu May 29 09:46:22 2014 +1000
@@ -87,4 +87,3 @@
    poshax3/thivet_et_al
    poshax3/FireII-1634s
    poshax3/Glass-Liu
-

--- a/doc/sphinx/poshax3/FireII-1634s.rst	Wed May 28 11:19:00 2014 +1000
+++ b/doc/sphinx/poshax3/FireII-1634s.rst	Thu May 29 09:46:22 2014 +1000
@@ -1,1 +1,1 @@
-../../../examples/poshax3/FireII/1634s/2T/README.txt
\ No newline at end of file
+../../../examples/poshax3/FireII/1634s/Panesi_comparison/README.txt
\ No newline at end of file

--- a/doc/sphinx/poshax3/number_density_profiles.png	Wed May 28 11:19:00 2014 +1000
+++ b/doc/sphinx/poshax3/number_density_profiles.png	Thu May 29 09:46:22 2014 +1000
@@ -1,1 +1,1 @@
-../../../examples/poshax3/FireII/1634s/2T/number_density_profiles.png
\ No newline at end of file
+../../../examples/poshax3/FireII/1634s/Panesi_comparison/number_density_profiles.png
\ No newline at end of file

--- a/doc/sphinx/poshax3/temperature_profiles.png	Wed May 28 11:19:00 2014 +1000
+++ b/doc/sphinx/poshax3/temperature_profiles.png	Thu May 29 09:46:22 2014 +1000
@@ -1,1 +1,1 @@
-../../../examples/poshax3/FireII/1634s/2T/temperature_profiles.png
\ No newline at end of file
+../../../examples/poshax3/FireII/1634s/Panesi_comparison/temperature_profiles.png
\ No newline at end of file

--- a/examples/eilmer3/2D/cone20-simple/cone20.py	Wed May 28 11:19:00 2014 +1000
+++ b/examples/eilmer3/2D/cone20-simple/cone20.py	Thu May 29 09:46:22 2014 +1000
@@ -1,12 +1,8 @@
-## \file cone20.py
-## \brief Simple job-specification file for e3prep.py
-## \author PJ, 08-Feb-2005
-##
-## 15-Sep-2008 -- simplified version for Eilmer3
-##
-## We have set this file up very much like the cone20.sit file
-## so that users may more-easily see the correspondence between
-## the Tcl and Python elements.
+# cone20.py
+# Simple job-specification file for e3prep.py
+# PJ, 08-Feb-2005
+#     15-Sep-2008 -- simplified version for Eilmer3
+#     29-May-2014 -- discard old way of setting BCs
 
 job_title = "Mach 1.5 flow over a 20 degree cone."
 print job_title
@@ -15,7 +11,6 @@
 gdata.dimensions = 2
 gdata.title = job_title
 gdata.axisymmetric_flag = 1
-gdata.stringent_cfl = 1  # to match the old mb_cns behaviour
 
 # Accept defaults for air giving R=287.1, gamma=1.4
 select_gas_model(model='ideal gas', species=['air'])
@@ -24,40 +19,34 @@
 initial = FlowCondition(p=5955.0,  u=0.0,    v=0.0, T=304.0)
 inflow  = FlowCondition(p=95.84e3, u=1000.0, v=0.0, T=1103.0)
 
-# Set up two quadrilaterals in the (x,y)-plane be first defining
-# the corner nodes, then the lines between those corners and then
-# the boundary elements for the blocks.
-# The labelling is not significant; it is just to make the SVG picture
-# look the same as that produced by the Tcl scriptit program.
+# Set up two quadrilaterals in the (x,y)-plane by first defining
+# the corner nodes, then the lines between those corners.
 a = Node(0.0, 0.0, label="A")
 b = Node(0.2, 0.0, label="B")
 c = Node(1.0, 0.29118, label="C")
 d = Node(1.0, 1.0, label="D")
 e = Node(0.2, 1.0, label="E")
 f = Node(0.0, 1.0, label="F")
-
 ab = Line(a, b); bc = Line(b, c) # lower boundary including cone surface
 fe = Line(f, e); ed = Line(e, d) # upper boundary
 af = Line(a, f); be = Line(b, e); cd = Line(c, d) # vertical lines
 
-# Define the blocks, boundary conditions and set the discretisation.
+# Define the blocks, with particular discretisation.
 nx0 = 10; nx1 = 30; ny = 40
 blk_0 = Block2D(make_patch(fe, be, ab, af), nni=nx0, nnj=ny,
                 fill_condition=initial, label="BLOCK-0")
 blk_1 = Block2D(make_patch(ed, cd, bc, be, "AO"), nni=nx1, nnj=ny,
                 fill_condition=initial, label="BLOCK-1",
                 hcell_list=[(9,0)], xforce_list=[0,0,1,0])
+
+# Set boundary conditions.
 identify_block_connections()
-blk_0.bc_list[WEST] = SupInBC(inflow, label="inflow-boundary") # one way to set a BC
-blk_1.set_BC(EAST, EXTRAPOLATE_OUT, label="outflow-boundary")   # another way
+blk_0.bc_list[WEST] = SupInBC(inflow, label="inflow-boundary")
+blk_1.bc_list[EAST] = ExtrapolateOutBC(label="outflow-boundary")
 
 # Do a little more setting of global data.
-gdata.viscous_flag = 1
-gdata.flux_calc = ADAPTIVE
-gdata.compression_tolerance = -0.05 # the old default value
 gdata.max_time = 5.0e-3  # seconds
 gdata.max_step = 3000
-gdata.write_at_step = 25
 gdata.dt = 1.0e-6
 gdata.dt_plot = 1.5e-3
 gdata.dt_history = 10.0e-5

--- a/examples/eilmer3/2D/cone20-simple/cone20.test	Wed May 28 11:19:00 2014 +1000
+++ b/examples/eilmer3/2D/cone20-simple/cone20.test	Thu May 29 09:46:22 2014 +1000
@@ -29,8 +29,8 @@
 	    set final_steps [lindex [split $line] 5]
 	}
     }
-    set final_steps
-} -result {1126}
+    list [expr abs($final_steps - 862) < 3]
+} -result {1}
 
 test shock-angle {The shock angle should be close to 49 degrees.} -body {
     set shock_angle 0

--- a/examples/eilmer3/user-guide/cone20-simple.tex	Wed May 28 11:19:00 2014 +1000
+++ b/examples/eilmer3/user-guide/cone20-simple.tex	Thu May 29 09:46:22 2014 +1000
@@ -13,7 +13,7 @@
 
 \medskip
 Assuming that you have the program executable files built and
-accessible on your system's search \texttt{PATH}, 
+accessible on your system's search \texttt{PATH}, as described in Appendix\,\ref{getting-started-file},
 try the following commands:\\
 %
 \topbar\\
@@ -24,7 +24,7 @@
 and, within a minute or so, you should end up with a number of files
 with various solution data plotted.
 The grid and initial solution are created and the time-evolution of the
-flow field is computed for 5\,ms (with 1105 time steps being required).
+flow field is computed for 5\,ms (with 862 time steps being required).
 The commands invoke the shell scripts displayed in 
 subsection~\ref{cone20-sh-files}.
 %
@@ -152,10 +152,9 @@
       These double dashes are a little hard to distinguish in the shell
       scripts.
 
-\item Run time is approximately 79 seconds for 1126 steps on a computer with 
-      an Intel Dual Pentium E2160, 1.6\,GHz processor.
-      As of September 2008, we have much optimisation to do.
-      Of course, the shared-memory code does not make use of the second processor,
+\item Run time is approximately 17 seconds for 862 steps on a computer with 
+      an AMD Phenom II X4 840, 800\,MHz processor.
+      Of course, the shared-memory code does not make use of the other 4 processor cores,
       however, there is an MPI version of the code that can.
 
 \item This cone20.py file really has full access to the Python interpreter
@@ -175,7 +174,7 @@
       \lstinputlisting[language={}]{../2D/cone20-simple/cp.awk}\index{xforce\_list!example of use}
 
 \item The script \texttt{cone20\_run\_mpi.sh} is available for running the simulation
-  with the parallel version of the code on a machine with LAM-MPI installed.
+  with the parallel version of the code on a machine with OpenMPI installed.
   This script is essentially the same as shown for the shared-memory simulation
   with the MPI simulation being started with the commands:\index{e3mpi.exe!example of use}
 \begin{verbatim}
@@ -184,18 +183,4 @@
   The only other modification required is to look for the surface-force data in the
   log file \texttt{e3mpi.0001.log} rather than \texttt{e3shared.log}.
 
-\item It turned out to be handy 
-  (while trying to debug one of those nasty memory segmentation violations) 
-  to be able to run the debug version of the MPI code within the valgrind 
-  instrumentation and profiling environment with the commands:
-\begin{verbatim}
-$ cd ~/work/eilmer3/2D/cone20-simple/
-$ script xxxx
-$ mpirun -np 2 valgrind --tool=memcheck e3mpi.exe -f cone20 --run
-$ exit
-\end{verbatim}
-  The \texttt{script} and \texttt{exit} start and stop recording of all of the console output
-  to the file \texttt{xxxx}.
-  If you have a few errors, valgrind output can be verbose.
-
 \end{itemize}