diff --git a/AGENTS.md b/AGENTS.md
index 88bdddc35..39fdc6cc3 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -19,4 +19,14 @@ IPPL is a C++ Particle and fields Framework. Preserve physical correctness over
 - For algorithmic changes, state expected impact on conservation, stability, and reproducibility.
 - Flag any change that may alter floating-point behavior or MPI/GPU execution order.
 - Add or update at least one regression/sanity test for physics-facing changes.
-- Keep am eye on parallel efficincy at least on the openmp level
\ No newline at end of file
+- Keep am eye on parallel efficincy at least on the openmp level
+
+# Naming Conventions
+
+- Variables should use camel casing
+- Compile time constants should use capital casing
+- Member variables should be suffixed with `_m`
+
+# Math
+
+Mathematical constants should be obtained from `Kokkos::numbers` (moved out of `experimental` in Kokkos 4). Any instance of a mathematical function in host-only code should use symbols from the standard library, e.g. `std::sqrt`. Any instances occurring in device-code or code that might be run on a device (such as those marked with `KOKKOS_INLINE_FUNCTION`) should use the symbols from Kokkos, e.g. `Kokkos::sqrt`, to ensure performance and portability on GPUs.
diff --git a/INSTALLATION.md b/INSTALLATION.md
deleted file mode 100644
index 6f5a2d14e..000000000
--- a/INSTALLATION.md
+++ /dev/null
@@ -1,249 +0,0 @@
-All the new developments of IPPL are merged into the `master` branch which can make it potentially unstable from time to time. So if you want a stable and more tested version
-please checkout the tagged branch corresponding to the latest release (e.g. `git checkout tags/IPPL-x.x.x`). Otherwise if you want the latest developments go with the master with the above caveat in mind.
-
-## Requirements
-
-* [CMake](https://cmake.org/download/)
-* A C++ compilation toolchain (GPU-capable for GPU builds, e.g. [nvcc](https://developer.nvidia.com/cuda-downloads), [clang]() or [rocmcc](https://rocm.docs.amd.com/en/docs-5.0.2/reference/rocmcc/rocmcc.html))
-* MPI (GPU-aware if building for GPUs)
-
-### Optional requirements
-* FFTW
-* CuFFT
-
-## Compilation
-IPPL is a CMake Project and can be configured by passing options in CMake syntax:
-```
-cmake <src_dir> -D<option>=<value>
-```
-#### None of the options have to be set explicitly, all have a default.
-
-The relevant options of IPPL are
-- IPPL_PLATFORMS, can be one of `SERIAL, OPENMP, CUDA, "OPENMP;CUDA"`, default `SERIAL`
-- `Kokkos_VERSION`, default `4.5.00` 
-- `Heffte_VERSION`, default `2.4.0`
-  - If set to `MASTER`, an additional flag `Heffte_COMMIT_HASH` can be set, default `9eab7c0eb18e86acaccc2b5699b30e85a9e7bdda`
-  - Currently, this is the only compatible commit of Heffte
-- `IPPL_DYL`, default `OFF`
-- `IPPL_ENABLE_SOLVERS`, default `OFF`
-- `IPPL_ENABLE_FFT`, default `OFF`
-  - If `IPPL_ENABLE_FFT` is set, `Heffte_ENABLE_CUDA` will default to `ON` if `IPPL_PLATFORMS` contains `cuda`
-  - Otherwise, `Heffte_ENABLE_AVX2` is enabled. FFTW has to be enabled explicitly.
-- `Heffte_ENABLE_FFTW`, default `OFF`
-- `IPPL_ENABLE_TESTS`, default `OFF`
-- `IPPL_ENABLE_UNIT_TESTS`, default `OFF`
-- `IPPL_ENABLE_ALPINE`, default `OFF`
-- `IPPL_USE_ALTERNATIVE_VARIANT`, default `OFF`. Can be turned on for GPU builds where the use of the system-provided variant doesn't work.  
-- `IPPL_ENABLE_SANITIZER`, default `OFF`
-- `IPPL_ENABLE_SCRIPTS`, default `OFF`
-  
-`Kokkos` and `Heffte` by default will try to use version that are found on the sytem, if the system has `kokkos@4.6` and you set `Kokkos_VERSION=4.5` then cmake's find_package will consider the system version a match (newer than requested) and use it. The same applies for `Heffte`. You can override the variable to checkout any version by setting a git tag/sha/branch such as 
-```
-cmake -DKokkos_version=git.4.7.01 -DHeffte_VERSION=git.v2.4.1 ...  
-# or for a very specific version 
-cmake -DHeffte_VERSION=git.9eab7c0eb18e86acaccc2b5699b30e85a9e7bdda ...  
-```
-Note that by default, Kokkos git tags use a format `x.x.xx (eg. 4.7.01)` and Heffte git tags (extra 'v') are of the form `vx.x.x (eg. v2.4.1)`
-
-Furthermore, be aware of `CMAKE_BUILD_TYPE`, which can be either
-- `Release` for optimized builds
-- `RelWithDebInfo` for optimized builds with debug info (default)
-- `Debug` for debug builds (with [**Sanitizers enabled**](https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Instrumentation-Options.html))
-
-### Examples
-Download and setup a build directory:
-```
-https://github.com/IPPL-framework/ippl
-cd ippl
-mkdir build
-cd build
-```
-#### CMakeUserPresets
-In the root IPPL source folder, there is a cmake user presets file which can be used to set some default cmake settings, they may be used in the following way
-```
-cmake --preset=release-testing ...
-```
-This will set the following variables automatically (exact values may change over time)
-```
-        "IPPL_ENABLE_TESTS": "ON",
-        "IPPL_ENABLE_UNIT_TESTS": "ON"
-        "BUILD_SHARED_LIBS": "ON",
-        "CMAKE_BUILD_TYPE": "Release",
-        "Kokkos_VERSION_DEFAULT": "4.5.01",
-        "Heffte_VERSION_DEFAULT": "2.4.0",
-        "IPPL_PLATFORMS": "OPENMP;CUDA",
-        "IPPL_ENABLE_FFT": "ON",
-        "IPPL_ENABLE_ALPINE": "ON",
-        "IPPL_ENABLE_COSMOLOGY": "ON",
-        "IPPL_USE_STANDARD_FOLDERS": "OFF"
-```
-Users are encouraged to define additional sets of flags and create presets for them.
-
-#### Serial debug build with tests and a Kokkos version
-```
-cmake .. \
-    -DCMAKE_BUILD_TYPE=Debug \
-    -DCMAKE_CXX_STANDARD=20 \
-    -DIPPL_ENABLE_TESTS=True \
-    -DKokkos_VERSION=4.2.00
-```
-#### OpenMP release build with alpine and FFTW
-```
-cmake .. \
-    -DCMAKE_BUILD_TYPE=Release \
-    -DCMAKE_CXX_STANDARD=20 \
-    -DIPPL_ENABLE_FFT=ON \
-    -DIPPL_ENABLE_SOLVERS=ON \
-    -DIPPL_ENABLE_ALPINE=True \
-    -DIPPL_ENABLE_TESTS=ON \
-    -DIPPL_PLATFORMS=openmp \
-    -DHeffte_ENABLE_FFTW=True
-```
-#### Cuda alpine release build
-```
-cmake .. \
-    -DCMAKE_BUILD_TYPE=Release \
-    -DKokkos_ARCH_[architecture]=ON \
-    -DCMAKE_CUDA_ARCHITECTURES=<architecture compute capability> \
-    -DCMAKE_CXX_STANDARD=20 \
-    -DIPPL_ENABLE_FFT=ON \
-    -DIPPL_ENABLE_TESTS=ON \
-    -DIPPL_USE_ALTERNATIVE_VARIANT=ON \
-    -DIPPL_ENABLE_SOLVERS=ON \
-    -DIPPL_ENABLE_ALPINE=True \
-    -DIPPL_PLATFORMS=cuda
-```
-#### HIP release build (LUMI)
-```
-cmake .. \
-      -DCMAKE_BUILD_TYPE=Release \
-      -DCMAKE_CXX_STANDARD=20 \
-      -DCMAKE_CXX_COMPILER=hipcc \
-      -DBUILD_SHARED_LIBS=ON \
-      -DCMAKE_HIP_ARCHITECTURES=gfx90a \
-      -DCMAKE_HIP_FLAGS=--offload-arch=gfx90a \
-      -DKokkos_ENABLE_DEBUG=OFF \
-      -DKokkos_ARCH_ZEN3=ON \
-      -DKokkos_ARCH_AMD_GFX90A=ON \
-      -DKokkos_ENABLE_HIP=ON \
-      -DIPPL_PLATFORMS="HIP;OPENMP" \
-      -DIPPL_ENABLE_TESTS=ON \
-      -DIPPL_ENABLE_FFT=ON  \
-      -DIPPL_ENABLE_SOLVERS=ON \
-      -DIPPL_ENABLE_ALPINE=ON \
-      -DHeffte_ENABLE_ROCM=ON \
-      -DCMAKE_EXE_LINKER_FLAGS="-L/opt/cray/pe/mpich/8.1.28/ofi/amd/5.0/lib -L/opt/cray/pe/mpich/8.1.28/gtl/lib -L/opt/cray/pe/libsci/24.03.0/AMD/5.0/x86_64/lib -L/opt/cray/pe/dsmml/0.3.0/dsmml
-/lib -L/opt/cray/xpmem/2.8.2-1.0_5.1__g84a27a5.shasta/lib64 -lsci_amd_mpi -lsci_amd -ldl -lmpi_amd -lmpi_gtl_hsa -ldsmml -lxpmem -L/opt/rocm-6.0.3/lib/lib -L/opt/rocm-6.0.3/lib/lib64 -L/opt/roc
-m-6.0.3/lib/llvm/lib"
-```
-
-`[architecture]` should be the target architecture, e.g.
-- `PASCAL60`
-- `PASCAL61`
-- `VOLTA70`
-- `VOLTA72`
-- `TURING75`
-- `AMPERE80` (PSI GWENDOLEN machine)
-- `AMD_GFX90A` (LUMI machine)
-- `HOPPER90` (Merlin7 GPUs)
-
-### Enable Scripts
-We add `IPPL_ENABLE_SCRIPTS=ON/OFF` and when enabled, cmake will use `configure_file` to copy the scripts to the build dir, and replace some strings in them with cmake generated ones with the correct paths/values in. This allows the user to
-```
-cmake -DIPPL_ENABLE_SCRIPTS=ON  ....
-make LandauDamping
-...
--- Scripts configured in /capstor/scratch/cscs/biddisco/build-santis/scripts
-```
-then
-```
-./scripts/landau/strong-scaling-alps/generate.sh
-```
-and the result will be something like
-```
-Generating job for node count 004 in /capstor/scratch/cscs/biddisco/build-santis/ippl/strongscaling_landau/nodes_004
-Submitted batch job 396349
-...
-Generating job for node count 256 in /capstor/scratch/cscs/biddisco/build-santis/ippl/strongscaling_landau/nodes_256
-Submitted batch job 396355
-```
-
-## Build Instructions for specific sytems
-Here we compile links to recipies for easy build on various HPC systems. 
-
-## GWENDOLEN (PSI)
-Gwendolen is a small Nvidia A100 cluster at PSI, accessible through Merlin 6. To build on this machine, load the following modules:
-```bash
-module load gcc/14.3.0 openmpi/5.0.10_slurm
-module load cmake/3.26.3
-```
-The Cmake command you can use to build all unit tests, tests, and the alpine mini-apps including all solvers is:
-```bash
-cmake .. -DIPPL_PLATFORMS=CUDA -DCMAKE_BUILD_TYPE=Release -DKokkos_ARCH_AMPERE80=ON -DCMAKE_CXX_STANDARD=20 -DIPPL_ENABLE_FFT=ON -DIPPL_ENABLE_TESTS=ON -DIPPL_ENABLE_SOLVERS=ON -DIPPL_ENABLE_ALPINE=True -DIPPL_ENABLE_UNIT_TESTS=True
-```
-
-### MERLIN 7 (PSI)
-[IPPL build for A100 and HG](https://hpce.pages.psi.ch/merlin7/ippl.html)
-
-### ALPS (CSCS)
-Start by loading a `uenv` that contains most of the tools we want. Note that in future an `official` uenv will be provided in the CSCS uenv repository, but until testing is complete, use the following ...
-
-```bash
-uenv start --view=develop \
-/capstor/store/cscs/cscs/csstaff/biddisco/uenvs/opal-x-gh200-mpich-gcc-2025-09-28.squashfs
-```
-or, look for a newer one and pick the one with the latest date in the name using
-```bash
-ls -al /capstor/store/cscs/cscs/csstaff/biddisco/uenvs/opal-x-gh200-*.squashfs
-``` 
-At the time of writing, the uenv provides (as well as many other packages)
-```yaml
-cmake@4.1.1         ~doc+ncurses+ownlibs~qtgui 
-cray-mpich@9.0.0    +cuda+cxi~rocm 
-cuda@12.8.1         ~allow-unsupported-compilers~dev 
-eigen@3.4.0         ~ipo~nightly~rocm 
-fftw@3.3.10         +mpi~openmp~pfft_patches+shared 
-gcc@13.4.0          ~binutils+bootstrap~graphite~mold~nvptx~piclibs+profiled+strip 
-googletest@1.17.0   ~absl+gmock~ipo+pthreads+shared 
-gsl@2.8             ~external-cblas+pic+shared 
-h5hut@master        ~fortran+mpi 
-hdf5@1.14.6         +cxx~fortran+hl~ipo~java~map+mpi+shared~subfiling+szip~threadsafe+tools api=default 
-heffte@2.4.1        +cuda+fftw~fortran~ipo~magma~mkl~python~rocm+shared 
-hpctoolkit@2025.0.1 +cuda~docs~level_zero~mpi~opencl+papi~python~rocm~strip+viewer 
-hwloc@2.11.1        ~cairo~cuda~gl~level_zero~libudev~libxml2~nvml~opencl+pci~rocm 
-kokkos@4.7.00       ~aggressive_vectorization~alloc_async~cmake_lang~compiler_warnings+complex_align+cuda~cuda_constexpr~cuda_lambda~cuda_ldg_intrinsic~cuda_relocatable_device_code~cuda_uvm~debug~debug_bounds_check~debug_dualview_modify_check~deprecated_code~examples~hip_relocatable_device_code~hpx~hpx_async_dispatch~hwloc~ipo~memkind~numactl+openmp~openmptarget~pic~rocm+serial+shared~sycl~tests~threads~tuning+wrapper build_system=cmake build_type=Release cuda_arch=90 cxxstd=20 generator=make intel_gpu_arch=none 
-ninja@1.13.0        +re2c 
-```
-You can check what is inside the uenv by executing the command
-```bash
-# This will show all packages installed by spack (including any ones you might have installed yourself outside of a uenv)
-spack find -flv
-
-# use this to only show packages inside the uenv (ie. not any you have installed elsewhere)
-spack -C /user-environment/config find -flv
-```
-It is important to use the `--view=develop` when loading the uenv as this sets-up the paths to packages in the spack environment ready for you to use them (without needing to manually `spack load xxx` packages individually) (In fact it will also add `/user-environment/env/develop/` to your `CMAKE_PREFIX_PATH`) which makes cmake-built packages 'just work'. 
-
-To build, try the following which uses default CMake settings (`release-testing`) taken from `CMakeUserPresets.json` (in the root ippl source of the cmake-alps branch - it is not required to use this branch, but cmake support has been cleaned up)
-```bash
-ssh daint
-uenv start --view=develop /capstor/scratch/cscs/biddisco/uenvs/gh200-opalxgccmpich-2025-07-23.squashfs
-
-# clone IPPL
-mkdir -p $HOME/src/ippl
-cd $HOME/src
-git clone https://github.com/IPPL-framework/ippl
-
-# (optionally) checkout the cmake-alps branch since it is not yet merged to master
-cd $HOME/src/ippl
-git remote add biddisco https://github.com/biddisco/ippl.git
-git fetch biddisco cmake-alps
-git checkout cmake-alps
-
-# create a build dir
-mkdir -p $HOME/build/ippl
-cd $HOME/build/ippl
-
-# run cmake (note that ninja is available in the uenv and "cmake -G Ninja" can be used)
-cmake --preset=release-testing -DCMAKE_INSTALL_PREFIX=$HOME/apps/ippl -DCMAKE_CUDA_ARCHITECTURES=90 $HOME/src/ippl/
-```
diff --git a/README.md b/README.md
index ee9256c3c..4b7e2ff7b 100644
--- a/README.md
+++ b/README.md
@@ -31,15 +31,23 @@ methods, with Eulerian (mesh-based) and Lagrangian (particle-based) approaches.
 IPPL makes use of [Kokkos](https://github.com/kokkos/kokkos), [HeFFTe](https://github.com/icl-utk-edu/heffte), and MPI (Message Passing Interface) to deliver a portable,
 massively parallel toolkit for particle-mesh methods. IPPL supports simulations in one to six dimensions, mixed precision, and asynchronous execution in different execution spaces (e.g. CPUs and GPUs).
 
-**[Installation](#installation)** |
+**[Resources](#Resources)** |
 **[Contributions](#contributions)** |
 **[CI/CD](#cicd-and-pr-testing)** |
 **[Citing IPPL](#citing-ippl)** |
-**[SLURM Job scripts](#slurm-job-scripts)** |
-**[Profiling](#profiling)**
 
-# Installation
-We compiled installation [instructions](./INSTALLATION.md) for many HPC systems. 
+# Resources
+
+The [IPPL Manual](https://ippl-framework.github.io/Manual/) contains comprehensive documentation, including:
+- **Installation Instructions:** Guides for building locally and on various HPC systems.
+- **Framework Overview:** A broad look at IPPL's core functionalities.
+- **Theory & Examples:** Underlying theoretical concepts alongside practical code examples.
+
+For detailed API, class, and file documentation, please visit our [Doxygen site](https://ippl-framework.github.io/ippl/).
+
+**Feedback & Support**
+If you find any issues with the manual, please report them in the [Manual's GitHub repository](https://github.com/IPPL-framework/Manual).
+
 
 # Contributions
 We are open and welcome contributions from others. Please open an issue and a corresponding pull request in the main repository if it is a bug fix or a minor change.
@@ -54,15 +62,11 @@ You can then easily pull by typing
 ```bash
 $ git pull upstream master
 ```
-All the contributions (except for bug fixes) need to be accompanied with a unit test. For more information on unit tests in IPPL please
-take a look at this [page](https://github.com/IPPL-framework/ippl/blob/master/UNIT_TESTS.md).
 
+Please refer to the [IPPL Manual](https://ippl-framework.github.io/Manual/) for further details regarding contributions, fromatting, unit tests, etc.
 # CI/CD and PR testing
 Please see [Julich CI results](https://ippl-bc4558.pages.jsc.fz-juelich.de/) and [CSCS PR testing](ci/cscs/cscs-ci-cd.md) for further information.
 
-# Code Formatting
-Please see [Code Formatting Setup](doc/extras/CodeFormattingSetup.md) for further information and instructions.
-
 # Citing IPPL
 
 ```
@@ -77,198 +81,3 @@ Please see [Code Formatting Setup](doc/extras/CodeFormattingSetup.md) for furthe
   organization={SIAM}
 }
 ```
-
-# SLURM Job scripts
-
-You can use the following example job scripts to run on the local PSI computing cluster, which uses slurm.
-More documentation on the local cluster can be found [here](https://lsm-hpce.gitpages.psi.ch/merlin6/introduction.html) (need to be in the PSI network to access).
-
-## Merlin CPU (MPI + OpenMP)
-For example, to run a job on 1 MPI node, with 44 OpenMP threads:
-```
-#!/bin/bash
-#SBATCH --partition=hourly      # Using 'hourly' will grant higher priority
-#SBATCH --nodes=1               # No. of nodes
-#SBATCH --ntasks-per-node=1     # No. of MPI ranks per node. Merlin CPU nodes have 44 cores
-#SBATCH --cpus-per-task=44      # No. of OMP threads
-#SBATCH --time=00:05:00         # Define max time job will run (e.g. here 5 mins)
-#SBATCH --hint=nomultithread    # Without hyperthreading
-##SBATCH --exclusive            # The allocations will be exclusive if turned on (remove extra hashtag to turn on)
-
-#SBATCH --output=<output_file_name>.out  # Name of output file
-#SBATCH --error=<error_file_name>.err    # Name of error file
-
-export OMP_NUM_THREADS=44
-export OMP_PROC_BIND=spread
-export OMP_PLACES=threads
-
-# need to pass the --cpus-per-task option to srun otherwise will not use more than 1 core per task
-# (see https://lsm-hpce.gitpages.psi.ch/merlin6/known-problems.html#sbatch-using-one-core-despite-setting--ccpus-per-task)
-
-srun --cpus-per-task=44 ./<your_executable> <args>
-```
-
-## Gwendolen GPU
-For example, to run a job on 4 GPUs (max on Gwendolen is 8 GPUs, which are all on a single node):
-```
-#!/bin/bash
-#SBATCH --time=00:05:00         # Define max time job will run (e.g. here 5 mins)
-#SBATCH --nodes=1               # No. of nodes (there is only 1 node on Gwendolen)
-#SBATCH --ntasks=4              # No. of tasks (max. 8)
-#SBATCH --clusters=gmerlin6     # Specify that we are running on the GPU cluster
-#SBATCH --partition=gwendolen   # Running on the Gwendolen partition of the GPU cluster
-#SBATCH --account=gwendolen
-##SBATCH --exclusive            # The allocations will be exclusive if turned on (remove extra hashtag to turn on)
-#SBATCH --gpus=4                # No. of GPUs (max. 8)
-
-#SBATCH --output=<output_file_name>.out  # Name of output file
-#SBATCH --error=<error_file_name>.err    # Name of error file
-
-srun ./<your_executable> <args> --kokkos-map-device-id-by=mpi_rank
-```
-## LUMI GPU partition
-For example, to run a job on 8 nodes with 8 GPUs each:
-```
-#!/bin/bash
-#SBATCH --job-name=TestGaussian
-#SBATCH --error=TestGaussian-%j.error
-#SBATCH --output=TestGaussian-%j.out
-#SBATCH --partition=dev-g  # partition name
-#SBATCH --time=00:10:00
-#SBATCH --nodes 8
-#SBATCH --ntasks-per-node=8     # 8 MPI ranks per node, 64 total (8x8)
-#SBATCH --gpus-per-node=8       # Allocate one gpu per MPI rank per node
-#SBATCH --account=project_xxx
-#SBATCH --hint=nomultithread
-module load  LUMI/24.03 partition/G cpeAMD rocm buildtools/24.03
-CPU_BIND="map_cpu:49,57,17,25,1,9,33,41"
-export MPICH_GPU_SUPPORT_ENABLED=1
-ulimit -s unlimited
-export EXE_DIR=/users/adelmann/sandbox/vico-paper/build/test/solver
-cat << EOF > select_gpu
-#!/bin/bash
-export ROCR_VISIBLE_DEVICES=\$SLURM_LOCALID
-exec \$*
-EOF
-chmod +x ./select_gpu
-srun ./select_gpu ${EXE_DIR}/TestGaussian 1024 1024 1024 pencils a2av no-reorder HOCKNEY --info 5
-rm -rf ./select_gpu
-```
-
-
-# Profiling
-
-## MPI Calls 
-You can use the mpiP tool (https://github.com/LLNL/mpiP) to get statistics about the MPI calls in IPPL. 
-
-To use it, download it from [Github](https://github.com/LLNL/mpiP) and follow the instructions to install it. You may run into some issues while installing, here is a list of common issues and the solution:
-- On Cray systems "MPI_Init not defined": This I fixed by passing the correct Cray wrappers for the compilers to the configure: `./configure CC=cc FC=ftn F77=ftn`
-- If you have an issue with it not recognizing a function symbol in Fortran 77, you need to substitute the line `echo "main(){ FF(); return 0; }" > flink.c` (line 706) in the file `configure.ac` by the following line `echo "extern void FF(); int main() { FF(); return 0; }" > flink.c`
-- During the `make all`, if you run into an issue of some Testing file not recognizing mpi.h, then you need to add the following line `CXX = CC` in the file `Testing/Makefile`.
-
-If the installation was successful, you should have the library `libmpip.so` in the mpiP directory. 
-
-To instument your application with the mpiP library, add the following line to your jobscript (or run it in your command line if you are running locally/on an interactive node):
-`export LD_PRELOAD=$[path to mpip directory]/libmpiP.so`
-To pass any options to mpiP, you can export the variable MPIP with the options you want. For example, if you would like to get a histogram of the data sent by MPI calls (option `-y`), you would need to add the following line to your jobscript:
-`export MPIP="-y"`
-
-If you application has been correctly instrumented, you will see that mpiP has been found and its version is printed at the top of the standard output. At the end of the standard output, you will get the name of the file containing the MPI statistics:
-`Storing mpiP output in ...`
-
-To get a total amount of bytes moved around by your application, you can use the python script mpiP.py (found in the top level IPPL directory) in the following form:
-`python3 mpiP.py [path/to/directory]`
-where path/to/directory refers to the place where the .mpiP output can be found. This python script will then print out the total amount of Bytes moved by MPI in your application.
-
-## Profiling on LUMI
-
-### rocprof
-
-Analysis with: https://ui.perfetto.dev/
-
-```
-#!/bin/bash -l
-#
-#SBATCH --job-name=opalx1
-#SBATCH --error=opalx-%j.error
-#SBATCH --output=opalx-2-%j.out
-#SBATCH --time=00:05:00
-#SBATCH --partition=standard-g
-#SBATCH --nodes 1
-#SBATCH --ntasks-per-core=1
-#SBATCH -c 56 --threads-per-core=1
-#SBATCH --ntasks-per-node=1
-#SBATCH --gpus-per-node=8
-#SBATCH --account=project_465001705 
-#SBATCH --hint=nomultithread
-#SBATCH --hint=exclusive
-CPU_BIND="map_cpu:49,57,17,25,1,9,33,41"
-export MPICH_GPU_SUPPORT_ENABLED=1
- 
-ulimit -s unlimited
-export EXE_DIR=/users/adelmann/sandbox/opalx/build/src/
-module load cray-python/3.11.7 
-module use /appl/local/containers/test-modules
-module load LUMI/24.03 partition/G cpeAMD rocm/6.1.3 buildtools/24.03
-
-cat << EOF > select_gpu
-#!/bin/bash
-export HIP_VISIBLE_DEVICES=\$SLURM_LOCALID
-exec \$*
-EOF
-chmod +x ./select_gpu
-srun ./select_gpu rocprof --hip-trace ${EXE_DIR}/opalx input.in --info 5
-rm -rf ./select_gpu
-
-```
-
-
-### omniperf (do not use omnitrace)
-
-doc url: https://rocm.docs.amd.com/projects/rocprofiler-compute/en/docs-6.2.4/how-to/profile/mode.html
-
-```
-#!/bin/bash -l
-#
-#SBATCH --job-name=opalx1
-#SBATCH --error=opalx-%j.error
-#SBATCH --output=opalx-2-%j.out
-#SBATCH --time=00:05:00
-#SBATCH --partition=standard-g
-#SBATCH --nodes 1
-#SBATCH --ntasks-per-core=1
-#SBATCH -c 56 --threads-per-core=1
-#SBATCH --ntasks-per-node=1
-#SBATCH --gpus-per-node=8
-#SBATCH --account=project_465001705 
-#SBATCH --hint=nomultithread
-#SBATCH --hint=exclusive
-CPU_BIND="map_cpu:49,57,17,25,1,9,33,41"
-export MPICH_GPU_SUPPORT_ENABLED=1
- 
-ulimit -s unlimited
-export EXE_DIR=/users/adelmann/sandbox/opalx/build/src/
-module load cray-python/3.11.7 
-module use /appl/local/containers/test-modules
-module load LUMI/24.03 partition/G cpeAMD rocm/6.1.3 buildtools/24.03
-module load omniperf
-cat << EOF > select_gpu
-#!/bin/bash
-#export ROCR_VISIBLE_DEVICES=\$SLURM_LOCALID
-export HIP_VISIBLE_DEVICES=\$SLURM_LOCALID
-exec \$*
-EOF
-chmod +x ./select_gpu
-srun ./select_gpu omniperf profile --name opalx  --roof-only --kernel-names -- ${EXE_DIR}/opalx input.in --info 5
-rm -rf ./select_gpu
-```
-
-
-
-
-
-
-
-
-
-Happy profiling!
diff --git a/UNIT_TESTS.md b/UNIT_TESTS.md
deleted file mode 100644
index 2fee38a88..000000000
--- a/UNIT_TESTS.md
+++ /dev/null
@@ -1,155 +0,0 @@
-# Overview
-
-IPPL allows the user to customize the behavior of its data types using template parameters. The unit tests verify that everything is working under all relevant and available configurations of the parameters. In particular, the tests verify behavior under
-- mixed precision, i.e. components using single or double precision (`float`, `double`)
-- varying dimensionality, i.e. components in 1D, 2D, 3D, etc. up to 6D (the maximum supported by Kokkos)
-- mixed execution spaces, i.e. components using different accelerators (e.g. OpenMP, CUDA) in different memory spaces (host, device)
-    - The unit tests are instantiated for all available execution spaces. These are determined based on the compilation settings for Kokkos, which exposes compiler macros to indicate which execution spaces are available.
-
-As an example, we look at the unit tests for `BareField`. Consider the following Kokkos configuration:
-```sh
-cmake \
-    -DCMAKE_INSTALL_PREFIX=${KOKKOS_PREFIX} \
-    -DCMAKE_CXX_COMPILER="${compiler}" \
-    -DCMAKE_BUILD_TYPE=Release \
-    -DCMAKE_CXX_STANDARD=20 \
-    -DCMAKE_CXX_EXTENSIONS=OFF \
-    -DKokkos_ENABLE_SERIAL=OFF \
-    -DKokkos_ARCH_AMPERE80=ON \
-    -DKokkos_ENABLE_OPENMP=ON \
-    -DKokkos_ENABLE_CUDA=ON \
-    -DKokkos_ENABLE_CUDA_LAMBDA=ON \
-    -DKokkos_ENABLE_CUDA_UVM=OFF \
-    kokkos
-```
-
-This compiles Kokkos to include support for OpenMP and CUDA as accelerators. All Kokkos kernels can thus use either of these execution spaces. In this case, each individual unit test is compiled 24 times: once for each possible combination of precision, rank, and execution space. This is visible in the first few lines of output:
-```
-[==========] Running 192 tests from 24 test suites.
-[----------] Global test environment set-up.
-[----------] 8 tests from BareFieldTest/0, where TypeParam = Parameters<double, Kokkos::OpenMP, Rank<1u> >
-[ RUN      ] BareFieldTest/0.DeepCopy
-[       OK ] BareFieldTest/0.DeepCopy (0 ms)
-[ RUN      ] BareFieldTest/0.Sum
-[       OK ] BareFieldTest/0.Sum (0 ms)
-[ RUN      ] BareFieldTest/0.Min
-[       OK ] BareFieldTest/0.Min (0 ms)
-[ RUN      ] BareFieldTest/0.Max
-[       OK ] BareFieldTest/0.Max (0 ms)
-[ RUN      ] BareFieldTest/0.Prod
-[       OK ] BareFieldTest/0.Prod (0 ms)
-[ RUN      ] BareFieldTest/0.ScalarMultiplication
-[       OK ] BareFieldTest/0.ScalarMultiplication (0 ms)
-[ RUN      ] BareFieldTest/0.DotProduct
-[       OK ] BareFieldTest/0.DotProduct (0 ms)
-[ RUN      ] BareFieldTest/0.AllFuncs
-[       OK ] BareFieldTest/0.AllFuncs (3 ms)
-[----------] 8 tests from BareFieldTest/0 (6 ms total)
-```
-
-Here, we see that the first configuration for the unit tests is for a 1D field in double precision using OpenMP. In particular, the field data is stored in host memory. Among the other tests, we also have the following configurations:
-```
-[----------] 8 tests from BareFieldTest/9, where TypeParam = Parameters<float, Kokkos::OpenMP, Rank<3u> >
-[----------] 8 tests from BareFieldTest/10, where TypeParam = Parameters<double, Kokkos::Cuda, Rank<3u> >
-[----------] 8 tests from BareFieldTest/15, where TypeParam = Parameters<float, Kokkos::Cuda, Rank<4u> >
-```
-
-The configurations using `Kokkos::Cuda` as the execution space store the field data on GPUs, as one would expect.
-
-Not all sets of unit tests have the same level of configuration. Data structures that do not involve parallel execution don't have an associated execution space; instantiations of these unit tests are thus independent of the number of Kokkos backends. On the other hand, some data structures can use multiple execution spaces. One example is particle bunches, which can store attributes in different execution spaces. Here, we have the following setup:
-```cpp
-template <typename T, typename IDSpace, typename PositionSpace, unsigned Dim>
-class ParticleBaseTest<Parameters<T, IDSpace, PositionSpace, Rank<Dim>>> : public ::testing::Test
-```
-
-Unit tests are instantiated for a particle bunch with the following properties:
-- Particles have an attribute of type `T` (which will be `double` or `float`)
-- The particle positions have type `T` (controls the precision of the position data)
-- The particle positions use the execution space `PositionSpace`
-- The particles are identified by IDs, which use the execution space `IDSpace`
-- The particle positions are `Dim`-vectors (controls the dimensionality of the particle layout)
-
-By instantiating unit tests for all possible combinations of execution spaces of multiple components, we can verify not only the correctness of the computations, but also that data is being copied where needed and that data in all execution spaces is being handled correctly. These are some of the test configurations generated for particle bunches using the same Kokkos configuration as the previous example:
-```
-... TypeParam = Parameters<float, Kokkos::OpenMP, Kokkos::Cuda, Rank<3u> >
-... TypeParam = Parameters<double, Kokkos::Cuda, Kokkos::Cuda, Rank<3u> >
-... TypeParam = Parameters<float, Kokkos::Cuda, Kokkos::Cuda, Rank<3u> >
-... TypeParam = Parameters<double, Kokkos::OpenMP, Kokkos::OpenMP, Rank<4u> >
-... TypeParam = Parameters<float, Kokkos::OpenMP, Kokkos::OpenMP, Rank<4u> >
-```
-
-# Implementation
-
-The generation of test configurations is implemented in `unit_tests/TestUtils.h`. It is controlled using the following struct:
-
-```cpp
-template <typename... Ts>
-struct Parameters { ... };
-
-struct TestParams {
-    using Spaces     = ippl::detail::TypeForAllSpaces<std::tuple>::exec_spaces_type;
-    using Precisions = std::tuple<double, float>;
-    using Combos     = CreateCombinations<Precisions, Spaces>::type;
-
-    template <unsigned... Dims>
-    using Ranks = std::tuple<Rank<Dims>...>;
-
-    template <unsigned... Dims>
-    using CombosWithRanks = typename CreateCombinations<Precisions, Spaces, Ranks<Dims...>>::type;
-
-    template <unsigned... Dims>
-    using tests = typename TestForTypes<
-        std::conditional_t<sizeof...(Dims) == 0, Combos, CombosWithRanks<Dims...>>>::type;
-...
-};
-```
-
-First, we generate a tuple containing all the available execution spacs (see `Utility/TypeUtils.h`). We then create tuples with the other parameters we want to test. The `CreateCombinations` struct recursively generates all combinations of the chosen parameters at compile time and instantiates the `Parameter` type to hold these combinations. We then use GoogleTest's `testing::Types<...>` to instantiate all the unit tests for each combination. Example:
-
-```cpp
-template <typename>
-class FieldTest;
-
-template <typename T, typename ExecSpace, unsigned Dim>
-class FieldTest<Parameters<T, ExecSpace, Rank<Dim>>> : public ::testing::Test { ... };
-
-using Tests = TestParams::tests<1, 2, 3, 4, 5, 6>;
-TYPED_TEST_CASE(FieldTest, Tests);
-
-TYPED_TEST(FieldTest, DeepCopy) { ... }
-```
-
-If we want to generate combinations beyond just ranks/precision/execution space like above, we can use the tuple generation with other types. For example, the particle bunch tests use two execution spaces:
-
-```cpp
-template <typename>
-class ParticleBaseTest;
-
-template <typename T, typename IDSpace, typename PositionSpace, unsigned Dim>
-class ParticleBaseTest<Parameters<T, IDSpace, PositionSpace, Rank<Dim>>> : public ::testing::Test { ... };
-
-using Precisions = TestParams::Precisions;
-using Spaces     = TestParams::Spaces;
-using Ranks      = TestParams::Ranks<1, 2, 3, 4, 5, 6>;
-using Combos     = CreateCombinations<Precisions, Spaces, Spaces, Ranks>::type;
-using Tests      = TestForTypes<Combos>::type;
-TYPED_TEST_CASE(ParticleBaseTest, Tests);
-
-TYPED_TEST(ParticleBaseTest, CreateAndDestroy) { ... }
-```
-
-# Run all Unit tests
-
-```bash
-#!/bin/bash
-
-for file in `find $1/unit_tests -type f`
-do
-    if [[ -x "$file" ]]
-    then
-        $file
-    fi
-done
-```
-
-The first argument needs to point to the directory were you build ippl.
diff --git a/WORKFLOW.md b/WORKFLOW.md
deleted file mode 100644
index 5f010ad28..000000000
--- a/WORKFLOW.md
+++ /dev/null
@@ -1,58 +0,0 @@
-# Naming Conventions
-
-- Variables should use camel casing
-- Compile time constants should use capital casing
-- Member variables should be suffixed with `_m`
-
-# Math
-
-Mathematical constants should be obtained from `Kokkos::numbers` (moved out of `experimental` in Kokkos 4). Any instance of a mathematical function in host-only code should use symbols from the standard library, e.g. `std::sqrt`. Any instances occurring in device-code or code that might be run on a device (such as those marked with `KOKKOS_INLINE_FUNCTION`) should use the symbols from Kokkos, e.g. `Kokkos::sqrt`, to ensure performance and portability on GPUs.
-
-# Other Formatting Conventions
-
-IPPL uses `clang-format` for automatic formatting. For explanations of the available settings, refer to the [clang documentation](https://clang.llvm.org/docs/ClangFormatStyleOptions.html). 
-IPPL's settings are available in the repository root. For more information about the formatting, refer to the workflow below.
-
-# Automatic Code Formatting
-
-IPPL uses `clang-format` to automatically format the codebase to maintain a consistent code style. When modifying IPPL, the changes can be reformatted automatically by 
-using a *git hook*. A git hook is a script that is executed by `git` before completing certain actions. The `hooks/` top-level directory includes a `pre-commit` script and a 
-shell script for setting up the git hook. Git hooks are stored in `.git/hooks`; the shell script creates a symbolic link in `.git/hooks` pointing to the `pre-commit` script, 
-effectively creating a pre-commit hook for the local repository. A pre-commit hook is run automatically before every commit.
-
-The provided script automatically runs `clang-format` on all files with *staged* changes, i.e. files that have been added to the commit, then re-stages these files to include 
-the reformatted changes in the commit. The result is that, even if the code is not properly formatted when you run `git commit`, the code is automatically reformatted before the 
-commit is created, so all committed code will always have the proper formatting.
-
-## Caveats
-
-- `clang-format` must be available to use the automatic formatting; Beware of the order in which modules are loaded, as the presence of `clang` can affect project configuration.
-  If you newly configure a project and `clang` has higher priority in your `$PATH` than `gcc` (or another desired compiler), the project may become configured to compile with clang
-  instead of your desired compiler. In general, it is advisable to only load the clang module once the project is configured, or to load clang before your desired compiler such
-  that it has lower priority in your `$PATH`.
-- To avoid misconfigurations due to the Clang module, a simple workaround is to create a symbolic link to `clang-format` in a folder that is always in your `$PATH`.
-  To locate `clang-format`, run `which clang-format` while the module is loaded. Create a symbolic link with `ln -s "$(which clang-format)" /path/to/link`, where `/path/to` is
-  included in your `$PATH`. Conventional paths include `~/.local/bin` (this folder may need to be created). If this is not already in your `$PATH`, you can modify
-  your `~/.bash_profile` to add this to your path: `PATH=$PATH:~/.local/bin`.
-- The pre-commit script always reformats and re-stages *entire* files. If you used `git add -i` to only stage a subset of the changes in a file, the pre-commit script will
-  render the interactive staging moot by staging the entire file. To prevent this, use the `--no-verify` flag when committing; this makes `git` skip the pre-commit script. Note that 
-  this means that your changes will not be reformatted before committing. If you would like to commit only a subset of the changes made to a file but still want to run the formatter,
-  you can stash the changes you don't want to commit by stashing in patch mode (`git stash save -p`) and shelving the other changes. After committing, run `git stash pop` to restore
-  the uncommitted changes.
-- The pre-commit script only reformats *staged* files. It does not affect unstaged or unmodified files. To reformat unchanged files, you will have to run the formatter manually.
-  This is also true if you stage a subset of modified files; the staged files will be reformatted, but unstaged files will not be reformatted even if they have modifications.
-
-Refer to our git introduction if the git-related terms on this page are unclear.
-
-# Git brief introduction 
-
-For those in need of a refresher or an introduction, here is a glossary of Git terms relevant to the workflow caveats, as well as some useful commands and flags:
-
-- A file is *tracked* if it is under version control. A file that has never been committed is *untracked* and will show up under "untracked files" when running `git status`.
-- Files whose names match patterns in a `.gitignore` file will be ignored by git and do not show up as untracked. To start tracking an ignored file, use the `-f` flag when staging it.
-- The *working tree* is the current state of the repository, excluding untracked files. Changes to the working tree are shown by `git diff`.
-- Before committing, changes have to be *staged*. This is done by running `git add` to stage the changes that need to be committed. You can view the staged changes using `git diff --staged`. This represents the changes that will be recorded by running `git commit`.
-- You can stage any subset of the changes to the working tree. You can also stage only a subset of changes to a file by using *interactive staging* with `git add -i` and choosing "patch" at the interactive prompt.
-- A *commit* is a set of changes that constitute a fixed point in the repository history. Running `git commit` creates a new commit out of the staged changes. Unstaged changes are untouched.
-
-
diff --git a/doc/examples/BasicsFFT.hpp b/doc/examples/BasicsFFT.hpp
deleted file mode 100644
index 010e8a92a..000000000
--- a/doc/examples/BasicsFFT.hpp
+++ /dev/null
@@ -1,99 +0,0 @@
-/**
-@page basics_fft Basics: FFT
-@section fft Introduction
-The FFT(Fast Fourier Transform) class performs complex-to-complex, real-to-complex and real-to-real
-on IPPL Fields. Currently, we use heffte for taking the transforms and the class FFT serves as an
-interface between IPPL and heffte. In making this interface, we have referred Cabana library
-https://github.com/ECP-copa/Cabana.
-
- * @subsection FFT Transformation Types
- *
- * FFT is templated on the type of transform to be performed, the dimensionality of the Field to
-transform, and the
- * floating-point precision type of the Field (float or double).
- *
- * **Types of transformation**
- * - complex-to-complex FFT: 'ippl::CCTransform'
- * - real-to-complex FFT: 'ippl::RCTransform'
- * - Sine transform: 'ippl::SineTransform'
- * - Cosine transform: 'ippl::CosTransform'
- * - Cosine type 1 transform: 'ippl::Cos1Transform'
-
-@section Example Usage
-
-Consider an example of a transformation from real valued Field to complex valued Field.
-Given a Field fieldInput, we can perform a forward FFT as follows:
-@code
-// Define FFT-Parameters
-ippl::ParameterList fftParams;
-fftParams.add("use_heffte_defaults", true);
-fftParams.add("r2c_direction", 0);
-
-
-// Define layout of complex valued Field output
-std::array<int, dim> pt = {64, 64, 64};
-std::array<double, dim> dx = {
-    1.0 / double(pt[0]),
-    1.0 / double(pt[1]),
-    1.0 / double(pt[2]),
-};
-ippl::Vector<double, 3> hx     = {dx[0], dx[1], dx[2]};
-ippl::Vector<double, 3> origin = {0, 0, 0};
-
-ippl::NDIndex<dim> ownedOutput;
-if (fftParams.get<int>("r2c_direction") == 0) {
-        ownedOutput[0] = ippl::Index(pt[0] / 2 + 1);
-        ownedOutput[1] = ippl::Index(pt[1]);
-        ownedOutput[2] = ippl::Index(pt[2]);
-} else if (fftParams.get<int>("r2c_direction") == 1) {
-        ownedOutput[0] = ippl::Index(pt[0]);
-        ownedOutput[1] = ippl::Index(pt[1] / 2 + 1);
-        ownedOutput[2] = ippl::Index(pt[2]);
-} else if (fftParams.get<int>("r2c_direction") == 2) {
-        ownedOutput[0] = ippl::Index(pt[0]);
-        ownedOutput[1] = ippl::Index(pt[1]);
-        ownedOutput[2] = ippl::Index(pt[2] / 2 + 1);
-} else {
-        if (ippl::Comm->rank() == 0) {
-            std::cerr << "RCDirection need to be 0, 1 or 2 and it"
-            << "indicates the dimension in which data is shortened" << std::endl;
-            }
-        return 0;
-}
-
-ippl::FieldLayout<dim> layoutOutput(MPI_COMM_WORLD, ownedOutput, isParallel);
-Mesh_t meshOutput(ownedOutput, hx, origin);
-field_type_complex fieldOutput(meshOutput, layoutOutput);
-
-
-// Fill Field fieldInput with random numbers
-typename field_type_real::view_type& view            = fieldInput.getView();
-typename field_type_real::host_mirror_type fieldInput_host = fieldInput.getHostMirror();
-
-const int nghost = fieldInput.getNghost();
-std::mt19937_64 eng(42 + ippl::Comm->rank());
-std::uniform_real_distribution<double> unif(0, 1);
-
-for (size_t i = nghost; i < view.extent(0) - nghost; ++i) {
-    for (size_t j = nghost; j < view.extent(1) - nghost; ++j) {
-        for (size_t k = nghost; k < view.extent(2) - nghost; ++k) {
-            fieldInput_host(i, j, k) = unif(eng);  // 1.0;
-        }
-    }
-}
-Kokkos::deep_copy(fieldInput.getView(), fieldInput_host);
-
-
-// Define FFT object
-typedef ippl::FFT<ippl::RCTransform, field_type_real> FFT_type;
-std::unique_ptr<FFT_type> fft;
-fft = std::make_unique<FFT_type>(layoutInput, layoutOutput, fftParams);
-
-
-// Perform FFT
-fft->transform(ippl::FORWARD, fieldInput, fieldOutput); // Forward transform
-fft->transform(ippl::BACKWARD, fieldInput, fieldOutput); // Reverse transform
-
-
-@endcode
-*/
\ No newline at end of file
diff --git a/doc/examples/BasicsFields.hpp b/doc/examples/BasicsFields.hpp
deleted file mode 100644
index ce1802a2a..000000000
--- a/doc/examples/BasicsFields.hpp
+++ /dev/null
@@ -1,238 +0,0 @@
-
-/**
-* @page basics_fields Basics: Fields
- *
- *
- *
-@section field_intro Introduction
-This sections provides the readers with a brief background on the used classes for handling Fields
-in IPPL.
-* ## FieldLayout
-//
-FieldLayout describes how a given index space (represented by an NDIndex
-object) is distributed among MPI ranks. It performs the initial
-partitioning. The user may request that a particular dimension not be
-partitioned by flagging that axis as 'SERIAL' (instead of 'PARALLEL').
-* @code
-        int pt = 25;
-        ippl::Index I(pt);
-        ippl::NDIndex<dim> owned(I, I, I);
-        std::array<bool, dim> isParallel;
-        isParallel.fill(true);  // Specifies SERIAL, PARALLEL dims
-        // all parallel layout, standard domain, normal axis order
-        ippl::FieldLayout<dim> layout(MPI_COMM_WORLD, owned, isParallel);
-* @endcode
-In this example, we create a 3-dimensional FieldLayout with 25 points in each direction. The layout
-is distributed among MPI ranks.
-
-
-* ## BareField
-The BareField class in IPPL is a template class that represents a numerical field in a computational
-domain. It is designed to handle data in up to three dimensions and supports various data types
-through its template parameter T. It provides a Kokkos-based multidimensional array, or view, which
-is the main data structure used to store field values. The class is integrated with IPPL's field
-layout and halo cell system for managing computational domains and communication between them,
-especially in parallel computing environments. A field can be initialized with a specific layout,
-and it supports operations such as resizing, updating the layout, and operations related to ghost
-cells which are used for boundary conditions and domain communication. It offers functions for
-calculating aggregate values over the field, such as sums, maxima, minima, and products. Fields can
-be assigned values from constants or other fields through expression templates, allowing for complex
-computations and assignments. The class provides range policies for iteration that can exclude or
-include ghost layers, giving flexibility in how the field data is traversed and manipulated.
-
-
-*@code
-constexpr unsigned int dim = 3;
-int numPoints = 100;
-ippl::Index domainIndex(numPoints);
-ippl::NDIndex<dim> domain(domainIndex, domainIndex, domainIndex);
-
-ippl::FieldLayout<dim> layout(domain);
-    // Create a BareField with 3 dimensions, double data type, and 1 ghost layer.
-ippl::BareField<double, dim> field(layout, 1);
-*@endcode
-
-
-
-*@section Field Field
-The Field class in IPPL is an advanced version of BareField, augmented with a mesh for defining the
-spatial domain and equipped with customizable boundary conditions. The class is templated to be
-flexible for various data types (T), dimensions (Dim), mesh types (Mesh), and centering schemes
-(Centering), along with additional Kokkos view arguments (ViewArgs...). It's associated with a Mesh
-object that dictates the structure of the simulation space. Boundary conditions can be set and
-updated, affecting how the field interacts with the limits of the simulation space. Offers methods
-for calculating volume integrals and averages, which are useful for analyzing the field over its
-entire domain. Inherits from BareField, allowing for basic field operations and attribute access.
-
-### Example: Creating a Field
- * The following example showcases the creation and basic manipulation of a field in IPPL:
- *
- * @code{.cpp}
-using namespace ippl;
-
-constexpr unsigned int dim = 3;
-std::array<int, dim> points = {256, 256, 256};
-
-ippl::Index Iinput(points[0]);
-ippl::Index Jinput(points[1]));
-ippl::Index Kinput(points[2]);
-ippl::NDIndex<dim> ownedInput(Iinput, Jinput, Kinput);
-
-// specifies SERIAL, PARALLEL dimensions
-std::array<bool, dim> isParallel;
-isParallel.fill(true);
-
-ippl::FieldLayout<dim> layoutInput(MPI_COMM_WORLD, ownedInput, isParallel);
-
-double dx = 1.0 / double(points);
-Vector<double,dim> hx = {dx, dx, dx};
-Vector<double,dim> origin = {0.0, 0.0, 0.0};
-
-UniformCartesian<double,dim> mesh(owned, hx, origin);
-Field<double,dim> field(mesh, layout);
-@endcode
-*
-* This example outlines the steps to define a three-dimensional field, specifying its layout and
-parallelization strategy.
-*
-
-
-
-
-
-* @subsection useful_field_functions Useful Field Functions
-* @subsubsection useful_field_ops Mathematical Operations
-* @code
-// Computes Lp norm of the field. For Max. norm p=0. Default is 2-norm.
-auto fieldNorm = norm(field,p);
-
-// Computes dot product of vector fields (in each element) and returns a scalar field
-auto field = dot(vfield, vfield)
-
-// Innerproduct of two scalar fields and returns a scalar
-auto fSquare = innerProduct(field, field);
-
-// Computes the sum of the field
-auto fieldSum = field.sum();
-
-// $\int f dV$ computed using midpoint rule
-auto fieldVolIntegral = field.getVolumeIntegral();
-* @endcode
-
-
-*@subsubsection field_properties Field Properties
-*@code
-// Returns the range policy for the fields excluding the ghosts layers.
-// If you want to include ghost layers specify nghost as an argument
-auto fieldRange = field.getFieldRangePolicy();
-
-// Return the number of ghost layers in the field
-auto nghost = field.getNghost();
-
-// Returns the underyling field layout
-auto layout = field.getLayout();
-
-// Get the local n-dimension indices from the field layout
-auto lDom = layout.getLocalNDIndex();
-
-// Get the global domain indices from the field layout
-auto gDom = layout.getDomain();
-
-// Shallow copy of fields. Changing field2 changes field1 also.
-auto field2 = field1;
-
-// Deep copy of fields. Changing field2 does not change field1.
-auto field2 = field1.deepCopy();
-*@endcode
-
-*@subsubsection field_distributed Parallel Helper Functions
-*@code
-// Return the underyling Kokkos View of the field
-auto fview = field.getView();
-
-// Return the Host Mirror corresponding to the Kokkos device view
-// of the field. It is a no-op if the field is already on the host.
-auto fHostView = field.getHostMirror();
-
-// You still have to do a deep copy to get the data from the device to host or vice-versa
-Kokkos::deep_copy(fHostView, fview); // device to host
-Kokkos::deep_copy(fview, fHostView); // host to device
-*@endcode
-
-* @subsubsection init_field_from_func Initializing a Field from a Function
-* @code
-const ippl::NDIndex<Dim>& lDom = fieldLayout.getLocalNDIndex();
-const int nghost = field.getNghost();
-auto fview = field.getView();
-
-using index_array_type = typenamep ippl::RangePolicy<Dim>::index_array_type;
-
-ippl::parallel_for(
-    "Assign a field based on func", field.getFieldRangePolicy(),
-    KOKKOS_LAMBDA(const index_array_type& args) {
-        // local to global index conversion
-        Vector<double, Dim> xvec = (args + lDom.first() - nghost + 0.5) * hr + origin;
-
-        // ippl::apply accesses the view at the given indices and obtains a
-        // reference; see src/Expression/IpplOperations.h
-        ippl::apply(fview, args) = func(xvec);
-    });
-*@endcode
-
-- To write dimension independent kernels use the wrappers 'ippl::parallel_for' and
-'ippl::parallel_reduce'.
-- If you don't want dimension independence in your application then you can just use
-'Kokkos::parallel_for' and 'Kokkos::parallel_reduce'.
-* @subsubsection boundary_conditions_fields Boundary Conditions for Fields
-Setting BCs for fields is a necessary prerequisite before applying differential operators on fields!
-Otherwise you will get garbage for the points close to the boundary.
-*@code
-typedef ippl::BConds<Field<t, Dim>, Dim> bc_type;
-bc_type bc;
-// Available BCs in Ippl see src/Field/BcTypes.h
-for(unsigned i = 0; i < 2*Dim; ++i){
-    bc[i]= std::make_shared<ippl::PeriodicFace<Field<T, Dim>>>(i);
-}
-
-field.setFieldBC(bc);
-bc_type BCs = field.getFieldBC();
-* @endcode
-* @subsubsection diff_op_fields Differential Operators for Fields
-* @code
-using mesh_type = ippl::UniformCartesian<T, Dim >;
-using centering_type = typename mesh_type::DefaultCentering ;
-using sfield_type = Field<double, Dim, mesh_type, centering_type>;
-using vfield_type = Field<Vector<double, Dim>, Dim, mesh_type, centering_type>;
-using mfield_type = Field <Vector<Vector<double, Dim>, Dim>, Dim, mesh_type, centering_type>;
-
-sfield_type sfield (field.get_mesh(), field.getLayout());
-vfield_type vfield (field.get_mesh (), field.getLayout ());
-mfield_type mfield (field.get_mesh (), field.getLayout ());
-
-// Computes gradient of a scalar field by cell - centered finite difference and returns a vector
-field vfield = grad(field);
-
-// Computes divergence of a vector field by cell - centered finite difference and returns a scalar
-field field = div(vfield);
-
-// Computes curl of a scalar field by cell - centered finite difference and returns a vector field
-// Only available in 3 D for the moment
-vfield = curl(field);
-
-// Computes Hessian of a scalar field by cell - centered finite difference and returns a matrix
-field
-// There is no native matrix data type in ippl so the output field is vector of vectors
-mfield = hess(field);
-
-// Computes Laplacian of a scalar field by cell - centered finite difference and returns a scalar
-field .
-// At the moment ippl does not do a copy of the original field when you specify the same scalar
-field
-// in both rhs and lhs . So the user has to allocate a different scalar field for lhs and rhs .
-sfield = laplace(field);
-
-* @endcode
-
-
-
-*/
diff --git a/doc/examples/BasicsIndex.hpp b/doc/examples/BasicsIndex.hpp
deleted file mode 100644
index 13c87b239..000000000
--- a/doc/examples/BasicsIndex.hpp
+++ /dev/null
@@ -1,62 +0,0 @@
-/**
-@page basic_index Basics: Index and NDIndex
- * @section index Introduction
- * ## Index
- *
- * The Index class represents a strided range of indices, and it is used to define the index extent
-of Field objects on construction.
- *
- * **Constructors**:
- * - `Index()`: Creates a null interval with no elements.
- * - `Index(n)`: Instantiates an Index object representing the range of integers from 0 to n-1
-inclusive, with implied stride 1.
- * - `Index(a,b)`: Instantiates an Index object representing the range of integers [a , b], with
-implied stride 1.
- * - `Index(a,b,s)`: Instantiates an Index object representing the range of integers [a , b], with
-stride s.
- *
- * **Examples**:
- * ```cpp
- * Index I(10);     // Integer set [0..9]
- * Index Low(5);    // Integer set [0..4]
- * Index High(5,9); // Integer set [5..9]
- * Index IOdd(1,9,2);   // Integer set [1..9] with stride 2
- * Index IEven(0,9,2);  // Integer set [0..9] with stride 2
- * ```
- * **Operations**:
- *
- * Given `Index I(a,n,s)` and an integer `j`, the following operations are possible:
- * ```cpp
- * I+j  : a+j+i*s     // For i in [0..n-1]
- * j-I  : j-a-i*s
- * j*I  : j*a + i*j*s
- * I/j  : a/j + i*s/j // Note: j/I is not defined due to non-uniform stride and fraction
-prohibition.
- * ```
- *
- * ## NDIndex
- *
- * NDIndex is a class that acts as a container for multiple Index instances. It simplifies
-operations such as intersections across N dimensions by forwarding requests to its contained Index
-objects.
- *
- @section Example Usage
-The following example demonstrates the use of Index and NDIndex classes.
-@code
-std::array<int, dim> pt = {64, 64, 64};
-ippl::Index Iinput(pt[0]);
-ippl::Index Jinput(pt[1]);
-ippl::Index Kinput(pt[2]);
-ippl::NDIndex<dim> ownedInput(Iinput, Jinput, Kinput);
-
-std::array<bool, dim> isParallel;  // Specifies SERIAL, PARALLEL dims
-isParallel.fill(true);
-
-ippl::FieldLayout<dim> layoutInput(MPI_COMM_WORLD, ownedInput, isParallel);
-@endcode
- *
- * In this example, we define an NDIndex object `ownedInput` with three Index objects `Iinput`,
-`Jinput`, and `Kinput`. We then create a FieldLayout object `layoutInput` using the NDIndex object
-and a boolean array `isParallel` that specifies the parallel dimensions.
- *
-*/
\ No newline at end of file
diff --git a/doc/examples/BasicsMesh.hpp b/doc/examples/BasicsMesh.hpp
deleted file mode 100644
index 0b1989bdf..000000000
--- a/doc/examples/BasicsMesh.hpp
+++ /dev/null
@@ -1,25 +0,0 @@
-/**
-@page basic_mesh Basics: Mesh
-*@section mesh Introduction
-*The Mesh class in IPPL is a basic class used for creating and handling meshes in simulations.
-*It lets you work with meshes of different sizes and types. You can get or set where the mesh starts
-(its origin) and find out the size of the grid it covers. *It's set up so other parts of the program
-can be updated if the mesh changes, like if it gets bigger or needs to be rearranged.
-@section example_usage Example Usage
-The following example demonstrates the use of the Mesh class in IPPL:
-* @code
-    using Mesh_t = ippl::UniformCartesian<double, dim>;
-
-    int pt = 25;
-    ippl::Index I(pt);
-    ippl::NDIndex<dim> owned(I, I, I);
-
-    double dx = 1.0 / double(pt);
-    ippl::Vector<double, dim> hx = {dx, dx, dx};
-    ippl::Vector<double, dim> origin = {0.0, 0.0, 0.0};
-    Mesh_t mesh(owned, hx, origin);
-* @endcode
-In this example, we initialize a 3-dimensional mesh using 25 points in each direction.
-We then define the mesh's origin, spacing, and size, and create a Mesh object using these
-parameters.
-*/
diff --git a/doc/examples/BasicsParticles.hpp b/doc/examples/BasicsParticles.hpp
deleted file mode 100644
index 58aa2bc14..000000000
--- a/doc/examples/BasicsParticles.hpp
+++ /dev/null
@@ -1,191 +0,0 @@
-/**
-* @page basic_particle Basics: Particles
-*
-* Introduction to handling particles in IPPL.
-* @section particles Particles in IPPL
-*
-* IPPL provides a flexible and efficient framework for handling particles in parallel computing
-environments.
-*
-* @subsection particle_concepts Key Concepts
-* The core components are `ParticleBase` and `ParticleAttrib` classes, which provide the base
-functionality and attributes for particles.
-* - `ParticleBase` acts as the abstract base class for a set of particles, requiring a derived class
-to specify data attributes (e.g., mass, charge).
-* - `ParticleAttrib<T>` represents a single particle attribute, with T indicating the data type.
-
-
-@subsubsection particle_base 'ParticleBase'
-*   The user must define a class derived from 'ParticleBase' which describes
-*   what specific data attributes the particle has (e.g., mass or charge).
-*   'ParticleBase' is the abstract base class for a set of particles.
-*   Each attribute is an instance of a ParticleAttribute<T> class; 'ParticleBase'
-*   keeps a list of pointers to these attributes, and performs particle creation
-*   and destruction.
-*
-*   'ParticleBase' is templated on the 'ParticleLayout' mechanism for the particles.
-*   This template parameter should be a class derived from 'ParticleLayout'.
-*   'ParticleLayout'-derived classes maintain the info on which particles are
-*   located on which processor, and performs the specific communication
-*   required between processors for the particles.  The 'ParticleLayout' is
-*   templated on the type and dimension of the atom position attribute, and
-*   'ParticleBase' uses the same types for these items as the given
-*   'ParticleLayout'.
-*
-*   'ParticleBase' and all derived classes have the following common
-*   characteristics:
-*       - The spatial positions of the N particles are stored in the
-*         particle_position_type variable R
-*       - The global index of the N particles are stored in the
-*         particle_index_type variable ID
-*       - A pointer to an allocated layout class.  When you construct a
-*         'ParticleBase', you must provide a layout instance, and 'ParticleBase'
-*         will delete this instance when it (the 'ParticleBase') is deleted.
-*
-*   To use this class, the user defines a derived class with the same
-*   structure as in this example:
-* @code
-*     class UserParticles :
-*              public ParticleBase< ParticleSpatialLayout<double,3> > {
-*     public:
-*       // attributes for this class
-*       ParticleAttribute<double> rad;  // radius
-*       particle_position_type    vel;  // velocity, same storage type as R
-*
-*       // constructor: add attributes to base class
-*       UserParticles(ParticleSpatialLayout<double,2>* L) : ParticleBase(L) {
-*         addAttribute(rad);
-*         addAttribute(vel);
-*       }
-*     };
-*   @endcode
-*   This example defines a user class with 3D position and two extra
-*   attributes: a radius rad (double), and a velocity vel (a 3D Vector).
-
-* @subsubsection particle_attrib ParticleAttrib and ParticleAttribBase
- *
- * These classes form the foundation for all particle attribute classes within the framework.
- *
- * ParticleAttrib is a templated class designed to represent a single particle attribute, such as
-mass or charge.
- * It encapsulates an attribute as a data element within a particle object, stored using a
-Kokkos::View for efficient parallel computation.
- * This class is essential for handling the type information of the attribute and provides a suite
-of methods for creating, destroying, and performing operations on particle attributes.
- *
- * ParticleAttribBase serves as the generic base class for the templated ParticleAttrib class.
- * It provides a common interface for all particle attribute classes, including virtual methods for
-creating and destroying elements of the attribute array.
- * By encapsulating data for a variable number of particles in a Kokkos::View, it facilitates
-operations on this data.
- *
- * @subsubsection particle_layout ParticleLayout and ParticleSpatialLayout
- *
- * ParticleLayout manages particle distribution and serves as a base class for
-ParticleSpatialLayout.
- *
- * ParticleSpatialLayout is a derivative of ParticleLayout, ParticleSpatialLayout specifically
-handles particle distribution based on spatial positions relative to a predefined grid.
- * It ensures particles are processed on the same MPI rank as their corresponding spatial region,
-defined by 'FieldLayout'.
- * It requires periodic updates to adjust particle locations.
- *
-
-
-
-
- * @subsection particle_example Example: Defining a Particle Bunch
- * Here's how you can define a simple particle bunch in IPPL:
- *
- * @code{.cpp}
- * using namespace ippl;
- *
- * template <class PLayout>
- * struct Bunch : public ParticleBase<PLayout> {
- *     ParticleAttrib<double> mass, charge;
- *     ParticleAttrib<Vector<double>> R, V;
- *
- *     Bunch(PLayout& layout) : ParticleBase<PLayout>(layout) {
- *         // add your own application attributes !
- *         this->addAttribute(mass);
- *         this->addAttribute(charge);
- *         this->addAttribute(R);
- *         this->addAttribute(V);
- *     }
- *    ~Bunch() = default;
- * };
- * // Compiled to single Kokkos Kernel
- * bunch->R = bunch->R + dt * bunch->V;
- * @endcode
- *
- * This example demonstrates how to extend `ParticleBase` to create a `Bunch` class that includes
-common particle attributes and how to perform a single timestep.
- *
- * @subsection useful_particle_functions Useful Particle Functions
- * Consider bunch a pointer to a derived class 'Bunch' from 'ParticleBase' and has attributes 'R',
-'V',
- *'mass', 'charge'
- * @subsubsection helper_particle_functions Helper Functions
- * A collection of essential functions for particle manipulation and attribute management, such as
-creation, deletion, and data operations.
-@code
-    // Creates nParticles locally by a core or GPU ( not the total no . of particles )
-    bunch->create( nParticles );
-
-    // Get the local number of particles in that rank ( in ippl there is a one - one correspondence
-between
-    // MPI ranks and GPUs
-    size_t localnum = bunch->getLocalNum ();
-
-    // Particle deletion Function . invalid is a boolean View
-    // marking which indices are invalid . destroyNum is the
-    // total number of invalid particles
-    bunch->destroy(invalid, destroyNum );
-
-    // Device and host views and the deep copy operations between them
-    // similar to fields
-    Kokkos::deep_copy(bunch->R.getHostMirror(), bunch->R.getView ()); // device to host
-    Kokkos::deep_copy(bunch->R.getView()      , bunch->R.getHostMirror()); // host to device
-
-    // sum () , prod () , min () and max () functions available for
-    // particle attributes similar to fields
-    auto Rsum = bunch->R.sum ();
-*@endcode
-*@subsubsection bdry_condition_particles Boundary Conditions for Particles
-* Setting up boundary conditions (e.g., periodic, reflective) for particle simulations.
-*@code
-
-// Types of BCs : PERIODIC , SINK , RFELECTIVE , NO
-// Sets periodic BCs in all directions
-bunch->setParticleBC(ippl::BC::PERIODIC);
-
-// Assume a 3D problem
-typedef std::array<ippl::BC, 6 > bc_container_type ;
-bc_container_type bcs ;
-
-for ( unsigned int i = 0; i < 4; ++ i ) {
-    bcs[i] = ippl::BC::NO;
-}
-
-bcs[4] = ippl::BC::PERIODIC;
-bcs[5] = ippl::BC::PERIODIC;
-// Sets open BCs in x and y directions but periodic in z direction
-bunch->setParticleBC( bcs );
-*@endcode
-*@subsubsection Interpolation_grid_particles Interpolation between Grid and Particles
- * Methods for data transfer between particles and grid, supporting operations like scatter and
-gather for efficient particle-field interaction.
-*@code
-// Particles-> grid
-// Can interpolate any particle attribute ( both scalar and vectors ) to the grid .
-// Only linear ( cloud - in - cell ) interpolation is available at the moment .
-// Interpolate a scalar particle attribute q ( e . g . charge ) onto the field rho .
-scatter(bunch->q , rho , this->R);
-
-// Grid - > particles
-// Can interpolate any field ( both scalar and vectors ) to the particles .
-// Only linear interpolation is available at the moment .
-// Interpolate a vector field E ( e . g . electric field ) to the particles
-gather (bunch->E , Efield , this->R);
-*@endcode
-*/
diff --git a/doc/examples/BasicsSolver.hpp b/doc/examples/BasicsSolver.hpp
deleted file mode 100644
index b88784fae..000000000
--- a/doc/examples/BasicsSolver.hpp
+++ /dev/null
@@ -1,120 +0,0 @@
-/**
-@page basic_solver Basics: Solver {#Solver} 
-
-@section solvers Solvers
-
-Different types of Poisson solvers and a biharmonic solver are available in IPPL.
-
-Poisson solvers are numerical method used to solve Poisson's equation, a PDE that appears in many
-areas of physics. The equation is of the form:
-
-\f[
-    - \nabla^2 \phi = f
-\f]
-
-where \f$\nabla^2 \f$ is the Laplace operator, \f$\phi\f$ is the unknown function, and \f$ f \f$ is
-a given function.
-
-IPPL provides different variants:
-
-- ippl::FFTPeriodicPoissonSolver: Solves Poisson equation with periodic bcs spectrally
-- ippl::FFTOpenPoissonSolver: Solves Poisson equation with Open BCs using FFTs (subtypes: Hockney
-(2nd order solver), Vico (spectral solver))
-- ippl::FFTTruncatedGreenSolver: Solves Poisson equation with periodic bcs, based on FFT
-- ippl::PoissonCG: Solves Poison equation with Conjugate Gradient method
-
-All these inherit from the Poisson class.
-
-The FFT based solvers are not available for 1D as heFFTe doesn't support 1D FFTs.
-
-For Poisson equation solved with these different types of solvers see:
-
-- test/solver/TestFFTPeriodicPoissonSolver.cpp (for FFTPeriodicPoissonSolver)
-- test/solver/TestGaussian_convergence.cpp (for FFTOpenPoissonSolver)
-- test/solver/TestFFTTruncatedGreenSolver.cpp (for FFTTruncatedGreenSolver)
-- test/solver/TestCGSolver.cpp (for CG Poisson solver)
-
-@subsection example_poisson_solver Example: Poisson solver
-
-This section shows how to use the solvers. This example uses the FFTOpenPoissonSolver. The concepts
-used here are the same for the other solvers.
-___
-
-To start we define the mesh and the field types:
-@code
-using Mesh_t      = ippl::UniformCartesian<double, 3>;
-using Centering_t = Mesh_t::DefaultCentering;
-typedef ippl::Field<double, Dim, Mesh_t, Centering_t> field;
-typedef ippl::Field<ippl::Vector<double, Dim>, Dim, Mesh_t, Centering_t> fieldV;
-
-
-// .... Define the mesh and the field types .... //
-
-
-// define the R (rho) field
-field exact, rho;
-exact.initialize(mesh, layout);
-rho.initialize(mesh, layout);
-
-// define the Vector field E (LHS)
-fieldV exactE, fieldE;
-exactE.initialize(mesh, layout);
-fieldE.initialize(mesh, layout);
-
-@endcode
-
-Then we need to define the solver type we want to use:
-@code
-using Solver_t = ippl::FFTOpenPoissonSolver<fieldV, field>
-@endcode
-We define the parameters to pass to the solver. Consider the not declared variable to be your choice
-for your own simulation:
-@code
-// Parameter List to pass to solver
-ippl::ParameterList params;
-
-// Set the parameters
-params.add("use_pencils", true); // can be true or false
-params.add("comm", ippl::a2a); // can be ippl::a2a, ippl::a2av, ippl::p2p, ippl::p2p_pl
-params.add("use_reorder", true); // can be true or false
-params.add("use_heffte_defaults", false); // can be true or false
-params.add("use_gpu_aware", true); // can be true or false
-params.add("r2c_direction", 0); // can be 0, 1, 2
-params.add("algorithm", Solver_t::HOCKNEY); // can be Solver_t::HOCKNEY or Solver_t::VICO
-params.add("output_type", Solver_t::SOL_AND_GRAD); // can be Solver_t::SOL_AND_GRAD or
-Solver_t::SOL_ONLY
-@endcode
-
-
-
-
-Now we can define the solver object and solve the Poisson equation:
-@code
-Solver_t FFTsolver(fieldE, rho, params);
-FFTsolver.solve();
-@endcode
-The potential is stored in the rho Field. The E-Field is stored in the fieldE Field.
-
-
-## [Optional] Using a Preconditioner 
-
-If you want to precondition the solver you can add following parameters to the parameter list:
-@code
-// Define the preconditioner type (jacobi, newton, chebyshev, richardson or gauss_seidel)
-params.add("preconditioner_type", preconditioner_type);
-// Define the gauss_seidel parameters
-params.add("gauss_seidel_inner_iterations", gauss_seidel_inner_iterations);
-params.add("gauss_seidel_outer_iterations", gauss_seidel_outer_iterations);
-// Define the newton parameters
-params.add("newton_level", newton_level);
-// Define the chebyshev parameters
-params.add("chebyshev_degree", chebyshev_degree);
-// Define the richardson parameters
-params.add("richardson_iterations", richardson_iterations);
-// Define the communication parameters (needed for richardson and gauss_seidel)
-params.add("communication", communication);
-// Merge the parameters
-solver.mergeParameters(params);
-@endcode
-
-*/
diff --git a/doc/examples/CustomPreconditioner.hpp b/doc/examples/CustomPreconditioner.hpp
deleted file mode 100644
index ac4e9f261..000000000
--- a/doc/examples/CustomPreconditioner.hpp
+++ /dev/null
@@ -1,89 +0,0 @@
-/** @page custom_preconditioner Defining Custom Preconditioners
-
-# Introduction to the Preconditioner Base Class
-
-The preconditioner class in the IPPL framework serves as an abstract base class for different preconditioning strategies applied in iterative solvers. It encapsulates common functionalities and interfaces that are essential for all types of preconditioners.
-Structure of the Preconditioner Base Class
-
-- Template Parameter: The class template Field determines the type of the numerical field the preconditioner will operate on.
-- Constructor: Constructors initialize the preconditioner, optionally setting a type name to identify the preconditioner strategy.
-- Virtual Function ('operator()'): This is a pure virtual function in the base class that must be implemented by derived classes to define the specific preconditioning behavior.
-
-Steps to Create a Custom Preconditioner
-## Step 1: Define the Preconditioner Class
-
-Begin by defining a new class that inherits from the 'preconditioner<Field>' provided by the IPPL framework. This new class should implement all abstract methods from the base class and can add additional members as needed for its specific strategy.
-
-@code
-template <typename Field>
-struct custom_preconditioner : public preconditioner<Field> {
-    // Additional member variables here
-
-    custom_preconditioner(std::string name = "Custom") : preconditioner<Field>(name) {
-        // Initialization code here
-    }
-
-    Field operator()(Field& u) override {
-        // Implementation of preconditioning logic here
-        return u; // Placeholder return
-    }
-};
-@endcode
-
-## Step 2: Implement the Constructor
-
-Use the constructor of your custom preconditioner to initialize any data members and forward any necessary parameters to the base class constructor, which sets the type name of the preconditioner.
-## Step 3: Override the Operator Function
-
-Implement the 'operator()' function to apply your preconditioning logic to the input field. This method is crucial as it defines how the preconditioner modifies the input data, aligning with the specific algorithmic needs of your solver.
-# Example Implementations
-
-## Jacobi Preconditioner
-
-The 'jacobi_preconditioner' provided by IPPL is a derived class of preconditioner. It implements a specific preconditioning strategy using an inverse diagonal matrix and a damping factor. Here is how it extends the base class:
-
-
-@code
-template <typename Field, typename InvDiagF>
-struct jacobi_preconditioner : public preconditioner<Field> {
-    InvDiagF inverse_diagonal_m;
-    double w_m;  // Damping factor
-
-    jacobi_preconditioner(InvDiagF&& inverse_diagonal, double w = 1.0)
-        : preconditioner<Field>("Jacobi"), inverse_diagonal_m(std::move(inverse_diagonal)), w_m(w) {}
-
-    Field operator()(Field& u) override {
-        typename Field::mesh_type& mesh = u.get_mesh();
-        typename Field::layout_type& layout = u.getLayout();
-        Field res(mesh, layout);
-
-        res = inverse_diagonal_m(u);  // Apply inverse diagonal matrix
-        res = w_m * res;              // Apply damping factor
-        return res;
-    }
-};
-@endcode
-## Scaling Preconditioner
-
-A simple example of a custom preconditioner that scales the input field can be structured as follows:
-
-
-@code
-template <typename Field>
-struct scaling_preconditioner : public preconditioner<Field> {
-    double scale_factor;
-
-    scaling_preconditioner(double factor = 1.0)
-        : preconditioner<Field>("Scaling"), scale_factor(factor) {}
-
-    Field operator()(Field& u) override {
-        return scale_factor * u; // Scales the input field
-    }
-};
-@endcode
-
-# Integration with Solvers
-
-To utilize your custom preconditioner in a solver, instantiate it and configure the solver to use it.
-
-*/ 
\ No newline at end of file
diff --git a/doc/examples/CustomSolver.hpp b/doc/examples/CustomSolver.hpp
deleted file mode 100644
index 2d6644329..000000000
--- a/doc/examples/CustomSolver.hpp
+++ /dev/null
@@ -1,77 +0,0 @@
-/**
-@page custom_solver Creating Custom Solver
-
-Here, we'll provide detailed guidelines on how to extend this base class of the 'SolverAlgorithm' to develop your own solver algorithm, 
-using the PCG (Preconditioned Conjugate Gradient) solver as an example.
-
-## Introduction to SolverAlgorithm Base Class
-
-The SolverAlgorithm class is a template abstract class designed to serve as a
-foundation for various numerical solver algorithms. 
-It provides a common interface for solving problems of the form 
-Op(lhs) = rhs, where Op is a differential operator and lhs and rhs are fields.
-
-** Key Components of SolverAlgorithm **
-- Template Parameters: The class template parameters FieldLHS and FieldRHS define the types for the left-hand side (LHS) and right-hand side (RHS) of the equation respectively.
-- Virtual Function: The operator() function is a pure virtual function that must be implemented by derived classes. It is where the main logic of the solver is implemented.
-
-
-@code
-*
-#include <functional>
-
-#include "Utility/ParameterList.h"
-
-namespace ippl {
-
-    template <typename FieldLHS, typename FieldRHS>
-    class SolverAlgorithm {
-    public:
-        using lhs_type = FieldLHS;
-        using rhs_type = FieldRHS;
-
-        /*!
-         * Solve the problem described by Op(lhs) = rhs, where Op is an unspecified
-         * differential operator (handled by derived classes)
-         * @param lhs The problem's LHS
-         * @param rhs The problem's RHS
-         * @param params A set of parameters for the solver algorithm
-         * /
-        virtual void operator()(lhs_type& lhs, rhs_type& rhs, const ParameterList& params) = 0;
-    };
-
-}  // namespace ippl
-
-@endcode 
-
-
-## Steps to Create a Custom Solver
-### 1. Define the Solver Class
-
-Start by defining your solver class that inherits from SolverAlgorithm. Specify any additional data members or methods needed for your solver.
-
-@code
-#include "SolverAlgorithm.h"
-
-template <typename FieldLHS, typename FieldRHS = FieldLHS>
-class MySolver : public ippl::SolverAlgorithm<FieldLHS, FieldRHS> {
-    using Base = ippl::SolverAlgorithm<FieldLHS, FieldRHS>;
-public:
-    // Additional methods or data members here
-
-};
-@endcode
-## 2. Implement the Solver Logic
-
-Implement the operator() function, which contains the core logic for the solver. This function should use the provided lhs, rhs, and params to compute the solution to the problem.
-
-@code
-void operator()(typename Base::lhs_type& lhs, typename Base::rhs_type& rhs, const ParameterList& params) override {
-    // Initialization and setup
-    // Iterative solution process
-    // Post-processing and cleanup
-}
-@endcode
-
-
-*/
diff --git a/doc/examples/HelloWorld.hpp b/doc/examples/HelloWorld.hpp
deleted file mode 100644
index cbe802ed1..000000000
--- a/doc/examples/HelloWorld.hpp
+++ /dev/null
@@ -1,29 +0,0 @@
-/**
-@page hello_world HelloWorld
-
-This is Hello World in IPPL.
-
-@code
-
-const char* TestName = "IPPL_Test";
-
-#include "Ippl.h"
-
-int main(int argc, char* argv[]) {
-    ippl::initialize(argc, argv);
-    {
-        Inform msg(TestName);
-
-        msg << "Hello World" << endl;
-    }
-    ippl::finalize();
-
-    return 0;
-}
-@endcode
-
-The executable can be run with the following command-line arguments:
-```
-./HelloWorld --info 10
-```
-*/
diff --git a/doc/examples/LandauDampingEx.hpp b/doc/examples/LandauDampingEx.hpp
deleted file mode 100644
index 8942edcaf..000000000
--- a/doc/examples/LandauDampingEx.hpp
+++ /dev/null
@@ -1,122 +0,0 @@
-/**
- * @page LandauDamping LandauDamping
-
- * This is an example demonstrating the setup and execution of a Landau damping simulation using the
-IPPL framework.
- *
- * ### Usage
- * The executable can be run with the following command-line arguments:
- * ```
- * srun ./LandauDamping <nx> [<ny>...] <Np> <Nt> <stype> <lbthres> <tintegr> --overallocate
-<ovfactor> --info 10
- * ```
- * - **nx**: Number of cell-centered points in the x-direction.
- * - **ny...**: Number of cell-centered points in the y-, z-, ...-direction.
- * - **Np**: Total number of macro-particles in the simulation.
- * - **Nt**: Number of time steps to execute.
- * - **stype**: Field solver type, with FFT and CG (Conjugate Gradient) being supported.
- * - **lbthres**: Load balancing threshold. For example, a value of 0.01 means load balancing occurs
-if the load imbalance exceeds 1%.
- * - **tintegr**: Type of time integrator. For example Leapfrog.
- * - **ovfactor**: Over-allocation factor for buffers used in communication. A value of 1.0 means no
-over-allocation.
- *
- * ### Example Command
- * ```
- * srun ./LandauDamping 128 128 128 10000 10 FFT 0.01 LeapFrog --overallocate 2.0 --info 10
- * ```
- * This command runs a simulation with a 128x128x128 grid, 10,000 particles, for 10 time steps,
-using the FFT solver,
- * a load balancing threshold of 1%, with LeapFrog integration, overallocating buffers by a factor
-of 2.
- *
- * ### Implementation Detail
- * The main function initializes the Ippl framework, sets up the simulation parameters from
-command-line arguments,
- * and then creates and configures an instance of `LandauDampingManager` to manage the simulation.
-It performs pre-run
- * operations to set up the simulation environment and then runs the simulation for the specified
-number of time steps.
- * Timing information is collected and output for performance analysis.
- * @code
-constexpr unsigned Dim = 3;
-using T = double;
-const char* TestName = "LandauDamping";
-
-#include "Ippl.h"
-
-#include <Kokkos_MathematicalConstants.hpp>
-#include <Kokkos_MathematicalFunctions.hpp>
-#include <Kokkos_Random.hpp>
-#include <chrono>
-#include <iostream>
-#include <random>
-#include <set>
-#include <string>
-#include <vector>
-
-#include "datatypes.h"
-
-#include "Utility/IpplTimings.h"
-
-#include "LandauDampingManager.h"
-#include "Manager/PicManager.h"
-
-int main(int argc, char* argv[]) {
-    ippl::initialize(argc, argv);
-    {
-
-        Inform msg(TestName);
-        Inform msg2all(TestName, INFORM_ALL_NODES);
-        static IpplTimings::TimerRef mainTimer = IpplTimings::getTimer("total");
-        IpplTimings::startTimer(mainTimer);
-
-
-//Parses command-line arguments to set up simulation parameters.
-// This segment of code iterates through the command-line arguments provided to the application,
-// assigning each parameter to the corresponding variable. These parameters define the
-// simulation's grid size, number of particles, number of time steps, solver type, load balancing
-// threshold, and overallocation factor.
-//
-        int arg = 1;
-        Vector_t<int, Dim> nr;
-        for (unsigned d = 0; d < Dim; d++) {
-            nr[d] = std::atoi(argv[arg++]);
-        }
-        size_type totalP = std::atoll(argv[arg++]);
-        int nt  = std::atoi(argv[arg++]);
-        std::string solver = argv[arg++];
-        double lbt = std::atof(argv[arg++]);
-        std::string step_method = argv[arg++];
-
-//Sets up and executes the Landau damping simulation.
-//  After parsing the input parameters, this code initializes the LandauDampingManager with the
-//  specified configuration. It then calls pre_run to prepare the simulation environment, sets
-//  the simulation start time, and executes the simulation for the defined number of time steps.
-
-
-        // Create an instance of a manger for the considered application
-        LandauDampingManager<T, Dim> manager(totalP, nt, nr, lbt, solver, step_method);
-        // Perform pre-run operations, including creating mesh, particles,...
-        manager.pre_run();
-        manager.setTime(0.0);
-        msg << "Starting iterations ..." << endl;
-        manager.run(manager.getNt());
-        msg << "End." << endl;
-
-
-//Collects timing information and finalizes the simulation.
-//  Marks the end of the simulation execution, stops the main timer, and outputs timing
-//  information. This helps in analyzing the performance of the simulation. Finally, it
-//  calls `ippl::finalize()` to clean up the Ippl framework and gracefully exit the application.
-
-        IpplTimings::stopTimer(mainTimer);
-        IpplTimings::print();
-        IpplTimings::print(std::string("timing.dat"));
-    }
-    ippl::finalize();
-
-    return 0;
-}
-* @endcode
-*/
\ No newline at end of file
diff --git a/doc/extras/Basics.md b/doc/extras/Basics.md
deleted file mode 100644
index fca574f40..000000000
--- a/doc/extras/Basics.md
+++ /dev/null
@@ -1,29 +0,0 @@
-Basic Usage of Main IPPL Classes {#Basics}
-===============
-Following classes are core components of the IPPL library. The examples are meant to show how to use these classes.
-
-
-# Structure of IPPL
-
-<img src="ippl_structure.jpg" alt="ippl_structure" width="400"/>
-
-
-- [Index](basic_index.html) 
-- [Mesh](basic_mesh.html) 
-- [Fields](basics_fields.html)
-- [Particles](basic_particle.html)
-- [FFT](basics_fft.html)
-- [Solver](basic_solver.html) 
-
-**Extras**
-- [Creating a Custom Preconditioner](custom_preconditioner.html)
-- [Creating a Custom Solver](custom_solver.html)
-
-# Example Code
-
-**Hello World in IPPL**
-- [HelloWorld](hello_world.html)
-
-**Case Study of the LandauDamping Manager**
-- [LandauDamping](LandauDamping.html) 
-
diff --git a/doc/extras/CodeFormattingSetup.md b/doc/extras/CodeFormattingSetup.md
deleted file mode 100644
index cc69678dd..000000000
--- a/doc/extras/CodeFormattingSetup.md
+++ /dev/null
@@ -1,188 +0,0 @@
-# Code Formatting Setup Guide
-
-This guide explains how to set up automatic code formatting for IPPL development using the pre-commit git hook.
-
-## Overview
-
-IPPL uses two automatic formatters:
-- **clang-format-21**: For C/C++ source files (`.c`, `.cc`, `.cpp`, `.cxx`, `.h`, `.hpp`, etc.)
-- **cmake-format**: For CMake configuration files (`CMakeLists.txt`, `*.cmake`)
-
-The pre-commit hook runs these formatters automatically before each commit, ensuring all committed code adheres to the project's styling conventions.
-
-## 1. Installing clang-format-21
-
-### Ubuntu/Debian
-
-Add the LLVM repository and install clang-format-21:
-
-```bash
-# Add LLVM repository (Ubuntu 20.04+, Debian 11+)
-wget -O - https://apt.llvm.org/llvm-snapshot.gpg.key | sudo apt-key add -
-sudo apt-add-repository "deb http://apt.llvm.org/$(lsb_release -cs)/ llvm-toolchain-$(lsb_release -cs)-21 main"
-sudo apt update
-
-# Install clang-format-21
-sudo apt install clang-format-21
-```
-
-Verify the installation:
-
-```bash
-clang-format-21 --version
-```
-
-Note: If you have `clang-format` installed but it doesn't use the full name `clang-format-21`, then just create a symlink in your `.local` path that redirects `clang-format-21` to your real `clang-format` executable  
-
-### APPLE macOS Tahoe
-```bash
-brew install llvm@21
-clang-format --version                                                                                               
-```
-
-### Other Systems
-
-For other operating systems, visit the [LLVM download page](https://releases.llvm.org/) or use your system's package manager to locate `clang-format` version 21 or later.
-
-## 2. Installing cmake-format
-
-cmake-format is a Python package available via pip:
-
-```bash
-# Install cmake-format (Python 3.x required)
-pip install cmake-format
-```
-
-Verify the installation:
-
-```bash
-cmake-format --version
-```
-
-If you prefer to install it system-wide or in a virtual environment, refer to the [cmake-format documentation](https://cmake-format.readthedocs.io/).
-
-## 3. Setting Up the Pre-Commit Hook
-
-### Basic Setup
-
-The repository includes the git hook script. From the repository root, setup a symlink to the git hook (in the .git/hooks dir):
-
-```bash
-cd /path/to/ippl
-ln -s -f ../../scripts/pre-commit .git/hooks/pre-commit
-chmod +x .git/hooks/pre-commit
-```
-(note that the extra ../../ in the path is because git runs the hook from the .git/hooks directory, so the symlink has to be redirected)
-
-Alternatively, create a symbolic link manually directly from the git hooks dir:
-
-```bash
-cd /path/to/ippl/.git/hooks
-ln -s -f ../../scripts/pre-commit pre-commit
-chmod +x pre-commit
-```
-
-### Verification
-
-To verify the hook is installed, check that the symlink exists:
-
-```bash
-ls -la /path/to/ippl/.git/hooks/pre-commit
-```
-
-You should see output similar to:
-
-```
-lrwxrwxrwx  1 user group  23 Mar  4 12:00 pre-commit -> ../../scripts/pre-commit
-```
-
-## 4. How the Hook Works
-
-When you run `git commit`:
-
-1. The pre-commit hook identifies all staged C/C++ and CMake files
-2. For each file, it checks if formatting is needed by comparing the staged content with the formatted version
-3. If formatting is needed, the hook:
-   - Reports which files need reformatting
-   - Displays the command to fix each file
-   - Prevents the commit from proceeding
-4. Run the suggested command and re-stage the files
-5. Retry `git commit`
-
-Note that we include the command-line parameter `-style=file` in all clang-format commands mentioned here, but this is actually the default and skipping it should not cause problems. Providing there is a `.clang-format` file present in the repository root, all should work as expected.
-
-### Example Workflow
-
-```bash
-# Make changes and stage them
-git add src/myfile.cpp
-
-# Try to commit
-git commit -m "Add feature"
-
-# If formatting is needed, you'll see:
-# clang-format-21 -style=file -i src/myfile.cpp
-# Then re-stage and retry
-git add src/myfile.cpp
-git commit -m "Add feature"
-```
-
-## 5. Bypassing the Hook
-
-If you need to commit without running the hook (not recommended), use:
-
-```bash
-git commit --no-verify
-```
-
-**Warning**: Code committed without formatting may not adhere to project standards.
-
-## 6. Manual Formatting
-
-To format files without committing:
-
-```bash
-# Format a single C/C++ file
-clang-format-21 -style=file -i src/myfile.cpp
-
-# Format all C/C++ files in a directory
-find src -type f \( -name "*.cpp" -o -name "*.hpp" \) -exec clang-format-21 -style=file -i {} \;
-
-# Format CMake files
-cmake-format -c /path/to/ippl/.cmake-format.py -i CMakeLists.txt
-```
-
-## 7. Troubleshooting
-
-### Hook not executing?
-
-- Verify the script is executable: `chmod +x .git/hooks/pre-commit`
-- Verify the symlink points to the correct location: `ls -la .git/hooks/pre-commit`
-- Ensure `clang-format-21` and `cmake-format` are in your `$PATH`: `which clang-format-21 cmake-format`
-
-### Formatting succeeds locally but hook still rejects?
-
-This is typically due to:
-- Different `clang-format-21` versions installed (ensure you have version 21)
-- Nested `.clang-format` configuration files in subdirectories that override the root config
-
-### Path issues on HPC systems?
-
-If you're on a shared HPC system where multiple compiler modules are available:
-- Load the correct module before working: `module load llvm/21` or similar
-- Create a symlink to `clang-format` in `~/.local/bin` if module loading is inconvenient
-
-## 8. Configuration Files
-
-The formatting behavior is controlled by:
-
-- **C/C++ formatting**: `.clang-format` (repository root and subdirectories)
-- **CMake formatting**: `.cmake-format.py` (repository root)
-
-These files define all style rules. For detailed customization, refer to:
-- [clang-format documentation](https://clang.llvm.org/docs/ClangFormatStyleOptions.html)
-- [cmake-format documentation](https://cmake-format.readthedocs.io/)
-
-## Questions?
-
-Refer to the main [WORKFLOW.md](../WORKFLOW.md) guide for additional context on IPPL's development practices.
diff --git a/doc/extras/IPPLonEULER.md b/doc/extras/IPPLonEULER.md
deleted file mode 100644
index 36a243e9f..000000000
--- a/doc/extras/IPPLonEULER.md
+++ /dev/null
@@ -1,84 +0,0 @@
-# Installing IPPL on EULER {#Installation}
-
-This guide outlines the steps to install the IPPL library on the EULER cluster. Before beginning, ensure you are connected to the ETH-VPN to access the cluster.
-
-## Connecting to the EULER Cluster
-
-Use SSH to connect to EULER. Replace '\<username\>' with your actual username.
-
-        ssh -Y <username>@euler.ethz.ch
-
-The '-Y' flag enables trusted X11 forwarding, necessary for running graphical applications remotely.
-
-## Preparing the Environment
-
-_Load the New Software Stack:_ Transition to the new software stack to access the latest dependencies:
-
-        env2lmod
-
-_Clean the Environment:_ Ensure no previous modules are loaded to avoid conflicts:
-
-        module purge
-
-_Load Dependencies:_ Load the required modules for IPPL:
-
-        module load gcc/11.4.0 cmake/3.26.3 cuda/12.1.1 openmpi/4.1.4
-
-## Cloning the IPPL Library
-
-Clone the IPPL library from its repository:
-
-        git clone https://github.com/IPPL-framework/ippl.git
-
-## Building IPPL
-
-#### Setup a build directory:
-
-        cd ippl
-        mkdir build
-        cd build
-
-#### Create build files
-
-Choose from the following options based on your needs. If necessary, you can build multiple versions in separate directories.
-
-**Serial Version** (for single-node computing)
-
-        cmake .. -DCMAKE_CXX_STANDARD=20 -DIPPL_PLATFORMS=SERIAL -DIPPL_ENABLE_SOLVERS=ON -DIPPL_ENABLE_FFT=ON -DIPPL_ENABLE_ALPINE=ON
-
-**OpenMP Version** (for multi-threaded computing):
-
-        cmake .. -DCMAKE_CXX_STANDARD=20 -DIPPL_PLATFORMS=OPENMP -DIPPL_ENABLE_SOLVERS=ON -DIPPL_ENABLE_FFT=ON -DIPPL_ENABLE_ALPINE=ON
-
-**Cuda Version** (for GPU computing):
-
-        cmake .. -DCMAKE_CXX_STANDARD=20 -DIPPL_PLATFORMS=CUDA -DIPPL_ENABLE_SOLVERS=ON -DIPPL_ENABLE_FFT=ON -DIPPL_ENABLE_ALPINE=ON -DIPPL_USE_ALTERNATIVE_VARIANT=OFF -DKokkos_ARCH_[architecture]=ON
-
-[architecture] should be the target architecture, e.g.
-
-- PASCAL60
-- VOLTA70
-- TURING75
-- AMPERE80
-
-
-#### Compile
-
-        make
-
-## Testing Your Installation
-
-Launch an interactive job on EULER to test your installation:
-
-        srun -n 1 --time=1:00:00 --mem-per-cpu=32g --pty bash
-
-This command allocates one computing node with 32GB of RAM for 60 minutes.
-
-**Task** : Execute a miniapp in the '/alpine' folder to verify the installation (don't forget to compile with Make).
-
-
-## Links
-
-Repository for Independent Parallel Particle Layer (IPPL)
-
-        https://github.com/IPPL-framework/ippl
diff --git a/doc/extras/MainPage.md b/doc/extras/MainPage.md
deleted file mode 100644
index c26f4d6b2..000000000
--- a/doc/extras/MainPage.md
+++ /dev/null
@@ -1,14 +0,0 @@
-# Independent Parallel Particle Layer (IPPL)
-Independent Parallel Particle Layer (IPPL) is a performance portable C++ library for Particle-Mesh methods. IPPL makes use of Kokkos (https://github.com/kokkos/kokkos), HeFFTe (https://github.com/icl-utk-edu/heffte), and MPI (Message Passing Interface) to deliver a portable, massively parallel toolkit for particle-mesh methods. IPPL supports simulations in one to six dimensions, mixed precision, and asynchronous execution in different execution spaces (e.g. CPUs and GPUs). 
-
-All IPPL releases (< 3.2.0) are available under the BSD 3-clause license. Since version 3.2.0, this repository includes a modified version of the `variant` header by GNU, created to support compilation under CUDA 12.2 with GCC 12.3.0. This header file is available under the same terms as the [GNU Standard Library](https://github.com/gcc-mirror/gcc); note the GNU runtime library exception. As long as this file is not removed, IPPL is available under GNU GPL version 3.
-
-
-# Goals of Independent Parallel Particle Layer (IPPL)
-- Open source modern C++ (requires at least C++ 20) library for grid and particle-based methods
-- Performance Portability across heterogeneous parallel architectures (different CPUs, GPUs etc.)
-- Development of reusable, cross-domain components to enable rapid application development
-- Prototyping library for the development of novel numerical methods targeting exascale architectures
-- Shorter time from problem inception to working parallel simulations
-- Primary application is particle-in-cell methods (backend of production particle accelerator code OPAL) but applicable for other use cases too
-
diff --git a/doc/extras/Profiling.md b/doc/extras/Profiling.md
deleted file mode 100644
index 3ab7c3006..000000000
--- a/doc/extras/Profiling.md
+++ /dev/null
@@ -1,220 +0,0 @@
-# Profiling in IPPL {#Profiling}
-
-In certain applications, you might want to use profiling tools for debugging and testing. Since IPPL uses **Kokkos** as a backend, you can leverage Kokkos' built-in profiling tools.
-
-This guide explains how to use Kokkos' profiling tools, using the **MemoryEvents** tool as an example.
-
-### Description of MemoryEvents
-
-MemoryEvents tracks a timeline of allocation and deallocation events in Kokkos Memory Spaces. It records time, pointer, size, memory-space-name, and allocation-name. This is in particular useful for debugging purposes to understand where all the memory is going.
-
-Additionally, the tool provides a timeline of memory usage for each individual Kokkos Memory Space.
-
-The tool is located at: https://github.com/kokkos/kokkos-tools/tree/develop/profiling/memory-events
-
-
----
-
-## Steps to Use Kokkos Profiling Tools
-
-### 1. Clone the Kokkos Tools Repository
-
-First, clone the Kokkos tools repository, which contains a variety of profiling tools:
-```
-git clone https://github.com/kokkos/kokkos-tools
-```
-
-### 2. Build and Install the Tools
-
-Navigate into the repository and build the tools using CMake:
-
-```
-cd kokkos-tools
-cmake ..
-make -j
-sudo make install
-```
-
-### 3. Set Up the Profiling Tool
-
-Before running your application, export the Kokkos Tools environment variable to point to the `kp_memory_events.so` tool:
-```
-export KOKKOS_TOOLS_LIBS={PATH_TO_TOOL_DIRECTORY}/kp_memory_events.so 
-```
-Replace `{PATH_TO_TOOL_DIRECTORY}` with the actual path where the tool is located.
-
-
-### 4. Run your Application
-
-Execute your application normally. The MemoryEvents tool will automatically collect data during execution. For example:
-
-```
-./application COMMANDS
-```
-
-### 5. Output Files
-
-The MemoryEvents tool will generate the following files:
-
-- `HOSTNAME-PROCESSID.mem_events:` Lists memory events.
-- `HOSTNAME-PROCESSID-MEMSPACE.memspace_usage:` Provides a utilization timeline for each active memory space.
-
-### 6. Example on with SLURM
-
-Here’s an example of how to run the profiling with a SLURM system using `sbatch`:
-```
-sbatch -n 2 --wrap="export KOKKOS_TOOLS_LIBS=$HOME/kokkos-tools/kp_memory_events.so; \
-mpirun -n 2 LandauDamping 128 128 128 10000 10 FFT 0.01 LeapFrog --overallocate 2.0 --info 10"
-```
-
-In this example:
-
-- `sbatch -n 2` specifies 2 nodes.
-- The Kokkos tool is exported and applied to the `LandauDamping` application.
-
-This guide provides the basic steps for integrating Kokkos profiling tools into your IPPL-based projects. You can adjust the commands as needed depending on your specific application and environment.
-
-## Example 
-
-Consider the following code:
-
-```
-#include <Kokkos_Core.hpp>
-
-  typedef Kokkos::View<int*,Kokkos::CudaSpace> a_type;
-  typedef Kokkos::View<int*,Kokkos::CudaUVMSpace> b_type;
-  typedef Kokkos::View<int*,Kokkos::CudaHostPinnedSpace> c_type;
-
-int main() {
-  Kokkos::initialize();
-  {
-    int N = 10000000;
-    for(int i =0; i<2; i++) { 
-      a_type a("A",N);
-      {
-        b_type b("B",N);
-        c_type c("C",N);
-        for(int j =0; j<N; j++) {
-          b(j)=2*j;
-          c(j)=3*j;
-        }
-      }
-    }
-  }
-  Kokkos::finalize();
-
-}
-```
-
-This will produce the following output:
-
-**HOSTNAME-PROCESSID.mem_events**
-
-```
-# Memory Events
-# Time     Ptr                  Size        MemSpace      Op         Name
-0.311749      0x2048a0080            128   CudaHostPinned Allocate   InternalScratchUnified
-0.311913     0x2305ca0080           2048             Cuda Allocate   InternalScratchFlags
-0.312108     0x2305da0080          16384             Cuda Allocate   InternalScratchSpace
-0.312667     0x23060a0080       40000000             Cuda Allocate   A
-0.317260     0x23086e0080       40000000          CudaUVM Allocate   B
-0.335289      0x2049a0080       40000000   CudaHostPinned Allocate   C
-0.368485      0x2049a0080      -40000000   CudaHostPinned DeAllocate C
-0.377285     0x23086e0080      -40000000          CudaUVM DeAllocate B
-0.379795     0x23060a0080      -40000000             Cuda DeAllocate A
-0.380185     0x23060a0080       40000000             Cuda Allocate   A
-0.384785     0x23086e0080       40000000          CudaUVM Allocate   B
-0.400073      0x2049a0080       40000000   CudaHostPinned Allocate   C
-0.433218      0x2049a0080      -40000000   CudaHostPinned DeAllocate C
-0.441988     0x23086e0080      -40000000          CudaUVM DeAllocate B
-0.444391     0x23060a0080      -40000000             Cuda DeAllocate A
-```
-**HOSTNAME-PROCESSID-Cuda.memspace_usage**
-
-```
-# Space Cuda
-# Time(s)  Size(MB)   HighWater(MB)   HighWater-Process(MB)
-0.311913 0.0 0.0 81.8
-0.312108 0.0 0.0 81.8
-0.312667 38.2 38.2 81.8
-0.379795 0.0 38.2 158.1
-0.380185 38.2 38.2 158.1
-0.444391 0.0 38.2 158.1
-``` 
-**HOSTNAME-PROCESSID-CudaUVM.memspace_usage**
-
-```
-# Space CudaUVM
-# Time(s)  Size(MB)   HighWater(MB)   HighWater-Process(MB)
-0.317260 38.1 38.1 81.8
-0.377285 0.0 38.1 158.1
-0.384785 38.1 38.1 158.1
-0.441988 0.0 38.1 158.1
-```
-
-**HOSTNAME-PROCESSID-CudaHostPinned.memspace_usage**
-
-```
-# Space CudaHostPinned
-# Time(s)  Size(MB)   HighWater(MB)   HighWater-Process(MB)
-0.311749 0.0 0.0 81.8
-0.335289 38.1 38.1 120.0
-0.368485 0.0 38.1 158.1
-0.400073 38.1 38.1 158.1
-0.433218 0.0 38.1 158.1
-```
-
-## mpiP.py
-
-import os
-import sys
-import re
-
-def sum_send_bytes_from_file(file_path):
-    total_bytes_sent = 0.0
-    pattern = re.compile(
-        r'^\s*Send\s+\d+\s+(\d+)\s+\d+\s+[\d.eE+-]+\s+[\d.eE+-]+\s+[\d.eE+-]+\s+([\d.eE+-]+)\s*$'
-    )
-    with open(file_path, 'r') as f:
-        for line in f:
-            match = pattern.match(line)
-            if match:
-                rank, sum_bytes = match.groups()
-                if rank.isdigit():
-                    total_bytes_sent += float(sum_bytes)
-    return total_bytes_sent
-
-if __name__ == '__main__':
-    folder_path = sys.argv[1]
-    if os.path.exists(folder_path):
-        # Look for any file in the folder ending with .mpiP
-        for filename in os.listdir(folder_path):
-            if filename.endswith('.mpiP'):
-                file_path = os.path.join(folder_path, filename)
-                try:
-                    total_bytes = sum_send_bytes_from_file(file_path)
-                except Exception as e:
-                    print(f"Error processing {file_path}: {e}")
-                break  # Only one histogram file per run assumed
-        print(f"Total bytes = ", total_bytes)
-    else:
-        print(f"Path given does not exist!")
-
-
----
-
-## Debugging apps with gdb
-
-### LandauDamping
-Some applications (LandauDamping currently) accept a command line option `--debug`, this causes them to pause on startup and allows you to attach a debugger and then resume (by pressing <enter>). This is useful when debugging N mpi ranks and you want to attach gdb to one or more of them, but can't launch using gdb directly. 
-
-Usually one would attach gdb using a launch command such as this (on a remote machine supporting xterm over X11 for example, to open N xterm windows with gdb attached to one rank in each) 
-```
-srun -N 1 -n 2 wrapper-script.sh xterm -fn 10x20 -e gdb 
-  -ex='set confirm on' \
-  -ex=record \
-  -ex=run \
-  -ex="set pagination off" \
-  --args my/path/to/executable
-```
-The extra `-ex` parameters tell gdb to launch the application and start executing and not wait for additional prompting. 
diff --git a/doc/images/hello_world.png b/doc/images/hello_world.png
deleted file mode 100644
index b7b82c5ae..000000000
Binary files a/doc/images/hello_world.png and /dev/null differ
diff --git a/doc/images/ippl_structure.jpg b/doc/images/ippl_structure.jpg
deleted file mode 100644
index f773cb7c7..000000000
Binary files a/doc/images/ippl_structure.jpg and /dev/null differ
diff --git a/doc/Doxyfile b/doxygen/Doxyfile
similarity index 99%
rename from doc/Doxyfile
rename to doxygen/Doxyfile
index 614f32622..7872d0515 100644
--- a/doc/Doxyfile
+++ b/doxygen/Doxyfile
@@ -771,7 +771,7 @@ WARN_LOGFILE           =
 # spaces. See also FILE_PATTERNS and EXTENSION_MAPPING
 # Note: If this tag is empty the current directory is searched.
 
-INPUT                  = ../src/ ../alpine/ ../README.md examples  extras
+INPUT                  = ../README.md ../src/  # ../demos/
 
 # This tag can be used to specify the character encoding of the source files
 # that doxygen parses. Internally doxygen uses the UTF-8 encoding. Doxygen uses
@@ -844,7 +844,7 @@ EXCLUDE_SYMBOLS        =
 # that contain example code fragments that are included (see the \include
 # command).
 
-EXAMPLE_PATH           = ../alpine/ ../examples/ #mainpage.md
+EXAMPLE_PATH           = # ../demos
 
 # If the value of the EXAMPLE_PATH tag contains directories, you can use the
 # EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp and
@@ -864,7 +864,7 @@ EXAMPLE_RECURSIVE      = YES
 # that contain images that are to be included in the documentation (see the
 # \image command).
 
-IMAGE_PATH             = images
+IMAGE_PATH             = # images
 
 # The INPUT_FILTER tag can be used to specify a program that doxygen should
 # invoke to filter for each input file. Doxygen will invoke the filter program
diff --git a/doc/DoxygenLayout.xml b/doxygen/DoxygenLayout.xml
similarity index 97%
rename from doc/DoxygenLayout.xml
rename to doxygen/DoxygenLayout.xml
index bc72f6dec..c87d37cfb 100644
--- a/doc/DoxygenLayout.xml
+++ b/doxygen/DoxygenLayout.xml
@@ -4,9 +4,6 @@
   <!-- Navigation index tabs for HTML output -->
   <navindex>
     <tab type="mainpage" visible="yes" title=""/>
-    <tab type="user" visible="yes" title="Basics Usage" url="@ref Basics" intro=""/>
-    <tab type="user" visible="yes" title="Installation" url="@ref Installation" intro=""/>
-    <tab type="user" visible="yes" title="Profiling" url="@ref Profiling" intro=""/>
 
     <tab type="pages" visible="no" title="" intro=""/>
     <tab type="topics" visible="yes" title="" intro=""/>
diff --git a/doc/Makefile b/doxygen/Makefile
similarity index 100%
rename from doc/Makefile
rename to doxygen/Makefile
diff --git a/manual/dingbat.sty b/manual/dingbat.sty
deleted file mode 100644
index 9ac9f494c..000000000
--- a/manual/dingbat.sty
+++ /dev/null
@@ -1,50 +0,0 @@
-%%
-%% This is file `dingbat.sty',
-%% generated with the docstrip utility.
-%%
-%% The original source files were:
-%%
-%% dingbat.dtx  (with options: `package')
-%% 
-%% This is a generated file.
-%% 
-%% Copyright (C) 2001 Scott Pakin <pakin@uiuc.edu>
-%% -------------------------------------------------------
-%% 
-%% This package may be distributed and/or modified under the
-%% conditions of the LaTeX Project Public License, either version 1.2
-%% of this license or (at your option) any later version.
-%% The latest version of this license is in
-%%    http://www.latex-project.org/lppl.txt
-%% and version 1.2 or later is part of all distributions of LaTeX
-%% version 1999/12/01 or later.
-%% 
-%% File: dingbat.dtx Copyright (C) 2001 Scott Pakin <pakin@uiuc.edu>
-\NeedsTeXFormat{LaTeX2e}
-\ProvidesPackage{dingbat}
-         [2001/04/27 v1.00 Hands and other dingbats]
-\newcommand{\arkfamily}{\fontencoding{U}\fontfamily{ark}\selectfont}
-\newcommand{\ark@sym}[1]{{\arkfamily\symbol{#1}}}
-\newcommand{\carriagereturn}{\ark@sym{'103}}
-\newcommand{\leftthumbsdown}{\ark@sym{'104}}
-\newcommand{\eye}{\ark@sym{'105}}
-\newcommand{\rightpointleft}{\ark@sym{'114}}
-\newcommand{\smallpencil}{\ark@sym{'120}}
-\newcommand{\leftpointright}{\ark@sym{'122}}
-\newcommand{\leftthumbsup}{\ark@sym{'125}}
-\newcommand{\largepencil}{\ark@sym{'127}}
-\newcommand{\rightthumbsdown}{\ark@sym{'144}}
-\newcommand{\rightthumbsup}{\ark@sym{'165}}
-\newcommand{\dingbatfamily}{\fontencoding{U}\fontfamily{dingbat}\selectfont}
-\newcommand{\dingbat@sym}[1]{{\dingbatfamily\symbol{#1}}}
-\newcommand{\checkmark}{\dingbat@sym{'104}}
-\newcommand{\satellitedish}{\dingbat@sym{'111}}
-\newcommand{\rightpointright}{\dingbat@sym{'116}}
-\newcommand{\anchor}{\dingbat@sym{'117}}
-\newcommand{\squarewithdots}{\dingbat@sym{'102}}
-\newcommand{\filledsquarewithdots}{\dingbat@sym{'103}}
-\newcommand{\Sborder}{\dingbat@sym{'123}}
-\newcommand{\Zborder}{\dingbat@sym{'132}}
-\endinput
-%%
-%% End of file `dingbat.sty'.
diff --git a/manual/figures/psi_logo_wide.eps b/manual/figures/psi_logo_wide.eps
deleted file mode 100644
index 07df5b878..000000000
--- a/manual/figures/psi_logo_wide.eps
+++ /dev/null
@@ -1,1266 +0,0 @@
-%!PS-Adobe-3.0 EPSF-3.0
-%%BoundingBox: 40 612 511 642 
-%%Creator: CorelDRAW 7
-%%Title: 
-%%CreationDate: Thu Sep 14 10:45:34 2000
-%%DocumentProcessColors: Black 
-%%DocumentSuppliedResources: (atend)
-%%EndComments
-%%BeginProlog
-/AutoFlatness true def
-/AutoSteps 0 def
-/CMYKMarks false def
-/UseLevel2 false def
-%Color profile: _DEFAULT.CCM - Generic Profile
-%%BeginResource: procset wCorel7Dict 7.0 0
-/wCorel7Dict 300 dict def wCorel7Dict begin
-% Copyright (c)1992-96 Corel Corporation
-% All rights reserved.     v7.0 r1.0
-/bd{bind def}bind def/ld{load def}bd/xd{exch def}bd/_ null def/rp{{pop}repeat}
-bd/@cp/closepath ld/@gs/gsave ld/@gr/grestore ld/@np/newpath ld/Tl/translate ld
-/$sv 0 def/@sv{/$sv save def}bd/@rs{$sv restore}bd/spg/showpage ld/showpage{}
-bd currentscreen/@dsp xd/$dsp/@dsp def/$dsa xd/$dsf xd/$sdf false def/$SDF
-false def/$Scra 0 def/SetScr/setscreen ld/setscreen{pop pop pop}bd/@ss{2 index
-0 eq{$dsf 3 1 roll 4 -1 roll pop}if exch $Scra add exch load SetScr}bd
-/SepMode_5 where{pop}{/SepMode_5 0 def}ifelse/CurrentInkName_5 where{pop}
-{/CurrentInkName_5(Composite)def}ifelse/$ink_5 where{pop}{/$ink_5 -1 def}
-ifelse/$c 0 def/$m 0 def/$y 0 def/$k 0 def/$t 1 def/$n _ def/$o 0 def/$fil 0
-def/$C 0 def/$M 0 def/$Y 0 def/$K 0 def/$T 1 def/$N _ def/$O 0 def/$PF false
-def/s1c 0 def/s1m 0 def/s1y 0 def/s1k 0 def/s1t 0 def/s1n _ def/$bkg false def
-/SK 0 def/SM 0 def/SY 0 def/SC 0 def/$op false def matrix currentmatrix/$ctm xd
-/$ptm matrix def/$ttm matrix def/$stm matrix def/$ffpnt true def
-/CorelDrawReencodeVect[16#0/grave 16#5/breve 16#6/dotaccent 16#8/ring
-16#A/hungarumlaut 16#B/ogonek 16#C/caron 16#D/dotlessi 16#27/quotesingle
-16#60/grave 16#7C/bar
-16#82/quotesinglbase/florin/quotedblbase/ellipsis/dagger/daggerdbl
-16#88/circumflex/perthousand/Scaron/guilsinglleft/OE
-16#91/quoteleft/quoteright/quotedblleft/quotedblright/bullet/endash/emdash
-16#98/tilde/trademark/scaron/guilsinglright/oe 16#9F/Ydieresis
-16#A1/exclamdown/cent/sterling/currency/yen/brokenbar/section
-16#a8/dieresis/copyright/ordfeminine/guillemotleft/logicalnot/minus/registered/macron
-16#b0/degree/plusminus/twosuperior/threesuperior/acute/mu/paragraph/periodcentered
-16#b8/cedilla/onesuperior/ordmasculine/guillemotright/onequarter/onehalf/threequarters/questiondown
-16#c0/Agrave/Aacute/Acircumflex/Atilde/Adieresis/Aring/AE/Ccedilla
-16#c8/Egrave/Eacute/Ecircumflex/Edieresis/Igrave/Iacute/Icircumflex/Idieresis
-16#d0/Eth/Ntilde/Ograve/Oacute/Ocircumflex/Otilde/Odieresis/multiply
-16#d8/Oslash/Ugrave/Uacute/Ucircumflex/Udieresis/Yacute/Thorn/germandbls
-16#e0/agrave/aacute/acircumflex/atilde/adieresis/aring/ae/ccedilla
-16#e8/egrave/eacute/ecircumflex/edieresis/igrave/iacute/icircumflex/idieresis
-16#f0/eth/ntilde/ograve/oacute/ocircumflex/otilde/odieresis/divide
-16#f8/oslash/ugrave/uacute/ucircumflex/udieresis/yacute/thorn/ydieresis]def
-/L2?/languagelevel where{pop languagelevel 2 ge}{false}ifelse def
-/@BeginSysCorelDict{systemdict/Corel30Dict known{systemdict/Corel30Dict get
-exec}if}bd/@EndSysCorelDict{systemdict/Corel30Dict known{end}if}bd AutoFlatness
-{/@ifl{dup currentflat exch sub 10 gt{
-([Error: PathTooComplex; OffendingCommand: AnyPaintingOperator]\n)print flush
-@np exit}{currentflat 2 add setflat}ifelse}bd/@fill/fill ld/fill{currentflat{
-{@fill}stopped{@ifl}{exit}ifelse}bind loop setflat}bd/@eofill/eofill ld/eofill
-{currentflat{{@eofill}stopped{@ifl}{exit}ifelse}bind loop setflat}bd/@clip
-/clip ld/clip{currentflat{{@clip}stopped{@ifl}{exit}ifelse}bind loop setflat}
-bd/@eoclip/eoclip ld/eoclip{currentflat{{@eoclip}stopped{@ifl}{exit}ifelse}
-bind loop setflat}bd/@stroke/stroke ld/stroke{currentflat{{@stroke}stopped
-{@ifl}{exit}ifelse}bind loop setflat}bd}if L2?{/@ssa{true setstrokeadjust}bd}{
-/@ssa{}bd}ifelse/d/setdash ld/j/setlinejoin ld/J/setlinecap ld/M/setmiterlimit
-ld/w/setlinewidth ld/O{/$o xd}bd/R{/$O xd}bd/W/eoclip ld/c/curveto ld/C/c ld/l
-/lineto ld/L/l ld/rl/rlineto ld/m/moveto ld/n/newpath ld/N/newpath ld/P{11 rp}
-bd/u{}bd/U{}bd/A{pop}bd/q/@gs ld/Q/@gr ld/&{}bd/@j{@sv @np}bd/@J{@rs}bd/g{1
-exch sub/$k xd/$c 0 def/$m 0 def/$y 0 def/$t 1 def/$n _ def/$fil 0 def}bd/G{1
-sub neg/$K xd _ 1 0 0 0/$C xd/$M xd/$Y xd/$T xd/$N xd}bd/k{1 index type
-/stringtype eq{/$t xd/$n xd}{/$t 0 def/$n _ def}ifelse/$k xd/$y xd/$m xd/$c xd
-/$fil 0 def}bd/K{1 index type/stringtype eq{/$T xd/$N xd}{/$T 0 def/$N _ def}
-ifelse/$K xd/$Y xd/$M xd/$C xd}bd/x/k ld/X/K ld/sf{1 index type/stringtype eq{
-/s1t xd/s1n xd}{/s1t 0 def/s1n _ def}ifelse/s1k xd/s1y xd/s1m xd/s1c xd}bd/i{
-dup 0 ne{setflat}{pop}ifelse}bd/v{4 -2 roll 2 copy 6 -2 roll c}bd/V/v ld/y{2
-copy c}bd/Y/y ld/@w{matrix rotate/$ptm xd matrix scale $ptm dup concatmatrix
-/$ptm xd 1 eq{$ptm exch dup concatmatrix/$ptm xd}if 1 w}bd/@g{1 eq dup/$sdf xd
-{/$scp xd/$sca xd/$scf xd}if}bd/@G{1 eq dup/$SDF xd{/$SCP xd/$SCA xd/$SCF xd}
-if}bd/@D{2 index 0 eq{$dsf 3 1 roll 4 -1 roll pop}if 3 copy exch $Scra add exch
-load SetScr/$dsp xd/$dsa xd/$dsf xd}bd/$ngx{$SDF{$SCF SepMode_5 0 eq{$SCA}
-{$dsa}ifelse $SCP @ss}if}bd/p{/$pm xd 7 rp/$pyf xd/$pxf xd/$pn xd/$fil 1 def}
-bd/@MN{2 copy le{pop}{exch pop}ifelse}bd/@MX{2 copy ge{pop}{exch pop}ifelse}bd
-/InRange{3 -1 roll @MN @MX}bd/@sqr{dup 0 rl dup 0 exch rl neg 0 rl @cp}bd
-/currentscale{1 0 dtransform matrix defaultmatrix idtransform dup mul exch dup
-mul add sqrt 0 1 dtransform matrix defaultmatrix idtransform dup mul exch dup
-mul add sqrt}bd/@unscale{}bd/wDstChck{2 1 roll dup 3 -1 roll eq{1 add}if}bd
-/@dot{dup mul exch dup mul add 1 exch sub}bd/@lin{exch pop abs 1 exch sub}bd
-/cmyk2rgb{3{dup 5 -1 roll add 1 exch sub dup 0 lt{pop 0}if exch}repeat pop}bd
-/rgb2cmyk{3{1 exch sub 3 1 roll}repeat 3 copy @MN @MN 3{dup 5 -1 roll sub neg
-exch}repeat}bd/rgb2g{2 index .299 mul 2 index .587 mul add 1 index .114 mul add
-4 1 roll pop pop pop}bd/WaldoColor_5 where{pop}{/SetRgb/setrgbcolor ld/GetRgb
-/currentrgbcolor ld/SetGry/setgray ld/GetGry/currentgray ld/SetRgb2 systemdict
-/setrgbcolor get def/GetRgb2 systemdict/currentrgbcolor get def/SetHsb
-systemdict/sethsbcolor get def/GetHsb systemdict/currenthsbcolor get def
-/rgb2hsb{SetRgb2 GetHsb}bd/hsb2rgb{3 -1 roll dup floor sub 3 1 roll SetHsb
-GetRgb2}bd/setcmykcolor where{pop/SetCmyk_5/setcmykcolor ld}{/SetCmyk_5{
-cmyk2rgb SetRgb}bd}ifelse/currentcmykcolor where{pop/GetCmyk/currentcmykcolor
-ld}{/GetCmyk{GetRgb rgb2cmyk}bd}ifelse/setoverprint where{pop}{/setoverprint{
-/$op xd}bd}ifelse/currentoverprint where{pop}{/currentoverprint{$op}bd}ifelse
-/@tc_5{5 -1 roll dup 1 ge{pop}{4{dup 6 -1 roll mul exch}repeat pop}ifelse}bd
-/@trp{exch pop 5 1 roll @tc_5}bd/setprocesscolor_5{SepMode_5 0 eq{SetCmyk_5}{0
-4 $ink_5 sub index exch pop 5 1 roll pop pop pop pop SepsColor true eq{$ink_5 3
-gt{1 sub neg SetGry}{0 0 0 4 $ink_5 roll SetCmyk_5}ifelse}{1 sub neg SetGry}
-ifelse}ifelse}bd/findcmykcustomcolor where{pop}{/findcmykcustomcolor{5 array
-astore}bd}ifelse/setcustomcolor where{pop}{/setcustomcolor{exch aload pop
-SepMode_5 0 eq{pop @tc_5 setprocesscolor_5}{CurrentInkName_5 eq{4 index}{0}
-ifelse 6 1 roll 5 rp 1 sub neg SetGry}ifelse}bd}ifelse/@scc_5{dup type
-/booleantype eq{setoverprint}{1 eq setoverprint}ifelse dup _ eq{pop
-setprocesscolor_5 pop}{findcmykcustomcolor exch setcustomcolor}ifelse SepMode_5
-0 eq{true}{GetGry 1 eq currentoverprint and not}ifelse}bd/colorimage where{pop
-/ColorImage{colorimage}def}{/ColorImage{/ncolors xd pop/dataaq xd{dataaq
-ncolors dup 3 eq{/$dat xd 0 1 $dat length 3 div 1 sub{dup 3 mul $dat 1 index
-get 255 div $dat 2 index 1 add get 255 div $dat 3 index 2 add get 255 div rgb2g
-255 mul cvi exch pop $dat 3 1 roll put}for $dat 0 $dat length 3 idiv
-getinterval pop}{4 eq{/$dat xd 0 1 $dat length 4 div 1 sub{dup 4 mul $dat 1
-index get 255 div $dat 2 index 1 add get 255 div $dat 3 index 2 add get 255 div
-$dat 4 index 3 add get 255 div cmyk2rgb rgb2g 255 mul cvi exch pop $dat 3 1
-roll put}for $dat 0 $dat length ncolors idiv getinterval}if}ifelse}image}bd
-}ifelse/setcmykcolor{1 5 1 roll _ currentoverprint @scc_5/$ffpnt xd}bd
-/currentcmykcolor{0 0 0 0}bd/setrgbcolor{rgb2cmyk setcmykcolor}bd
-/currentrgbcolor{currentcmykcolor cmyk2rgb}bd/sethsbcolor{hsb2rgb setrgbcolor}
-bd/currenthsbcolor{currentrgbcolor rgb2hsb}bd/setgray{dup dup setrgbcolor}bd
-/currentgray{currentrgbcolor rgb2g}bd}ifelse/WaldoColor_5 true def/@sft{$tllx
-$pxf add dup $tllx gt{$pwid sub}if/$tx xd $tury $pyf sub dup $tury lt{$phei
-add}if/$ty xd}bd/@stb{pathbbox/$ury xd/$urx xd/$lly xd/$llx xd}bd/@ep{{cvx exec
-}forall}bd/@tp{@sv/$in true def 2 copy dup $lly le{/$in false def}if $phei sub
-$ury ge{/$in false def}if dup $urx ge{/$in false def}if $pwid add $llx le{/$in
-false def}if $in{@np 2 copy m $pwid 0 rl 0 $phei neg rl $pwid neg 0 rl 0 $phei
-rl clip @np $pn cvlit load aload pop 7 -1 roll 5 index sub 7 -1 roll 3 index
-sub Tl matrix currentmatrix/$ctm xd @ep pop pop pop pop}{pop pop}ifelse @rs}bd
-/@th{@sft 0 1 $tly 1 sub{dup $psx mul $tx add{dup $llx gt{$pwid sub}{exit}
-ifelse}loop exch $phei mul $ty exch sub 0 1 $tlx 1 sub{$pwid mul 3 copy 3 -1
-roll add exch @tp pop}for pop pop}for}bd/@tv{@sft 0 1 $tlx 1 sub{dup $pwid mul
-$tx add exch $psy mul $ty exch sub{dup $ury lt{$phei add}{exit}ifelse}loop 0 1
-$tly 1 sub{$phei mul 3 copy sub @tp pop}for pop pop}for}bd/$fm 0 def/wfill{1
-$fm eq{fill}{eofill}ifelse}bd/wclip{1 $fm eq{clip}{eoclip}ifelse}bd/@pf{@gs
-$ctm setmatrix $pm concat @stb wclip Bburx Bbury $pm itransform/$tury xd/$turx
-xd Bbllx Bblly $pm itransform/$tlly xd/$tllx xd/$wid $turx $tllx sub def/$hei
-$tury $tlly sub def @gs $vectpat{1 0 0 0 0 _ $o @scc_5{wfill}if}{$t $c $m $y $k
-$n $o @scc_5{SepMode_5 0 eq $pfrg or{$tllx $tlly Tl $wid $hei scale <00> 8 1
-false[8 0 0 1 0 0]{}imagemask}{/$bkg true def}ifelse}if}ifelse @gr $wid 0 gt
-$hei 0 gt and{$pn cvlit load aload pop/$pd xd 3 -1 roll sub/$phei xd exch sub
-/$pwid xd $wid $pwid div ceiling 1 add/$tlx xd $hei $phei div ceiling 1 add
-/$tly xd $psx 0 eq{@tv}{@th}ifelse}if @gr @np/$bkg false def}bd/@Pf{@sv
-SepMode_5 0 eq $Psc 0 ne or $ink_5 3 eq or{0 J 0 j[]0 d $t $c $m $y $k $n $o
-@scc_5 pop $ctm setmatrix 72 1000 div dup matrix scale dup concat dup Bburx
-exch Bbury exch itransform ceiling cvi/Bbury xd ceiling cvi/Bburx xd Bbllx exch
-Bblly exch itransform floor cvi/Bblly xd floor cvi/Bbllx xd $Prm aload pop $Psn
-load exec}{1 SetGry wfill}ifelse @rs @np}bd/F{matrix currentmatrix $sdf{$scf
-$sca $scp @ss}if $fil 1 eq{@pf}{$fil 2 eq{@ff}{$fil 3 eq{@Pf}{$t $c $m $y $k $n
-$o @scc_5{wfill}{@np}ifelse}ifelse}ifelse}ifelse $sdf{$dsf $dsa $dsp @ss}if
-setmatrix}bd/f{@cp F}bd/S{matrix currentmatrix $ctm setmatrix $SDF{$SCF $SCA
-$SCP @ss}if $T $C $M $Y $K $N $O @scc_5{matrix currentmatrix $ptm concat stroke
-setmatrix}{@np}ifelse $SDF{$dsf $dsa $dsp @ss}if setmatrix}bd/s{@cp S}bd/B{@gs
-F @gr S}bd/b{@cp B}bd/_E{5 array astore exch cvlit xd}bd/@cc{currentfile $dat
-readhexstring pop}bd/@sm{/$ctm $ctm currentmatrix def}bd/@E{/Bbury xd/Bburx xd
-/Bblly xd/Bbllx xd}bd/@c{@cp}bd/@p{/$fil 1 def 1 eq dup/$vectpat xd{/$pfrg true
-def}{@gs $t $c $m $y $k $n $o @scc_5/$pfrg xd @gr}ifelse/$pm xd/$psy xd/$psx xd
-/$pyf xd/$pxf xd/$pn xd}bd/@P{/$fil 3 def/$Psn xd/$Psc xd array astore/$Prm xd
-}bd/@ii{concat 3 index 3 index m 3 index 1 index l 2 copy l 1 index 3 index l 3
-index 3 index l clip pop pop pop pop}bd/tcc{@cc}def/@i{@sm @gs @ii 6 index 1 ne
-{/$frg true def pop pop}{1 eq{s1t s1c s1m s1y s1k s1n $O @scc_5/$frg xd}{/$frg
-false def}ifelse 1 eq{@gs $ctm setmatrix F @gr}if}ifelse @np/$ury xd/$urx xd
-/$lly xd/$llx xd/$bts xd/$hei xd/$wid xd/$dat $wid $bts mul 8 div ceiling cvi
-string def $bkg $frg or{$SDF{$SCF $SCA $SCP @ss}if $llx $lly Tl $urx $llx sub
-$ury $lly sub scale $bkg{$t $c $m $y $k $n $o @scc_5 pop}if $wid $hei abs $bts
-1 eq{$bkg}{$bts}ifelse[$wid 0 0 $hei neg 0 $hei 0 gt{$hei}{0}ifelse]/tcc load
-$bts 1 eq{imagemask}{image}ifelse $SDF{$dsf $dsa $dsp @ss}if}{$hei abs{tcc pop}
-repeat}ifelse @gr $ctm setmatrix}bd/@I{@sm @gs @ii @np/$ury xd/$urx xd/$lly xd
-/$llx xd/$ncl xd/$bts xd/$hei xd/$wid xd/$dat $wid $bts mul $ncl mul 8 div
-ceiling cvi string def $ngx $llx $lly Tl $urx $llx sub $ury $lly sub scale $wid
-$hei abs $bts[$wid 0 0 $hei neg 0 $hei 0 gt{$hei}{0}ifelse]/@cc load false $ncl
-ColorImage $SDF{$dsf $dsa $dsp @ss}if @gr $ctm setmatrix}bd/COMP 0 def L2?{
-/@I_2{@sm @gs @ii @np/$ury xd/$urx xd/$lly xd/$llx xd/$ncl xd/$bts xd/$hei xd
-/$wid xd/$dat $wid $bts mul $ncl mul 8 div ceiling cvi string def $ngx $ncl 1
-eq{/DeviceGray}{$ncl 3 eq{/DeviceRGB}{/DeviceCMYK}ifelse}ifelse setcolorspace
-$llx $lly Tl $urx $llx sub $ury $lly sub scale 8 dict begin/ImageType 1 def
-/Width $wid def/Height $hei abs def/BitsPerComponent $bts def/Decode $ncl 1 eq
-{[0 1]}{$ncl 3 eq{[0 1 0 1 0 1]}{[0 1 0 1 0 1 0 1]}ifelse}ifelse def
-/ImageMatrix[$wid 0 0 $hei neg 0 $hei 0 gt{$hei}{0}ifelse]def/DataSource
-currentfile/ASCII85Decode filter COMP 1 eq{/DCTDecode filter}{COMP 2 eq
-{/RunLengthDecode filter}if}ifelse def currentdict end image $SDF{$dsf $dsa
-$dsp @ss}if @gr $ctm setmatrix}bd}{/@I_2{}bd}ifelse/@B{@gs S @gr F}bd/@b{@cp @B
-}bd/@sep{CurrentInkName_5(Composite)eq{/$ink_5 -1 def}{CurrentInkName_5(Cyan)
-eq{/$ink_5 0 def}{CurrentInkName_5(Magenta)eq{/$ink_5 1 def}{CurrentInkName_5
-(Yellow)eq{/$ink_5 2 def}{CurrentInkName_5(Black)eq{/$ink_5 3 def}{/$ink_5 4
-def}ifelse}ifelse}ifelse}ifelse}ifelse}bd/@whi{@gs -72000 dup m -72000 72000 l
-72000 dup l 72000 -72000 l @cp 1 SetGry fill @gr}bd/@neg{[{1 exch sub}/exec cvx
-currenttransfer/exec cvx]cvx settransfer @whi}bd/deflevel 0 def/@sax{/deflevel
-deflevel 1 add def}bd/@eax{/deflevel deflevel dup 0 gt{1 sub}if def deflevel 0
-gt{/eax load}{eax}ifelse}bd/eax{{exec}forall}bd/@rax{deflevel 0 eq{@rs @sv}if}
-bd/@daq{dup type/arraytype eq{{}forall}if}bd/@BMP{/@cc xd 12 index 1 gt
-UseLevel2 true eq and{7 -2 roll pop pop @I_2}{11 index 1 eq{12 -1 roll pop @i}
-{7 -2 roll pop pop @I}ifelse}ifelse}bd systemdict/pdfmark known not{/pdfmark
-/cleartomark ld}if
-end
-%%EndResource
-%%EndProlog
-%%BeginSetup
-wCorel7Dict begin
-@BeginSysCorelDict
-2.6131 setmiterlimit
-1.00 setflat
-/$fst 128 def
-%%EndSetup
-
-%%Page: 1 1
-%LogicalPage: 1
-%%BeginPageSetup
-@sv
-@sm
-@sv
-%%EndPageSetup
-@rax %Note: Object
-41.13808 617.64888 157.41808 631.11288 @E
- 0 O 0 @g
-0.44 0.36 0.35 0.01 k
-/$fm 0 def
-67.41808 617.64888 m
-42.79408 617.64888 L
-42.14608 617.79288 L
-41.64208 618.08088 L
-41.28208 618.65688 L
-41.13808 619.23288 L
-41.13808 629.45688 L
-41.28208 630.10488 L
-41.64208 630.60888 L
-42.14608 630.96888 L
-42.79408 631.11288 L
-155.76208 631.11288 L
-156.41008 630.96888 L
-156.91408 630.60888 L
-157.27408 630.10488 L
-157.41808 629.45688 L
-157.41808 619.23288 L
-157.27408 618.65688 L
-156.91408 618.08088 L
-156.41008 617.79288 L
-155.76208 617.64888 L
-67.41808 617.64888 L
-@c
-F
-
-@rax %Note: Object
-67.41808 613.76088 92.76208 641.26488 @E
- 0 O 0 @g
-0.01 0.00 0.00 0.00 k
-/$fm 0 def
-76.41808 622.90488 m
-76.41808 616.64088 L
-76.34608 616.06488 L
-76.20208 615.48888 L
-75.91408 614.98488 L
-75.55408 614.62488 L
-75.19408 614.26488 L
-74.69008 613.97688 L
-74.11408 613.83288 L
-73.53808 613.76088 L
-70.29808 613.76088 L
-69.72208 613.83288 L
-69.21808 613.97688 L
-68.71408 614.26488 L
-68.28208 614.62488 L
-67.92208 614.98488 L
-67.70608 615.48888 L
-67.49008 616.06488 L
-67.41808 616.64088 L
-67.41808 638.45688 L
-67.49008 639.03288 L
-67.70608 639.53688 L
-67.92208 640.04088 L
-68.28208 640.47288 L
-68.71408 640.83288 L
-69.21808 641.04888 L
-69.72208 641.26488 L
-70.29808 641.26488 L
-89.88208 641.26488 L
-90.45808 641.26488 L
-90.96208 641.04888 L
-91.46608 640.83288 L
-91.89808 640.47288 L
-92.25808 640.04088 L
-92.54608 639.53688 L
-92.69008 639.03288 L
-92.76208 638.45688 L
-92.76208 625.78488 L
-92.69008 625.20888 L
-92.54608 624.70488 L
-92.25808 624.20088 L
-91.89808 623.76888 L
-91.46608 623.40888 L
-90.96208 623.19288 L
-90.45808 622.97688 L
-89.88208 622.90488 L
-76.41808 622.90488 L
-@c
-F
-
-@rax %Note: Object
-67.41808 613.76088 92.76208 641.26488 @E
-0 J 0 j [] 0 d 0 R 0 @G
-0.84 0.73 0.72 0.91 K
-[1.00000000 0.00000000 0.00000000 1.00000000 0.00000000 0.00000000] 1 1.42753 1.42753 0.00000 @w
-/$fm 0 def
-76.41808 622.90488 m
-76.41808 616.64088 L
-76.41808 615.05688 75.12208 613.76088 73.53808 613.76088 C
-70.29808 613.76088 L
-68.71408 613.76088 67.41808 615.05688 67.41808 616.64088 C
-67.41808 638.45688 L
-67.41808 640.04088 68.71408 641.26488 70.29808 641.26488 C
-89.88208 641.26488 L
-91.46608 641.26488 92.76208 640.04088 92.76208 638.45688 C
-92.76208 625.78488 L
-92.76208 624.20088 91.46608 622.90488 89.88208 622.90488 C
-76.41808 622.90488 L
-@c
-S
-
-@rax %Note: Object
-75.84208 632.12031 84.41008 632.12145 @E
-0 J 0 j [] 0 d 0 R 0 @G
-0.84 0.73 0.72 0.91 K
-[1.00000000 0.00000000 0.00000000 1.00000000 0.00000000 0.00000000] 1 1.42753 1.42753 0.00000 @w
-/$fm 0 def
-75.84208 632.12088 m
-84.41008 632.12088 L
-S
-
-@rax %Note: Object
-92.76208 613.76088 118.03408 641.26488 @E
- 0 O 0 @g
-0.01 0.00 0.00 0.00 k
-/$fm 0 def
-110.11408 622.90488 m
-95.57008 622.90488 L
-94.99408 622.97688 L
-94.49008 623.19288 L
-93.98608 623.40888 L
-93.55408 623.76888 L
-93.19408 624.20088 L
-92.97808 624.70488 L
-92.83408 625.20888 L
-92.76208 625.78488 L
-92.76208 638.45688 L
-92.83408 639.03288 L
-92.97808 639.53688 L
-93.19408 640.04088 L
-93.55408 640.47288 L
-93.98608 640.83288 L
-94.49008 641.04888 L
-94.99408 641.26488 L
-95.57008 641.26488 L
-115.15408 641.26488 L
-115.73008 641.26488 L
-116.30608 641.04888 L
-116.73808 640.83288 L
-117.17008 640.47288 L
-117.53008 640.04088 L
-117.81808 639.53688 L
-117.96208 639.03288 L
-118.03408 638.45688 L
-118.03408 635.00088 L
-117.96208 634.42488 L
-117.81808 633.84888 L
-117.53008 633.34488 L
-117.17008 632.98488 L
-116.73808 632.62488 L
-116.30608 632.33688 L
-115.73008 632.19288 L
-115.15408 632.12088 L
-100.68208 632.12088 L
-115.15408 632.12088 L
-115.73008 632.04888 L
-116.30608 631.90488 L
-116.73808 631.61688 L
-117.17008 631.25688 L
-117.53008 630.82488 L
-117.81808 630.39288 L
-117.96208 629.81688 L
-118.03408 629.24088 L
-118.03408 616.64088 L
-117.96208 616.06488 L
-117.81808 615.48888 L
-117.53008 614.98488 L
-117.17008 614.62488 L
-116.73808 614.26488 L
-116.30608 613.97688 L
-115.73008 613.83288 L
-115.15408 613.76088 L
-95.57008 613.76088 L
-94.99408 613.83288 L
-94.49008 613.97688 L
-93.98608 614.26488 L
-93.55408 614.62488 L
-93.19408 614.98488 L
-92.97808 615.48888 L
-92.83408 616.06488 L
-92.76208 616.64088 L
-92.76208 620.09688 L
-92.83408 620.67288 L
-92.97808 621.17688 L
-93.19408 621.68088 L
-93.55408 622.11288 L
-93.98608 622.47288 L
-94.49008 622.68888 L
-94.99408 622.90488 L
-95.57008 622.90488 L
-110.11408 622.90488 L
-@c
-F
-
-@rax %Note: Object
-92.76208 613.76088 118.03408 641.26488 @E
-0 J 0 j [] 0 d 0 R 0 @G
-0.84 0.73 0.72 0.91 K
-[1.00000000 0.00000000 0.00000000 1.00000000 0.00000000 0.00000000] 1 1.42753 1.42753 0.00000 @w
-/$fm 0 def
-110.11408 622.90488 m
-95.57008 622.90488 L
-93.98608 622.90488 92.76208 624.20088 92.76208 625.78488 C
-92.76208 638.45688 L
-92.76208 640.04088 93.98608 641.26488 95.57008 641.26488 C
-115.15408 641.26488 L
-116.73808 641.26488 118.03408 640.04088 118.03408 638.45688 C
-118.03408 635.00088 L
-118.03408 633.41688 116.73808 632.12088 115.15408 632.12088 C
-100.68208 632.12088 L
-115.15408 632.12088 L
-116.73808 632.12088 118.03408 630.82488 118.03408 629.24088 C
-118.03408 616.64088 L
-118.03408 615.05688 116.73808 613.76088 115.15408 613.76088 C
-95.57008 613.76088 L
-93.98608 613.76088 92.76208 615.05688 92.76208 616.64088 C
-92.76208 620.09688 L
-92.76208 621.68088 93.98608 622.90488 95.57008 622.90488 C
-110.11408 622.90488 L
-@c
-S
-
-@rax %Note: Object
-117.02608 631.11288 118.03408 632.69688 @E
- 0 O 0 @g
-0.84 0.73 0.72 0.91 k
-/$fm 0 def
-117.02608 632.12088 m
-118.03408 632.69688 L
-118.03408 631.11288 L
-117.02608 632.12088 L
-@c
-F
-
-@rax %Note: Object
-118.03408 613.76088 131.06608 641.26488 @E
- 0 O 0 @g
-0.01 0.00 0.00 0.00 k
-/$fm 0 def
-118.03408 617.86488 m
-118.03408 638.45688 L
-118.10608 639.03288 L
-118.25008 639.53688 L
-118.53808 640.04088 L
-118.89808 640.47288 L
-119.25808 640.83288 L
-119.76208 641.04888 L
-120.33808 641.26488 L
-120.91408 641.26488 L
-128.25808 641.26488 L
-128.83408 641.26488 L
-129.33808 641.04888 L
-129.84208 640.83288 L
-130.27408 640.47288 L
-130.63408 640.04088 L
-130.85008 639.53688 L
-130.99408 639.03288 L
-131.06608 638.45688 L
-131.06608 616.64088 L
-130.99408 616.06488 L
-130.85008 615.48888 L
-130.63408 614.98488 L
-130.27408 614.62488 L
-129.84208 614.26488 L
-129.33808 613.97688 L
-128.83408 613.83288 L
-128.25808 613.76088 L
-120.91408 613.76088 L
-120.33808 613.83288 L
-119.76208 613.97688 L
-119.25808 614.26488 L
-118.89808 614.62488 L
-118.53808 614.98488 L
-118.25008 615.48888 L
-118.10608 616.06488 L
-118.03408 616.64088 L
-118.03408 617.86488 L
-@c
-F
-
-@rax %Note: Object
-118.03408 613.76088 131.06608 641.26488 @E
-0 J 0 j [] 0 d 0 R 0 @G
-0.84 0.73 0.72 0.91 K
-[1.00000000 0.00000000 0.00000000 1.00000000 0.00000000 0.00000000] 1 1.42753 1.42753 0.00000 @w
-/$fm 0 def
-118.03408 617.86488 m
-118.03408 638.45688 L
-118.03408 640.04088 119.33008 641.26488 120.91408 641.26488 C
-128.25808 641.26488 L
-129.84208 641.26488 131.06608 640.04088 131.06608 638.45688 C
-131.06608 616.64088 L
-131.06608 615.05688 129.84208 613.76088 128.25808 613.76088 C
-120.91408 613.76088 L
-119.33008 613.76088 118.03408 615.05688 118.03408 616.64088 C
-118.03408 617.86488 L
-@c
-S
-
-@rax %Note: Object
-199.39408 617.64888 207.31408 630.53688 @E
- 0 O 0 @g
-0.84 0.73 0.72 0.91 k
-/$fm 0 def
-199.39408 630.53688 m
-199.39408 617.64888 L
-200.83408 617.64888 L
-200.83408 623.12088 L
-204.43408 623.12088 L
-205.01008 623.19288 L
-205.58608 623.40888 L
-206.09008 623.69688 L
-206.52208 624.20088 L
-206.88208 624.70488 L
-207.09808 625.35288 L
-207.24208 626.07288 L
-207.31408 626.86488 L
-207.24208 627.65688 L
-207.09808 628.37688 L
-206.81008 628.95288 L
-206.52208 629.52888 L
-206.09008 629.96088 L
-205.58608 630.24888 L
-205.01008 630.46488 L
-204.43408 630.53688 L
-204.21808 630.53688 L
-199.39408 630.53688 L
-@c
-200.83408 624.56088 m
-200.83408 629.09688 L
-203.78608 629.02488 L
-204.65008 628.88088 L
-205.29808 628.52088 L
-205.73008 627.80088 L
-205.87408 626.86488 L
-205.73008 625.92888 L
-205.29808 625.20888 L
-204.72208 624.77688 L
-203.85808 624.63288 L
-200.83408 624.56088 L
-@c
-F
-
-@rax %Note: Object
-213.14608 617.64888 222.65008 630.53688 @E
- 0 O 0 @g
-0.84 0.73 0.72 0.91 k
-/$fm 0 def
-217.17808 630.53688 m
-213.14608 617.64888 L
-214.65808 617.64888 L
-215.81008 621.39288 L
-219.98608 621.39288 L
-221.06608 617.64888 L
-222.65008 617.64888 L
-218.83408 630.53688 L
-217.17808 630.53688 L
-@c
-217.89808 628.66488 m
-219.48208 622.97688 L
-216.24208 622.97688 L
-217.89808 628.66488 L
-@c
-F
-
-@rax %Note: Object
-228.98608 617.28888 237.33808 630.53688 @E
- 0 O 0 @g
-0.84 0.73 0.72 0.91 k
-/$fm 0 def
-228.98608 630.53688 m
-228.98608 621.75288 L
-229.13008 620.60088 L
-229.49008 619.52088 L
-230.13808 618.51288 L
-230.93008 617.86488 L
-231.86608 617.43288 L
-233.09008 617.28888 L
-234.02608 617.36088 L
-234.81808 617.64888 L
-235.61008 618.08088 L
-236.18608 618.65688 L
-236.69008 619.30488 L
-237.05008 620.09688 L
-237.26608 620.96088 L
-237.33808 621.82488 L
-237.33808 630.53688 L
-235.89808 630.53688 L
-235.89808 622.18488 L
-235.89808 622.04088 L
-235.82608 621.46488 L
-235.53808 620.38488 L
-234.96208 619.59288 L
-234.60208 619.23288 L
-234.17008 619.01688 L
-233.66608 618.87288 L
-233.16208 618.87288 L
-232.51408 618.87288 L
-232.01008 619.08888 L
-231.57808 619.37688 L
-231.14608 619.73688 L
-230.85808 620.24088 L
-230.64208 620.81688 L
-230.49808 621.53688 L
-230.42608 622.32888 L
-230.42608 630.53688 L
-228.98608 630.53688 L
-@c
-F
-
-@rax %Note: Object
-244.61008 617.64888 251.45008 630.53688 @E
- 0 O 0 @g
-0.84 0.73 0.72 0.91 k
-/$fm 0 def
-244.61008 630.53688 m
-244.61008 617.64888 L
-251.45008 617.64888 L
-251.45008 619.23288 L
-246.05008 619.23288 L
-246.05008 630.53688 L
-244.61008 630.53688 L
-@c
-F
-
-@rax %Note: Object
-272.40208 617.28888 280.82608 630.89688 @E
- 0 O 0 @g
-0.84 0.73 0.72 0.91 k
-/$fm 0 def
-280.53808 626.79288 m
-280.46608 627.72888 L
-280.25008 628.52088 L
-279.96208 629.24088 L
-279.45808 629.81688 L
-278.88208 630.32088 L
-278.23408 630.60888 L
-277.37008 630.82488 L
-276.50608 630.89688 L
-275.64208 630.82488 L
-274.92208 630.60888 L
-274.27408 630.32088 L
-273.77008 629.81688 L
-273.33808 629.24088 L
-273.05008 628.59288 L
-272.83408 627.80088 L
-272.76208 626.93688 L
-272.83408 626.21688 L
-272.97808 625.64088 L
-273.26608 625.06488 L
-273.62608 624.63288 L
-274.20208 624.20088 L
-274.77808 623.91288 L
-277.73008 623.12088 L
-278.45008 622.76088 L
-279.02608 622.32888 L
-279.31408 621.75288 L
-279.45808 621.03288 L
-279.38608 620.45688 L
-279.24208 620.02488 L
-279.02608 619.66488 L
-278.66608 619.37688 L
-277.73008 618.94488 L
-276.72208 618.80088 L
-276.07408 618.87288 L
-275.49808 619.01688 L
-274.99408 619.23288 L
-274.56208 619.59288 L
-274.20208 620.02488 L
-273.98608 620.52888 L
-273.84208 621.10488 L
-273.77008 621.82488 L
-272.40208 621.82488 L
-272.54608 620.45688 L
-272.83408 619.52088 L
-273.41008 618.58488 L
-274.20208 617.93688 L
-274.63408 617.64888 L
-275.21008 617.43288 L
-276.65008 617.28888 L
-277.58608 617.36088 L
-278.37808 617.57688 L
-279.09808 617.86488 L
-279.74608 618.29688 L
-280.25008 618.87288 L
-280.53808 619.52088 L
-280.75408 620.31288 L
-280.82608 621.17688 L
-280.68208 622.40088 L
-280.25008 623.40888 L
-279.89008 623.84088 L
-279.53008 624.12888 L
-278.52208 624.63288 L
-275.28208 625.56888 L
-274.77808 625.78488 L
-274.41808 626.14488 L
-274.27408 626.57688 L
-274.20208 627.22488 L
-274.34608 628.08888 L
-274.77808 628.80888 L
-275.57008 629.24088 L
-276.57808 629.38488 L
-277.65808 629.24088 L
-278.09008 629.02488 L
-278.45008 628.73688 L
-278.73808 628.30488 L
-278.95408 627.87288 L
-279.17008 626.79288 L
-280.53808 626.79288 L
-@c
-F
-
-@rax %Note: Object
-287.16208 617.28888 296.59408 630.89688 @E
- 0 O 0 @g
-0.84 0.73 0.72 0.91 k
-/$fm 0 def
-296.45008 626.64888 m
-296.30608 627.58488 L
-296.09008 628.37688 L
-295.65808 629.09688 L
-295.15408 629.74488 L
-294.50608 630.24888 L
-293.78608 630.60888 L
-292.99408 630.82488 L
-292.13008 630.89688 L
-291.05008 630.75288 L
-290.11408 630.39288 L
-289.25008 629.81688 L
-288.53008 629.09688 L
-287.95408 628.08888 L
-287.52208 626.86488 L
-287.30608 625.56888 L
-287.16208 624.05688 L
-287.30608 622.54488 L
-287.52208 621.24888 L
-287.95408 620.09688 L
-288.45808 619.08888 L
-289.17808 618.36888 L
-289.97008 617.79288 L
-290.90608 617.43288 L
-291.98608 617.28888 L
-292.85008 617.36088 L
-293.71408 617.64888 L
-294.43408 618.08088 L
-295.08208 618.65688 L
-295.58608 619.37688 L
-296.01808 620.24088 L
-296.37808 621.24888 L
-296.59408 622.40088 L
-295.15408 622.40088 L
-294.79408 620.88888 L
-294.50608 620.24088 L
-294.14608 619.73688 L
-293.71408 619.37688 L
-293.28208 619.08888 L
-292.70608 618.94488 L
-292.13008 618.87288 L
-291.33808 618.94488 L
-290.69008 619.23288 L
-290.04208 619.59288 L
-289.53808 620.24088 L
-289.17808 620.96088 L
-288.89008 621.82488 L
-288.74608 622.90488 L
-288.67408 624.12888 L
-288.74608 625.28088 L
-288.89008 626.28888 L
-289.17808 627.22488 L
-289.61008 627.94488 L
-290.11408 628.52088 L
-290.69008 628.95288 L
-291.41008 629.24088 L
-292.20208 629.31288 L
-293.28208 629.16888 L
-294.14608 628.59288 L
-294.43408 628.23288 L
-294.72208 627.80088 L
-295.08208 626.64888 L
-296.45008 626.64888 L
-@c
-F
-
-@rax %Note: Object
-303.36208 617.64888 311.71408 630.53688 @E
- 0 O 0 @g
-0.84 0.73 0.72 0.91 k
-/$fm 0 def
-303.36208 630.53688 m
-303.36208 617.64888 L
-304.80208 617.64888 L
-304.80208 623.69688 L
-310.27408 623.69688 L
-310.27408 617.64888 L
-311.71408 617.64888 L
-311.71408 630.53688 L
-310.27408 630.53688 L
-310.27408 625.20888 L
-304.80208 625.20888 L
-304.80208 630.53688 L
-303.36208 630.53688 L
-@c
-F
-
-@rax %Note: Object
-319.13008 617.64888 326.90608 630.53688 @E
- 0 O 0 @g
-0.84 0.73 0.72 0.91 k
-/$fm 0 def
-319.13008 630.53688 m
-319.13008 617.64888 L
-326.90608 617.64888 L
-326.90608 619.23288 L
-320.57008 619.23288 L
-320.57008 623.48088 L
-326.33008 623.48088 L
-326.33008 625.06488 L
-320.57008 625.06488 L
-320.57008 629.02488 L
-326.83408 629.02488 L
-326.83408 630.53688 L
-319.13008 630.53688 L
-@c
-F
-
-@rax %Note: Object
-333.96208 617.64888 342.81808 630.53688 @E
- 0 O 0 @g
-0.84 0.73 0.72 0.91 k
-/$fm 0 def
-333.96208 630.53688 m
-333.96208 617.64888 L
-335.47408 617.64888 L
-335.47408 623.19288 L
-339.07408 623.19288 L
-339.72208 623.04888 L
-340.22608 622.76088 L
-340.51408 622.40088 L
-340.65808 621.96888 L
-340.80208 620.16888 L
-340.80208 619.37688 L
-340.87408 618.80088 L
-341.01808 617.64888 L
-342.81808 617.64888 L
-342.81808 617.93688 L
-342.45808 618.29688 L
-342.31408 618.72888 L
-342.17008 621.82488 L
-342.09808 622.61688 L
-341.88208 623.19288 L
-341.45008 623.62488 L
-340.87408 623.98488 L
-341.59408 624.56088 L
-342.02608 625.20888 L
-342.31408 626.07288 L
-342.38608 627.15288 L
-342.24208 628.37688 L
-341.81008 629.31288 L
-341.30608 629.81688 L
-340.65808 630.24888 L
-339.86608 630.46488 L
-339.07408 630.53688 L
-333.96208 630.53688 L
-@c
-335.47408 629.09688 m
-339.07408 629.09688 L
-339.14608 629.02488 L
-339.65008 629.02488 L
-340.15408 628.80888 L
-340.58608 628.30488 L
-340.80208 627.65688 L
-340.87408 626.86488 L
-340.80208 625.92888 L
-340.44208 625.28088 L
-339.86608 624.84888 L
-339.14608 624.70488 L
-335.47408 624.70488 L
-335.47408 629.09688 L
-@c
-F
-
-@rax %Note: Object
-349.65808 617.64888 358.44208 630.53688 @E
- 0 O 0 @g
-0.84 0.73 0.72 0.91 k
-/$fm 0 def
-349.65808 630.53688 m
-349.65808 617.64888 L
-351.09808 617.64888 L
-351.09808 623.19288 L
-354.77008 623.19288 L
-355.34608 623.04888 L
-355.85008 622.76088 L
-356.13808 622.40088 L
-356.35408 621.96888 L
-356.42608 620.16888 L
-356.49808 619.37688 L
-356.49808 618.80088 L
-356.71408 617.64888 L
-358.44208 617.64888 L
-358.44208 617.93688 L
-358.08208 618.29688 L
-357.93808 618.72888 L
-357.79408 621.82488 L
-357.72208 622.61688 L
-357.50608 623.19288 L
-357.14608 623.62488 L
-356.57008 623.98488 L
-357.21808 624.56088 L
-357.72208 625.20888 L
-357.93808 626.07288 L
-358.08208 627.15288 L
-357.93808 628.37688 L
-357.50608 629.31288 L
-357.00208 629.81688 L
-356.28208 630.24888 L
-355.56208 630.46488 L
-354.69808 630.53688 L
-349.65808 630.53688 L
-@c
-351.09808 629.09688 m
-354.69808 629.09688 L
-354.77008 629.02488 L
-355.27408 629.02488 L
-355.77808 628.80888 L
-356.21008 628.30488 L
-356.49808 627.65688 L
-356.57008 626.86488 L
-356.42608 625.92888 L
-356.06608 625.28088 L
-355.49008 624.84888 L
-354.77008 624.70488 L
-351.09808 624.70488 L
-351.09808 629.09688 L
-@c
-F
-
-@rax %Note: Object
-365.28208 617.64888 373.13008 630.53688 @E
- 0 O 0 @g
-0.84 0.73 0.72 0.91 k
-/$fm 0 def
-365.28208 630.53688 m
-365.28208 617.64888 L
-373.13008 617.64888 L
-373.13008 619.23288 L
-366.72208 619.23288 L
-366.72208 623.48088 L
-372.48208 623.48088 L
-372.48208 625.06488 L
-366.72208 625.06488 L
-366.72208 629.02488 L
-372.98608 629.02488 L
-372.98608 630.53688 L
-365.28208 630.53688 L
-@c
-F
-
-@rax %Note: Object
-380.11408 617.64888 388.97008 630.53688 @E
- 0 O 0 @g
-0.84 0.73 0.72 0.91 k
-/$fm 0 def
-380.11408 630.53688 m
-380.11408 617.64888 L
-381.62608 617.64888 L
-381.62608 623.19288 L
-385.22608 623.19288 L
-385.87408 623.04888 L
-386.37808 622.76088 L
-386.66608 622.40088 L
-386.81008 621.96888 L
-386.95408 620.16888 L
-386.95408 619.37688 L
-387.02608 618.80088 L
-387.17008 617.64888 L
-388.97008 617.64888 L
-388.97008 617.93688 L
-388.61008 618.29688 L
-388.46608 618.72888 L
-388.32208 621.82488 L
-388.25008 622.61688 L
-388.03408 623.19288 L
-387.60208 623.62488 L
-387.02608 623.98488 L
-387.74608 624.56088 L
-388.17808 625.20888 L
-388.46608 626.07288 L
-388.53808 627.15288 L
-388.39408 628.37688 L
-387.96208 629.31288 L
-387.45808 629.81688 L
-386.81008 630.24888 L
-386.01808 630.46488 L
-385.22608 630.53688 L
-380.11408 630.53688 L
-@c
-381.62608 629.09688 m
-385.22608 629.09688 L
-385.29808 629.02488 L
-385.80208 629.02488 L
-386.30608 628.80888 L
-386.73808 628.30488 L
-386.95408 627.65688 L
-387.02608 626.86488 L
-386.95408 625.92888 L
-386.59408 625.28088 L
-386.01808 624.84888 L
-385.29808 624.70488 L
-381.62608 624.70488 L
-381.62608 629.09688 L
-@c
-F
-
-@rax %Note: Object
-410.85808 617.64888 412.29808 630.53688 @E
- 0 O 0 @g
-0.84 0.73 0.72 0.91 k
-/$fm 0 def
-410.85808 630.53688 m
-410.85808 617.64888 L
-412.29808 617.64888 L
-412.29808 630.53688 L
-410.85808 630.53688 L
-@c
-F
-
-@rax %Note: Object
-419.71408 617.64888 428.13808 630.53688 @E
- 0 O 0 @g
-0.84 0.73 0.72 0.91 k
-/$fm 0 def
-419.71408 630.53688 m
-419.71408 617.64888 L
-421.15408 617.64888 L
-421.15408 628.08888 L
-426.55408 617.64888 L
-428.13808 617.64888 L
-428.13808 630.53688 L
-426.77008 630.53688 L
-426.77008 620.09688 L
-421.44208 630.53688 L
-419.71408 630.53688 L
-@c
-F
-
-@rax %Note: Object
-434.97808 617.28888 443.40208 630.89688 @E
- 0 O 0 @g
-0.84 0.73 0.72 0.91 k
-/$fm 0 def
-443.11408 626.79288 m
-443.04208 627.72888 L
-442.82608 628.52088 L
-442.53808 629.24088 L
-442.03408 629.81688 L
-441.45808 630.32088 L
-440.81008 630.60888 L
-439.94608 630.82488 L
-439.08208 630.89688 L
-438.21808 630.82488 L
-437.49808 630.60888 L
-436.85008 630.32088 L
-436.34608 629.81688 L
-435.91408 629.24088 L
-435.62608 628.59288 L
-435.41008 627.80088 L
-435.33808 626.93688 L
-435.41008 626.21688 L
-435.55408 625.64088 L
-435.84208 625.06488 L
-436.20208 624.63288 L
-436.77808 624.20088 L
-437.35408 623.91288 L
-440.30608 623.12088 L
-441.02608 622.76088 L
-441.60208 622.32888 L
-441.89008 621.75288 L
-442.03408 621.03288 L
-441.96208 620.45688 L
-441.81808 620.02488 L
-441.60208 619.66488 L
-441.24208 619.37688 L
-440.30608 618.94488 L
-439.29808 618.80088 L
-438.65008 618.87288 L
-438.07408 619.01688 L
-437.57008 619.23288 L
-437.13808 619.59288 L
-436.77808 620.02488 L
-436.56208 620.52888 L
-436.41808 621.10488 L
-436.34608 621.82488 L
-434.97808 621.82488 L
-435.12208 620.45688 L
-435.41008 619.52088 L
-435.98608 618.58488 L
-436.77808 617.93688 L
-437.21008 617.64888 L
-437.85808 617.43288 L
-439.22608 617.28888 L
-440.16208 617.36088 L
-440.95408 617.57688 L
-441.67408 617.86488 L
-442.32208 618.29688 L
-442.82608 618.87288 L
-443.11408 619.52088 L
-443.33008 620.31288 L
-443.40208 621.17688 L
-443.25808 622.40088 L
-442.82608 623.40888 L
-442.46608 623.84088 L
-442.10608 624.12888 L
-441.09808 624.63288 L
-437.85808 625.56888 L
-437.35408 625.78488 L
-436.99408 626.14488 L
-436.85008 626.57688 L
-436.77808 627.22488 L
-436.92208 628.08888 L
-437.35408 628.80888 L
-438.14608 629.24088 L
-439.15408 629.38488 L
-440.23408 629.24088 L
-440.66608 629.02488 L
-441.02608 628.73688 L
-441.31408 628.30488 L
-441.53008 627.87288 L
-441.74608 626.79288 L
-443.11408 626.79288 L
-@c
-F
-
-@rax %Note: Object
-449.30608 617.64888 457.94608 630.53688 @E
- 0 O 0 @g
-0.84 0.73 0.72 0.91 k
-/$fm 0 def
-449.30608 630.53688 m
-449.30608 629.02488 L
-452.90608 629.02488 L
-452.90608 617.64888 L
-454.34608 617.64888 L
-454.34608 629.02488 L
-457.94608 629.02488 L
-457.94608 630.53688 L
-449.30608 630.53688 L
-@c
-F
-
-@rax %Note: Object
-464.49808 617.64888 465.93808 630.53688 @E
- 0 O 0 @g
-0.84 0.73 0.72 0.91 k
-/$fm 0 def
-464.49808 630.53688 m
-464.49808 617.64888 L
-465.93808 617.64888 L
-465.93808 630.53688 L
-464.49808 630.53688 L
-@c
-F
-
-@rax %Note: Object
-472.41808 617.64888 481.05808 630.53688 @E
- 0 O 0 @g
-0.84 0.73 0.72 0.91 k
-/$fm 0 def
-472.41808 630.53688 m
-472.41808 629.02488 L
-476.01808 629.02488 L
-476.01808 617.64888 L
-477.45808 617.64888 L
-477.45808 629.02488 L
-481.05808 629.02488 L
-481.05808 630.53688 L
-472.41808 630.53688 L
-@c
-F
-
-@rax %Note: Object
-487.39408 617.28888 495.74608 630.53688 @E
- 0 O 0 @g
-0.84 0.73 0.72 0.91 k
-/$fm 0 def
-487.39408 630.53688 m
-487.39408 621.75288 L
-487.53808 620.60088 L
-487.89808 619.52088 L
-488.54608 618.51288 L
-489.33808 617.86488 L
-490.34608 617.43288 L
-491.49808 617.28888 L
-492.43408 617.36088 L
-493.29808 617.64888 L
-494.01808 618.08088 L
-494.59408 618.65688 L
-495.09808 619.30488 L
-495.45808 620.09688 L
-495.67408 620.96088 L
-495.74608 621.82488 L
-495.74608 630.53688 L
-494.30608 630.53688 L
-494.30608 622.18488 L
-494.30608 622.04088 L
-494.23408 621.46488 L
-494.01808 620.38488 L
-493.44208 619.59288 L
-493.01008 619.23288 L
-492.57808 619.01688 L
-492.07408 618.87288 L
-491.57008 618.87288 L
-490.99408 618.87288 L
-490.41808 619.08888 L
-489.98608 619.37688 L
-489.55408 619.73688 L
-489.26608 620.24088 L
-489.05008 620.81688 L
-488.90608 621.53688 L
-488.83408 622.32888 L
-488.83408 630.53688 L
-487.39408 630.53688 L
-@c
-F
-
-@rax %Note: Object
-502.08208 617.64888 510.72208 630.53688 @E
- 0 O 0 @g
-0.84 0.73 0.72 0.91 k
-/$fm 0 def
-502.08208 630.53688 m
-502.08208 629.02488 L
-505.68208 629.02488 L
-505.68208 617.64888 L
-507.12208 617.64888 L
-507.12208 629.02488 L
-510.72208 629.02488 L
-510.72208 630.53688 L
-502.08208 630.53688 L
-@c
-F
-
-%%PageTrailer
-@rs
-@rs
-%%Trailer
-@EndSysCorelDict
-end
-%%DocumentSuppliedResources: procset wCorel7Dict
-%%EOF
\ No newline at end of file
diff --git a/manual/figures/psi_logo_wide.pdf b/manual/figures/psi_logo_wide.pdf
deleted file mode 100644
index e713fcb50..000000000
Binary files a/manual/figures/psi_logo_wide.pdf and /dev/null differ
diff --git a/manual/html.sty b/manual/html.sty
deleted file mode 100644
index b5f8fbb84..000000000
--- a/manual/html.sty
+++ /dev/null
@@ -1,887 +0,0 @@
-%
-% $Id: html.sty,v 1.23 1998/02/26 10:32:24 latex2html Exp $
-% LaTeX2HTML Version 96.2 : html.sty
-% 
-% This file contains definitions of LaTeX commands which are
-% processed in a special way by the translator. 
-% For example, there are commands for embedding external hypertext links,
-% for cross-references between documents or for including raw HTML.
-% This file includes the comments.sty file v2.0 by Victor Eijkhout
-% In most cases these commands do nothing when processed by LaTeX.
-%
-% Place this file in a directory accessible to LaTeX (i.e., somewhere
-% in the TEXINPUTS path.)
-%
-% NOTE: This file works with LaTeX 2.09 or (the newer) LaTeX2e.
-%       If you only have LaTeX 2.09, some complex LaTeX2HTML features
-%       like support for segmented documents are not available.
-
-% Changes:
-% See the change log at end of file.
-
-
-% Exit if the style file is already loaded
-% (suggested by Lee Shombert <las@potomac.wash.inmet.com>
-\ifx \htmlstyloaded\relax \endinput\else\let\htmlstyloaded\relax\fi
-\makeatletter
-
-\providecommand{\latextohtml}{\LaTeX2\texttt{HTML}}
-
-
-%%% LINKS TO EXTERNAL DOCUMENTS
-%
-% This can be used to provide links to arbitrary documents.
-% The first argumment should be the text that is going to be
-% highlighted and the second argument a URL.
-% The hyperlink will appear as a hyperlink in the HTML 
-% document and as a footnote in the dvi or ps files.
-%
-\newcommand{\htmladdnormallinkfoot}[2]{#1\footnote{#2}} 
-
-
-% This is an alternative definition of the command above which
-% will ignore the URL in the dvi or ps files.
-\newcommand{\htmladdnormallink}[2]{#1}
-
-
-% This command takes as argument a URL pointing to an image.
-% The image will be embedded in the HTML document but will
-% be ignored in the dvi and ps files.
-%
-\newcommand{\htmladdimg}[1]{}
-
-
-%%% CROSS-REFERENCES BETWEEN (LOCAL OR REMOTE) DOCUMENTS
-%
-% This can be used to refer to symbolic labels in other Latex 
-% documents that have already been processed by the translator.
-% The arguments should be:
-% #1 : the URL to the directory containing the external document
-% #2 : the path to the labels.pl file of the external document.
-% If the external document lives on a remote machine then labels.pl 
-% must be copied on the local machine.
-%
-%e.g. \externallabels{http://cbl.leeds.ac.uk/nikos/WWW/doc/tex2html/latex2html}
-%                    {/usr/cblelca/nikos/tmp/labels.pl}
-% The arguments are ignored in the dvi and ps files.
-%
-\newcommand{\externallabels}[2]{}
-
-
-% This complements the \externallabels command above. The argument
-% should be a label defined in another latex document and will be
-% ignored in the dvi and ps files.
-%
-\newcommand{\externalref}[1]{}
-
-
-% Suggested by  Uffe Engberg (http://www.brics.dk/~engberg/)
-% This allows the same effect for citations in external bibliographies.
-% An  \externallabels  command must be given, locating a labels.pl file
-% which defines the location and keys used in the external .html file.
-%  
-\newcommand{\externalcite}{\nocite}
-
-
-%%% HTMLRULE
-% This command adds a horizontal rule and is valid even within
-% a figure caption.
-% Here we introduce a stub for compatibility.
-\newcommand{\htmlrule}{\protect\HTMLrule}
-\newcommand{\HTMLrule}{\@ifstar\htmlrulestar\htmlrulestar}
-\newcommand{\htmlrulestar}[1]{}
-
-% This command adds information within the <BODY> ... </BODY> tag
-%
-\newcommand{\bodytext}[1]{}
-\newcommand{\htmlbody}{}
-
-
-%%% HYPERREF 
-% Suggested by Eric M. Carol <eric@ca.utoronto.utcc.enfm>
-% Similar to \ref but accepts conditional text. 
-% The first argument is HTML text which will become ``hyperized''
-% (underlined).
-% The second and third arguments are text which will appear only in the paper
-% version (DVI file), enclosing the fourth argument which is a reference to a label.
-%
-%e.g. \hyperref{using the tracer}{using the tracer (see Section}{)}{trace}
-% where there is a corresponding \label{trace}
-%
-\newcommand{\hyperref}{\hyperrefx[ref]}
-\def\hyperrefx[#1]{{\def\next{#1}%
- \def\tmp{ref}\ifx\next\tmp\aftergroup\hyperrefref
- \else\def\tmp{pageref}\ifx\next\tmp\aftergroup\hyperpageref
- \else\def\tmp{page}\ifx\next\tmp\aftergroup\hyperpageref
- \else\def\tmp{noref}\ifx\next\tmp\aftergroup\hypernoref
- \else\def\tmp{no}\ifx\next\tmp\aftergroup\hypernoref
- \else\typeout{*** unknown option \next\space to  hyperref ***}%
- \fi\fi\fi\fi\fi}}
-\newcommand{\hyperrefref}[4]{#2\ref{#4}#3}
-\newcommand{\hyperpageref}[4]{#2\pageref{#4}#3}
-\newcommand{\hypernoref}[3]{#2}
-
-
-%%% HYPERCITE --- added by RRM
-% Suggested by Stephen Simpson <simpson@math.psu.edu>
-% effects the same ideas as in  \hyperref, but for citations.
-% It does not allow an optional argument to the \cite, in LaTeX.
-%
-%   \hypercite{<html-text>}{<LaTeX-text>}{<opt-text>}{<key>}
-%
-% uses the pre/post-texts in LaTeX, with a  \cite{<key>}
-%
-%   \hypercite[ext]{<html-text>}{<LaTeX-text>}{<key>}
-%
-% uses the pre/post-texts in LaTeX, with a  \nocite{<key>}
-% the actual reference comes from an \externallabels  file.
-%
-\newcommand{\hypercite}{\hypercitex[int]}
-\def\hypercitex[#1]{{\def\next{#1}%
- \def\tmp{int}\ifx\next\tmp\aftergroup\hyperciteint
- \else\def\tmp{cite}\ifx\next\tmp\aftergroup\hyperciteint
- \else\def\tmp{ext}\ifx\next\tmp\aftergroup\hyperciteext
- \else\def\tmp{nocite}\ifx\next\tmp\aftergroup\hyperciteext
- \else\def\tmp{no}\ifx\next\tmp\aftergroup\hyperciteext
- \else\typeout{*** unknown option \next\space to  hypercite ***}%
- \fi\fi\fi\fi\fi}}
-\newcommand{\hyperciteint}[4]{#2{\def\tmp{#3}\def\emptyopt{}%
- \ifx\tmp\emptyopt\cite{#4}\else\cite[#3]{#4}\fi}}
-\newcommand{\hyperciteext}[3]{#2\nocite{#3}}
-
-
-
-%%% HTMLREF
-% Reference in HTML version only.
-% Mix between \htmladdnormallink and \hyperref.
-% First arg is text for in both versions, second is label for use in HTML
-% version.
-\newcommand{\htmlref}[2]{#1}
-
-%%% HTMLCITE
-% Reference in HTML version only.
-% Mix between \htmladdnormallink and \hypercite.
-% First arg is text for in both versions, second is citation for use in HTML
-% version.
-\newcommand{\htmlcite}[2]{#1}
-
-
-%%% HTMLIMAGE
-% This command can be used inside any environment that is converted
-% into an inlined image (eg a "figure" environment) in order to change
-% the way the image will be translated. The argument of \htmlimage
-% is really a string of options separated by commas ie 
-% [scale=<scale factor>],[external],[thumbnail=<reduction factor>
-% The scale option allows control over the size of the final image.
-% The ``external'' option will cause the image not to be inlined 
-% (images are inlined by default). External images will be accessible
-% via a hypertext link. 
-% The ``thumbnail'' option will cause a small inlined image to be 
-% placed in the caption. The size of the thumbnail depends on the
-% reduction factor. The use of the ``thumbnail'' option implies
-% the ``external'' option.
-%
-% Example:
-% \htmlimage{scale=1.5,external,thumbnail=0.2}
-% will cause a small thumbnail image 1/5th of the original size to be
-% placed in the final document, pointing to an external image 1.5
-% times bigger than the original.
-% 
-\newcommand{\htmlimage}[1]{}
-
-
-% \htmlborder causes a border to be placed around an image or table
-% when the image is placed within a <TABLE> cell.
-\newcommand{\htmlborder}[1]{}
-
-% Put \begin{makeimage}, \end{makeimage} around LaTeX to ensure its
-% translation into an image.
-% This shields sensitive text from being translated.
-\newenvironment{makeimage}{}{}
-
-
-% A dummy environment that can be useful to alter the order
-% in which commands are processed, in LaTeX2HTML
-\newenvironment{tex2html_deferred}{}{}
-
-
-%%% HTMLADDTONAVIGATION
-% This command appends its argument to the buttons in the navigation
-% panel. It is ignored by LaTeX.
-%
-% Example:
-% \htmladdtonavigation{\htmladdnormallink
-%              {\htmladdimg{http://server/path/to/gif}}
-%              {http://server/path}}
-\newcommand{\htmladdtonavigation}[1]{}
-
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-% Comment.sty   version 2.0, 19 June 1992
-% selectively in/exclude pieces of text: the user can define new
-% comment versions, and each is controlled separately.
-% This style can be used with plain TeX or LaTeX, and probably
-% most other packages too.
-%
-% Examples of use in LaTeX and TeX follow \endinput
-%
-% Author
-%    Victor Eijkhout
-%    Department of Computer Science
-%    University Tennessee at Knoxville
-%    104 Ayres Hall
-%    Knoxville, TN 37996
-%    USA
-%
-%    eijkhout@cs.utk.edu
-%
-% Usage: all text included in between
-%    \comment ... \endcomment
-% or \begin{comment} ... \end{comment}
-% is discarded. The closing command should appear on a line
-% of its own. No starting spaces, nothing after it.
-% This environment should work with arbitrary amounts
-% of comment.
-%
-% Other 'comment' environments are defined by
-% and are selected/deselected with
-% \includecomment{versiona}
-% \excludecoment{versionb}
-%
-% These environments are used as
-% \versiona ... \endversiona
-% or \begin{versiona} ... \end{versiona}
-% with the closing command again on a line of its own.
-%
-% Basic approach:
-% to comment something out, scoop up  every line in verbatim mode
-% as macro argument, then throw it away.
-% For inclusions, both the opening and closing comands
-% are defined as noop
-%
-% Changed \next to \html@next to prevent clashes with other sty files
-% (mike@emn.fr)
-% Changed \html@next to \htmlnext so the \makeatletter and
-% \makeatother commands could be removed (they were causing other
-% style files - changebar.sty - to crash) (nikos@cbl.leeds.ac.uk)
-% Changed \htmlnext back to \html@next...
-
-\def\makeinnocent#1{\catcode`#1=12 }
-\def\csarg#1#2{\expandafter#1\csname#2\endcsname}
-
-\def\ThrowAwayComment#1{\begingroup
-    \def\CurrentComment{#1}%
-    \let\do\makeinnocent \dospecials
-    \makeinnocent\^^L% and whatever other special cases
-    \endlinechar`\^^M \catcode`\^^M=12 \xComment}
-{\catcode`\^^M=12 \endlinechar=-1 %
- \gdef\xComment#1^^M{\def\test{#1}\edef\test{\meaning\test}
-      \csarg\ifx{PlainEnd\CurrentComment Test}\test
-          \let\html@next\endgroup
-      \else \csarg\ifx{LaLaEnd\CurrentComment Test}\test
-            \edef\html@next{\endgroup\noexpand\end{\CurrentComment}}
-      \else \csarg\ifx{LaInnEnd\CurrentComment Test}\test
-            \edef\html@next{\endgroup\noexpand\end{\CurrentComment}}
-      \else \let\html@next\xComment
-      \fi \fi \fi \html@next}
-}
-
-\def\includecomment
- #1{\expandafter\def\csname#1\endcsname{}%
-    \expandafter\def\csname end#1\endcsname{}}
-\def\excludecomment
- #1{\expandafter\def\csname#1\endcsname{\ThrowAwayComment{#1}}%
-    {\escapechar=-1\relax
-     \edef\tmp{\string\\end#1}%
-      \csarg\xdef{PlainEnd#1Test}{\meaning\tmp}%
-     \edef\tmp{\string\\end\string\{#1\string\}}%
-      \csarg\xdef{LaLaEnd#1Test}{\meaning\tmp}%
-     \edef\tmp{\string\\end \string\{#1\string\}}%
-      \csarg\xdef{LaInnEnd#1Test}{\meaning\tmp}%
-    }}
-
-\excludecomment{comment}
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-% end Comment.sty
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-%
-% Alternative code by Robin Fairbairns, 22 September 1997
-%
-\newcommand\@gobbleenv{\let\reserved@a\@currenvir\@gobble@nv}
-\long\def\@gobble@nv#1\end#2{\def\reserved@b{#2}%
- \ifx\reserved@a\reserved@b
-  \edef\reserved@a{\noexpand\end{\reserved@a}}%
-  \expandafter\reserved@a
- \else
-  \expandafter\@gobble@nv
- \fi}
-
-\renewcommand{\excludecomment}[1]{%
-    \csname newenvironment\endcsname{#1}{\@gobbleenv}{}}
-
-%%% RAW HTML 
-% 
-% Enclose raw HTML between a \begin{rawhtml} and \end{rawhtml}.
-% The html environment ignores its body
-%
-\excludecomment{rawhtml}
-
-
-%%% HTML ONLY
-%
-% Enclose LaTeX constructs which will only appear in the 
-% HTML output and will be ignored by LaTeX with 
-% \begin{htmlonly} and \end{htmlonly}
-%
-\excludecomment{htmlonly}
-% Shorter version
-\newcommand{\html}[1]{}
-
-% for images.tex only
-\excludecomment{imagesonly}
-
-%%% LaTeX ONLY
-% Enclose LaTeX constructs which will only appear in the 
-% DVI output and will be ignored by latex2html with 
-%\begin{latexonly} and \end{latexonly}
-%
-\newenvironment{latexonly}{}{}
-% Shorter version
-\newcommand{\latex}[1]{#1}
-
-
-%%% LaTeX or HTML
-% Combination of \latex and \html.
-% Say \latexhtml{this should be latex text}{this html text}
-%
-%\newcommand{\latexhtml}[2]{#1}
-\long\def\latexhtml#1#2{#1}
-
-
-%%% tracing the HTML conversions
-% This alters the tracing-level within the processing
-% performed by  latex2html  by adjusting  $VERBOSITY
-% (see  latex2html.config  for the appropriate values)
-%
-\newcommand{\htmltracing}[1]{}
-\newcommand{\htmltracenv}[1]{}
-
-
-%%%  \strikeout for HTML only
-% uses <STRIKE>...</STRIKE> tags on the argument
-% LaTeX just gobbles it up.
-\newcommand{\strikeout}[1]{}
-
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-%%% JCL - stop input here if LaTeX2e is not present
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-\ifx\if@compatibility\undefined
-  %LaTeX209
-  \makeatother\relax\expandafter\endinput
-\fi
-\if@compatibility
-  %LaTeX2e in LaTeX209 compatibility mode
-  \makeatother\relax\expandafter\endinput
-\fi
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-%
-% Start providing LaTeX2e extension:
-% This is currently:
-%  - additional optional argument for \htmladdimg
-%  - support for segmented documents
-%
-
-\ProvidesPackage{html}
-          [1996/12/22 v1.1 hypertext commands for latex2html (nd, hws, rrm)]
-%%%%MG
-
-% This command takes as argument a URL pointing to an image.
-% The image will be embedded in the HTML document but will
-% be ignored in the dvi and ps files.  The optional argument
-% denotes additional HTML tags.
-%
-% Example:  \htmladdimg[ALT="portrait" ALIGN=CENTER]{portrait.gif}
-%
-\renewcommand{\htmladdimg}[2][]{}
-
-%%% HTMLRULE for LaTeX2e
-% This command adds a horizontal rule and is valid even within
-% a figure caption.
-%
-% This command is best used with LaTeX2e and HTML 3.2 support.
-% It is like \hrule, but allows for options via key--value pairs
-% as follows:  \htmlrule[key1=value1, key2=value2, ...] .
-% Use \htmlrule* to suppress the <BR> tag.
-% Eg. \htmlrule[left, 15, 5pt, "none", NOSHADE] produces
-% <BR CLEAR="left"><HR NOSHADE SIZE="15">.
-% Renew the necessary part.
-\renewcommand{\htmlrulestar}[1][all]{}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-%
-%  renew some definitions to allow optional arguments
-%
-% The description of the options is missing, as yet.
-%
-\renewcommand{\latextohtml}{\textup{\LaTeX2\texttt{HTML}}}
-\renewcommand{\htmladdnormallinkfoot}[3][]{#2\footnote{#3}} 
-\renewcommand{\htmladdnormallink}[3][]{#2}
-\renewcommand{\htmlbody}[1][]{}
-\renewcommand{\hyperref}[1][ref]{\hyperrefx[#1]}
-\renewcommand{\hypercite}[1][int]{\hypercitex[#1]}
-\renewcommand{\htmlref}[3][]{#2}
-\renewcommand{\htmlcite}[1]{#1\htmlcitex}
-\newcommand{\htmlcitex}[2][]{{\def\tmp{#1}\ifx\tmp\@empty\else~[#1]\fi}}
-\renewcommand{\htmlimage}[2][]{}
-\renewcommand{\htmlborder}[2][]{}
-
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-%
-%  HTML  HTMLset  HTMLsetenv
-%
-%  These commands do nothing in LaTeX, but can be used to place
-%  HTML tags or set Perl variables during the LaTeX2HTML processing;
-%  They are intended for expert use only.
-
-\newcommand{\HTMLcode}[2][]{}
-\ifx\undefined\HTML\newcommand{\HTML}[2][]{}\else
-\typeout{*** Warning: \string\HTML\space had an incompatible definition ***}%
-\typeout{*** instead use \string\HTMLcode\space for raw HTML code ***}%
-\fi 
-\newcommand{\HTMLset}[3][]{}
-\newcommand{\HTMLsetenv}[3][]{}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-%
-% The following commands pertain to document segmentation, and
-% were added by Herbert Swan <dprhws@edp.Arco.com> (with help from
-% Michel Goossens <goossens@cern.ch>):
-%
-%
-% This command inputs internal latex2html tables so that large
-% documents can to partitioned into smaller (more manageable)
-% segments.
-%
-\newcommand{\internal}[2][internals]{}
-
-%
-%  Define a dummy stub \htmlhead{}.  This command causes latex2html
-%  to define the title of the start of a new segment.  It is not
-%  normally placed in the user's document.  Rather, it is passed to
-%  latex2html via a .ptr file written by \segment.
-%
-\newcommand{\htmlhead}[3][]{}
-
-%  In the LaTeX2HTML version this will eliminate the title line
-%  generated by a \segment command, but retains the title string
-%  for use in other places.
-%
-\newcommand{\htmlnohead}{}
-
-
-%  In the LaTeX2HTML version this put a URL into a <BASE> tag
-%  within the <HEAD>...</HEAD> portion of a document.
-%
-\newcommand{\htmlbase}[1]{}
-%
-
-%
-%  The dummy command \endpreamble is needed by latex2html to
-%  mark the end of the preamble in document segments that do
-%  not contain a \begin{document}
-%
-\newcommand{\startdocument}{}
-
-
-% \tableofchildlinks, \htmlinfo
-%     by Ross Moore  ---  extensions dated 27 September 1997
-%
-%  These do nothing in LaTeX but for LaTeX2HTML they mark 
-%  where the table of child-links and info-page should be placed,
-%  when the user wants other than the default.
-%	\tableofchildlinks	 % put mini-TOC at this location
-%	\tableofchildlinks[off]	 % not on current page
-%	\tableofchildlinks[none] % not on current and subsequent pages
-%	\tableofchildlinks[on]   % selectively on current page
-%	\tableofchildlinks[all]  % on current and all subsequent pages
-%	\htmlinfo	 	 % put info-page at this location
-%	\htmlinfo[off]		 % no info-page in current document
-%	\htmlinfo[none]		 % no info-page in current document
-%  *-versions omit the preceding <BR> tag.
-%
-\newcommand{\tableofchildlinks}{%
-  \@ifstar\tableofchildlinksstar\tableofchildlinksstar}
-\newcommand{\tableofchildlinksstar}[1][]{}
-
-\newcommand{\htmlinfo}{\@ifstar\htmlinfostar\htmlinfostar}
-\newcommand{\htmlinfostar}[1][]{}
-
-
-%  This redefines  \begin  to allow for an optional argument
-%  which is used by LaTeX2HTML to specify `style-sheet' information
-
-\let\realLaTeX@begin=\begin
-\renewcommand{\begin}[1][]{\realLaTeX@begin}
-
-
-%
-%  Allocate a new set of section counters, which will get incremented
-%  for "*" forms of sectioning commands, and for a few miscellaneous
-%  commands.
-%
-
-\newcounter{lpart}
-\newcounter{lchapter}[part]
-\@ifundefined{c@chapter}%
- {\let\Hchapter\relax \newcounter{lsection}[part]}%
- {\let\Hchapter=\chapter \newcounter{lsection}[chapter]}
-\newcounter{lsubsection}[section]
-\newcounter{lsubsubsection}[subsection]
-\newcounter{lparagraph}[subsubsection]
-\newcounter{lsubparagraph}[paragraph]
-\newcounter{lequation}
-
-%
-%  Redefine "*" forms of sectioning commands to increment their
-%  respective counters.
-%
-\let\Hpart=\part
-%\let\Hchapter=\chapter
-\let\Hsection=\section
-\let\Hsubsection=\subsection
-\let\Hsubsubsection=\subsubsection
-\let\Hparagraph=\paragraph
-\let\Hsubparagraph=\subparagraph
-\let\Hsubsubparagraph=\subsubparagraph
-
-\ifx\c@subparagraph\undefined
- \newcounter{lsubsubparagraph}[lsubparagraph]
-\else
- \newcounter{lsubsubparagraph}[subparagraph]
-\fi
-
-%
-%  The following definitions are specific to LaTeX2e:
-%  (They must be commented out for LaTeX 2.09)
-%
-\renewcommand{\part}{\@ifstar{\stepcounter{lpart}%
-  \bgroup\def\tmp{*}\H@part}{\bgroup\def\tmp{}\H@part}}
-\newcommand{\H@part}[1][]{\def\tmp@a{#1}\check@align
- \expandafter\egroup\expandafter\Hpart\tmp}
-
-\ifx\Hchapter\relax\else
- \def\chapter{\resetsections \@ifstar{\stepcounter{lchapter}%
-   \bgroup\def\tmp{*}\H@chapter}{\bgroup\def\tmp{}\H@chapter}}\fi
-\newcommand{\H@chapter}[1][]{\def\tmp@a{#1}\check@align
- \expandafter\egroup\expandafter\Hchapter\tmp}
-
-\renewcommand{\section}{\resetsubsections
- \@ifstar{\stepcounter{lsection}\bgroup\def\tmp{*}%
-   \H@section}{\bgroup\def\tmp{}\H@section}}
-\newcommand{\H@section}[1][]{\def\tmp@a{#1}\check@align
- \expandafter\egroup\expandafter\Hsection\tmp}
-
-\renewcommand{\subsection}{\resetsubsubsections
- \@ifstar{\stepcounter{lsubsection}\bgroup\def\tmp{*}%
-   \H@subsection}{\bgroup\def\tmp{}\H@subsection}}
-\newcommand{\H@subsection}[1][]{\def\tmp@a{#1}\check@align
- \expandafter\egroup\expandafter\Hsubsection\tmp}
-
-\renewcommand{\subsubsection}{\resetparagraphs
- \@ifstar{\stepcounter{lsubsubsection}\bgroup\def\tmp{*}%
-   \H@subsubsection}{\bgroup\def\tmp{}\H@subsubsection}}
-\newcommand{\H@subsubsection}[1][]{\def\tmp@a{#1}\check@align
- \expandafter\egroup\expandafter\Hsubsubsection\tmp}
-
-\renewcommand{\paragraph}{\resetsubparagraphs
- \@ifstar{\stepcounter{lparagraph}\bgroup\def\tmp{*}%
-   \H@paragraph}{\bgroup\def\tmp{}\H@paragraph}}
-\newcommand\H@paragraph[1][]{\def\tmp@a{#1}\check@align
- \expandafter\egroup\expandafter\Hparagraph\tmp}
-
-\renewcommand{\subparagraph}{\resetsubsubparagraphs
- \@ifstar{\stepcounter{lsubparagraph}\bgroup\def\tmp{*}%
-   \H@subparagraph}{\bgroup\def\tmp{}\H@subparagraph}}
-\newcommand\H@subparagraph[1][]{\def\tmp@a{#1}\check@align
- \expandafter\egroup\expandafter\Hsubparagraph\tmp}
-
-\ifx\Hsubsubparagraph\relax\else\@ifundefined{subsubparagraph}{}{%
-\def\subsubparagraph{%
- \@ifstar{\stepcounter{lsubsubparagraph}\bgroup\def\tmp{*}%
-   \H@subsubparagraph}{\bgroup\def\tmp{}\H@subsubparagraph}}}\fi
-\newcommand\H@subsubparagraph[1][]{\def\tmp@a{#1}\check@align
- \expandafter\egroup\expandafter\Hsubsubparagraph\tmp}
-
-\def\check@align{\def\empty{}\ifx\tmp@a\empty
- \else\def\tmp@b{center}\ifx\tmp@a\tmp@b\let\tmp@a\empty
- \else\def\tmp@b{left}\ifx\tmp@a\tmp@b\let\tmp@a\empty
- \else\def\tmp@b{right}\ifx\tmp@a\tmp@b\let\tmp@a\empty
- \else\expandafter\def\expandafter\tmp@a\expandafter{\expandafter[\tmp@a]}%
- \fi\fi\fi \def\empty{}\ifx\tmp\empty\let\tmp=\tmp@a \else 
-  \expandafter\def\expandafter\tmp\expandafter{\expandafter*\tmp@a}%
- \fi\fi}
-%
-\def\resetsections{\setcounter{section}{0}\setcounter{lsection}{0}%
- \reset@dependents{section}\resetsubsections }
-\def\resetsubsections{\setcounter{subsection}{0}\setcounter{lsubsection}{0}%
- \reset@dependents{subsection}\resetsubsubsections }
-\def\resetsubsubsections{\setcounter{subsubsection}{0}\setcounter{lsubsubsection}{0}%
- \reset@dependents{subsubsection}\resetparagraphs }
-%
-\def\resetparagraphs{\setcounter{lparagraph}{0}\setcounter{lparagraph}{0}%
- \reset@dependents{paragraph}\resetsubparagraphs }
-\def\resetsubparagraphs{\ifx\c@subparagraph\undefined\else
-  \setcounter{subparagraph}{0}\fi \setcounter{lsubparagraph}{0}%
- \reset@dependents{subparagraph}\resetsubsubparagraphs }
-\def\resetsubsubparagraphs{\ifx\c@subsubparagraph\undefined\else
-  \setcounter{subsubparagraph}{0}\fi \setcounter{lsubsubparagraph}{0}}
-%
-\def\reset@dependents#1{\begingroup\let \@elt \@stpelt
- \csname cl@#1\endcsname\endgroup}
-%
-%
-%  Define a helper macro to dump a single \secounter command to a file.
-%
-\newcommand{\DumpPtr}[2]{%
-\count255=\arabic{#1}\def\dummy{dummy}\def\tmp{#2}%
-\ifx\tmp\dummy\else\advance\count255 by \arabic{#2}\fi
-\immediate\write\ptrfile{%
-\noexpand\setcounter{#1}{\number\count255}}}
-
-%
-%  Define a helper macro to dump all counters to the file.
-%  The value for each counter will be the sum of the l-counter
-%      actual LaTeX section counter.
-%  Also dump an \htmlhead{section-command}{section title} command
-%      to the file.
-%
-\newwrite\ptrfile
-\def\DumpCounters#1#2#3#4{%
-\begingroup\let\protect=\noexpand
-\immediate\openout\ptrfile = #1.ptr
-\DumpPtr{part}{lpart}%
-\ifx\Hchapter\relax\else\DumpPtr{chapter}{lchapter}\fi
-\DumpPtr{section}{lsection}%
-\DumpPtr{subsection}{lsubsection}%
-\DumpPtr{subsubsection}{lsubsubsection}%
-\DumpPtr{paragraph}{lparagraph}%
-\DumpPtr{subparagraph}{lsubparagraph}%
-\DumpPtr{equation}{lequation}%
-\DumpPtr{footnote}{dummy}%
-\def\tmp{#4}\ifx\tmp\@empty
-\immediate\write\ptrfile{\noexpand\htmlhead{#2}{#3}}\else
-\immediate\write\ptrfile{\noexpand\htmlhead[#4]{#2}{#3}}\fi
-\dumpcitestatus \dumpcurrentcolor
-\immediate\closeout\ptrfile
-\endgroup }
-
-
-%% interface to natbib.sty
-
-\def\dumpcitestatus{}
-\def\loadcitestatus{\def\dumpcitestatus{%
-  \ifciteindex\immediate\write\ptrfile{\noexpand\citeindextrue}%
-  \else\immediate\write\ptrfile{\noexpand\citeindexfalse}\fi }%
-}
-\@ifpackageloaded{natbib}{\loadcitestatus}{%
- \AtBeginDocument{\@ifpackageloaded{natbib}{\loadcitestatus}{}}}
-
-
-%% interface to color.sty
-
-\def\dumpcurrentcolor{}
-\def\loadsegmentcolors{%
- \let\real@pagecolor=\pagecolor
- \let\pagecolor\segmentpagecolor
- \let\segmentcolor\color
- \ifx\current@page@color\undefined \def\current@page@color{{}}\fi
- \def\dumpcurrentcolor{\bgroup\def\@empty@{{}}%
-   \expandafter\def\expandafter\tmp\space####1@{\def\thiscol{####1}}%
-  \ifx\current@color\@empty@\def\thiscol{}\else
-   \expandafter\tmp\current@color @\fi
-  \immediate\write\ptrfile{\noexpand\segmentcolor{\thiscol}}%
-  \ifx\current@page@color\@empty@\def\thiscol{}\else
-   \expandafter\tmp\current@page@color @\fi
-  \immediate\write\ptrfile{\noexpand\segmentpagecolor{\thiscol}}%
- \egroup}%
- \global\let\loadsegmentcolors=\relax
-}
-
-% These macros are needed within  images.tex  since this inputs
-% the <segment>.ptr files for a segment, so that counters are
-% colors are synchronised.
-%
-\newcommand{\segmentpagecolor}[1][]{%
- \@ifpackageloaded{color}{\loadsegmentcolors\bgroup
-  \def\tmp{#1}\ifx\@empty\tmp\def\next{[]}\else\def\next{[#1]}\fi
-  \expandafter\segmentpagecolor@\next}%
- {\@gobble}}
-\def\segmentpagecolor@[#1]#2{\def\tmp{#1}\def\tmpB{#2}%
- \ifx\tmpB\@empty\let\next=\egroup
- \else
-  \let\realendgroup=\endgroup
-  \def\endgroup{\edef\next{\noexpand\realendgroup
-   \def\noexpand\current@page@color{\current@color}}\next}%
-  \ifx\tmp\@empty\real@pagecolor{#2}\def\model{}%
-  \else\real@pagecolor[#1]{#2}\def\model{[#1]}%
-  \fi
-  \edef\next{\egroup\def\noexpand\current@page@color{\current@page@color}%
-  \noexpand\real@pagecolor\model{#2}}%
- \fi\next}
-%
-\newcommand{\segmentcolor}[2][named]{\@ifpackageloaded{color}%
- {\loadsegmentcolors\segmentcolor[#1]{#2}}{}}
-
-\@ifpackageloaded{color}{\loadsegmentcolors}{\let\real@pagecolor=\@gobble
- \AtBeginDocument{\@ifpackageloaded{color}{\loadsegmentcolors}{}}}
-
-
-%  Define the \segment[align]{file}{section-command}{section-title} command,
-%  and its helper macros.  This command does four things:
-%       1)  Begins a new LaTeX section;
-%       2)  Writes a list of section counters to file.ptr, each
-%           of which represents the sum of the LaTeX section
-%           counters, and the l-counters, defined above;
-%       3)  Write an \htmlhead{section-title} command to file.ptr;
-%       4)  Inputs file.tex.
-
-\def\segment{\@ifstar{\@@htmls}{\@@html}}
-\def\endsegment{}
-\newcommand{\@@htmls}[1][]{\@@htmlsx{#1}}
-\newcommand{\@@html}[1][]{\@@htmlx{#1}}
-\def\@@htmlsx#1#2#3#4{\csname #3\endcsname* {#4}%
-                   \DumpCounters{#2}{#3*}{#4}{#1}\input{#2}}
-\def\@@htmlx#1#2#3#4{\csname #3\endcsname {#4}%
-                   \DumpCounters{#2}{#3}{#4}{#1}\input{#2}}
-
-\makeatother
-\endinput
-
-
-% Modifications:
-%
-% (The listing of Initiales see Changes)
-
-% $Log: html.sty,v $
-% Revision 1.23  1998/02/26 10:32:24  latex2html
-%  --  use \providecommand for  \latextohtml
-%  --  implemented \HTMLcode to do what \HTML did previously
-% 	\HTML still works, unless already defined by another package
-%  --  fixed problems remaining with undefined \chapter
-%  --  defined \endsegment
-%
-% Revision 1.22  1997/12/05 11:38:18  RRM
-%  --  implemented an optional argument to \begin for style-sheet info.
-%  --  modified use of an optional argument with sectioning-commands
-%
-% Revision 1.21  1997/11/05 10:28:56  RRM
-%  --  replaced redefinition of \@htmlrule with \htmlrulestar
-%
-% Revision 1.20  1997/10/28 02:15:58  RRM
-%  --  altered the way some special html-macros are defined, so that
-% 	star-variants are explicitly defined for LaTeX
-% 	 -- it is possible for these to occur within  images.tex
-% 	e.g. \htmlinfostar \htmlrulestar \tableofchildlinksstar
-%
-% Revision 1.19  1997/10/11 05:47:48  RRM
-%  --  allow the dummy {tex2html_nowrap} environment in LaTeX
-% 	use it to make its contents be evaluated in environment order
-%
-% Revision 1.18  1997/10/04 06:56:50  RRM
-%  --  uses Robin Fairbairns' code for ignored environments,
-%      replacing the previous  comment.sty  stuff.
-%  --  extensions to the \tableofchildlinks command
-%  --  extensions to the \htmlinfo command
-%
-% Revision 1.17  1997/07/08 11:23:39  RRM
-%     include value of footnote counter in .ptr files for segments
-%
-% Revision 1.16  1997/07/03 08:56:34  RRM
-%     use \textup  within the \latextohtml macro
-%
-% Revision 1.15  1997/06/15 10:24:58  RRM
-%      new command  \htmltracenv  as environment-ordered \htmltracing
-%
-% Revision 1.14  1997/06/06 10:30:37  RRM
-%  -   new command:  \htmlborder  puts environment into a <TABLE> cell
-%      with a border of specified width, + other attributes.
-%  -   new commands: \HTML  for setting arbitrary HTML tags, with attributes
-%                    \HTMLset  for setting Perl variables, while processing
-%                    \HTMLsetenv  same as \HTMLset , but it gets processed
-%                                 as if it were an environment.
-%  -   new command:  \latextohtml  --- to set the LaTeX2HTML name/logo
-%  -   fixed some remaining problems with \segmentcolor & \segmentpagecolor
-%
-% Revision 1.13  1997/05/19 13:55:46  RRM
-%      alterations and extra options to  \hypercite
-%
-% Revision 1.12  1997/05/09 12:28:39  RRM
-%  -  Added the optional argument to \htmlhead, also in \DumpCounters
-%  -  Implemented \HTMLset as a no-op in LaTeX.
-%  -  Fixed a bug in accessing the page@color settings.
-%
-% Revision 1.11  1997/03/26 09:32:40  RRM
-%  -  Implements LaTeX versions of  \externalcite  and  \hypercite  commands.
-%     Thanks to  Uffe Engberg  and  Stephen Simpson  for the suggestions.
-%
-% Revision 1.10  1997/03/06 07:37:58  RRM
-% Added the  \htmltracing  command, for altering  $VERBOSITY .
-%
-% Revision 1.9  1997/02/17 02:26:26  RRM
-% - changes to counter handling (RRM)
-% - shuffled around some definitions
-% - changed \htmlrule of 209 mode
-%
-% Revision 1.8  1997/01/26 09:04:12  RRM
-% RRM: added optional argument to sectioning commands
-%      \htmlbase  sets the <BASE HREF=...> tag
-%      \htmlinfo  and  \htmlinfo* allow the document info to be positioned
-%
-% Revision 1.7  1997/01/03 12:15:44  L2HADMIN
-% % - fixes to the  color  and  natbib  interfaces
-% % - extended usage of  \hyperref, via an optional argument.
-% % - extended use comment environments to allow shifting expansions
-% %     e.g. within \multicolumn  (`bug' reported by Luc De Coninck).
-% % - allow optional argument to: \htmlimage, \htmlhead,
-% %     \htmladdimg, \htmladdnormallink, \htmladdnormallinkfoot
-% % - added new commands: \htmlbody, \htmlnohead
-% % - added new command: \tableofchildlinks
-%
-% Revision 1.6  1996/12/25 03:04:54  JCL
-% added patches to segment feature from Martin Wilck
-%
-% Revision 1.5  1996/12/23 01:48:06  JCL
-%  o introduced the environment makeimage, which may be used to force
-%    LaTeX2HTML to generate an image from the contents.
-%    There's no magic, all what we have now is a defined empty environment
-%    which LaTeX2HTML will not recognize and thus pass it to images.tex.
-%  o provided \protect to the \htmlrule commands to allow for usage
-%    within captions.
-%
-% Revision 1.4  1996/12/21 19:59:22  JCL
-% - shuffled some entries
-% - added \latexhtml command
-%
-% Revision 1.3  1996/12/21 12:22:59  JCL
-% removed duplicate \htmlrule, changed \htmlrule back not to create a \hrule
-% to allow occurrence in caption
-%
-% Revision 1.2  1996/12/20 04:03:41  JCL
-% changed occurrence of \makeatletter, \makeatother
-% added new \htmlrule command both for the LaTeX2.09 and LaTeX2e
-% sections
-%
-%
-% jcl 30-SEP-96
-%  - Stuck the commands commonly used by both LaTeX versions to the top,
-%    added a check which stops input or reads further if the document
-%    makes use of LaTeX2e.
-%  - Introduced rrm's \dumpcurrentcolor and \bodytext
-% hws 31-JAN-96 - Added support for document segmentation
-% hws 10-OCT-95 - Added \htmlrule command
-% jz 22-APR-94 - Added support for htmlref
-% nd  - Created
diff --git a/manual/introduction.tex b/manual/introduction.tex
deleted file mode 100644
index 0d305a764..000000000
--- a/manual/introduction.tex
+++ /dev/null
@@ -1,348 +0,0 @@
-\chapter{Introduction}
-\label{sec:Introduction}
-One of \ippl 's most attractive features is its high performance on both single-processor and distributed-memory multiprocessor machines. As future releases of the library will also support shared-memory machines. 
-
-The heart of the problem \ippl 's authors face is that while data-parallel programming is a natural way to express many scientific and numerical algorithms, straightforward implementations of it do exactly the wrong thing on modern architectures, whose performance depends critically on the re-use of data loaded into cache. If a program evaluates A+B+C for three arrays A, B, and C by adding A to B, then adding C to that calculation's result, performance suffers both because of the overhead of executing two loops instead of one, but also (and more importantly) because every value in the temporary array that stores the result of A+B has to be accessed twice: once to write it, and once to read it back in. As soon as this array is too large to fit into cache, the program's performance will drop dramatically.
-
-%The first section of this tutorial explains what \ippl  does to solve this problem. Subsequent sections discuss other advanced aspects of \ippl , such as how to build pointwise functions, or reduction functions that will execute efficiently regardless of how arrays are laid out in memory.
-
-%\ippl  tries to resolve the tension between how programmers want to express their ideas, and what runs most efficiently on modern architectures, by delaying the evaluation of expressions until enough is known about their context to ensure that they can be evaluated efficiently. It does this by blocking calculations into units called iterates, and putting those iterates into a queue of work that is still to be done. Each iterate is a portion of a computation, over a portion of a domain. \ippl  tracks data dependencies between iterates dynamically to ensure that out-of-order computation cannot occur.
-
-%Depending on the switches specified during configuration when the library is installed, and the version of the \ippl  library that a program is linked against, \ippl  will run in one of four different modes. In the first mode, the work queue doesn't actually exist. Instead, the single thread of execution in the program evaluates iterates as soon as they are "enqueued", i.e. work is done immediately. The result is that all of the calculations in a statement are completed by the time execution reaches the semi-colon at the end of that statement.
-
-%In its second mode, \ippl  maintains the work queue, but all work is done by a single thread. The queue is used because the explicit parceling up of work into iterates gives \ippl  an opportunity to re-order or combine those iterates. While the overhead of maintaining and inspecting the work queue can slow down operations on small arrays, it makes operations on large arrays much faster.
-
-%For example, consider the four function calls that perform red/black relaxation in the second tutorial. In order to get the highest possible performance out of the cache, all four of these expressions should be evaluated on a given cache block before any of the expressions are evaluated for the next cache block. Managing this by hand is a nightmare, both because cache size varies from machine to machine (even when those machines come from the same manufacturer), and because very slight changes in the dimensions of arrays can tip them in or out of cache. \ippl 's array classes and overloaded operators do part of the job by creating appropriately-sized iterates; its work queue does the rest of the job by deciding how best to evaluate them. The net result is higher performance for less programmer effort.
-
-%\ippl 's third and fourth modes of operation are multi-threaded. Each thread in a pool takes iterates from the work queue when and as they become available. Iterates are evaluated independently; the difference between the two modes is that one is synchronous, and blocks after evaluating each data-parallel statement, while the other is asynchronous, i.e. permits out-of-order execution. The table below summarizes these four modes, along with the configuration arguments used to produce each.
-
-
-\section{Example 1 Laplace solver using Jacobi iteration}
-\begin{code}[caption={Laplace solver}]
-#include "Ippl.h"
-int main(int argc, char *argv[])
-{
-    Ippl ippl(argc,argv);
-    Inform msg(argv[0]);
-    const unsigned N=8;
-    const unsigned Dim=2;
-
-    Index IGLOBAL(N);  // Specify the global domain 
-    Index JGLOBAL(N); 
-
-    Index I(1, N-1); // Specify the interior domain
-    Index J(1, N-1);
-    FieldLayout<Dim> layout(IGLOBAL,JGLOBAL);
-    GuardCellSizes<Dim> gc(1);
-    typedef UniformCartesian<Dim> Mesh;
-    Field<double,Dim,Mesh> A(layout,gc);
-    Field<double,Dim,Mesh> b(layout,gc);
-
-    assign(A,0.0);  // Assign initial conditions
-    assign(b,0.0);
-
-    b[N/2][N/2] = -1.0;  // put a spike on the RHS 
-    double fact = 0.25;
-
-    // Iterate 200 times
-    for (int i=0; i<200; ++i) {
-        assign(A[I][J],fact*(A[I+1][J] +
-                             A[I-1][J] +
-                             A[I][J+1] +
-                             A[I][J-1] - b[I][J]));
-    }                                                                                                                                            
-    msg << A << endl;
-    return 0;
-}
-\end{code}
-The syntax is very similar to that of Fortran 90: a single assignment fills an entire array with a scalar value, subscripts express ranges as well as single points, and so on. In fact, the combination of C++ and \ippl provides so many of the features of Fortran 90 that one might well ask whether it wouldn't better to just use the latter language straight up. One answer comes down to economics. While the various flavors of Fortran are still used in scientific computing, Fortran's user base is shrinking, particularly in comparison to C++. Networking, graphics, database access, and operating system interfaces are available in C++ programmers long before they're available in Fortran (if they become available at all). What's more, support tools such as debuggers and memory inspectors are primarily targeted at C++ developers, as are hundreds of books, journal articles, and web sites.
-
-Another answer is that the abstraction facilities of C++ are much more powerful that those in Fortran. While Fortran 90 supports an attractive array syntax for floating point arrays one could not, for example, efficiently extend this high level syntax to arrays of vectors or tensors. Until recently, Fortran has had two powerful arguments in its favor: legacy applications, and performance. However, the importance of the former is diminishing as the invention of new algorithms force programmers to rewrite old codes, while the invention of techniques such as {\it expression templates} has made it possible for C++ programs to match, or exceed, the performance of highly-optimized Fortran 77. 
-%!TEX encoding = UTF-8 Unicode
-
-\section{Example 2 Power Spectrum}
-A sinussoidal field  $\rho(i,j,k) = a_1sin(k_1 \frac{2\pi}{n_x} i) + a_5 sin(k_5 \frac{2\pi}{n_x} i)$, 
-$i= 1 \dots n_x, ~ j= 1 \dots n_y, ~ k= 1 \dots n_z $ with $n_x,n_y$ and $n_z$ denoting the grid size is generated and
-the power spectrum calculated. This examples shows how to initialise fields, compute discrete complex-complex FFT and 
-compute the resulting powerspectrum.
-
-Assume a real density field is defined like 
-\begin{smallcode}
-typedef Field<double,Dim,Mesh_t,Center_t>  Field_t;
-Field_t rho;
-\end{smallcode}
-we then can immediately initialize the field according to the above formula 
-\begin{smallcode}
-assign(rho[I][J][K], a1*sin(2.0*pi/nr_m[0]*k1*I) + 
-                     a5*sin(2.0*pi/nr_m[0]*k5*I));
-\end{smallcode}
-Normalizing to $\max(\rho) \le 1.0 $ with
-\begin{smallcode}
-rho /= max(rho)
-\end{smallcode} 
-we then assume to have defined a complex field "fC" and a complex-complex FFT. 
-\begin{smallcode}
-fC = rho;
-fft->transform("forward" , fC);
- \end{smallcode}
-Here we used the in place version of the FFT to obtain $\rho $ in Fourier space. Now
-we can compute the power spectrum: 
-\begin{smallcode}  
-pwrSpec = real(fC*conj(fC));
-\end{smallcode}
-%\pagebreak
-and calculate the 1D pwr-spectrum (in x direction) by integrating over y and z: \\
-\begin{code}  
- NDIndex<3> elem;  
- for (int i=lDomain[0].min(); i<=(lDomain[0].max()-1)/2; ++i) {
-  elem[0]=Index(i,i);
-   for (int j=lDomain[1].min(); j<=(lDomain[1].max()-1)/2; ++j) {
-    elem[1]=Index(j,j);
-     for (int k=lDomain[2].min(); k<=(lDomain[2].max()-1)/2; ++k) {
-       elem[2]=Index(k,k);
-       f1D[i] += pwrSpec.localElement(elem);
-     }
-   }
- }
-\end{code}
-The power spectra of the local domain is stored in $f1$. We have to update all other node
-so that each node has the full power spectrum by:
-\begin{smallcode} 
-reduce(&(f1[0]),&(f1[0])+f1_lenght,OpAddAssign());
-\end{smallcode} 
-assuming the non local part of $f1$ is initialized with zero.
-
-%The full code pwrspec-1.cpp is located at $\ippl_ROOT/test/simple.
-
- 
- \section{Example 3 Particle in Cell Code (PIC)}
- This example discusses how to write a 3D Particle in Cell Code (PIC). The 
- complete source file can be found at {\em \$IPPL\_ROOT/test/particles}. The 
- this presentation details are omitted, only the structure and important issues are
- highlighted. 
- \subsection{The {\em ChargedParticles} Class}
- The base class {\tt ParticleBase} is augmented with attributes such as charge to mass ration
- {\tt qm}, the vector momenta {\tt P} and the vector holding the electric field {\tt E}. 
- \begin{code}
- ChargedParticles(PL* pl, Vector_t hr, Vector_t rmin, 
-                  Vector_t rmax, e_dim_tag decomp[Dim]) :
-                  ParticleBase<PL>(pl),
-                  hr_m(hr),
-                  rmin_m(rmin),
-                  rmax_m(rmax),
-                  fieldNotInitialized_m(true)
-{
-    this->addAttribute(qm);
-    this->addAttribute(P);
-    this->addAttribute(E);
-
-    for (int i=0; i < 2*Dim; i++) {
-        this->getBConds()[i] = ParticlePeriodicBCond;
-        bc_m[i]  = new PeriodicFace<double  ,Dim,Mesh_t,Center_t>(i);
-        vbc_m[i] = new PeriodicFace<Vector_t,Dim,Mesh_t,Center_t>(i);
-    }
-    for(int i=0; i<Dim; i++)
-        decomp_m[i]=decomp[i];
-}
-\end{code}
-The arrays {\tt bc\_m} and {\tt vbc\_m} holding the boundary conditions for particles and fields.
-In {\tt decomp\_m} the domain decomposition is stored.
-
-\subsection{The {\em main}}
-
- \begin{code}
-int main(int argc, char *argv[]) {
-    Ippl ippl(argc, argv);
-    Inform msg(argv[0]);
-
-    Vektor<int,Dim> nr(atoi(argv[1]),atoi(argv[2]),atoi(argv[3]));
-
-    const unsigned int totalP = atoi(argv[4]);
-    const int nt              = atoi(argv[5]);
-
-    e_dim_tag decomp[Dim];
-    int serialDim = 2;
-
-    Mesh_t *mesh;
-    FieldLayout_t *FL;
-    ChargedParticles<playout_t>  *partBunch;
-
-    NDIndex<Dim> domain;
-    for(int d=0; d<Dim; d++) {
-        domain[d] = domain[d] = Index(nr[d] + 1);
-        decomp[d] = (d == serialDim) ? SERIAL : PARALLEL;
-    }
-\end{code}
-In the fist part of main, the discrete computational domain ({\tt domain}) and the 
-domain decomposition ({\tt decomp}) is constructed. We have choose a 2D domain decomposition
-with $z$ serial i.e. not parallelized. \\
-\begin{code}
-    mesh          = new Mesh_t(domain);
-    FL            = new FieldLayout_t(*mesh, decomp);
-    playout_t* PL = new playout_t(*FL, *mesh);
-
-    Vector_t hr(1.0);
-    Vector_t rmin(0.0);
-    Vector_t rmax(nr);
-
-    partBunch=new ChargedParticles<playout_t>(PL,hr,rmin,rmax,decomp);
-\end{code} 
- Here we construct the {\tt mesh} the field layout ({\tt FL}), describing how the fields are distributed
-  and finally the particle layout {\tt PL}. The latter is the used as a template argument to construct the
-  particle container. For this example the mesh size is set to unity and the computational domain is
-  the given by the number of mesh points defined in {\tt nr}. \\
-\begin{code}
-    unsigned long int nloc = totalP / Ippl::getNodes();
-
-    partBunch->create(nloc);
-    for (unsigned long int i = 0; i< nloc; i++) {
-        for (int d = 0; d<Dim; d++)
-            partBunch->R[i](d) =  IpplRandom() * nr[d];
-    }
-
-    partBunch->qm =  1.0/totalP;
-    partBunch->myUpdate(); 
-    partBunch->initFields();
-\end{code} 
-  Now each node created {\tt nloc} particles and initialized the coordinates randomly in the 
-  computational domain.  A fixed charge to mass ration is assigned. The \texttt{myUpdate()} moves
-  all particles to their node defined by the domain decomposition and initialized the fields. In the last
-  call the fields gets initialized with the sinusoidal electric field.
-  \clearpage
-\begin{code}
-    for (unsigned int it=0; it<nt; it++) {
-
-        partBunch->R = partBunch->R + dt * partBunch->P;
-        partBunch->myUpdate();
-        partBunch->gather();
-        partBunch->P += dt * partBunch->qm * partBunch->E;
-    }
-    return 0;
-}
-\end{code}
-The last part of main consists of a simple integration scheme to advance the particles. The call
-{\tt gather} interpolates the electric field at the particle position form the nearby grid points by a second
-order {\it cloud in cell} (CIC) interpolation scheme. 
- 
- 
-\subsection{{\em initFields}}
- 
-\begin{code}
-void initFields() {
-
-    NDIndex<Dim> domain = getFieldLayout().getDomain();
-
-    for(int i=0; i<Dim; i++)
-        nr_m[i] = domain[i].length();
-
-    int nx = nr_m[0]; int ny = nr_m[1]; int nz = nr_m[2];
-
-    double phi0 = 0.1*nx;            
-
-    Index I(nx), J(ny), K(nz);
-
-    assign(EFD_m[I][J][K](0), 
-            -2.0*pi*phi0/nx * 
-            cos(2.0*pi*(I+0.5)/nx) * 
-            cos(4.0*pi*(J+0.5)/ny) * cos(pi*(K+0.5)/nz));
-
-    assign(EFD_m[I][J][K](1),  ..... ;
-
-    assign(EFD_m[I][J][K](2),  ..... ;
-
-    assign(EFDMag_m[I][J][K],
-           EFD_m[I][J][K](0) * EFD_m[I][J][K](0) +
-           EFD_m[I][J][K](1) * EFD_m[I][J][K](1) +
-           EFD_m[I][J][K](2) * EFD_m[I][J][K](2));
-}
-\end{code}
-
-\subsection{{\em myUpdate}}
- 
- \begin{code}
-void myUpdate() {
-
-    if(fieldNotInitialized_m) {
-         fieldNotInitialized_m=false;
-         getMesh().set_meshSpacing(&(hr_m[0]));
-         getMesh().set_origin(rmin_m);
-         EFD_m.initialize(getMesh(), getFieldLayout(), GuardCellSizes<Dim>(1), vbc_m);
-         EFDMag_m.initialize(getMesh(), getFieldLayout(), GuardCellSizes<Dim>(1), bc_m);
-    }
-    this->update();  
-}
-\end{code}
- 
-  \subsection{{\em gather}}
- 
-\begin{code}
-void gather() {	
-    IntCIC myinterp;
-    E.gather(EFD_m, this->R, myinterp);
-}
-\end{code}
- 
-\section{Installation}
- \ippl uses the {\em cmake } build philosophy.  The following environment variables must be set
-\begin{verbatim}
-IPPL_ROOT
-\end{verbatim} 
-defining where \ippl is installed.
-
-\subsection{Building \ippl}
-\begin{verbatim}
-cd $IPPL_ROOT
-CXX=mpicxx F77=gfortran cmake -DCMAKE_VERBOSE_MAKEFILE=OFF
--DCMAKE_INSTALL_PREFIX=~/extlib/ippl $IPPL_ROOT
-\end{verbatim}
-
-
-\subsection{Used Compilers and Libraries}
-The supported operating systems and libraries are listed in Table \ref{tab:archlib}.
-\begin{table}[h]
-  \caption{Supported Architectures and needed Libraries}
-  \label{tab:archlib}
-  \begin{center}
-    \begin{tabular}{|lcccc|}
-      \hline
-      Operating System & HDF5  & H5hut & Compiler & Open MPI\\
-      \hline
-      Linux (SL) 2.6.18 & hdf5-1.8.5 & V0.99 & GNU 4.4.x, icc11.1 & 1.4.2 \\
-      Cray XTx  & hdf5-1.8.5 & V0.99 & GNU 4.4 & - \\
-      \hline
-    \end{tabular}
-  \end{center}
-\end{table}
-
-
-
-
-
-\clearpage
-\section{Acknowledgements}
-The contributions of various individuals and groups are acknowledged in the relevant chapters, 
-however a few individuals have or had considerable influence on the 
-development, Julian Cummings, Yves Ineichen and Jakob Progsch.
-Misprints and obscurity are almost inevitable in a document of this size.
-Comments and {\em active contributions}  from readers are therefore most welcome.
-They may also be sent to \htmladdnormallink{\texttt{andreas.adelmann@psi.ch}}{mailto:andreas.adelmann@psi.ch}.
-
-\subsection{Citation}
-Please cite \ippl in the following way:
-\begin{small}
-\begin{verbatim} 
-@techreport{ippl-User-Guide,
-title = "{The IPPL (Independent Parallel Particle Layer)
-              Framework }",
-author = "A. Adelmann",
-institution = "Paul Scherrer Institut",
-number = "PSI-PR-09-05",
-year = 2009}
-\end{verbatim}
-\end{small}
-
-
-%& OPAL \\
-% & V 1.0
-
-
diff --git a/manual/ippl_centering_ref.tex b/manual/ippl_centering_ref.tex
deleted file mode 100644
index fd6256363..000000000
--- a/manual/ippl_centering_ref.tex
+++ /dev/null
@@ -1,251 +0,0 @@
-\chapter{Centering}
-\label{sec:cent}
-Classes in this chapter represent the abstraction of centering at particular positions on a \texttt{Mesh}. 
-For any type of mesh, vertex (mesh-node) centering is well-defined. For Cartesian meshes, cell centering is well defined, because each 
-rectangular mesh cell has a well-defined center, the midpoint along each dimension. Also, for Cartesian meshes, combinations of cell and vertex centering 
-along the various dimensions clearly define common centerings such as face centering and edge centering. \ippl predefines classes for cell and vertex centering, 
-as well as classes to represent all possible combination centerings for Cartesian meshes. These classes are all static in the current implementation 
-(you do not instantiate objects of the class types, you just refer to the centerings by class name). The centering classes typically serve as the centering 
-template parameter for Field and other \ippl classes parameterized on centering. 
-\section{\texttt{Cell} Class}
-The static \texttt{Cell} class represents the abstraction of cell-centering of something on a \texttt{Mesh}. 
-That "something" is usually a \texttt{Field}. \texttt{Cell} can serve as a value for the \texttt{Centering} template parameter of the \texttt{Field} class. Every \texttt{Field} element, whatever its type, 
-is centered at the position of the corresponding cell center in the \texttt{Mesh} using the same index space for mesh cell centers as 
-(or the \texttt{Field} elements. If the Field elements (\texttt{T} parameter for \texttt{Field} class) is some kind of multi component type such as \texttt{Vektor}, the whole object of that type in every \texttt{Field} 
-element is cell-centered (that is, all components have the same centering). The \texttt{CartesianCentering} class allows you to center components of \texttt{Field} elements independently. 
-If you center a \texttt{Field} on a \texttt{Mesh} using \texttt{Cell}, you must make sure that you construct the \texttt{Field} to have the proper number of elements so that it has one-for every cell in the mesh. 
-When you use \texttt{Field} constructors taking a \texttt{Mesh} object argument (instance' of the class specified as the \texttt{Mesh} template parameter for \texttt{Field}), the extents of the 
-\texttt{NDIndex} object or index field constructor arguments match those used to instantiate that \texttt{Mesh}. When you instantiate a \texttt{Field} with \texttt{Cell} centering using 
-constructors without a mesh object argument, the internally-constructed mesh object will automatically have the right number of cells. 
-subsection{Cell Definition (Public Interface)}
-\begin{smallcode}
-class Cell { 
-public: 
-    static char* CenteringName ;
-    static void print_Centerings(ostream&) ;
-}; 
-\end{smallcode}
-
-
-
-\subsection{\texttt{Cell} Constructors}
-\texttt{Cell} is a static class you don't instantiate objects, but rather only refer to it by its class name. 
-
-\subsection{\texttt{Cell} Member Functions and Member Data}
-
-\begin{smallcode}
-static char* CenteringName; 
-\end{smallcode}
-Public data member, having static value "\texttt{Cell}".
- 
-\begin{smallcode}
-static void print_Centerings(ostream&) ;
-\end{smallcode}
-Invoked as \texttt{Cell::printCenterings(ostream\&)}  prints the value of the \texttt{string Cell::CenteringName}. 
-
-\section{\texttt{Vert} Class}
-The static \texttt{Vert} class represents the abstraction of vertex-centering of something on a mesh. 
-That "something" is usually a \texttt{Field}. \texttt{Vert} can serve as a value for the \texttt{Centering} template parameter of the \texttt{Field} class. Every \texttt{Field} element, whatever its type, 
-is centered at the position of the corresponding vertex center in the mesh-using the same index space for \texttt{Mesh} vertex centers as for the \texttt{Field} elements. If the \texttt{Field} elements 
-(\texttt{T} parameter for \texttt{Field} class) is some kind of multicomponent type such as \texttt{Vektor}, the whole object of that type in every \texttt{Field} element is vertex-centered 
-(that is, all components have the same centering). The \texttt{CartesianCentering} class allows you to center components of \texttt{Field} elements independently. 
-If you center a \texttt{Field} on a \texttt{Mesh} using \texttt{Vert}, you must make sure that you construct the Field to have the proper number of elements so that it has one for every vertex in the mesh. 
-When you use \texttt{Field} constructors taking a mesh object argument (instance of the class specified as the \texttt{Mesh} template parameter for \texttt{Field}), the extents of the \texttt{NDIndex} object or \texttt{Index} 
-\texttt{Field} constructor arguments match those used to instantiate that \texttt{Mesh}. When you instantiate a \texttt{Field} with \texttt{Vert} centering using constructors without a mesh object argument, 
-the internally constructed mesh object will automatically have the right number of vertices. 
-
-subsection{Vert Definition (Public Interface)}
-\begin{smallcode}
-class Vert { 
-public: 
-    static char* CenteringName;
-    static void print_Centerings(ostream&);
-} ; 
-\end{smallcode}
-
-
-\subsection{\texttt{Vert} Constructors}
-\texttt{Vert} is a static class you don't instantiate objects, but rather only refer to it by its class name. 
-
-\subsection{\texttt{Vert} Member Functions and Member Data}
-
-\begin{smallcode}
-static char* CenteringName; 
-\end{smallcode}
-Public data member, having static value "\texttt{Vert}".
- 
-\begin{smallcode}
-static void print_Centerings(ostream&) ;
-\end{smallcode}
-Invoked as \texttt{Vert::printCenterings(ostream\&)}  prints the value of the \texttt{string Vert::CenteringName}. 
-
-
-\section{\texttt{CommonCartesianCenterings} Class}
-The static CommonCartesianCenterings class is a wrapper class for commonly-used special cases ofthe \texttt{CartesianCentering} class, predefinedby \ippl as a convenience for the user. 
-Basically, it is a collection of typedef's. \\
-\texttt{CartesianCentering} is a parameterized static class representing the abstraction of componentwise centering of a multicomponent object (typically a \texttt{Field}) 
-on a cartesian mesh. Via the template parameters, the user specifies the centering of the various components along the various directions. See next section for more details. 
-\texttt{CommonCartesianCenterings} provides a, shorthand definition for some of the common cases expressible by \texttt{CartesianCentering}. \\
-Also shown in the definition of \texttt{CommonCartesianCenterings} below are the \texttt{CenteringEnum} which it uses and the static wrapper class \\ \texttt{commonCartesianCenteringEnums}. 
-This last class contains the special-case arrays of \texttt{CenteringEnum} values (\texttt{CELL} or \texttt{VERT}) which represent the various centerings for various specializations of the template parameters. \\
-\texttt{CommonCartesianCenterings}  parameterized on dimensionality \texttt{Dim}, which has the same meaning as the dimensionality parameter in \texttt{Field} or \texttt{UniformCartesian} (for example). 
-
-The unsigned value \texttt{NComponents} and the unsigned value \texttt{Direction}. \texttt{NComponents} represents the number of components in a multicomponent object to be centered on the mesh, 
-for example, if you are centering a \texttt{Field<Vektor<double, 3U>} ,the number of components is three. Direction represents a specifying direction, and is only really used in some of the 
-\texttt{CommonCartesianCenterings} members. For example, to specify face centering of a scalar field (or single component of a non-scalar field), you must specify which direction is perpendicular 
-to the faces where you are centering. If you wanted to center a scalar field on the $xy$ faces in 3D, you would use the value \texttt{2U} for \texttt{Direction}; because the $xy$ faces are perpendicular to 
-the $z$ direction (the directions are numbered sequentially, $x$ is \texttt{0U}, $y$ is \texttt{1U}, and $z$ is \texttt{2U}). 
-
-\subsection{\texttt{CommonCartesianCenterings} Definition (Public Interface)}
-\begin{smallcode}
-
-enum CenteringEnum {CELL=0, VERTEX=1, VERT=1};
- 
-template<unsignedDim, unsigned NComponents=1U, unsigned Direction=0U> 
-class CommonCartesianCenteringEnums
-{ 
-public: 
-// CenteringEnum arrays Classes with simple, des'criptive names 
-
-// All components of Field cell-centered in all directions: 
-static CenteringEnum allCell [NComponents*Dim] ;
- 
-// All components of Field vertex-ceritered in all directions: 
-static CenteringEnum allVertex[NComponents*Dim] ; 
-
-// All components of Field face-centered in specified 
-// direction (meaning vertex centered in that direction, cell-centered in others): 
-static CenteringEnum allFace[NComponents*Dim];
-
-// All components of Field edge-centered along specified direction
-// (cell centered in that direction, vertex-centered in others): 
-static CenteringEnum allEdge[NComponents*bim];, 
-
-// Each vector component of Field face-centered in the corresponfing direction 
-staticCenteringEnum vectorFace[NComponents*Dim]; 
-} ; 
-
-template<unsigned Dim, unsigned NComponents=1U, unsigned Direction=0U> 
-class CommonCartesianCenterings 
-{ 
-public: 
-typedef CartesianCentering<CommonCartesianCenteringEnums<Dim,NComponents,
-Direction>::allCell, Dim, NComponents> allCell; 
-typedef CartesianCentering<CommonCartesianCenteringEnums<Dim,NComponents,
-Direction>::allVertex, Dim, NComponents> allVertex; 
-typedef CartesianCentering<CommonCartesianCenteringEnums<Dim, NCo mponents,
-Direction>::allFace, pim, NComponehts> allFace; 
-typedef CartesianCentering<CommonCartesianCenteringEnums<Dim, NCo mponents,
-Direction>::allEdge, Dim, NComponents> allEdge; 
-typedef CartesianCentering<CommonCartesianCenteringEnums<Dim,NComponents,
-Direction>::vectorFace, Dim, NComponents> vectorFace; 
-}; 
-\end{smallcode}
-
-
-\subsection{\texttt{CommonCartesianCenterings} Constructors}
-\texttt{CommonCartesianCenterings} is a static class, you don't instantiate objects, but rather only refer to it by its class name. 
-Refer to its members his way also for example: \texttt{CartesianCenterings<3U, 1U>} for the member representing centering on a 3D mesh of a scalar 
-( one-component) object. 
-
-\subsection{\texttt{CommonCartesianCenterings} Member Data}
-\begin{smallcode}
-typedef CartesianCentering<CommonCartesianCenteringEnums<Dim,NComponents,
-Direction>::allCell, Dim, NComponents> allCell ;
-\end{smallcode}
-Specifies \texttt{CELL} centering of all components along all dimensions. Functionally equivalent to the \texttt{Cell} centering class. 
-
-\begin{smallcode}
-typedef CartesianCentering<CommonCartesianCenteringEnums<Dim,NComponents,
-Direcition>::allVertex, Dim, NComponents> allVertex ;
-\end{smallcode}
-Specifies \texttt{VERTEX} centering of all components along all dimensions. Functionally equivalent to the \texttt{Vert} centering class. 
-
-\begin{smallcode}
-typedef CartesianCentering<CommonCartesianCenteringEnums<Dim, NComponents, 
-Direction>::allFace, Dim, NComponents> allFace ;
-\end{smallcode}
-Specifies centering of all components on the faces which are orthogonal to the specified direction (Direction=0 means x, 1 means y, 2 means z). 
-That is, vertex-centering along direction \texttt{Direction}, and cell-centering along all other directions. 
-
-\begin{smallcode}
-typedef CartesianCentering<CommonCartesianCenteringEnums<Dim, NComponents,
-Direction>::allEdge, Dim, NComponents> allEdge ;
-\end{smallcode}
-Specifies centering of all components on the edges which are parallel to the specified direction (Direction=0 means x, 1 means y, 2 means z). That is, cell-centering 
-along direction Direction, and vertex-centering along all other directions. 
-
-\begin{smallcode}
-typedef CartesianCentering<CommonCartesianCenteringEnums<Dim, NComponents,
-Direction>::vectorFace, Dim, NComponents> vectorFace ;
-\end{smallcode}
-
-Specifies componentwise face centering of the components of a \texttt{Vector}. Usually you use this for centering a \ippl \texttt{Field} whose elements are \texttt{Vektor}'s. 
-For example,
-\begin{smallcode}
-Field<Vektor<double, 3>, 3,UniformCartesian<3>,CommonCartesianCenterings<3,3,3>>
-\end{smallcode}
-
-\section{\texttt{CartesianCentering} Class}
-The static \texttt{CartesianCentering} class represents the abstraction of component-wise centering of a multicomponent object (typically a \texttt{Field}) on a cartesian mesh. Via the template parameters, 
-the user specifies the centering of the various components along the various directions.
- 
-\subsection{CartesianCenteringDefinition(Public Interface)}
-\begin{smallcode}
-template<const CenteringEnum* CE, unsigned Dim, unsigned NComponents=1U>
-class CartesianCentering
-{
-public:
-static char* CenteringName; 
-static void print_Centerings(ostream&) ;
-};
-\end{smallcode}
- 
-\subsection{\texttt{CartesianCentering} Constructors}
-\texttt{CartesianCentering} is a static class, you don't instantiate objects, but rather only refer to it by its class name, with fully-specified template parameter values.
-If you have defined a static array of type \texttt{CenteringEnumcalled myCEArray}, the identifier \texttt{CartesianCenterings<myCEArray,3U,1U>} refers to the static class 
-representing centering on a 3D mesh of a scalar (one-component) object according to the centering specifiers in \texttt{myCEArray}. In this case, \texttt{myCEArray} would 
-have to have three elements (each having the value \texttt{CELL} or \texttt{VERT}). 
-In general, the number of elements in the array of \texttt{CenteringEnum} (the CE template parameter value) must equal the value of the \texttt{Dim} parameter multiplied by the value of the \texttt{NComponent} parameter. 
-The ordering of the elements is so that the component indices vary fastest, and the dimensions indices vary the slowest (like a 2D C array dimensioned as \texttt{[Dim][NComponent]}). 
-You must declare the \texttt{CenteringEnum} array you use as the value of the CE template parameter as static, and at global scope.
-
-\subsection{\texttt{CartesianCentering} Member Functions and Member Data} 
-All the member functions of \texttt{CartesianCentering} are of course static. Refer to them with the syntax \texttt{classname::membername}, where classname is, a name identifying aparticular \texttt{CartesianCentering} 
-class specialization, as described in this Appendix. 
-
-\begin{smallcode}
-static char* CenteringName ;
-\end{smallcode}
-A string containing a identifying name for a particular template instance of\\  \texttt{CartesianCentering}. Currently, there is only a single name, so that the value of 
-\texttt{CartesianCentering<CE,Dim,NComponent> }is the same for any values of the template parameters. 
-
-\begin{smallcode}
-static void print_Centerings(ostream&) ;
-\end{smallcode}
-Prints a formatted version of the \texttt{CartesianCentering} class. Specifically, it prints the values of the elements of the \texttt{CE} template parameter (as an array with \texttt{Dim*NComponents} elements).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/manual/ippl_fft.tex b/manual/ippl_fft.tex
deleted file mode 100644
index 2a4c326ae..000000000
--- a/manual/ippl_fft.tex
+++ /dev/null
@@ -1,58 +0,0 @@
-\chapter{FFT}
-\label{sec:fft}
-
-The FFT class provides an interface for performing parallel Fourier transforms of various types on \ippl \texttt{\texttt{Field}} objects. FFT is templated on the type of transform to perform (\texttt{CCTransform}, \texttt{RCTransform}, or \texttt{SineTransform}); the dimensionality \texttt{\texttt{Dim}} of the fields to be transformed, and the floating-point precision type (either \texttt{float} or \texttt{double}). It is capable of transforming along all dimensions of a \texttt{\texttt{Field}} or only specified dimensions, and it handles all of the data transposes required to make the Fourier transforms efficient automatically. The FFT constructor arguments vary slightly depending upon which type of transform you wish to perform. Generally speaking, you provide an {\tt NDIndex} object or objects which contain the domains of the input and/or output \texttt{Field}s for the Fourier transform, an optional array of bools of length \texttt{Dim} indicating which dimensions are to be transformed (default is all dimensions), and an optional bool indicating whether or not to compress the intermediate \texttt{Field}s needed to perform data transposes when they are not in use. The default value of this optional argument is false, but the user can set this argument to true if it is necessary to conserve memory. For a complex--to--complex Fourier transform, the input and output fields are of the same element type and are the same size, so only one domain argument is needed. So in the simple case of transforming all dimensions of a \texttt{Field} of type {\tt complex<double>}, we would construct the FFT object with the code
-\begin{smallcode}
-FFT<CCTransform,Dim,double> ccfft(domain); 
-\end{smallcode}
-where domain is an {\tt NDIndex<Dim>} describing the domain of complex \texttt{Field}s to be transformed with the FFT object.
-A real--to--complex Fourier transform takes a field of real numbers and returns a field of complex numbers (or vice-versa for an inverse complex--to--real transform), so we require separate domain arguments describing each \texttt{Field} in the FFT constructor. From the theory of Fourier mode analysis, we know that a Fourier transform of $N$ real numbers will produce $N/2+ 1$ unique complex modes, with modes $0$ and $N/2$ being purely real. Some FFT routines take advantage of the fact that if you pack together the real parts of modes $0$ and $N/2$ as one complex number, you can store all the resulting mode information in the same space as required for the input (i.e., $N$ real numbers or $N/2$ complex numbers). Such a technique tends to cause confusion in multidimensional real--to--complex FFTs, since mode data must then be separated out afterwards. So we choose a format in which the $N/2+ 1$ complex modes are stored separately as complex numbers. Thus, when a real--to--complex transform is performed on a {\tt \texttt{Field}} of doubles, the resulting {\tt \texttt{Field}} of type {\tt complex<double>} will have an extent one greater than half the length of the input field along the first dimension to be transformed and the same length along all other dimensions. This conformance of domains is checked by the FFT constructor. We might construct an FFT object for real--to--complex transforms with the line
-\begin{smallcode}
-FFT<RCTransform,Dim,double> rcfft(rdomain,cdomain,tdim); 
-\end{smallcode}
-where {\tt rdomain} and {\tt cdomain} are the conforming domains for the {\tt real} and {\tt complex} fields and {\tt tdim} is an array of bools indicating whether or not to transform each dimension. Note that we assume the axes of the field are to be transformed along in the order indicated by the domain arguments for a forward FFT and in the reverse order for an inverse FFT. Each \texttt{Index} object inside the provided domain should refer to a particular axis of the input \texttt{Field}, and these axes are transformed along in order. A sine transform is a special type of Fourier transform in which only the sine (odd) modes are retained. This transform has a field of real numbers for both its input and output, and its effect is to keep only that portion of the data which exhibits odd parity (i.e., vanishes at the endpoints of the interval). Typically, one wishes to enforce odd parity along one or more dimensions of a field, and then perform a standard real-to-complex transform along remaining dimensions. Hence, we require that the user provide two arrays of bools in the constructor: the first to indicate along which dimensions to perform a sine transform, and the second to indicate all of the transform dimensions (both sine transforms and standard FFTs). For example,
-\begin{smallcode}
-FFT<SineTransform,Dim,double> sinefft(rdomain,cdomain,sinedim,tdim);
-\end{smallcode}
- 
-
-constructs an FFT object for doing sine transforms along the dimensions indicated by sinedim and a standard real-to-complex FFT over the other dimensions included in tdim. Alternatively, such transforms could be achieved in two steps, doing the sine transforms and the standard FFTs separately. In this case, we might construct our sine transform FFT object with the code
-\begin{smallcode}
-FFT<SineTransform,Dim,double> sinefft2(rdomain,sinedim); 
-\end{smallcode}
-
-
-and then construct a second FFT object for handling the real-to-complex transform. Note that a sine transform FFT object which is doing only sine transforms requires only a single domain argument describing the real input and output \texttt{Field}s in its constructor.
-
-Once the appropriate FFT object has been constructed, a Fourier transform of data is invoked using the transform member function. The normal arguments to this function are an integer value of + 1 or -1 to indicate the sign of the exponential used in the transform (i.e., the direction of the transform, forward or inverse), and the input and output \texttt{Field}s. For this "two-field" form of the transform function, there is also an optional argument of type bool, which indicates whether or not the input \texttt{Field} is considered to be constant by the transform function. The default value of this optional argument is false, which allows the transform routine to attempt to use the input \texttt{Field} as temporary storage and avoid doing an additional data transpose. You should set the value of this argument to true if you must preserve the contents of the input \texttt{Field} for later use. We would use our previously constructed FFT object for real--to--complex transforms to perform a forward FFT in the following manner:
-\begin{smallcode}
-rcfft.transform(+l,realField,complexField);
-\end{smallcode}
- 
-
-The results of the transform are automatically normalized such that a forward transform followed by an inverse transform returns the original data. For convenience, the FFT class has a member function \texttt{setDirectionName} which allows you to associate a character string with each of the transform directions + 1 and -1. You might choose to refer to these directions as "xtok" and "ktox", for example.
-
-In the case of a complex-to-complex FFT or a pure sine transform; the input and output fields are the same size and of the same type. In these instances, we offer the option of performing the transform "in place"; that is, using just one \texttt{Field} argument for both the input and output. For example, we could perform an inverse complex-to-complex FFT with the code
-\begin{smallcode}
-ccfft.transform(-1,complexField2); 
-\end{smallcode}
-
-
-
-\subsection{Improving FFT Performance}
-Some improvement in performance of the transform method may be obtained by careful selection of the axis ordering of input and output \texttt{Field}s. In order to perform a parallel FFT along a particular dimension, the FFT object will first reorder the axes so that the first axis is the one to be transformed. It does this by assigning the field data into a new \texttt{Field} with a domain in which the order of the original \texttt{Index} objects has been permuted. This new \texttt{Field},
-which is maintained internally by the FFT class, has a data layout that is serial along this first dimension and parallel along all other dimensions. With this layout, each processor can independently perform FFTs along the serial axis for each of the one-dimensional strips of data it owns. To subsequently transform along another dimension, the FFT object must again transpose the data so that the next dimension to be transformed is now the first dimension and is serial. These data
-transposes can be fairly costly to perform. We can eliminate at least one data transpose if the output \texttt{Field} supplied by the user has the same layout characteristics needed for the final transform (or, in the case of an "in place" transform, if the input \texttt{Field} matches the layout needed for either the first or last transform), and has no guard cell layers. For instance, let us assume we have a three-dimensional \texttt{Field} of complex numbers and we want to transform
-all dimensions. If the \texttt{Index} objects {\tt I,J}, and {\tt K} describe the first, second, and third axes of our \texttt{Field} domain, we could perform a forward FFT with the line
-\begin{smallcode}
-ccfft.transform(+l,complexFieldl);
-\end{smallcode}
-
-If the first dimension of \texttt{complexField} is serial, the transform method will skip the first data transpose because the input data is already distributed appropriately for transforming along the first dimension. Similarly, if we were to call an inverse transform with this same \texttt{Field}, it would transform the axes in reverse order, and we would be able to skip the final data transpose. Alternatively, we might choose to do this FFT using separate input and output \texttt{Field}s:
-\begin{smallcode}
-ccfft.transform(+1,complexField1,complexField2); 
-\end{smallcode}
-In this case, the final optional argument to the "two-field" trans form function defaults to false, meaning that \texttt{complexFieldl} is not considered constant and may be used in place of a temporary \texttt{Field} to avoid the first data transpose. In addition, the output \texttt{Field} can be used in place of the final temporary \texttt{Field} if it has the proper layout. If \texttt{complexField2} has its axes reordered so that its first axis is the final axis to be transformed
-(e.g., \texttt{K}, then \texttt{I}, then \texttt{J}) and that first axis is serial, then we can skip the final data transpose. This choice of data layout results in a slightly faster parallel FFT, and it is often convenient if all you need to do is transform the data, do a brief computation with the transformed data, and then invert the transform.
-
-Another issue of relevance to the performance of the transform method is the type of routine used to perform the actual one-dimensional FFT. Currently, we provide two options for this. The first is Fortran 77 implementations of FFT routines from the Netlib repository. These are portable and highly optimized routines that we invoke via C++ wrapper functions. The second option (available only on SGI and Cray systems) is native FFT routines from the SGI/Cray Scientific Library. These routines can be substituted for the portable Netlib routines by supplying the option {\tt USE\_SCSL\_FFT} to the configure utility before compiling the \ippl library. These native library routines tend to be somewhat faster than the portable Fortran routines, and we plan to offer the ability to use native FFT routines such as FFTW in the future. 
diff --git a/manual/ippl_field_ref.tex b/manual/ippl_field_ref.tex
deleted file mode 100644
index 0b8996677..000000000
--- a/manual/ippl_field_ref.tex
+++ /dev/null
@@ -1,239 +0,0 @@
-\chapter{Fields}
-\label{sec:fields}
-The Field class represents the common computational science abstraction of a continuum (mathematical) field discretized on a mesh, 
-with some centering on that mesh. Used in it simplest, default, way with basic-type elements such as double's or float's. Field serves as a 
-multidimensional array class. Similarly, you can use collections of simple or not-so-simple instances of the Field class to represent almost any 
-data structure found in computational science; but this is against the philosophy of object-oriented design, in which you should design classes 
-to represent the physics/numerical-mathematics abstractions of the problem domain, rather than the data structures typically found in computer codes. 
-\section{Field Class Definition}
-The Field class is parameterized on the type  \texttt{T} of elements (typically a type like  \texttt{double,Vektor}, or \texttt{Tenzor}), dimensionality, mesh type, and centering on the mesh:
-\begin{smallcode}
-template<class T, unsigned Dim, 
-                  class Mesh=Cartesian, 
-                  class Centering=Mesh::DefaultCentering> 
-class Field : public FieldBase 
-\end{smallcode}
-\pagebreak
-\section{Field Constructors}
-To instantiate a \texttt{Field} we use the following of  Field constructors:
-\begin{smallcode}
-Field(FieldLayout<Dim>&); 
-Field (FieldLayout<Dim>&, const GuardCellSizes<Dim>&); 
-Field (FieldLayout<Dim>&, const BConds<T,Dim,Mesh,Centering>&); 
-Field (FieldLayout<Dim>&, const GuardCellSizes<Dim>&, 
-			const BConds<T,Dim,Mesh,Centering>&); 
-Field (FieldLayout<Dim>&, const BConds<T,Dim,Mesh,Centering>&, 
-			const GuardCellSizes<Dim>&); 
-\end{smallcode}
-\section{Field Member Functions and Member Data}
-
-\begin{smallcode}
-IndexingField<T,Dim,l,Mesh,Centering> operator[] (const Index& idx) 
-IndexingField<T,Dim,l,Mesh,Centering> operator[] (int i) 
-const iterator& begin() const { return Begin; } 
-const iterator& end() const { return End; } 
-void fillGuardCells() ; 
-const GuardCellSizes<Dim>& getGuardCellSizes() { return Allocated;  
-
-// Boundary condition handling. 
-unsigned leftGuard(unsigned d) 	{ return Allocated.left(d); } 
-unsigned rightGuard(unsigned d) 	{ return Allocated.right(d); } 
-const Index&: getIndex(unsigned d) { return Layout~>get_Domain() [d]; 
-const NDIndex<Dim>& getDomain() 	{returnLayout->get_Domain();} 
-
-// Definitions for accessing boundary conditions. 
-typedef BCondBase<T,Dim,Mesh,Centering> bcond_value; 
-typedef BConds<T,Dim,Mesh,Centering> bcond_container; 
-typedef bcond_container::iterator bcond_iterator; 
-bcond_value& getBCond(int bC);
-bcond_container& getBConds(){return *BC;} 
-\end{smallcode}
-
-\section{Operations on Field Objects}
-\subsection{Assignment}
-For the special case where there is only one term on the right-hand side of an assignment, the assignment operator can be utilized. 
-Examples of single term assignments include: 
-\begin{smallcode}
-unsigned Dim = 2,int N = 100; 
-Index I (N), J (N) ; 
-FieldLayout<Dim> layout(I,J)i Field<double,Dim> A(layout) , B(layout);
-A = 2.0;
-B = A; 
-\end{smallcode}
-For cases where more than one term exists on the right hand side of an assignment, the \texttt{assign()} call must be made. Any combination of scalars, \texttt{Field}'s,  \texttt{IndexingField}'s, and\texttt{ Index}'s
-can be put as the second argument of the \texttt{assign()} call. The only requirement in combining terms is that the appearance of an\texttt{ Index} object anywhere inside of an expression requires, 
-that all the \texttt{Field} contained in the expression must be indexed. It is not possible to combine \texttt{Field}'s and \texttt{IndexingField}'s in a single expression. 
-Nor is it possible to combine \texttt{Field}'s and \texttt{Index} objects in a single expression. The following examples define legal expressions: 
-\begin{smallcode}
-unsigned Dim = 2;
-int N = 100; 
-Index I(N), J(N); 
-FieldLayout<Dim> layout(I,J); 
-Field<double,Dim> A(layout) , B(layout) , C.(layout);
-
-assign(A, 2.0 + B); 
-assign(B , A + 2.0); 
-assign(B[I][J],3.0+B[I][J]); 
-assign(A[I][J] , I + A[I][J]/C[I][J]); 
-\end{smallcode}
-
-The following are examples of illegal expression:
-\begin{smallcode}
-B[I][J] = 3.0 + B[I][J]; 	// must use assign() with indexed Field~s, 
-assign(A, 2.0 + B[I][J]); // can't combine indexed Band non~indexed B 
-assign(B[I][J] , A + 2.0); 	// can't combine indexed B and non-indexed A 
-assign(A[I][J] , I + A/C[I][J]); // can't combine indexed C ,and non-indexed A 
-\end{smallcode}
-
-\subsection{Boundary Conditions}
-\ippl pre-defines classes to represent 7 different forms of boundary conditions: 
-\begin{enumerate}
-\item Periodic boundary condition: \texttt{PeriodicFace}
-\item Positive reflecting boundary condition: \texttt{PosReflectFace} 
-\item Negative reflecting boundary condition: \texttt{NegReflectFace} 
-\item Constant boundary condItion: \texttt{ConstantFace} 
-\item Zero boundary condition (special case of constant): \texttt{ZeroFace} 
-\item Linear extrapalation baundary condition: \texttt{ExtrapolateFace}
-\item none (should not be used) 
-\end{enumerate}
-Let's examine each boundary condition as applied to. the same shift operation. In each case, the first \texttt{assign()} invocation shows how the \texttt{Field A} with the following values: 
-\begin{center}
-        \begin{tabular}{|c|c|c|c|}
-        \hline
-        0 & 1 & 2 & 3 \\        \hline
-        1 & 2 & 3 & 4 \\        \hline
-        2 & 3 & 4 & 5 \\        \hline
-        3 & 4 & 5 & 6 \\        \hline	
-        \end{tabular}
-   \label{tbl:t1}
-   \end{center}
-The results after the second \texttt{assign()} invocation show how the boundary conditions on \texttt{A} affect the calculation. 
-For the first example, consider the case where each boundary of the \texttt{Field} object \texttt{A} has periodic boundary conditions: 
-
-\begin{smallcode}
-unsigned Dim = 2; 
-Index 1(4), J(4); 
-BConds<double,Dim> bc;
- 
-bc[0] = new PeriodicFace<double,Dim>(0); 
-bc[1] = new PeriodicFace<double,Dim>(1); 
-bc[2] = new PeriodicFace<double,Dim>(2);
-be[3] = new PeriodicFace<double,Dim>(3);
-
-FieldLayout<Dim> layout(I,J); 
-Field<double, Dim> A( layout, GuardCellSizes<Dim> (1) , bc) ; 
-Field<double,Dim> B(layout); 
-assign(A[I][J] ,I + J); 
-assign(B[I][J] ,A[I+l][J+l]) 
-\end{smallcode}
-This code segment produces the following values in the \texttt{Field B}: 
-\begin{center}
-        \begin{tabular}{|c|c|c|c|}
-        \hline
-        2 & 3 & 4 & 1 \\        \hline
-        3 & 4 & 5 & 2 \\        \hline
-        4 & 5 & 6 & 3 \\        \hline
-        1 & 6 & 3 & 0 \\        \hline	
-        \end{tabular}
-   \label{tbl:t2}
-   \end{center}
-In the case af the periodic boundary conditions, we see that the values wrap around the domain of the \texttt{Field} and pull values from the opposite side of the \texttt{Field} when the 
-indexing operations reference positions outside the domain. Note that the specification of a boundary condition above overrides the default behavior, which places zeroes into
-positions that attempt to obtain data from outside the domain. 
-
-Next we consider the case where positive reflecting boundary conditions are applied to each 
-boundary of the  \texttt{Field} object  \texttt{A} in the same shift operation: 
-\begin{smallcode}
-bc[0] = new PosReflectFace <double,Dim>(0); 
-bc[1] = new PosReflectFace <double,Dim>(1); 
-bc[2] = new PosReflectFace <double,Dim>(2);
-be[3] = new PosReflectFace <double,Dim>(3);
-
-assign(A[I][J] ,I+ J); 
-assign(B[I][J] ,A[I+1][J+1);
-\end{smallcode}
-This code segment produces the following values in \texttt{Field B}: 
-\begin{center}
-        \begin{tabular}{|c|c|c|c|}
-        \hline
-        2 & 3 & 4 & 4 \\        \hline
-        3 & 4 & 5 & 5 \\        \hline
-        4 & 5 & 6 & 6 \\        \hline
-         4 & 5 & 6 & 6 \\        \hline	
-        \end{tabular}
-   \label{tbl:t3}
-\end{center}
-In the case of the positive reflecting boundary conditions, we see that the values are simply reflected across the boundary over which the \texttt{Field} indexing operation occur. 
-This boundary condition is meant to represent Neuman boundary conditions in physical systems.
- 
-Next, consider the case where each boundary of the \texttt{Field} object \texttt{A} has negative reflecting boundary conditions:
-\begin{smallcode}
-bc[0] = new NegReflectFace <double,Dim>(0); 
-bc[1] = new NegReflectFace <double,Dim>(1); 
-bc[2] = new NegReflectFace <double,Dim>(2);
-be[3] = new NegReflectFace <double,Dim>(3);
-
-assign(A[I][J] ,I+ J); 
-assign(B[I][J] ,A[I+1][J+1]);
-\end{smallcode}
-This code segment produces the following values in \texttt{Field B}: 
-\begin{center}
-        \begin{tabular}{|c|c|c|c|}
-        \hline
-        2 & 3 & 4 & -4 \\        \hline
-        3 & 4 & 5 & -5 \\        \hline
-        4 & 5 & 6 & -6 \\        \hline
-         -4 & -5 & -6 & -6 \\        \hline	
-        \end{tabular}
-   \label{tbl:t4}
-\end{center}
-In the case of the negative reflecting boundary conditions, we see that the values are simply reflected across the boundary over which the \texttt{Field} indexing operation occur and negated. 
-This boundary condition is meant to represent Dirichlet boundary conditions in physical systems. 
-
-
-Next, consider the case where each boundary of the \texttt{Field} object \texttt{A} has constant boundary conditions: 
-\begin{smallcode}
-bc[0] = new ConstantFace <double,Dim>(0,9.0); 
-bc[1] = new ConstantFace <double,Dim>(1,9.0); 
-bc[2] = new ConstantFace <double,Dim>(2,9.0);
-be[3] = new ConstantFace <double,Dim>(3,9.0);
-
-assign(A[I][J] ,I+ J); 
-assign(B[I][J] ,A[I+1][J+1]);
-\end{smallcode}
-Note additional argument to the \texttt{constantFace} constructor. This argument represents the value which is to be fixed on the boundary in that direction. 
-The code segment above produces the following values in \texttt{Field B}: 
-\begin{center}
-        \begin{tabular}{|c|c|c|c|}
-        \hline
-        2 & 3 & 4 & 9 \\        \hline
-        3 & 4 & 5 & 9 \\        \hline
-        4 & 5 & 6 & 9 \\        \hline
-         9 & 9 & 9 & 9 \\        \hline	
-        \end{tabular}
-   \label{tbl:t5}
-\end{center}
-In the case of the constant boundary conditions, we see that a fixed value is shifted into the domain across the boundary over which the \texttt{Field} indexing operation occur. 
-
-Finally, consider the case where the \texttt{Field} object \texttt{A} has mixed boundary conditions, boundary-by-boundary (i.e., face-by-face): 
-\begin{smallcode}
-be[0] = new PeriodicFace <double,Dim>(0); 
-be[1] = new PeriodicFace <double,Dim>(1); 
-be[2] = new PosReflectFace <double,Dim>(2); 
-be[3] = new NegReflectFace <double,Dim>(3);
-assign(A[I][J] ,I+ J); 
-assign(B[I][J] ,A[I+1][J+1]);
-\end{smallcode}
-The code segment above produces the following values in \texttt{Field B}: 
-\begin{center}
-        \begin{tabular}{|c|c|c|c|}
-        \hline
-        2 & 3 & 4 & 1 \\        \hline
-        3 & 4 & 5 & 2 \\        \hline
-        4 & 5 & 6 & 3 \\        \hline
-         -4 & -5 & -6 & -3 \\        \hline	
-        \end{tabular}
-   \label{tbl:t6}
-\end{center}
-
-
diff --git a/manual/ippl_fieldlayout_ref.tex b/manual/ippl_fieldlayout_ref.tex
deleted file mode 100644
index 1f5dbbfae..000000000
--- a/manual/ippl_fieldlayout_ref.tex
+++ /dev/null
@@ -1,305 +0,0 @@
-\chapter{FieldLayout Class}
-\label{sec:flcl}
-The \texttt{FieldLayout} class represents the abstraction of a decomposition of a Field object into pieces (subsets of elements). The number of pieces need not be, but typically is, greater than or equal to the number of physical processors or cores used to run the \ippl program in parallel. This is a decomposition in the sense that the parallel computing literature talks about domain decomposition. The Field object represents a mathematical 
-field discretized on a spatial domain, each piece of it is a subdomain. Equivalent to the actual spatial subdomain is the subset of the index space of the discretization. Currently in \ippl, these subsets are contiguous, stride-1 subranges of the global (N -dimensional) index space. Other \ippl mechanisms assign each sub domain to a processor or core. The \texttt{FieldLayout} class provides mechanisms for specifying decomposition, and has two relationships with the \texttt{Field} class: \texttt{Field} uses a \texttt{FieldLayout} reference and invokes its mechanisms to manage the distribution of its data, and \texttt{FieldLayout} maintains a container of pointers to all the 
-\texttt{Field}'s it is used by. When the user requests that a \texttt{FieldLayout} be redistributed, the \texttt{FieldLayout} goes through its list of Field pointers and tells the 
-\texttt{Field}' s to effect the redistribution of their data. 
-\section{FieldLayout Definition (Public Interface)} 
-
-\begin{smallcode}
-// enumeration used to select serial or parallel axes 
-enum e_dim_tag { SERIAL=O, PARALLEL=l } 
-
-// A base class for FieldLayout that is independent of dimension. 
-
-class FieldLayoutBase 
-{ 
-private: 
-// Some dummy storage so that it doesn't confuse purify. 
-char Dummy; 
-
-public: 
-
-FieldLayoutBase() : Dummy(0) {} 	
-};
-
-template<unsigned Dim>
-class FieldLayout public FieldLayoutBase { 
-public: 
-
-// Typedefs'for containers. 
-
-typedef vmap<Unique::type,my_auto_ptr<Vnode<Dim> > >ac_id_vodes;
-typedef DomainMap<NDIndex<Dim>,RefCountedP< Vnode<Dim> >,
-                                       Touches<Dim>,Contains<Dim>,
-                                       Split<Dim> > ac_domain_vnodes;
-typedef vmap<GuardCellSizes<Dim>,my_auto_ptr<ac_domain_vnodes> > 
-	     ac_gc_domain_vnodes; 
-
-typedef vmap <Unique::type,FieldBase*> ac_id_fields;
-
-// Typedefs for iterators. 
-
-typedef ac_id_vodes::iterator iterator_iv;
-typedef ac_id_vodes: :const_iterator const_iterator_iv; 
-typedef ac_domain_vnodes::iterator iterator_dv; 
-typedef ac_domain_vnodes::touch_iterator touch_iterator_dv; 
-typedef pair<touch_iterator_dv,touch_iterator_dv> touch_range_dv; 
-typedef ac_id_fields::iterator iterator_if;
-typedef ac_id_fields::const_iterator const_iterator_if; 
-typedef ac_gc_domain_vnodes: :iterator iterator_gdv; 
-public: 
-
-// Accessors for the locals by Id. 
-ac_id_vnodes: : size_type size_iv(); 
-iterator_iv begin_iv(); 
-iterator_ivend_iv(); 
-const_iterator_iv begin_iv() const; 
-const_iterator_iv end_iv() const; 
-
-// Accessors for the remote vnode containers. 
-ac_gc_domain_vnodes::size_type size_rgdv(); 
-iterator_gdv begin_rgdv(); 
-iterator_gdvend_rgdv(); 
-
-// Accessors for the remote vnodes themselves. 
-ac_domain_vnodes::size_type size_rdv( const GuardCellSizes<Dim>& gc = gc0()) ;
- 
-iterator_dv begin_rdv(const GuardCellSizes<Dim>& gc = gcO()); 
-iterator_dv end_rdv(const GuardCellSizes<Dim>& gc= gcO()); 
-touch_range_dv touch_range_rdv(const NDIndex<Dim>& domain, 
-		const GuardCellSizes<Dim>& gc = gcO()); 
-
-// Accessors for the fields declared on this 
-// FieldLayout. ac_id_fields:.: size_type size_if () ; 
-iterator_if begin_if () ; 
-iterator_ifend_if(); 
-const_iterator_if begin_if() const; 
-const_iterator_if end_if() const; 
-
-// Tell the FieldLayout that a FieldBase has been declared on it
-void checkin(FieldBase&f, const GuardCellSizes<Dim>& gc= gcO()); 
-// Tell the FieldLayout that a FieldBase is no longer using it. 
-
-void checkout(FieldBase& f); 
-
-// Compare FieldLayouts to see if they represent the same domain. 
-
-bool operator==(const FieldLayout<Dim>& x) 
-{ 
-return Domain == x.Domain; 
-}
-// Constructors. 
-// Default constructor, which should only be used if you are going to 
-// call 'initialize' soon after (before using in any context) 
-
-FieldLayout() { } 
-
-//Constructorsfor 1 ... 6 dimensions 
-
-FieldLayout(const Index& il, e_dim_tag pl=PARALLEL, int vnodes=-1); 
-
-FieldLayout(const Index&il, const Index& i2, e_dim_tag pl=PARALLEL, 
-			e_dim_tag p2=PARALLEL, int vnodes=-1); 
-
-FieldLayout(const Index& il, const Index& i2, const Index& i3,
-e_dim_tag pl=PARALLEL, e_dim_tag p2=PARALLEL, e_dim_tag p3=PARALLEL, int vnodes=-1); 
-
-FieldLayout(const Index& il, const Index& i2, const Index& i3, 
-const Index& i4, e_dim_tag pi = PARALLEL , e_dim_tag p2 = PARALLEL , e_dim_tag p3=PARALLEL, 
-e_dim_tag p4=PARALLEL, int vnodes=-1) ; 
-
-FieldLayout(const Index& il, const Index& i2, const Index& i3,
-const Index& i4, const Index& i5, e_dim_tag pl=PARALLEL, e_dim_tag p2=PARALLEL, 
-e_dim_tag p3=PARALLEL, e_dim_tag p4=PARALLEL, e_dim_tag p5=PARALLEL, int vnodes=-1) ; 
-
-FieldLayout(const Index& il, const Index& i2, const Index& i3, 
-const Index&i4, const Index& is, const Index& i6, e_dim_tag pl=PARALLEL, e_dim_tag. p2=PARALLEL, 
-e_dim_tag p3=PARALLEL, e_dim_tag p4=PARALLEL, e_dim_tag pS = PARALLEL , 
-e_dim_tag p6=PARALLEL, int vnodes=-1);
-
-// Next we have one for arbitrary dimension. 
-FieldLayout(const NDIndex<Dim>& domain, e_dim_tag *p==O, int vnodes"=-1)
-{ initialize (domain,p,vnodes) ; 
-
-//Build a FieldLayout given the whole domain and 
-//begin and end iterators for the set of domains for the local Vnodes. 
-//It does a collective computation to find the remote Vnodes. 
-
-FieldLayout(const NDIndex<Dim>& Domain, NDIndex<Dim>* begin, NDIndex<Dim>* end); 
-
-// initialization functions, for use when the FieldLayout was created using the default constructor. 
-void initialize(const Index& il, e_dim_tag pl=PARALLEL,int vnodes=-1); 
-
-void initialize(const Index& il, const Index& i2, e_dim_tag pl=PARALLEL, 
-		e_dim_tag p2=PARALLEL, int vnodes=-l);
-
-void initialize{const Index& il, const Index& i2. const Index& i3, e_dim_tag pl=PARALLEL, 
-		e_dim_tag p2=PARALLEL, e_dim_tag p3=PARALLEL, int vnodes=-1);
-
-void initialize(const Index& il, const Index&i2, const Index& i3, const.Index& i4, 
-	e_dim_tag pl=PARALLEL, e_dim_tag p2=PARALLEL, 
-	e_dim~tag p3=PARALLEL, e_dim_tag p4=PARALLEL, int vnodes=-1);
-
-void initialize(const Index& il,.const Index&, i2, Cbnst Index& i3, const Index& i4, 
-const Index& is, e_dim_tag pl=PARALLEL, 
-e_dim_tag p2=PARALLEL, e_dim_tag p3=PARALLELi e_dim_tag p4=PARALLEL, 
-e_dim_tag pS = PARALLEL , int vnodes=-1); 
-		
-void initialize(const Index& il, constIndex& i2, const Index& i3, const Inde.x& i4, const Index& is, 
-const Index& i6, e_dim_tag pl=PARALLEL,e_dim_tag p2=PARALLEL, e_dim tagp3=PARALLEL, 
-e_dim_tag p4=PARALLEL, e_dim_tag p5=PARALLEL, e_dim_tagp6=PARALLEL, int vnodes=-1);
- 
-void initialize(const NDIndex<Dim>& domain, e_dim_tag *p=O" int vnodes=-1);
-
-// Let the user set the local vnodes. 
-// this does everything necessary to realign all the fields associated with this FieldLayout! 
-// It inputs begin and end iterators for the local vnodes. 
-
-void Repartition(NDIndex<Dim>*,NDIndex<Dim>*);
-
-void Repartition(NDIndex<Dim>& domain)
-{ 
-Repartition(&domain, (&domain) +1);
-}
-
-// Destructor: Everything deletes itself automatically, 
-// except we must tell all the registered FieldBase's we're going away.
-~FieldLayout();
- 
-// Return the domain. 
-constNDIndex<Dim>& getDomain() const { return Domain; } 
-
-// Print it out. 
-void write (ostream&) const;
-friend ostream& operator<<(ostream&, const FieldLayout<Dim>&);
-};
-
-\end{smallcode}
-
-\section{FieldLayout Constructors}
- 
-\texttt{FieldLayout} is parameterized on (\texttt{unsigned}) dimensionality, having the same meaning as the dimensionality template parameter for the \texttt{Field} class. 
- When constructing a \texttt{FieldLayout} object, you must specify the index range for each dimension (or axis). To do this, you can 
-	use a single \texttt{NDIndex} object:
-  
-\begin{smallcode}
-index I(S), J(9), K(4); 
-NDIndex<3> Domain(l, J, K);
-FieldLayout<3> Layout(Domain);
-\end{smallcode}
-For \texttt{FieldLayout}'s of $N$ dimensions up to six, you may instead specify $N$ Index objects to the constructor of \texttt{FieldLayout} directly, without creating an \texttt{NDIndex} object: 
-\begin{smallcode}
-Index l(5), J(9), K(4);
-FieldLayout<3> Layout (I, J, K); 
-\end{smallcode}
-
-\subsection{Specifying Serial or Parallel Layout}
-'By default, \texttt{FieldLayout} will attempt to distribute the data among the processors (vnodes, actually) by subdividing each dimension in turn until it has the proper number of subregions. 
-Those axes which are considered for subdivision are the parallel axes, which means that a given node will only contain \texttt{Field} data for a subset of the indices along that dimension. 
-You can, however, tell \texttt{FieldLayout} which axes to subdivide, and which to maintain as serial. Serial axes are not ever partitioned by \texttt{FieldLayout}. 
-You must have at least one parallel dimension in a given \texttt{FieldLayout}; by default, all axes are parallel. 
-To specify things, use the predefined enumeration \texttt{e\_dim\_tag}, which has values \texttt{SERIAL} and \texttt{PARALLEL}. When you pass a \texttt{NDIndex<Dim>} as the\\ \texttt{FieldLayout} 
-constructor argument, you pass an array of \texttt{e\_dim\_tag} values, having length Dim. When you construct a \texttt{FieldLayout} with $N$ \texttt{Index}  arguments, you may also include 
-up to $N$ more arguments of type \texttt{$e\_dim\_tag$} to set the corresponding dimensions  layout methods; any omitted dimensions at the end of the list default to \texttt{PARALLEL}. 
-Refer to the first few chapters of this report for appropriate examples. 
-
-\section{FieldLayout Member Functions and Member Data}
-\subsection{Access Functions to Containers in \texttt{FieldLayout}}
-The \texttt{Index} class has several private members whose types are parameterized container classes patterned after STL containers. These have STL-like semantics, including iterators. 
-The container objects themselves are private, but the user has public access to their sizes and iterators over them via \texttt{Index} public member functions. 
-\texttt{Index} provides some typedef's to make this access easier: 
-
-\begin{smallcode}
-typedef vmap<unique: type,my_auto_ptr<Vnode<Dim> > > ac_id_vnodes;
-\end{smallcode}
-Type for \texttt{FieldLayout}'s container of pointers to \texttt{Vnode} objects; the \ippl internal \texttt{Vnode} class represents the vnode, or index-space subdomain in this context. 
-The number of subdomains is equal to the number of vnodes, and\\ \texttt{FieldLayout}' s serial/parallel specification determines the extents of the subdomains in \texttt{Index} space.
-
-
- 
-\begin{smallcode}
-typedef DomainMap<NDIndex<Dim>,RefCountedP< Vnode<Dim> >, 
-Touches<Dim>,Contains<Dim>,Split<Dim> > ac_domain_vnodes; 
-typedef vrnap<GuardCellSi~es<Dim>, my_auto_ptr<ac_domain_vnodes> > ac_gc_domain_vnodes; 
-\end{smallcode}
-The first of these typedef's is only used inside the second. 
-\begin{smallcode}
-typedef vmap<Unique::type,FieldBase*> ac_id_fields;
-\end{smallcode}
-Type for \texttt{FieldLayout}'s container of pointers to \texttt{Field}'s using this \texttt{FieldLayout} object, mentioned in the general discussion anhe beginning of this chapter. 
-
-\begin{smallcode}
-typedef ac_id_vnodes: :iterator iterator_iv;
-typedef ac_id_vnodes: :const_iteratorconst_iterator_iv;
-typedef ac_domain_vnodes::iterator iterator_dv;
-typedef ac_domain_vnodes::touch_iterator touch_iterator_dv;
-typedef pair<touch_iterator_dv,touch_iterator_dv> touch_range_dv;
-typedef ac_id_fields::iterator iterator_if;
-typedef ac_iQ._fields::const_iterator const_iterator_if; 
-typedef ac_gc_domain_vnodes::iterator iterator_gdv;
-\end{smallcode}
-
-More to come ..... 
-
-
-
-\chapter{\texttt{CenteredFieldLayout} Class}
-\label{sec:flcent}
-The \texttt{CenteredFieldLayout} class inherits from \texttt{FieldLayout}. It represents the same abstraction as \texttt{FieldLayout}, except specialized to a particular type of 
-centering on a particular type of  \texttt{Mesh}; it is parameterized on mesh type and centering type. 
-These template parameters have the same meaning as the corresponding parameters for the \texttt{Field} class. \\
-The primary use of  \texttt{CenteredFieldLayout} is for guaranteeing correct specification of numbers of elements in 
-\texttt{Field}'s along the various dimensions according to the centering along those dimensions. The \texttt{Mesh} object reference constructor arguments provide for this. 
-\section{\texttt{CenteredFieldLayout} Definition (Public Interface)}
-\begin{smallcode}
-template<unsigned Dim, class Mesh, class Centering> 
-class CenteredFieldLayout : public FieldLayout<Dim> { 
-public: 
-//-------------~--------~----------------------~----~----------------------- 
-// Constructors from a mesh object only and parallel/serial specifiers. 
-//--------------------~---------------------~------------------------------- 
-// Constructor for arbitrary dimension with parallel/serial specifier array: 
-//This one also works if nothing except mesh is specified: 
-
-CenteredFieldLayout(Mesh& mesh, e_dim_tag *p=0, int vnoqes=-1);
- 
-// Constructors for 1 ... 6 dimenslons with parallel/serial specifiers: 
- 
-CenteredFieldLayout(Mesh& mesh, e_dim_tag pI, int vnodes=-1); 
-CenteredFieldLayout(Mesh& mesh, e_dim_tagpI, e_dim_tag p2, int vnodes=-1);
-CenteredFieldLayout(Mesh& mesh, e_dim_tag pI, e_dim_tag p2, e_dim_tag p3, int vnodes=-1); 
-CenteredFieldLayout(Mesh&mesh, e_dim_tag pI, e_dim_tag p2, e_dim_tag p3, 
-e_dim_tag p4, int vnodes=-1);
-CenteredFieldLayout(Mesh&mesh, e_dim_tag pI, e_dim_tag p2, e_dim_tag p3, 
-e_dim_tag p4, e_dim_tag p5, int vnodes=-1);
-CenteredFieldLayout(Mesh& mesh,e_dim_tag pI, e_dim_tag p2, e_dim_tag p3, 
-e_dim_tag p4, e_dim_tag p5, e_dim_tag p6, int vnodes=-1); 
-};
-\end{smallcode}
-\section{\texttt{CenteredFieldLayout} Constructors}
-
-Here is where \texttt{CenteredFieldLayout} differs from \texttt{FieldLayout}. Instead of taking \texttt{NDIndex\&} or \texttt{Index\&} arguments to specify the numbers of elements along the 
-various dimensions, the constructors take an argument having the type ofthe \texttt{Mesh} template parameter. This might be, for example, a \texttt{UniformCartesian} object reference. 
-\texttt{CenteredFieldLayout} queries the mesh object for numbers of grid nodes arid sets up the right number of elements for subsequent \texttt{Field} objects instantiated to use this \texttt{CenteredFieldLayout}.
-There are implementations for \texttt{Cell}, \texttt{Vert}, and \texttt{Cartesian} centerings on \texttt{UniformCartesian} and \texttt{Cartesian} meshes. 
-If you are not providing a \texttt{Mesh} object to construct a \texttt{CenteredFieldLayout}, you probably should be just using simple \texttt{FieldLayout} objects instead, though no harm would be done by constructing a \texttt{CenteredFieldLayout} with \texttt{Index/NDIndex} arguments via the inherited constructors from \texttt{FieldLayout}. Refer to Appendix \ref{sec:flcl} for more details about \texttt{FieldLayout}. Other than these different constructors, \texttt{CenteredFieldLayout} is the same as \texttt{FieldLayout}. 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/manual/ippl_fields.tex b/manual/ippl_fields.tex
deleted file mode 100644
index 608f6c591..000000000
--- a/manual/ippl_fields.tex
+++ /dev/null
@@ -1,646 +0,0 @@
-\chapter{Using the \texttt{Field} and Related Classes}
-
-This section introduces the interface of the \texttt{Field} class and related classes. We describe how
-to instantiate \texttt{Field} objects, use \texttt{Index} objects to perform index operations, perform expression
-operations with overloaded operators, apply boundary conditions, use the where construct for
-conditionals, invoke reduction operations, and use mathematical functions.
-
-\section{\texttt{Field} Object Instantiation}
-
-\subsection{\texttt{Field} Template Parameters} \label{sec:tmpl_params}
-
-The \texttt{Field} class is parametrized on 4 template parameters: type \texttt{T}, dimensionality \texttt{Dim},
-mesh type \texttt{Mesh}, and centering \texttt{Centering}.
-\begin{smallcode}
-Field<class T, unsigned Dim, class Mesh=UniformCartesian<Dim,MFLOAT=doub1e>,
-      class Centering=Mesh::DefaultCentering>
-\end{smallcode}
-The \texttt{T} parameter represents the type of data that can be stored inside of a \texttt{Field}. Currently,
-the \texttt{Field} class supports the intrinsic types \texttt{bool, int, float, double}. One may use any
-user-defined type or class as the template parameter; however, one must also add traits to the
-framework to implement the desired data-parallel promotion properties so that \texttt{Field} operations
-work. The framework includes 
-\begin{smallcode}
-Vektor<Dim, T>, Tenzor<Dim , T>, SymTenzor<Dim, T> 
-\end{smallcode}
-classes\footnote{The strange spellings avoid conflicts with other classes such as the STL vector class.}
-, which are (mathematical) vectors, tensors, and symmetric tensors whose
-elements are of type \texttt{T}. Traits are implemented in these classes so that they may serve as elements
-of fully-functional \texttt{Field} objects.
-The \texttt{Dim} parameter represent the dimensionality of the \texttt{Field} that is being constructed. This
-must correspond to the \texttt{Dim} parameters in all other objects used to construct the \texttt{Field}.
-The \texttt{Mesh} parameter represents the mesh on which the field is discretized. \ippl
-pre-defines two appropriate classes (\texttt{Cartesian} and \texttt{UniformCartesian}) to use for this
-parameter, one of which serves as the default value of the \texttt{Field} ``Mesh'' template parameter:
-\texttt{UniformCartesian<Dim, double>}. Refer to the \ippl User Refercnce for details on the
-\texttt{UniformCartesian} class; basically, it represents a \texttt{Cartesian} mesh with uniform grid spacings. 
-The \texttt{Cartesian} class represents a cartesian mesh with nonuniform grid spacings. NB.:
-the type parameter \texttt{MFLOAT} for \texttt{Cartesian} represents only the data type used to store internal
-information like mesh spacing values; if \texttt{double} satisfies the user, he need not specify it.
-
-The \texttt{Centering} parameter represents the centering of the field on its mesh. \ippl
-pre-defines \texttt{Cell} and \texttt{Vert} classes to represent cell and vertex centering, and has implementations 
-of appropriate mechanisms for \texttt{Cartesian} and other classes which use them. \ippl
-also predefines a \texttt{CartesianCentering} class to represent more general centerings--combinations 
-of vertex and cell centering direction-by-direction and component-by-component for
-\texttt{Field}s with multicomponent element types such as \texttt{Vektor}. Finally, \ippl predefines a
-wrapper class \texttt{CommonCartesianCenterings} with typedef’s several common special
-cases to represent face and edge centerings, for example, refer to the \ippl User Reference
-for details.
-
-\subsection{Invoking the \texttt{Field} Constructor} \label{sec:inv_field}
-
-There are six steps in the general construction of a \texttt{Field}:
-\begin{enumerate}
-    \item Construct \texttt{Index} objects, one for each dimension of the \texttt{Field}. The \texttt{Index} objects describe the desired index domain along the axis.
-    \item Construct an \texttt{NDIndex} object with the dimensions of the \texttt{Field}. A single \texttt{NDIndex} object contains N \texttt{Index} objects, and fully describes the total index domain.
-    \item Populate the \texttt{NDIndex} with the \texttt{Index} objects created in step 1.
-    \item Construct a \texttt{FieldLayout} object with the \texttt{NDIndex} object. The \texttt{FieldLayout} object will control how the data of a specified \texttt{Field} object will be partitioned among physical nodes in a parallel environment.
-    \item If desired, construct \texttt{BConds} and \texttt{GuardCellSizes} objects for specifying boundary conditions and guard-cell layers, respectively. If unspecified, these default to no-op and zero.
-    \item Finally, construct a \texttt{Field} with the \texttt{FieldLayout}, \texttt{BConds}, and \texttt{GuardCellSizes} object as arguments to the constructor. This target \texttt{Field} must be parametrized as described in Section \ref{sec:tmpl_params}. The \texttt{Dim} template parameter must match the one for the \texttt{FieldLayout} and other objects involved, or you will get a compiler error.
-\end{enumerate}
-
-For the cases of a 1,2, or 3 dimensional \texttt{Field}, you may omit steps 2 and 3; instead directly pass the one, two, or three \texttt{Index} objects as arguments to the \texttt{FieldLayout()} constructor. The \texttt{Dim} template parameter must match the number of \texttt{Index} objects passed or you will get a compiler error.
-
-The following code segment demonstrates the construction of a single two dimensional \texttt{Field} of \texttt{double}'s using the six-step method described above: \\
-\begin{code}
-unsigned Dim = 2;
-int Nx = 100, Ny = 50;
-Index I(Nx), J(Ny)l                 // Step 1
-NDIndex<Dim> domain;                // Step 2
-domain[0] = I;                      // Step 3
-domain[1] = J;                      // Step 3
-FieldLayout<Dim> layout(domain);    // Step 4
-Field<double, Dim> A(layout);       // Step 5
-\end{code}
-
-The following three examples show the construction of a 3 dimensional \texttt{Field} without the intermediate \texttt{NDIndex} construction:
-\begin{smallcode}
-Index I(100), J(5), K(25);
-FieldLayout<3> layout(I,J,K);
-Field<double, 3> A(layout);
-\end{smallcode}
-
-You may also construct \texttt{Field} via copy constructor, wherein a \texttt{Field} is copied into another \texttt{Field}. This results in an element-by-element copy of the data: 
-\begin{smallcode}
-// assuming we have constructed a 2D Field of doubles in A
-A = 2.0;
-Field<double, Dim> B(A);
-// B now contains the values 2.0 everywhere
-\end{smallcode}
-
-\section{The \texttt{Index} Class}
-
-The \texttt{Index} class represents a strided range of indices, and it is used to define the index extent of \texttt{Field} objects on construction and to reference subranges within \texttt{Field}'s in expressions. The constructor for \texttt{Index} takes one, two or three int arguments. In the case of three arguments, these represent the base index value, the bounding index value and the stride. The two and one-argument cases are simplifications, with the one-argument case being qualitatively different; in
-particular,
-\begin{smallcode}
-Index I(8);
-\end{smallcode}
-instantiates an \texttt{Index} object representing the range of integers from $0$ to $7$ inclusive, with implied stride $1$. The two-argument
-\begin{smallcode}
-Index J(2,8);
-\end{smallcode}
-instantiates an \texttt{Index} object representing the range of integers $[2,8]$, with implied stride 1. The three-argument
-\begin{smallcode}
-Index K(1,8,2);
-\end{smallcode}
-instantiates an \texttt{Index} object representing the range of integers $[1,8]$, with stride 2; that is the ordered set $\{1,3,5,7\}$.
-
-Note that the single argument in the one-argument case defines the number of elements, rather than the bound. This means that \texttt{Index J(8)}, which represents $[0,7]$, is different than \texttt{Index J(0,8)} and \texttt{Index J(0,8,1)}, which both mean $[0,8]$.
-
-As illustrated in Section \ref{sec:inv_field}, you use \texttt{Index}'s in constructing the \texttt{FieldLayout} object which goes into the \texttt{Field} constructor. The sizes of the \texttt{Index}'s used to construct the \texttt{FieldLayout} determine the size of the \texttt{Field} in each dimension; here size means the number of integers in the range represented by the \texttt{Index}. For example, the following code segment instantiates a 3-dimensional \texttt{Field A} having size 5 in the first dimension, size 9 in the second dimension, and size 4 in the
-third dimension: \\
-\begin{code}
-unsigned Dim = 3;
-int Nx = 5;
-int Ny = 9;
-int Nx = 4;
-Index I(Nx), J(Ny), K(Nz);
-FieldLayout<Dim> layout(I,J,K);
-Field<double, Dim> A(layout);
-\end{code}
-
-You can also use \texttt{Index} objects for initializing \texttt{Field} elements with integer ranges of values. This and more typical use of \texttt{Index} object in conjunction with \texttt{Field} objects is discussed in Section \ref{sec:index_fields}.
-
-Finally, \ippl defines various operators on \texttt{Index} objects, mostly used to represent finite-different stencil operations on \texttt{Field}'s, as described in Section \ref{sec:index_fields}. If
-\begin{smallcode}
-Index I(8);
-\end{smallcode}
-is an \texttt{Index} object representing $[0,7]$, then the expression
-\begin{smallcode}
-I - 1
-\end{smallcode}
-represents the range of the same length offset by $-1$, or $[-1,6]$. Similarly, the expression
-\begin{smallcode}
-I + 1
-\end{smallcode}
-represents $[2,8]$.
-
-\section{The \texttt{NDIndex} Class}
-
-The \texttt{NDIndex} class is primarily a container which holds \texttt{N} \texttt{Index} objects. It is templated on the spatial dimension \texttt{N}, and the constructor takes \texttt{N} \texttt{Index} arguments. For example: 
-\begin{smallcode}
-Index I(5), J(9), K(4);
-NDIndex<3> Domain(I, J, K);
-\end{smallcode}
-
-An \texttt{NDIndex} object appears as an array of \texttt{Index} objects; you may access the \texttt{Index} object for and dimension using the \texttt{[]} operator. For example:
-\begin{smallcode}
-Index tmpJ = Domain[1];
-\end{smallcode}
-
-\section{The \texttt{FieldLayout} Class}
-
-\texttt{FieldLayout} is the class responsible for determining where the data in a \texttt{Field} object is located. It is templated on the number of indices for the \texttt{Field}; when constructing a new \texttt{FieldLayout} object, you must tell it what is the index range for each dimension (or axis). A single \texttt{NDIndex} object may be used as the argument to a new \texttt{FieldLayout} instance:
-\begin{smallcode}
-Index I(5), J(9), K(4);
-NDIndex<3> Domain(I, J, K);
-FieldLayout<3> Layout(Domain);
-\end{smallcode}
-Or, possibly more conveniently, you may just specify the N \texttt{Index} objects to the constructor of the \texttt{FieldLayout} directly, without explicitly creating an \texttt{NDIndex} object:
-\begin{smallcode}
-Index I(5), J(9), K(4);
-FieldLayout<3> Layout(I, J, K);
-\end{smallcode}
-
-\subsection{Specifying Serial or Parallel Layout}
-
-By default, a \texttt{FieldLayout} object will partition all \texttt{N} dimensions in a parallel fashion. For example a 2D \texttt{Field} with indices running from $0 \ldots 5$ in each dimension, created with a \texttt{FieldLayout} specified as follows:
-\begin{smallcode}
-Index I(6), J(6);
-FieldLayout<3> Layout(I, J);
-\end{smallcode}
-will have both the \texttt{I} and \texttt{J} indices partitioned across the nodes in parallel. This would lead to a layout something like that shown in the following figure, if there are four nodes:
-
-TODO: BILD
-
-Unless you tell it otherwise, \texttt{FieldLayout} will attempt to distribute the data among the processors by subdividing each dimension in turn until it has the proper number of subregions. Those axes which are considered for subdivision are the \textit{parallel} axes, which means that a given node will only contain \texttt{Field} data for a subset of the indices along that dimension. You can, however, tell \texttt{FieldLayout} which axes to subdivide, and which to maintain as \textit{serial}. Serial axes are
-not ever partitioned by \texttt{FieldLayout}. You must have at least on parallel dimension in a given \texttt{FieldLayout}; by default, all axes are parallel.
-
-To specify serial axes, you provide additional arguments to the \texttt{FieldLayout} constructor, using the keywords \texttt{SERIAL} or \texttt{PARALLEL}. If you create a new \texttt{FieldLayout} by just specifying \texttt{N} \texttt{Index} objects, then you may provide up to \texttt{N} more arguments to the constructor to set the corresponding dimension's layout method. For example, we may change the earlier example of a 2D \texttt{Field} to have the second dimension use a serial layout as follows:
-\begin{smallcode}
-Index I(6), J(6);
-FieldLayout<3> Layout(I, J, PARALLEL, SERIAL);
-\end{smallcode}
-In this case, the data would be partitioned into four subregions like the following (the horizontal direction is the first dimension, the vertical direction the second)
-
-TODO: BILD
-
-If an \texttt{NDIndex} object is used to create the \texttt{FieldLayout} instead of several \texttt{Index} objects, to change the default layout style you must instead provide an array of keywords (of type \texttt{e\_dim\_tag}) specifying the layout for the \texttt{N} dimensions. For example: \\
-\begin{code}
-Index I(5), J(9), K(4);
-NDIndex<3> Domain(I, J, K);
-e_dim_tag ParallelMethod[2];
-ParallelMethod[0] = PARALLEL;
-ParallelMethod[1] = SERIAL;
-ParallelMethod[2] = SERIAL;
-FieldLayout<3> Layout(Domain, ParallelMethod);
-\end{code}
-
-\section{Boundary Condition Classes}
-
-One of the great frustrations in using data parallel objects is the proper representation of boundary conditions. Most data parallel environments (such as HPF or CMFortran) require that one perform special operations to observe periodic or reflected behaviour at the boundary. This requirement obscures the original clarity of the index notation. You construct \texttt{Field} objects within the \ippl framework using \texttt{BConds} boundary condition object which defines the behaviour of \texttt{Field} and \texttt{Field}
-indexing operations at the boundaries. This makes the same, clear indexing notation do the right thing under a variety of imposed boundary conditions.
-
-\subsection{Available Boundary Conditions}
-
-\ippl pre-defines classes to represent 6 different forms of boundary conditions:
-\begin{enumerate}
-    \item Periodic boundary condition: \texttt{PeriodicFace}
-    \item {\color{red} Positive reflecting boundary condition: \texttt{PosReflectFace}
-    \item Negative reflecting boundary condition: \texttt{NegReflectFace}
-    \item Constant boundary condition: \texttt{ConstantFace}}
-    \item Zero boundary condition (special case of constant): \texttt{ZeroFace}
-    \item {\color{red} Linear extrapolation boundary condition: \texttt{ExtrapolateFace}}
-\end{enumerate}
-The {\color{red} red} ones are not yet important.
-
-
-They represent boundary conditions for a single dimension of a (possibly) multidimensional field, for one ``side'' (or face) of the mesh along that dimension. That is, you must specify two boundary condition objects for each dimension of the \texttt{Field} -- one for each face of the mesh along that dimension. These classes are parametrized on the same four template parameters as \texttt{Field} (see Section \ref{sec:tmpl_params}); the defaults for \texttt{Mesh} and \texttt{Centering} are
-\texttt{UniformCartesian} and \texttt{Cell}. As a
-further refinement, you may specify boundary conditions for individual components of multicomponent \texttt{Field} elements such as \texttt{Vektor}.
-
-\subsection{Using Boundary Conditions With \texttt{Field}s}
-
-The \texttt{BConds} class is a container for the individual specialized boundary conditions; this is the argument passed to the \texttt{Field} constructor. A \texttt{BConds} object acts very much like an array of boundary conditions: when first created, the \texttt{BConds} object is empty, and you add new boundary condition objects to it by treating it as a vector and assigning to its elements. The basic procedure is to construct a \texttt{BConds} object, then construct new or use existing boundary condition objects (from the list
-above) to fill it, as illustrated in this example: \\
-\begin{code}
-unsigened Dim = 2;
-Index I(4), J(4);
-BConds<double, Dim> bc;
-bc[0] = new PeriodicFace<double, Dim>(0);
-bc[1] = new PeriodicFace<double, Dim>(1);
-bc[2] = new PeriodicFace<double, Dim>(2);
-bc[3] = new PeriodicFace<double, Dim>(3);
-Field Layout<Dim> layout(I, J);
-Field <double, Dim> A(layout, GuardCellSizes<Dim>(1), bc);
-\end{code}
-Again, the individual face boundary condition objects (in this example, \texttt{PeriodicFace}) perform their task for only a single face of the mesh. In this way, there may be different types of boundary conditions in different dimensions. The face boundary-condition constructors take an unsigned argument designating the face according the following numbering convention: The integers 0 and 1 apply to the boundaries of the first coordinate direction where 0 represents the negative face and 1
-represents the positive face. The integers 2 and 3 apply to the boundaries of the second coordinate direction where 2 represents the negative face and 3 represents the positive face. This pairing of integers and domains continues into higher dimensions. The constructors also take optional second and third unsigned parameters to specify a single \texttt{Field} element component rather than all of them. Refer to the \ippl User Reference for more details on these classes, and a detailed discussion
-of how the various boundary conditions affect \texttt{Field} operations.
-
-\subsection{Default Boundary Condition}
-
-If a \texttt{Field} is constructed with no \texttt{BConds} object specified, the default is for that \texttt{Field} to have NO boundary conditions. In that case, the boundary conditions container within the \texttt{Field} is empty. It is possible to add additional boundary conditions for a specific face to a \texttt{Field} after it has been constructed; to do so, retrieve the boundary condition container from the \texttt{Field} using the method \texttt{Field::getBConds()}, and then add new face-specific boundary conditions to the returned
-\texttt{BConds} container object as shown in the previous example.
-
-\section{The \texttt{GuardCellSizes} Class}
-
-A \texttt{GuardCellSizes} class, an optional argument to the \texttt{Field} constructor, represents the maximum separation (in elements) of \texttt{Field} elements which will be combined in \texttt{Field} expressions. Typically, this reflects the order of finite differencing in stencil operations. The primary reason for guard cells is parallelism -- a \texttt{Field} domain-decomposed into multiple subdomains with data from adjacent subdomains, so that the stencil operations
-have all required data locally. The \texttt{GuardCellSizes}
-class is parameterized on the unsigned value \texttt{Dim}, which represents the number of dimensions of the \texttt{Field} object. This \texttt{Dim} value must match the corresponding parameter value of the \texttt{Field} object.
-
-The constructor for \texttt{GuardCellSizes} takes either one or two arguments, which are either \texttt{unsigned} or \texttt{unsigned*}. The one-argument forms specify the same number of guard layers for all dimensions; the two-argument forms specify different numbers for the right and left faces; the unsigned forms specify the same number of layers for all dimensions; and the \texttt{unsigned*} forms specify different number of layers for the different dimensions: 
-\begin{smallcode}
-GuardCellSizes(unsigned s);  // Same no. left&right, same for all directions
-GuardCellSizes(unsigned *s); // Same no. left&right, value for each direction
-// Diff. left&right, same for all directions
-GuardCellSizes(unsigned l, unsigned r); 
-// Diff. left&right, value for each direction
-GuardCellSizes(unsigned *l, unsigned *r); 
-\end{smallcode}
-
-Section \ref{sec:index_fields}, ``Using \texttt{Index} Objects with \texttt{Field}'s'', shows examples using \texttt{Field} indexing to implement stencil operations. It discusses the numbers of guard layers required by one of the examples.
-
-\section{Operations on \texttt{Field} Objects}
-
-\subsection{Assignment}
-
-A single line of code which contains an assignment operator and a \texttt{Field} on the left hand side of the assignment operator is called a \texttt{Field} expression. Many different terms may appear on the right-hand side of a \texttt{Field} expression (or as the second argument in an \texttt{assign()} call as described below). These include scalars, \texttt{Index}'s, \texttt{Field}'s and \texttt{IndexingField}s's. Currently because of the lack of template member functions in
-C++ compilers, you must use the \texttt{assign()} function rather than the
-\texttt{operator=}:
-\begin{smallcode}
-assign(Lhs, Rhs);
-\end{smallcode}
-where \texttt{Lhs} and \texttt{Rhs} are \texttt{Field} expressions. When template member functions become available, you will simply write:
-\begin{smallcode}
-Lhs = Rhs
-\end{smallcode}
-
-Refer to the \ippl Users Reference for more details, and examples showing where you may use \texttt{operator=} and where you must use \texttt{assign()}. The following are examples of legal assignments:\\
-\begin{code}
-unsigned Dim = 2, int N = 100;
-Index I(N), J(N);
-FieldLayout<Dim> layout(I, J);
-Field<double, Dim> A(layout), B(layout), C(layout);
-A = 2.0;
-assign(A, 2.0 + B);
-assign(B, A + 2.0);
-assign(B[I][J], 3.0 + B[I][J]);
-assign(A[I][J], I + A[I][J]/C[I][J]);
-\end{code}
-
-For cases where more than one term exists on the right hand side of an assignment, the \texttt{assign()} call must be made. Any combination of scalars, \texttt{Field}'s, \texttt{IndexingField}'s (indexed \texttt{Field} objects; see Section \ref{sec:index_fields}), and \texttt{Index}'s can be put as the second argument of the \texttt{assing()} call. The only requirement in combining terms is that the appearance of an \texttt{Index} object anywhere inside of an expression requires that all the \texttt{Field} objects contained in the expression must be indexed. It
-is not possible to combine \texttt{Field}'s and \texttt{IndexingField}'s in a single expression. Nor is it possible to combine \texttt{Field}'s and \texttt{Index} objects in a single expression.
-
-Another intermediate solution to accommodate the lack of member function templates (and therefore the ability to use the \texttt{operator=} member function with more than one term on the right hand side of an expression) is the utilization of the accumulation operators (since this does not require member function templates). Thus, instead of writing
-\begin{smallcode}
-assign(A, 4.0 + B);
-\end{smallcode}
-one could write
-\begin{smallcode}
-A = 0.0;
-A += 4.0 + B;
-\end{smallcode}
-This technique can be used with any of the accumulation operators (\texttt{+=,-=,*=,/=}).
-
-\subsection{Using \texttt{Index} Objects with \texttt{Field}'s} \label{sec:index_fields}
-
-The \texttt{Field} object works intimately with \texttt{Index} objects to perform a wide variety of operations. Use the \texttt{Index} object to specify the access pattern into a data parallel \texttt{Field} object. Do this by using \texttt{Index} objects inside the brackets following a \texttt{Field} object as follows:
-\begin{smallcode}
-A[I][J] = B[I][J];
-\end{smallcode}
-A \texttt{Field} object followed by brackets containing \texttt{Index} objects is called an \texttt{IndexingField}, because \ippl internally uses an \texttt{IndexingField} class as the return value for the \texttt{Field::operator[]}.
-
-You can use \texttt{Index} objects to initialize a \texttt{Field} with integer range data -- that is, assign to a strided range of \texttt{Field} elements the values of a strided range of integers multiplied by the element type. This only works of multiplication by an int is defined for the \texttt{Field} element type, which it is for the intrinsic types $\{$\texttt{int, float, double, bool}$\}$ and the \ippl pre-defined \texttt{Field} element classes $\{$\texttt{Vektor, Tenzor,
-SymTenzor}$\}$. For multidimensional \texttt{Field}'s, the range of values is replicated along
-the other dimensions. For example, given a \texttt{Field} that is size 8 in its first dimension and size 4 in its second dimension, the code segment
-\begin{smallcode}
-assign(A[I][J], I);
-\end{smallcode}
-produces the following values in the \texttt{Field A}:
-%
-   \begin{center}
-        \begin{tabular}{|c|c|c|c|c|c|c|c|}
-        \hline
-        0 & 1 & 2 & 3 & 4 & 5 & 6 & 7 \\
-        \hline
-        0 & 1 & 2 & 3 & 4 & 5 & 6 & 7 \\        \hline
-        0 & 1 & 2 & 3 & 4 & 5 & 6 & 7 \\        \hline
-        0 & 1 & 2 & 3 & 4 & 5 & 6 & 7 \\        \hline
-        \end{tabular}
-   \label{tbl:t1}
-   \end{center}
-%
-(Here, as in subsequent figures like this displaying \texttt{Field} values, the positive direction of the first coordinate is from left to right and the positive direction for the second coordinate is from top to bottom.) Likewise, an assignment of the form
-\begin{smallcode}
-assign(A[I],[J], J);
-\end{smallcode}
-produces
-%
-   \begin{center}
-        \begin{tabular}{|c|c|c|c|c|c|c|c|}
-        \hline
-        0 & 0 & 0 & 0 & 0 & 0 & 0 & 0 \\        \hline
-        1 & 1 & 1 & 1 & 1 & 1 & 1 & 1 \\        \hline
-        2 & 2 & 2 & 2 & 2 & 2 & 2 & 2 \\        \hline
-        3 & 3 & 3 & 3 & 3 & 3 & 3 & 3 \\        \hline
-        \end{tabular}
-   \label{tbl:t2}
-   \end{center}
-
-The \texttt{Index} objects used to access ranges of values in a \texttt{Field} object do not have to be the same \texttt{Index}'s used in constructing the \texttt{FieldLayout} object used to construct the \texttt{Field}. You can use \texttt{Index} objects of smaller size to access a subrange of the \texttt{Field}. For example, if we wanted to have an 8 by 8 \texttt{Field} with zeros everywhere except for a 4 by 4 subregion in the center, the following code segment would accomplish this goal: \\
-\begin{code}
-unsigned Dim = 2;
-Index I(8), J(8);
-Index I2(2,5), J2(2,5);
-FieldLayout<Dim> layout(I, J);
-Field<double, Dim> A(layout);
-A = 0.0;
-A[I2][J2] = 1.0;
-\end{code}
-This would produce the following values in the \texttt{Field A}:
-%
-   \begin{center}
-        \begin{tabular}{|c|c|c|c|c|c|c|c|}
-        \hline
-        0 & 0 & 0 & 0 & 0 & 0 & 0 & 0 \\        \hline
-        0 & 0 & 0 & 0 & 0 & 0 & 0 & 0 \\        \hline
-        0 & 0 & 1 & 1 & 1 & 1 & 0 & 0 \\        \hline
-        0 & 0 & 1 & 1 & 1 & 1 & 0 & 0 \\        \hline
-        0 & 0 & 1 & 1 & 1 & 1 & 0 & 0 \\        \hline
-        0 & 0 & 1 & 1 & 1 & 1 & 0 & 0 \\        \hline
-        0 & 0 & 0 & 0 & 0 & 0 & 0 & 0 \\        \hline
-        0 & 0 & 0 & 0 & 0 & 0 & 0 & 0 \\        \hline
-        \end{tabular}
-   \label{tbl:t2}
-   \end{center}
-
-The lower-limiting case range for an \texttt{Index} object is, of course, a single element. For this case you can just use an integer constant or variable; the following assigns a single element of the \texttt{Field A}: \\
-\begin{code}
-Index I(4), J(4);
-FieldLayout<2> layout(I, J);
-Field<double,2> A(layout);
-A = 0.0;
-A[1][1] = 1.0;
-\end{code}
-The resultant \texttt{Field A} contains the values:
-%
-   \begin{center}
-        \begin{tabular}{|c|c|c|c|}
-        \hline
-        0 & 0 & 0 & 0 \\        \hline
-        0 & 1 & 0 & 0 \\        \hline
-        0 & 0 & 0 & 0 \\        \hline
-        0 & 0 & 0 & 0 \\        \hline
-        \end{tabular}
-   \label{tbl:t2}
-   \end{center}
-
-The typical use for indexing is stencil operations, using \texttt{Index} expressions adding or subtracting integer constants to represent the finite differences. This amounts to global data transformation upon a \texttt{Field} through the use of \texttt{Index} operations. For example, if a 4 by 4 \texttt{Field} named \texttt{A} is initialized as follows: \\
-\begin{code}
-unsigned Dim = 2;
-int N = 4;
-Index I(N), J(N);
-FieldLayout<Dim> layout(I, J);
-Field<double, Dim> A(layout, GuardCellSizes<Dim>(1));
-assign(A[I][J], I + 1);
-\end{code}
-then the values in the \texttt{Field A} will be:
-%
-   \begin{center}
-        \begin{tabular}{|c|c|c|c|}
-        \hline
-        1 & 2 & 3 & 4 \\        \hline
-        1 & 2 & 3 & 4 \\        \hline
-        1 & 2 & 3 & 4 \\        \hline
-        1 & 2 & 3 & 4 \\        \hline
-        \end{tabular}
-   \label{tbl:t2}
-   \end{center}
-
-Now, let's form another \texttt{Field}, \texttt{B}, and assign to it the value of an \texttt{IndexingField} of A which represents an indexed operation:
-\begin{smallcode}
-Field<double, Dim> B(layout);
-assign(B[I][J], A[I+1][J]);
-\end{smallcode}
-
-Here we see that the \texttt{Field A} has been indexed with something other than a plain \texttt{Index} object. Rather, it has been indexed by an index expression. The \texttt{Index} objects have been overloaded to allow addition and subtraction by integers to produce other \texttt{Index} objects. The framework recognizes this operation as requesting that all the data in \texttt{A} be shifted to the left (along the first dimension in the negative direction) by 1 position. The \texttt{Field B} contains the values:
-%
-   \begin{center}
-        \begin{tabular}{|c|c|c|c|}
-        \hline
-        2 & 3 & 4 & 0 \\        \hline
-        2 & 3 & 4 & 0 \\        \hline
-        2 & 3 & 4 & 0 \\        \hline
-        2 & 3 & 4 & 0 \\        \hline
-        \end{tabular}
-   \label{tbl:t2}
-   \end{center}
-
-\texttt{Index}ing operations which access data beyond a \texttt{Field} boundary set the target positions to zero. For the reminder of this section, we shall assume this zero valued boundary condition (which is the default condition when no boundary condition is specified). A variety of boundary conditions can be set on each boundary of a \texttt{Field} and are discussed in detail in the next section.
-
-The \texttt{GuardCellSizes} object used to construct \texttt{Field A} in this example must specify at least on guard layer in the 1st dimension, to accommodate the ``$+1$'' in the indexing operation. The one used, \texttt{GuardCellSizes<Dim>(1)} allows ``$+/-1$'' indexing (as in a width-one stencil), and also allows width-one stencils in the 2nd dimension, because the use of the unsigned argument (the constant, 1) specifies one guard layer both left and right for all directions.
-
-Had we wished to shift the \texttt{Field A} down (along the second dimension in the negative direction) we could have written
-\begin{smallcode}
-assign(B[I][J], A[I][J+1]);
-\end{smallcode}
-Then the values in the \texttt{Field B} are:
-%
-   \begin{center}
-        \begin{tabular}{|c|c|c|c|}
-        \hline
-        1 & 2 & 3 & 4 \\        \hline
-        1 & 2 & 3 & 4 \\        \hline
-        1 & 2 & 3 & 4 \\        \hline
-        0 & 0 & 0 & 0 \\        \hline
-        \end{tabular}
-   \label{tbl:t2}
-   \end{center}
-
-You can shift in the positive or negative direction on any \texttt{Index} object used to index a \texttt{Field}. For example, \\
-\begin{code}
-unsigned Dim = 2;
-int N = 4;
-Index I(N), J(N);
-FieldLayout<Dim> layout(I, J);
-Field<double, Dim> A(layout, GuardCellSizes<Dim>(1));
-assign(A[I][J], I + J + 1);
-\end{code}
-will initialize the values in the \texttt{Field A} to:
-%
-   \begin{center}
-        \begin{tabular}{|c|c|c|c|}
-        \hline
-        1 & 2 & 3 & 4 \\        \hline
-        2 & 2 & 4 & 4 \\        \hline
-        3 & 4 & 5 & 6 \\        \hline
-        4 & 5 & 6 & 7 \\        \hline
-        \end{tabular}
-   \label{tbl:t2}
-   \end{center}
-%
-and the operation 
-\begin{smallcode}
-Field<double, Dim> B(layout);
-assign(B[I][J], A[I+1][J-2]);
-\end{smallcode}
-will produce a \texttt{Field B} with the values:
-%
-   \begin{center}
-        \begin{tabular}{|c|c|c|c|}
-        \hline
-        0 & 0 & 0 & 0 \\        \hline
-        0 & 0 & 0 & 0 \\        \hline
-        3 & 4 & 5 & 0 \\        \hline
-        4 & 5 & 6 & 0 \\        \hline
-        \end{tabular}
-   \end{center}
-
-\subsection{Overloaded operators}
-
-\ippl pre-defines a suite of overloaded operators with the \texttt{Field} class. These include the unary $-$ operator; the binary operators, $+$, $-$, $*$, and $/$; and the accumulation operators \texttt{+=, -=, *=, /=}. Traits~\cite{traits} determine the appropriate casts and promotions of mixed types inside \texttt{Field}. For example, a \texttt{Field} of \texttt{int}'s added to a \texttt{Field} of \texttt{double}'s would perform the correct promotion of \texttt{int} to \texttt{double} element by element. As mentioned earlier, the assign operator $=$ does not work
-for most cases because of the lack of member function templates. In addition, the relational operators are not directly available due to conflicts in the current HP reference STL implementation. This functionality is provided through the explicit inlined binary function calls:
-%
-   \begin{center}
-        \begin{tabular}{ll}
-        \hline
-        binary function relationals & corresponding relation operator \\
-        \hline
-        gt(A, B) & $A > B$ \\ 
-        lt(A, B) & $A < B$ \\ 
-        ge(A, B) & $A >= B$ \\ 
-        le(A, B) & $A  <= B$ \\ 
-        eq(A, B) & $A == B$ \\
-        ne(A, B) & $A != B$ \\
-        \hline
-        \end{tabular}
-   \end{center}
-%
-The return value of these binary relational functions is a conforming \texttt{Field} of \texttt{bool}'s. Here is an example using binary functional relationals in an expression: \\
-\begin{code}
-unsigned Dim = 2;
-Index I(8), J(4);
-FieldLayout<Dim> layout(I, J);
-Field<double, Dim> A(layout), B(layout), C(layout);
-A = 0.0;
-assign(B[I][J], J);
-assign(C[I][J], I);
-assign(A, lt(B, 2,0)*C);
-\end{code}
-The resulting \texttt{Field A} contains the values
-%
-   \begin{center}
-        \begin{tabular}{|c|c|c|c|c|c|c|c|}
-        \hline
-        0 & 1 & 2 & 3 & 4 & 5 & 6 & 7\\        \hline
-        0 & 1 & 2 & 3 & 4 & 5 & 6 & 7\\        \hline
-        0 & 0 & 0 & 0 & 0 & 0 & 0 & 0\\        \hline
-        0 & 0 & 0 & 0 & 0 & 0 & 0 & 0\\        \hline
-        \end{tabular}
-   \end{center}
-
-\subsection{The \texttt{where()} Function}
-
-Data parallel simulations often require element-by-element conditionals. The \ippl framework provides a \texttt{where} functions which reduces to the inlined conditional \texttt{operator?}: for each element of the \texttt{Field} objects passed to the \texttt{where()} function. The \texttt{where()} function takes three \texttt{Field} arguments:
-\begin{smallcode}
-assign(A, where(B, C, D));
-\end{smallcode}
-where the \texttt{Field B}'s a \texttt{Field} of \texttt{bool}'s. The value of \texttt{C} is placed into \texttt{A} everywhere that \texttt{B} is \texttt{true}, and the value of \texttt{D} is placed into \texttt{A} everywhere that \texttt{B} is \texttt{false}. Thus, \\
-\begin{code}
-unsigned Dim = 2;
-Index I(4), J(4);
-FieldLayout<Dim> layout(I, J);
-Field<double, Dim> A(layout), B(layout), C(layout);
-assign(B[I][J], I - 1);
-C = 1.0;
-assign(A[I][J], where( lt(B, C), B, C));
-\end{code}
-leaves the following values in \texttt{Field A}:
-%
-   \begin{center}
-        \begin{tabular}{|c|c|c|c|}
-        \hline
-        -1 & 0 & 1 & 1 \\        \hline
-        -1 & 0 & 1 & 1 \\        \hline
-        -1 & 0 & 1 & 1 \\        \hline
-        -1 & 0 & 1 & 1  \\        \hline
-        \end{tabular}
-   \end{center}
-
-Since \texttt{where()} returns a \texttt{Field}, invocations of \texttt{where()} may be used as arguments to where(); this allows nested element-by-element conditionals. The following example code\\
-\begin{code}
-unsigned Dim = 2;
-Index I(4), J(4);
-FieldLayout<Dim> layout(I, J);
-Field<double, Dim> A(layout), B(layout), C(layout), D(layout);
-assign(B[I][J], I - 1);
-assign(C[I][J], J - 1);
-D = 1.0;
-assign(A[I][J], where( lt(B, D), B, where( lt(C, D), C, D)));
-\end{code}
-leaves the following values in \texttt{Field A}:
-%
-   \begin{center}
-        \begin{tabular}{|c|c|c|c|}
-        \hline
-        -1 & 0 & -1 & -1 \\        \hline
-        -1 & 0 & 0 & 0 \\        \hline
-        -1 & 0 & 1 & 1 \\        \hline
-        -1 & 0 & 1 & 1  \\        \hline
-        \end{tabular}
-   \end{center}
-
-\subsection{Mathematical Functions on \texttt{Field}'s}
-
-As would be expected of any framework for scientific simulation, all the standard mathematical operations are included. The unary functions take a \texttt{Field} object and return a \texttt{Field} object of the same dimension and size where the unary operation has been performed upon each element of the \texttt{Field}. The binary functions take two conforming \texttt{Field}'s and apply the function pairwise to each member of the two \texttt{Field}'s to produce a new conforming \texttt{Field} containing the resultant values. The following
-functions, mirroring those in math.h, are available in the framework for \texttt{Field} operations:
-\begin{smallcode}
-acos, asine, atan, cos, sin, tan, cosh, sinh, tanh, 
-exp, log, log10, pow, sqrt, ceil, fabs, floor.
-\end{smallcode}
-For machines which provide them in \texttt{math.h}, \ippl provides the \texttt{Field} version of the \texttt{Bessel, gamma, and error} functions
-\begin{smallcode}
-erf, erfc, gamma, j0, j1, y0, y1.
-\end{smallcode}
-
-\subsection{Reduction Operations}
-
-\ippl includes several reduction operations with the \texttt{Field} class. These include determining the maximum and minimum elements of a \texttt{Field}, the global sum and product of all the elements in a \texttt{Field}, and determining the location of the minimum and maximum values within a \texttt{Field} (typically called minloc and maxloc).
-
-\textit{WARNING: Currently, these functions are only implemented on \texttt{Field} objects; they will not work on \texttt{Field} expressions. This means that invocations like \texttt{min(A+B)} and \texttt{min(2.0*A)} are illegal!}
-
-The following exampled code, which demonstrates the usage of these operators,\\
-\begin{code}
-unsigned Dim = 2;
-Index I(10), J(10);
-FieldLayout<Dim> layout(I, J);
-Field<double, Dim> A(layout);
-assign(A[I][J], I + J);
-cout << min(A) << endl;
-cout << max(A) << endl;
-cout << sum(A) << endl;
-cout << prod(A) << endl;
-\end{code}
-produces the following output:
-\begin{smallcode}
-0
-18
-900
-0
-\end{smallcode}
-
-The minloc and maxloc capabilities, rather than being separately named functions, are two-argument forms of the \texttt{min()} and \texttt{max()} functions. The second argument is an \texttt{NDIndex<Dim>} object, which is a multi-dimensional container for \texttt{Index} objects. The minloc and maxloc operations fill an \texttt{NDIndex<Dim>} object with one \texttt{Index} object for each dimension; each \texttt{Index} is of size one, representing a single point. The following code segment demonstrates: \\
-\begin{code}
-unsigned Dim = 2;
-Index I(10), J(10);
-FieldLayout<Dim> layout(I, J);
-Field<double, Dim> A(layout);
-assign(A[I][J], cos((I-2)*(I-2) + (J-2)*(J-2)));
-NDIndex<Dim> LocMin, LocMax;
-min(A, LocMin);
-max(A, LocMax);
-\end{code}
-The \texttt{NDIndex<Dim>} objects \texttt{LocMin} and \texttt{LocMax} now contain the position (index location) of the minimum and maximum elements of the \texttt{Field} object \texttt{A}.
-
diff --git a/manual/ippl_index_ref.tex b/manual/ippl_index_ref.tex
deleted file mode 100644
index 7d15929db..000000000
--- a/manual/ippl_index_ref.tex
+++ /dev/null
@@ -1,313 +0,0 @@
-\chapter{Index Class}
-\label{sec:index}
-The \texttt{Index} class represents a strided range of integer indices (described by base, bound, and stride integer values). 
-You use it to define the size (index extent) per dimension of \texttt{Field} objects on construction and to specify subsets of 
-\texttt{Field} elements along a dimension in \texttt{Field} expressions.
- 
-It is important to note that the actual memory address of an \texttt{Index} object is relevant to whether that object may be used 
-interchangeably with another \texttt{Index} object specifying the same index values. In fact, two \texttt{Index} objects specifying 
-the same index values are not interchangeable. This is qualitatively different than the semantics of Fortran 90 array-syntax, 
-for example. You may construct a "new" \texttt{Index} object with a different name, but which has the same values and 
-is interchangeable with a given \texttt{Index} by setting it equal to the first Index object on construction. 
-\section{Index Definition}
-\label{sec:indpubldef}
-\begin{smallcode}
-class Index { 
-public: 
-// Public data member -- iterator class: class iterator 
-{ 
-public:
-iterator() : Current (0) , Stride(0) {} 
-iterator(int current, int stride=l) : Current (current) , Stride(stride){} 
-int operator*(); 
-iterator operator--(int); // Post decrement iterator& operator--(); 
-iterator operator++(int); // Post increment iterator& operator++(); 
-iterator& operator+=(int); 
-iterator& operator-=(int); 
-iterator operator+(int) const; 
-iterator operator-(int) const; 
-int operator[] (int); 
-bool operator==(const iterator &) const; 
-bool pperator<const iterator &) const; 
-bool operator!=(const iterator &) const; 
-bool operator> (const iterator &) const; 
-bool operator<=(const iterator &) const; 
-bool operator>=(const iterator &) const; 
-private: 
-int Stride; 
-intCurrent; 
-};
-
-// Public member functions. 
-// Constructors: 
-Index ( ) ;                                  // null range
-inline Index(unsigned n);      // [0 .. n-1]  
-inline Index(int f, int l);         // [f .. l] 
-inline Index(int f, int l, int s); // First to Last using Step. 
-
-// Destructor 
-~Index () {};         // Don't need to do anything. 
-
-int id () { return 1 ; }
- 
-inline int min() const;		// the smallest element.
-inline int max() const;	// the largest element.
-inline int length() const; 	// the number of elems.
-inline int stride() const; 	// the stride. 
-inline int first() const; 	// the first element. 
-inline int last() const; 	// the last element.
-inline bool emty() const;	 // is it empty? 
-inline const Index* getBase() const; // the base index 
- 
-// Additive operations. 
-friend inline Index operator+ (const Index&, int);
-friend inline Index operator+(int,const Index&);
-friend inline Index operator~(const Index&,int);
-friend inline Index operator-(int,const Index&);
-
-// Multiplicative operations. 
-friend inline Index operator-(const'Index&);
-friend inline Index operator*(const Index&,int);
-friend inline Index operator*(int,const Index&); 
-friend inline Index operator I (const Index&,int);
-
-// Intersect with another Index. 
-Index intersect(const Index&) const;
-
-// Plug the base range of one into another. 
-Index plugBase(const Index &) const;
- 
-// Test to see if two indexes are from the same base. 
-inline bool sameBase(const Index &) const;
- 
-// Test to see if there is any overlap between two Indexes. 
-inline bool touches (const Index& a) const;
- 
-// Test to see if one contains another. , 
-inline bool contains(const Index& a) const;
-
-// Split one. into two. 
-inline bool split(Index& I, Index& r) const; 
-
-// iterator begin 
-iterator begin() { return iterator(First,Stride); } 
-
-// iterator end 
-iterator end () { return iterator (First+Stride*Length, Stride);
- 
-// An operator< so we can impose some sort of ordering. 
-bool operator< (const Index& r) const;
-
-// Test for equality. 
-bool operator==(const Index& r) const;
- 
-static void findPut(const Index&,const Index&, const Index&, Index&, Index&); 
-
-// put data into a message to send to another node 
-Message& putMessage(Message& m);
-
-// get data out from a message 
-Message& getMessage(Message& m); 
-
-// Print it out. 
-friend ostream& operator<<(ostream& out, const Index& I); 
-}; 
-\end{smallcode}
-
-
-\section{Index Constructors}
-The constructor for \texttt{Index} takes one, two, or three in arguments. In the case of three arguments, 
-these represent the base index value, the bounding index value, and the stride. The two and one-argument cases are simplifications. 
-\begin{smallcode}
-Index I(8);
-\end{smallcode}
-instantiates an \texttt{Index} object representing the range of integers from 0 through 7 (i.e" [0,7]) with implied stride 1. The two-argument
-\begin{smallcode}
-Index J(2,8); 
-\end{smallcode}
-instantiates an \texttt{Index} object representing the range of integers [2,8] with implied stride 1. The three-argument 
-\begin{smallcode}
-Index(1,8,2); 
-\end{smallcode}
-instantiates an Index object representing the range of integers [1,8] with stride 2- .. that is, the  ordered set ${1,3,5,7}$.
-
-Note that the single argument in the one-argument case defines the number of elements, rather than the bound. This means that \texttt{Index J(8)} , which represents $[0,7]$, 
-is different than \texttt{Index J(0,8)} \texttt{and Index J(0,8,1)} , which both mean $[0,8]$.
- 
-There is also a special special constructor taking no arguments; this is meant for use in constructing arrays of\texttt{ Index}'s.
-
-\section{Index Member Functions and Member Data}
-\subsection{Index iterator} 
-The only public member data is the \texttt{Index::iterator} class. This class has the semantics of an STL random access iterator; the advanced user can use 
-it to iterate over integer index values represented by the containing \texttt{Index} object. 
-The STL semantics means that the class provides increment and decrement operators, increment/decrement by specified integer amounts, deference operator, 
-random-access \texttt{operator[]}, and comparison operators. See the class definition in Section \ref{sec:indpubldef} for the full list. The \texttt{iterator class} definition is contained within. 
-
-\begin{smallcode}
-iterator begin () 
-\end{smallcode}
-Returns an \texttt{Index: : iterator} positioned at the beginning of the index values represented by the \texttt{Index} object.
-\begin{smallcode}
-iterator end ( ) 
-\end{smallcode}
-Returns an \texttt{Index::iterator} positioned beyond the last index value represented by the \texttt{Index} object. 
-
-
-\subsection{Index Query/Accessor Functions} 
-These functions mostly return values of or values computed from private data members of the \texttt{Index}. 
-\begin{smallcode}
-int min () const 
-\end{smallcode}
-Returns the smallest integer value allowed for the \texttt{Index} object. 
-\begin{smallcode}
-int max () const 
-\end{smallcode}
-Returns the largest integer value allowed for the \texttt{Index} object. 
-\begin{smallcode}
-int length() const 
-\end{smallcode}
-Returns the total number of integer values spanned by the \texttt{Index} object. 
-\begin{smallcode}
-int stride()const
-\end{smallcode} 
-Returns the value of the stride for the \texttt{Index} object. 
-\begin{smallcode}
-int first() const 
-\end{smallcode}
-Returns the integer value ofthe first element in the \texttt{Index} object. 
-\begin{smallcode}
-int last () const 
-\end{smallcode}
-Returns the integer value of the last element the \texttt{Index} object. 
-\begin{smallcode}
-bool empty() const 
-\end{smallcode}
-Returns true/false depending on whether the \texttt{Index} object is empty. Empty (true) means, that it was constructed with the zero-argument constructor.
-\begin{smallcode}
-const Index* getBase() const 
-\end{smallcode}
-Returns a pointer to the base \texttt{Index} object associated with the \texttt{Index} object. As described at the beginning of this chapter, the memory address of an \texttt{Index} 
-is important, and if two \texttt{Index}'s are to be interchangeable they must share the same base address as well as be conforming (have the same base, bound, and stride values). 
-
-
-\subsection{Index Arithmetic operator Functions} 
-Here we describe the arithmetic operator functions defined in the Index class to act on \texttt{Index} objects. In the example code in these descriptions, \texttt{I} is an \texttt{Index} object and \texttt{n} is an \texttt{int}.
-\begin{smallcode}
-friend Index operator+(const Index&,int)
-\end{smallcode} 
-The \texttt{Index} expression\texttt{I +n} invokes this operator. It adds an integer value \texttt{n} to the base and bound values of \texttt{I}, then constructs and returns the resulting \texttt{Index} object using those 
-	revised values.
- 
-\begin{smallcode}
-friend Index operator+(int,const Index&) 
-\end{smallcode}
-Same as the previous, except for the order of the operands. That is, the \texttt{Index} expression \texttt{n+I} invokes this operator. 
-
-\begin{smallcode}
-friend Index operator-(const Index&,int) 
-\end{smallcode}
-Invoked by \texttt{ I-n} subtracts \texttt{n} from the base and bound of \texttt{I} and returns the resulting \texttt{Index}. 
-\begin{smallcode}
-friend Index operator-(int,const Index&) 
-\end{smallcode}
-Invoked by \texttt{n-I} subtracts the base of \texttt{I} from \texttt{n}, multiplies the stride by \texttt{ -1},and returns the 
-	resulting \texttt{Index} object.
-
-\begin{smallcode}
-friend Index operator-(const Index&) 
-\end{smallcode}
-Negation operator, invoked by \texttt{-1}. This multiplies the base and bound of \texttt{I} by \texttt{-1} and returns the resulting Index object. 
-\begin{smallcode}
-friend Index operator*(const Index&,int) 
-friend Index operator*(int,const Index&) 
-\end{smallcode}
-
-Invoked by \texttt{I*n} and \texttt{n*I}, respectively. These multiply the base, bound, and stride of \texttt{I} by \texttt{n} and return the resulting \texttt{Index} object 
-\begin{smallcode}
-friend Index operator /(const Index&,int) 
-\end{smallcode}
-Invoked by \texttt{I/n}. These divide the base, bound, and stride of \texttt{I} by \texttt{n} and return the resulting \texttt{Index} object (integer division, truncates). 
-Note that the division operator with the operands the other way around (\texttt{n/I}) is not defined.
-
-\subsection{Index I/O and Message-Passing Functions}
-These are functions are to write out an \texttt{Index} object, and to pack/unpack and send/receive an \texttt{Index} object as a message between two processes. 
-\begin{smallcode}
-friend ostream& operator<<(ostream&, const Index&) 
-\end{smallcode}
-Formatted insertion of the contents of an \texttt{Index} object into the output stream. The interface is the stream I/O  \texttt{operator <<}, invoked by \texttt{os<<I} (os is an ostream object, or a \ippl Inform object).
-
-\begin{smallcode}
-static void findPut(const Index&, const Index&, const Index&,Index&, Index&)
-\end{smallcode} 
-Need to describe .....
-  
-\begin{smallcode}
-Message& putMessage(Message&)
-\end{smallcode} 
-Put \texttt{Index} data into a message to send to another node. 
-\begin{smallcode}
-Message&getMessage{Message&) 
-\end{smallcode}
-Get  \texttt{Index} data out of a message you have received from another node. 
-
-\subsection{Index Comparison Operators} 
-\begin{smallcode}
-bool operator < const Index&) const;
-\end{smallcode} 
-A less-than test so we can impose some sort of ordering of two \texttt{Index} objects. The implementation is such that \texttt{I<J} returns true if one of the following is true: 
-the length of \texttt{I }(number of integer index values represented by \texttt{I}) is less than the length of \texttt{J}, the length's are, equal but the first integer index value in 
-\texttt{I} is less than the first value in \texttt{J}, or (failing either of the first two tests, and given that the length of \texttt{I} is greater than 0) the stride of I is less than the stride of \texttt{J}. 
-\begin{smallcode}
-bool operator == (const Index&) const 
-\end{smallcode}
-Test for equality of two \texttt{Index} objects.\texttt{I==J} returns true if the {base,bound,stride} values of \texttt{I} and \texttt{J} are the same. This does not check that the two 
-\texttt{Index} objects have the same base address . 
-
-
-\subsection{Index Composition Functions}
-\begin{smallcode}
-Index intersect(const Index&) const
-\end{smallcode} 
-\texttt{I.intersect(J)} returns an \texttt{Index} object containing the intersection of \texttt{I} with \texttt{J}  such that it contains all the integer index values contained both in \texttt{I} and \texttt{J} (expressed as the 
-	{base,bound,stride} of the new \texttt{Index} object).
-\begin{smallcode}
-Index plugBase(constIndex&) const
-\end{smallcode} 
-Plug the base range of one into another. 
-\begin{smallcode}
-inline bool sameBase(const Index&) const 
-\end{smallcode}
-Test to see if two \texttt{Index}'s are from the same base. Internally, \texttt{Index} contains a (private) \texttt{Index*} which points to the base \texttt{Index} object from which it was constructed. If it is an \texttt{Index}
-which was constructed explicitly with one of the constructors described in Section xxx then this will be a pointer to itself. If you construct an \texttt{Index} object by arithmetic on an existing, object, the pointer points to, the existing Index. Example:
-\begin{smallcode}
-Index I(10);
-Index J( 10); 
-bool t1 = I.sameBase(J);     // false 
-bool t2 = I.sameBase(I+1); // true 
-\end{smallcode}
-\begin{smallcode}
-inline bool touches(const Index&) const 
-\end{smallcode}
-Test to see if there is any overlap between two Indexes. \texttt{I.touches(J)} returns true if the minimum integer value represented by \texttt{I} is less than or equal to the maximum value represented by
-\texttt{J}, and the maximum integer value represented by \texttt{I} is greater than or equal to the minimum value represent by \texttt{J}. 
-\begin{smallcode}
-inline bool contains(const Index&) const
-\end{smallcode}
-Test to see if one \texttt{Index} object completely conntains another. \texttt{I.contains (J)} returns true if the minimum integer value represented by \texttt{I} is less than or equal to the minimum value represented by \texttt{J}, and the maximum integer value represented by \texttt{I} is greater than or equal to the maximum value represented by \texttt{J}. 
-\begin{smallcode}
-inlinebool split(Index& 1, Index& r) const 
-\end{smallcode}
-Splits one \texttt{Index} object into two. \texttt{I.split(J,K) }divides the set of integers represented by \texttt{I} into two halves, and fills the \texttt{Index} object \texttt{J} with the left half of the set, and the \texttt{Index} object \texttt{K} 
-with the right half of the set. 
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/manual/ippl_mesh_ref.tex b/manual/ippl_mesh_ref.tex
deleted file mode 100644
index 363773a07..000000000
--- a/manual/ippl_mesh_ref.tex
+++ /dev/null
@@ -1,611 +0,0 @@
-\chapter{Meshes}
-\label{sec:mesh}
-\ippl predefines classes to represent Cartesian meshes; these typically serve as the \texttt{Mesh} template parameter for \texttt{Field} 
-and other classes parameterized on \texttt{Mesh} type. These classes also provide various mechanism to query mesh 
-geometry (spacings, cell volumes, etc.) from \texttt{Mesh} objects. 
-
-\section{Mesh Class} 
-The \texttt{Mesh} class is an abstract base class for classes representing computational meshes. 
-Currently, the base class does nothing it does not even provide any virtual functions, because it is difficult 
-to conceive of commonality among potential derived meshes as disparate as unstructured and uniform structured meshes 
-(for example). It does allow writing functions and classes that have \texttt{Mesh} objects as arguments and members; 
-but, so far, that hasn't been used even within the
-\ippl internal implementation. \ippl predefines the \texttt{UniformCartesian} and \texttt{Cartesian} classes which inherit from \texttt{Mesh}. 
-
-\subsection{Mesh Definition (Public Interface)} 
-\begin{smallcode}
-template<unsigned Dim> 
-class Mesh 
-{};
-\end{smallcode}
-
-\section{\texttt{UniformCartesian} Class} 
-\label{app:unifcart}
-The \texttt{UniformCartesian} class represents the abstraction of a uniform-spacing Cartesian mesh discretizing a rectangular region of space. The \texttt{Mesh} has 
-uniform spacing in the sense that the mesh spacings (vertex-vertex distances) along a dimension are the same {\it all along that dimension}. The different dimensions 
-may have different (single) values for mesh spacing. The \texttt{Cartesian} class (Appendix \ref{app:cartclass}) generalizes this to meshes whose spacings vary cell-by-cell along each 
-dimension. \texttt{UniformCartesian} has mechanisms for returning various kinds of geometrical information from the mesh: cell-cell and vertex-vertex spacings, 
-nearest mesh vertex positions to a given point in space, and others. Many of these; such as a function to return the volume of a particular indexed cell in the mesh, 
-are somewhat redundant, for the uniform case, but make more sense in the nonuniform case (\texttt{Cartesian}); the interfaces of \texttt{UniformCartesian} and 
-\texttt{Cartesian} are meant to be as much alike as possible. 
-\texttt{UniformCartesian} is parameterized on dimensionality Dim, and another parameter MFLOAT. The MFLOAT parameter specifies the elemental type to use 
-in storing and returning mesh geometrical information such as spacings and position coordinates. Generally, this should be a floating-point type, and it defaults 
-to double. Vector values are represented using \texttt{Vektor<MFLOAT,Dim>}. 
-
-\subsection{\texttt{UniformCartesian} Definition (Public Interface)}
-\begin{smallcode}
-template < unsigned Dim, class MFLOAT=double>
-class UniformCartesian : public Mesh<Dim>
-{ );
-public: 
-// Public member data: 
-unsigned gridSizes[Dim];            // Sizes (number of vertices) 
-typedef Cell DefaultCentering;   // used by Field
-Vektor<MFLOAT,Dim>  Dvc[1<<Dim];  // Constants for derivatives 
-
-bool hasSpacingFields;  	          
-BareField<Vektor<MFLOAT, Dim>, Dim>* VertSpacings ;
-BareField<Vektor<MFLOAT, Dim>, Dim>* CellSpacings ;
-
-// Public member functions: 
-// Constructors 
-UniformCartesian() {}; // Default constructor 
-
-// Non-default constructors 
-UniformCartesian(NDIndex<Dim>& ndi); 
-UniformCartesian(Index& I); 
-UniformCartesian(Index& I, Index& J); 
-UniformCartesian(Index& I, Index& J, Index& K); 
-// These also take a MFLOAT* specifying the mesh spacings: 
-UniformCartesian(NDIndex<Dim>& ndi, MFLOAT* delX); 
-UniformCartesian(Index& I, MFLOAT* delX); 
-UniformCartesian(Index& I, Index& J, MFLOAT* delX); 
-UniformCartesian(Index& I, Index& J, Index& K, MFLOAT* delX); 
-// These further take a Vektor<I:1FLOAT,Dim>& specifying the origin: 
-UniformCartesian(NDIndex<Dim>& ndi, MFLOAT*delX, Vektor<MFLOAT,Dim>& orig); 
-UniformCartesian(Index& I, MFLOAT* delX, Vektor<MFLOAT,Dim> orig); 
-UniformCartesian(Index& I, Index& J, MFLOAT* delX, Vektor<MFLOAT,Dim>& orig) ;
-UniformCartesian(Index& I, Index& J, Index& K, MFLOAT* delX, Vektor<MFLOAT,Dim>& orig); 
-
-~UniformCartesian() { }; // Destructor 
-
-// Set functions for member data: 
-// Create BareField's of vertex and cell spacingsi allow for specifying 
-// layouts via the FieldLayout e_dim_tag and vnodes parameters (these 
-// get passed in to construct the FieldLayout used to construct the BareField's).
- 
-void storeSpacingFields(); // Defaulti will have default layout 
-
-// Special cases for 1-3 dimensions, a la FieldLayout ctors
-void storeSpacingFields(e_dim_tag pI, int vnodes=-1);
-void storeSpacingFields (e_dim_tag pI, e_dim_tag p2', int vnodes=-l) ; 
-void storeSpacingFields (e_dim_tag pI, e_dim_tag p2, e_dim_tag p3,int vnodes=-1); 
-
-// It Next we have one for arbitrary dimension, a la FieldLayout ctor: 
-// All the others call this one internally: 
-void storeSpacingFields(e_dim_tag *p, int vnodes=-1); 
-
-// Accessorfunctions for member data: 
-// Get the origin of mesh vertex positions: 
-Vektor<MFLOAT,Dim> get_origin(); 
-
-// Get the spacings of mesh vertex positions along specified direction: 
-MFLOAT get_meshSpacing(int d); 
-
-// Get the cell volume: 
-MFLOAT get_volume(); 
-
-// Formatted output of UniformCartesian object: 
-void print (ostream&);
-// Stream formatted output of UniformCartesian object: 
-friend ostream& operator<<(ostream&, const UniformCartesian<Dim,MFLOAT>&);
-
-// Other UniformCartesian methods
-
-// Volume of single cell indexed by input NDIndex
-MFLOAT getCellVolume(NDIndex<Dim>&);
-
-// Field of volumes of all cells: ' Field<MFLOAT,Dim,UniformCartesian<Dim,MFLOAT>,Cel1>& 
-getCellVolumeField (Field<MFLOAT, Dim, UniformCartesian<Dim,MFLOAT>,Cell>&); 
-
-// Volume of range of cells bounded by verticies specified by inputNDIndex: 
-MFLOAT getVertRangeVolume(NDIndex<Dim>&); 
-
-// Volume of range of cells spanned by input NDIndex (index o'f cells): 
-MFLOAT getCe//Rangevolume(NDIndex<Dim>&); 
-
-// Nearest vertex index to (x,y,z)
-NDIndex<Dim>& getNearestVertex(Vektor<MFLOAT,Dim>&); 
-
-// Nearest vertex index with all vertex coordinates below (x,y,z): 
-NDIndex<Dim>& getVertexBelow(Vektor<MFLOAT,Dim>&);
-
-// NDIndex for cell incell-ctrd Field containing the point (x,y,z): 
-NDIndez<Dim>& getCellContaining(Vektor<MFLOAT,Dim>&);
- 
-// (x,y,z) coordinates of indexed vertex: 	_ 
-Vektor<MFLOAT, Dim> getVertexPosition (NDIndex<Dim>&); 
- 
-// Field of (x,y,z) coordinates of all vertices: 
-Field<Vektor<MFLOAT, Dim>, Dim, UniformCartesian<Dim, MFLOAT>, Vert>& 
-getvertexPositionField(Field<Vektor<MFLOAT,Dim>,Dim, UniformCartesian<Dim,MFLOAT>,Vert>& ); 
- 
-//Vertex-vertex grid spacing of indexed cell:
-Vektor<MFLOAT,Dim> getDeltaVertex(NDIndex<Dim>&); 
-
-// Field of vertex-vertex ,grid spacings of all cells: 
-Field<Vektor<MFLOAT,Dim>,Dim,UniformCartesian<Dim,MFLOAT>,Cell>& 
-getDeltaVertexField (Field<Vektor<MFLOAT, Dim>, Dim, UniformCartesian<Dim,MFLOAT>,Cell>& ); 
-
-// Cell-cell grid spacing of indexed vertex: 
-Vektor<MFLOAT,Dim> getDeltaCell(NDIndex<Dim>&); 
-
-// Field of cell-cell grid spacingsof all vertices: 
-Field<Vektor<MFLOAT, Dim>, Dim,UniformCar,tesian<Dim, MFLOAT>, Vert>& 
-getDeltaCellField(Field<Vektor<MFLOAT,Dim>,Dim, UniformCartesian<Dim,MFLOAT>,Vert>& ); 
-
-// Array of surface normals to cells adjoining indexed cell: 
-Vektor<MFLOAT,Dim>* getSurfaceNormals(NDIndex<Dim>&); 
-
-// Array of {pointers to} Fields of surface normals to all cells: 
-void getSurfaceNormalFields(Field<Vektor<MFLOAT,Dim>,Dim, UniformCartesian<Dim,MFLOAT>,Cell>** ); 
-
-// Similar functions, but specify the surface normal to a single face, using 
-// the following numbering convention: 0 means low face of 1st dim, 1 means 
-// high face of 1st dim, 2 means low face of 2nd dim, 3 means high face of  2nd dim, and so on: 	, 
-
-Vektor<MFLOAT,Dim> getSurfaceNormal(NDIndex<Dim>&, unsigned); 
-
-Field<Vektor<MFLOAT,Dim>,Dim,UniformCartesian<Dim,MFLOAT>,Cell>& getSurfaceNormalField(
-Field<Vektor<MFLOAT,Dim>,Dim, UniformCartesian<Dim,MFLOAT>,Cell>&, unsigned); 
-\end{smallcode}
-
-
-\subsection{UniformCartesian Constructors}
-Aside from the default constructor, which you should not be used if you, don't know what it's there for, there are three categories of \texttt{UniformCartesian} constructors. 
-All require an argument or set of \texttt{Dim} arguments specifying the number of mesh nodes along each dimension. The one-argument form takes an \texttt{NDIndex<Dim>\&} 
-to specify this: the \texttt{length()} value of each \texttt{Index} and the \texttt{NDIndex} represents the number of mesh nodes (vertices); the multi-argument forms take 
-\texttt{Dim Index\&}'s (these are implemented only up to Dim = 3). {\it Warning:} be sure to use zero-based, unit-stride \texttt{NDIndex Index} objects; \texttt{UniformCartesian} 
-should eventually work for other cases, but for now the implementation doesn't account for non-zero base or non-unit stride for the index space spanning the mesh nodes/cells. 
-The first and simplest category of constructors has only the size arguments; here are examples of the one-argument and multi-argument case: 
-\begin{smallcode}
-Index I {5} , J {5} , K (5 ); 
-NDIndex<3> ndi; 
-ndi[0] = I; ndi[1] = J; ndi[2] = K;
-
-UniformCartesian<3> umesh1(ndi); 
-UniformCartesian<3> umesh2(I,J,K); 
-\end{smallcode}
-
-Both of these \texttt{UniformCartesian} objects will have default mesh spacings of 1.0 in all directions and an origin (location of first vertex) at (0.0, 0.0, 0.0). 
-The second category adds specification of the mesh spacings. You create an array of type MFLOAT and pass it to the constructor:
- 
-\begin{smallcode}
-double spacings[3] = {1. 0, 1,.0, 2.0}; //double because default of MFLOAT 
-UniformCartesian<3> umesh3{ndi, spacings);
-\end{smallcode} 
-
-The \texttt{umesh3} object has mesh spacings $\Delta_x= 1.0,~\Delta_y=1.0, \text{ and }\Delta_z = 2.0$. We used type \texttt{double} for the array of spacings because we used the 
-default \texttt{MFLOAT} template parameter value of \texttt{double} when instantiating \texttt{umesh3}. If we had specified something else, \texttt{UniformCartesian<3,float>}, we 
-would have had to specify \texttt{float} as the type of the spacings array. The \texttt{umesh3} object has a default origin (location of first vertex) at (0:0, 0.0, 0.0). 
-
-The third category adds specification of the origin (location of the first vertex). You create a \texttt{Vektor<MFLOAT, Dim>} and pass it as the last constructor argument: 
-
-\begin{smallcode}
-// Defining spacings and origin, use double because it's default .of MFLOAT: 
-double spacings[3] = {1.0,1.0,2.0}; 
-Vektor<double,3> origin; 
-origin(0) = 5.0; origin(1) = 6.0; origin(2)= 7.0; 
-UniformCartesian<3> umesh4(ndi, spacings, origin); 
-\end{smallcode}
-The umesh4 object has mesh spacings $\Delta_x= 1.0,~\Delta_y=1.0, \text{ and }\Delta_z = 2.0$ and origin at (5.0,6.0,7.0).
-
-
-
-\subsection{\texttt{UniformCartesian} Member Functions and Member Data} 
-\texttt{UniformCartesian} Member Data for Sizes and Spacings. There are several-public data members representing mesh size and spacing information: 
-\begin{smallcode}
-unsigned gridSizes[Dim] ;
-\end{smallcode}
-An array containing the mesh sizes-numbers of vertices along each dimension. 
-\begin{smallcode}
-typedef Cell DefaultCentering ;
-\end{smallcode} 
-Used by \texttt{Field} and other classes which are parameterized on \texttt{Mesh} and centering classes and require consistent defaults for both. 
-The general user probably need never use this member. 
-\begin{smallcode}
-Vektor<MFLOAT,Dim> Dvc[1<<Dim] ;
-\end{smallcode}
-Constants for derivatives in global differential operator functions such as \texttt{Div()}. Again, the general user probably never need know that this is publicly visible.  
-\begin{smallcode}
-bool hasSpacingFields ;
-\end{smallcode}
-Flags whether the user has requested that the mesh object internally allocate and compute mesh-spacing \texttt{BareField}'s pointed to by \texttt{VertSpacings} and \\ \texttt{CellSpacings}. 
-\begin{smallcode}
-BareField<Vektor<MFLOAT,Dim>,Dim>* VertSpacings; 
-BareField<Vektor<MFLOAT,Dim>,Dim>* CellSpacings;
-\end{smallcode}
-If you invoke the \texttt{storeSpacingFields()} function, \texttt{UniformMesh} will allocate two \texttt{BareField}'s and fill them with vertex-vertex and cell-cell mesh spacing values 
-(stored as vectors whose components are the spacings along each dimension of the cell or shifted cell). These pointers provide public access to them. 
-The general user can always use the functions like \texttt{getDeltaVertexField ()} to put spacing values into his own \texttt{Field} objects, and this may be the best way to do this in general. 
-Certain predefined \ippl global functions, such as the \texttt{Div()} differential operators, might rely on having these BareField's internally available from the mesh object associated with 
-the \texttt{Field}'s on which they operator. 
-Note: These internal \texttt{BareField}'s are redundant for \texttt{UniformCartesian} in a couple of ways. First, the mesh spacing information is the same everywhere in the \texttt{Mesh}, 
-and the vertex-vertex spacing is the same as the cell-cell spacing. The operators like \texttt{Div()} don't need \texttt{BareField}'s of spacings for the uniform Cartesian case; and they don't, 
-in fact, use them or check if they exist. Both of these redundancies are removed in the nonuniform Cartesian case, however. In this case, storing this information in the internal 
-\texttt{BareField}'s in the Cartesian objects is essential for functions like \texttt{Div(}) -they return errors if \texttt{hasSpacingFields} is false. 
-
-
-\subsection{\texttt{UniformCartesian} Set/Accessor Functions for Member Data} 
-
-\begin{smallcode}
-void storeSpacingFields ( );
-void storeSpacingFields(e_dim_tag pI, int vnodes=-I) 
-void storeSpacingFields(e_dim_tag pl, e_dim_tag p2, int vnodes=-1); 
-void storeSpacingFields(e_dim_tag pI, e_dim_tag p2, e_dim_tag p3, int vnodes=-1); 
-void storeSpacingFields(e_dim_tag *p, int vrlodes=-1);
-\end{smallcode}
-The \texttt{UniformCartesian} class will optionally create internal \texttt{BareField}'s of appropriate sizes and fill them with vertex-vertex arid cell-cell spacing values. 
-You access these \texttt{BareField}'s via the \texttt{VertSpacings} and \texttt{CellSpacings} pointers described above. 
-The \texttt{storeSpacingFields()} functions make this happen. Because they are constructing \texttt{BareField}'s, they provide prototypes based on those for \texttt{FieldLayout} 
-so you can control the serial/parallel layout of the \texttt{BareField}'s, you specify which dimensions are serial or parallel using lists or an array of \texttt{e\_dim\_tag} 
-values (\texttt{SERIAL} or \texttt{PARALLEL}). If you use the first prototype, with no arguments, you will get the default \texttt{FieldLayout} for the internal \texttt{BareField}'s: 
-parallel for all dimensions.
-
-\begin{smallcode}
-Vektor<MFLOAT,Dim> get_origin();
-\end{smallcode}
-Returns the value of the origin of the mesh (position in space of the lowest mesh vertex). 
-
-\begin{smallcode}
-MFLOAT get_meshSpacing(int d);
-\end{smallcode}
-Returns the mesh spacing value for the specified direction. There is only one value for uniform spacing; thus the return type \texttt{MFLOAT}. 
-\begin{smallcode}
-MFLOAT get_volume() ;
-\end{smallcode}
-Returns the volume of a cell, which is the same everywhere in a uniform Cartesian mesh. 
-
-
-\subsection{Other UniformCartesian Methods} 
-Most of the public member functions in \texttt{UniformCartesian} are designed to return some typical kinds of geometrical information about the \texttt{Mesh} that a user (programmer or class) might want. 
-Where the information or input parameters are more complex than single \texttt{MFLOAT} values, the function return values or arguments are typically \ippl classes  such as \texttt{Field}.
-The set of functions evolved from general discussions among application programmers of, what is expected of a mesh, and we will continue to evolve its design iteratively as new applications demand new \texttt{Mesh} 
-information. Many of these functions use \texttt{NDIndex} to index mesh vertices and cells. \texttt{NDIndex} has no intrinsic awareness of centering, but can clearly represent index values specifying 
-mesh node or cell positions. The user must keep in mind that cell 0 along a dimension is between node 0 and node 1, and that there are one fewer cells than vertices. 
-\begin{smallcode}
-MFLOAT getCellVolume(NDIndex<Dim>&);
-\end{smallcode} 
-Volume of single cell indexed by input \texttt{NDIndex}. The argument must describe a single element. That is, the range of every \texttt{Index} in the \texttt{NDIndex} must be 1. The \texttt{getCellVolume()} function 
-returns an error otherwise.
-
-\begin{smallcode}
-Field<MFLOAT,Dim,UniformCartesian<Dim,MFLOAT>, Cell>& 
-getCellVolumeField (Field<MFLOAT, Dim, UniformCartesian<Dim,MFLOAT>,Cell>&);
-\end{smallcode}
-Field of volumes of all cells. This function basically assigns every element of the cell-centered Field to the return value of \texttt{getCellVolume ( )}. For a \texttt{UniformCartesian} mesh, this is obviously redundant,
-but the function is here for interface compatibility with \texttt{Cartesian} (which represents a nonuniform Cartesian mesh, for which this is not redundant). 
-If you are only using \texttt{UniformCartesian} mesh objects, you should just use the single cell-volume value retuned by \texttt{getCellVolume}; this will combine with other\texttt{ Field}'s of 
-values in your code the same way any scalar value will do. 
-\begin{smallcode}
-MFLOAT getVertRangeVolume(NDIndex<Dim>&);
-\end{smallcode} 
-Volume of range of cells bounded by vertices specified by input \texttt{NDIndex}, which in this context will generally have a range greater than one in at least one dimension. The vertices represented by the lowest and 
-highest index value set contained in the \texttt{NDIndex} mark the corners of a rectangular solid region; this function returns the volume of that region. 
-\begin{smallcode}
-MFLOAT getCellRangevolume(NDIndex<Dim>&);
-\end{smallcode}
-Volume of range of cells spanned by input \texttt{NDIndex} (index of cells). This is like \texttt{getVertRangeVolume( )} , except that the corners of the rectangular solid are 
-cell-center positions rather than vertex positions. 
-
-\begin{smallcode}
-NDIndex<Dim>& getNearestvertex(Vektbr<MFLOAT,Dim>&);
-\end{smallcode}
-Nearest vertex index to a point in space (x,y,z). 
-
-\begin{smallcode}
-NDIndex<Dim>& getVertexBelow(Vektor<MFLOAT,Dim>&);
-\end{smallcode} 
-Nearest vertex inpex with all vertex coordinates below a point in space (x,y,z). 
-
-\begin{smallcode}
-NDIndex<Dim>& getCellContaining(Vektor<MFLOAT,Dim>&) ;
-\end{smallcode}
-\texttt{NDIndex} for the mesh cell containing the point (x,y,z). Use this, for example, to index a corresponding element in a cell-centered \texttt{Field}. 
-
-\begin{smallcode}
-Vektor<MFLOAT,Dim> getVertexposition(NDIndex<Dim>&) ;
-\end{smallcode}
-(x,y,z) coordinates of the \texttt{Mesh} vertex indexed by the \texttt{NDIndex}, which just have a range of one in all dimensions (that is, it must index a single point in index space). 
-
-\begin{smallcode}
-Field<Vektor<MFLOAT, Dim>, Dim, UniformCartesian<Dim,MFLOAT>,Vert>& 
-getVertexPositionField(Field<Vektor<MFLOAT, Dim>, Dim, UniformCartesian<Dim,MFLOAT>,Vert>& );
-\end{smallcode}
-Fills a vertex-centeredField with the (x,y,z) coordinates of all mesh vertices. 
-
-\begin{smallcode}
-Vektor<MFLOAT, Dim> getDeltaVertex (NDIndex<Dim>&); 
-\end{smallcode}
-Vertex-vertex grid spacing $(\Delta_x, \Delta_y, \Delta_z)$ of the cell indexed by the NDIndex. 
-
-\begin{smallcode}
-Field<Vektor<MFLOAT, Dim>, Dim, UniformCartesian<Dim,MFLOAT>,Cell>& 
-getDeltaVertexField(Field<Vektor<MFLOAT,Dim>,Dim, UniformCartesiap<Dim,MFLOAT>,Cell>& );
-\end{smallcode}
-Fills a cell-centered Field with the vertex-vertex grid spacings $(\Delta_x, \Delta_y, \Delta_z)$  of all cells. 
-
-\begin{smallcode}
-Vektor<MFLOAT,Dim> getDeltaCell(NDIndex<Dim>&) ;
-\end{smallcode}
-Cell-cell grid spacing $(\Delta_x, \Delta_y, \Delta_z)$ of indexed cell vertex. That is, this returns the distance between the cell centers on either side of the vertex position indexed by the \texttt{NDIndex} for each dimension. 
-
-\begin{smallcode}
-Field<Vektor<MFLOAT, Dim>, Dim,uniforrnCartesian<Dim, MFLOAT>, Vert>& 
-getDeltaCellField(Field<Vektor<MFLOAT,Dim>,Dim, UniformCartesian<Dim,MFLOAT>,Vert>& ) ;
-\end{smallcode}
-Fills a vertex-centered Field with,the cell-cell grid spacings $(\Delta_x, \Delta_y, \Delta_z)$ around all vertices. 
-
-\begin{smallcode}
-Vektor<MFLOAT,Dim>* getSurfaceNormals(NDIndex<Dim>&) ;
-\end{smallcode}
-Array of surface normals to cells adjoining indexed cell. This is trivial for a Cartesian mesh, and is the same for every cell even in the nonuniform spacing cases represented by \texttt{Cartesian}. 
-Future implementations in non-cartesian mesh classes would be more complicated. 
-
-\begin{smallcode}
-void getSurfaceNormalFields(Field<Vektor<MFLOAT,Dim>,Dim, UniformCartesian<Dim,MFLOAT>,Cell>**);
-\end{smallcode}
-Fills the Field's pointed to by the array with of surface normals to all cells. Again, this is trivial for a cartesian mesh, and the values are the same everywhere; but future implementations in non-cartesian meshes would be more complicated. 
-
-\begin{smallcode}
-Vektor<MFLOAT,Dim> getSurfaceNormal(NDIndex<Dim>&, unsigned) ;
-
-Field<Vektor<MFLOAT,Dim>,Dim, UniformCartesian<Dim,MFLOAT>,Cell>& 
-getSurfaceNormalField(Field<Vektor<MFLOAT,Dim>,Dim, 
-	UniformCartesian<Dim,MFLOAT>,Cell>&, unsigned) ;
-\end{smallcode}
-Similar functions to \texttt{getSurfaceNormals()} and \texttt{getSurfaceNormalFields()}, but specify the surface normal to a single face, using the following numbering convention: 
-0 means low face of 1st dimension, 1 means high face of 1st dimension, 2 means low face of 2nd dimension, 3 means high face of 2nd dimension; and so on. 
-
-\section{\texttt{Cartesian} Class}
-\label{app:cartclass} 
-The \texttt{Cartesian} class represents the abstraction of a nonuniform-spacing Cartesian mesh discretizing a rectilinear region of space. The mesh spacings vary cell-by-cell along each dimension. As much as possible, the 
-\texttt{Cartesian} interface is identical to the \texttt{UniformCartesian} interface described in Section xxx. It has the same mechanisms for returning various kinds of geometrical information from the \texttt{Mesh}: 
-cell-cell and vertex-vertex spacings, nearest mesh vertex positions to a given point in space, and others. 
-Like \texttt{UniformCartesian, Cartesian} is parameterized on dimensionality \texttt{Dim}, and another parameter \texttt{MFLOAT} which specifies the elemental type to use in storing and returning mesh geometrical 
-information such as spacings and position coordinates. Generally, this should be a floating-point type, and it defaults to \texttt{double}. Vector values are represented using \texttt{Vektor<MFLOAT,Dim>}. 
-This chapter only discusses the places where the \texttt{Cartesian} interface differs from the \texttt{UniformCartesian} interface. Refer to Section xxx for all other information about \texttt{Cartesian}; substitute "\texttt{Cartesian}" for "\texttt{UniformCartesian}" in places such as the \texttt{Mesh} parameter for \texttt{Field} arguments to the member functions. To help with this, we show the entire \texttt{Cartesian} public definition in the next section; 
-in the subsequent sections discussing the member functions and data, we discuss only the cases that differ from \texttt{UniformCartesian}. 
-
-\subsection{\texttt{Cartesian} Definition (Public Interface)}
- Enumeration used for specifying mesh boundary conditions. Mesh BC are used  for things like figuring out how to return the mesh spacing for a cell 
-beyond the edge of the physical mesh, as might arise in stencil operations lion Field's on the mesh.
- 
-\begin{smallcode}
-
-enum MeshBC_E { Reflective, Periodic, None };
-char* MeshBC_E_Names"[3] = {"Reflective", "Periodic ", "None"} ;
-
-template < unsigned Dim, class MFLOAT=double> 
-class Cartesian : public Mesh<Dim> 
-{ 
-public: 
-// Public member data: 
-unsigned gridSizes[Dim]; // Sizes (number of vertices) 
-typedef Cell DefaultCentering; //Default cemtering (used by Field,etc.)
-Vektor<MFLOAT,Dim> Dvc[1<<Dim];  // Constants for derivatives. 
-
-bool hasSpacingFields; // Flags allocation of the following:
-BareField<Vektor<MFLOAT,Dim>, Dim>* VertSpacings;
-BareField<Vektor<MFLOAT, Dim>, Dim>* CellSpacings;
-
-// Public member functions: 
-// Constructors 
-Cartesian() {} ; // Default constructor 
-
-// Non-default constructors 
-Cartesian (NDIndex<Dim>& ndi); 
-Cartesian(Index& I);
-Cartesian(Index& I; Index& J);
-Cartesian(Ihdex& I, Index& J, Index& K);
-
-// These also take a MFLOAT** specifying the mesh spacings: 
-Cartesian(NDIndex<Dim>& ndi, MFLOAT** delX); 
-Cartesian(Index& I, MFLOAT** delX);
-Cartesian(Index& I, Index& J, MFLOAT**deIX); 
-Cartesian(Index& I, Index& J, Index& K, MFLOAT** deIX); 
-
-// These further take a Vektor<MFLOAT,Dim>& specifying the origin:
-Cartesian(NDIndex<Dim>& ndi, MFLOAT** deIX,Vektor<MFLOAT,Dim>& orig); 
-Cartesian(Index& I, MFLOAT** delX, Vektor<MFLOAT,Dim> orig); 
-Cartesian (Index& I, Index& J, MFLOAT* * delX, Vektor<MFLOAT ,Dim>& orig) ; 
-Cartesian(Index& I, Index& J, Index& K, MFLOAT** delX, Vektor<MFLOAT,Dim>& orig); 
- 
-// These further take a MeshBC_E array specifying mesh boundary conditions, 
-Cartesian(NDIndex<Dim>& ndi, MFLOAT** delX, Vektor<MFLOAT,Dim>& arig, MeshBC_E* mbc);
-Cartesian (Index& I, MFLOAT* * deIX, Vektor<MFLOAT, Dim> arig, MeshBC_E* mbc); 
-Cartesian(Index& I, Iridex& J, MFLOAT** delX, Vektor<MFLOAT,Dim>& orig, MeshBC_E* mbc); 
-Cartesian(Index& I, Index& J, Index& K, MFLOAT** delX, Vektor<MFLOAT,Dim>& arig, MeshBC_E* mbc); 
--Cartesian () { };
-\end{smallcode}
-
-Set functions for member data: create\texttt{ BareField}'s of vertex and cell spacings; allow for specifying layouts via the \texttt{FieldLayaut e\_dim\_tag} and vnodes parameters 
-(these get passed by constructing  the \texttt{FieldLayaut} and used to, construct the \texttt{BareField}' s) . 
-
-\begin{smallcode}
-
-void stareSpacingFields(); // Default will have default layaut 
-
-// Special cases far 1-3 dimensians, ala FieldLayaut ctars: 
-void stareSpacingFields(e_dim_tag p1; int vnodes=-1); 
-void stareSpacingFields (e_dim_tag pl, e_dim_tag p2, int vnodes=-1); 
-void stareSpacingFields(e_dim_tag p1, e_dim_tag p2, e_dim_tag p3, int vnodes=-1); 
-
-// Next we have ane far arbitrary dimensian,a la FieldLayaut ctor: 
-// All the others call this one internally: 
-void storeSpacingFields(e_dim_tag *p, int vnodes=-1);
- 
-// Accessar functians far member data: 
-// Get the arigin of mesh vertex pasitians: 
-Vektor<MFLOAT,Dim> get_orgin(); 
- 
-// Get the spacings of mesh vertex positions along specified direction: 
-MFLOAT* get_meshSpacing(int d); 
-
-// Get mesh boundary conditions: 
-MeshBC_E get_MeshBC(unsigned face);     // One face at a time 
-MeshBC_E* get_MeshBC () ; 	                        // All faces at ance
-
-// Formatted output of Cartesian object: 
-void print(ostream&); 
-
-// Stream formatted output of Cartesian abject:
-friend ostream& operato<<(ostream&, const Cartesian<Dim,MFLOAT>&);
- 
-  
-// Other Cartesian methods
-  
-// Volume of a single cell indexed by input NDIndex
-MFLOAT getCellVolume(NDIndex<Dim>&); 
-  
-// Field of Volumesof of all cells
-Field<MFLOAT,Dim,Cartesian<Dim,MFLOAT>, Cell>& getCellVolumeField(
-Field<MFLOAT,Dim,Cartesian<Dim,MFLOAT>,Cell>&);
-   
-// Volume of range of cells bounded by verticies specified by input NDIndex: 
-MFLOAT getVertRangeVolume (NDIndex<Dim>&);
-    
-// Volume of range of cells spanned by input NDIndex (index of cells) 
-MFLOAT getCellRangeVolume(NDIndex<Dim>&);
-     
-// Nearest vertex index to, (x,y,z)
-NDIndex<Dim>& getNearestVertex (Vektor<MFLOAT, Dim>&);
-
-// Nearest vertex index with all vertex coordinates below (x,y, z)
-NDIndex<Dim>& getVertexBelow(Vektor<MFLOAT,Dim>&); 
-
-// NDIndex for cell in cell-ctrd Field containing the point (x,y, z) 
-NDIndex<Dim>& getCellContaining(Vektor<MFLOAT,Dim>&); 
-
-// (x,y,z) coordinates of indexed vertex
-Vektor<MFLOAT,Dim> getVertexPosition(NDIndex<Dim>&); 
-
-// Field of (x,y,z) coordinates of all vertices: 
-Field<Vektor<MFLOAT,Dim> ,Dim, Cartesian<Dim,MFLOAT>,Vert>& getVertexPositionField(
-Field<Vektor<MFLOAT,Dim>, Dim, Cartesian<Dim,MFLOAT>,Vert>&);
-
-// Vertex-vertex grid spacing of indexed vertex
-Vektor<MFLOAT,Dim> getDeltaVertex(NDIndex<Dim>&);
- 
-// Field of vertex-vertex grid spacings of all vertices
-Field<Vektor<MFLOAT,Dim> ,Dim, Cartesian<Dim, MFLOAT> , Cel 1>& getDeltaVertexField(
-Field<Vektor<MFLOAT,Dim>, Dim, Cartesian<Dim,MFLOAT>,Cell>& );
-
-// Cell-cell grid spacing of indexed cell: 
-Vektor<MFLOAT,Dim> getDeltaCell(NDIndex<Dim>&);
-
-// Field of cell-cell grid spacings of all vertices: 
-Field<Vektor<MFLOAT,Dim>, Dim, Cartesian<Dim,MFLOAT>,Vert>& getDeltaCellField(
-Field<Vektor<MFLOAT,Dim>,Dim, Cartesian<Dim,MFLOAT>,Vert>& );
-
-// Array of surface normals to cells adjoining indexed cell: 
-Vektor<MFLOAT,Dim>* getSurfaceNormals(NDIndex<Dim>&);
-
-// Array of (pointers to) Fields of surface normals to all cells: 
-void getSurfaceNormalFields(Field<Vektor<MFLOAT,Dim>,Dim, Cartesian<Dim,MFLOAT>,Cell>** );
-\end{smallcode}
- Similar functions, but specify the surface normal to a single face, using the following numbering convention: 0 means low face of 1st dim, 1 means 
- high face of 1st dim, 2. means low face of 2nd dim, 3 means high face of 2nd dim, and so on:
- \begin{smallcode}
-Vektor<MFLOAT,Dim> getSurfaceNormal(NDIndex<Dim>&, unsigned);
-Field<Vektor<MFLOAT,Dim>,Dim, Cartesian<Dim, MFLOAT> , Cel 1>& getSurfaceNormalField(
-Field<Vektor<MFLOAT,Dim>,Dim, Cartesian<Dim,MFLOAT>,Cell>&, unsigned);
-} ;
-\end{smallcode}
-
-
-
-\subsection{Cartesian Constructors} 
-Aside from the default constructor, which you should not be using if you don't know what it's there for, there are four categories of \texttt{Cartesian} constructors. 
-The first three are the same as for \texttt{UniformCartesian} (see Section xxx), except that specifying mesh spacings requires more than just a single \texttt{MFLOAT} value for \texttt{Cartesian( )}. 
-You must pass in an array of arrays of \texttt{MFLOAT} values \texttt{(MFLOA T * * )} one array for each dimension, having size given by the number of cells along that dimension. 
-The new fourth constructor category adds specification of mesh-spacing boundary conditions. 
-You create an array of type \texttt{MeshBC\_E}, an enumeration having values \texttt{\{Reflective,Periodic,None\}}. This tells \texttt{Cartesian} how to provide geometry information such as 
-mesh spacings beyond the physical edge of the mesh, as might arise in implementing differential operators using finite differencing of \texttt{Field}'s centered on the mesh. There are 
-basically only two ways to do this: wrap around periodically to mesh spacing values inside the physical mesh, or reflect the mesh spacing values across the boundary. The user should 
-avoid specifying \texttt{None} for mesh boundary-condition types. The following code example illustrates using this fourth constructor category for \texttt{Cartesian()}, and how to set up 
-mesh spacing and boundary condition specifiers: 
-\begin{smallcode}
-
-const unsigned Dim = 3U;
-unigned nx=5, ny=5, nz=5; 
-Index I(nx),J(nz) ,K(nz);
-
-NDIndex<Dim> ndi; 
-ndi[0] = I; ndi[1] = J; ndi[2] =K; 
-
-// Defining spacings and origin, use double because it's default of MFLOAT: 
-double* spacings[Dim]; 
-spacings[0] = new double [nx] ; 
-spacings[1] = new double [ny] ; 
-spacings[2] = new double [nz];
- 
-int vert; 
-for (vert=0; vert < nx; vert++) (delX[0]) [vert] = 1.0 + vert*1.0;
-for (vert=0; vert < ny; vert++) (delX[1]) [vert] = 2.0 + vert*2.0;
-for (vert=0; vert < nz; vert++) (delX[2]) [vert] = 3.0 + vert*3.0;
-
-Vektor<double,Dim> origin; 
-origin(0) = 5.0; 
-origin(1) = 6.0; 
-origin(2) = 7.0'
-
-MeshBC_E meshbc[2*Dim];
- 
-for (unsigned face=0; face < (2*Dim); face++) 
- meshbc[face] =Reflective; 
- 
-Cartesian<Dim> cmesh(ndi, ,spacings, origin, meshbc); 
-
-\end{smallcode}
-The \texttt{cmesh} object has mesh spacings $\Delta_x = {1.,2., \dots}, \Delta_y = {2.,3., \dots} \text{ and } \Delta_z = {3.,6., \dots}$ the origin is at (5.0, 6.0, 7.0) and reflective mesh boundary conditions on all faces. 
-The other three cases of \texttt{Cartesian ()} are like this but with fewer parameters. As in \texttt{UniformCartesian}, if the origin is unspecified it defaults to (0,0,0), 
-if the mesh spacings are unspecified they default to uniform values of 1.0 for all cells along all axes. The mesh boundary conditions default to \texttt{Reflective} on all faces. 
-
-\subsection{\texttt{Cartesian} Member Functions and Member Data} 
-\subsubsection{ \texttt{Cartesian} Member Data for Sizes and Spacings}
-The types are all the same as for \texttt{UniformCartesian} (See Appendix \ref{app:unifcart} ). The values of and interpretation of the \texttt{Dvc} data member are completely different; functions such as \texttt{Div()} which 
-use this information to implement differential operators must account properly for the variation of mesh spacing values and the difference between cell-cell and vertex-vertex spacings in the nonuniform case. 
-For \texttt{UniformCartesian}, the single \texttt{Dvc} array could hold all the necessary information; for \texttt{Cartesian}, a slightly different \texttt{Dvc} coordinates with VertSpacings and CellSpacings, 
-which must exist before the user can invoke operators such as \texttt{Div()}.
-
-\subsubsection{\texttt{Cartesian} Set/Accessor Functions for Member Data}
-Except for the return value of\texttt{ get\_meshSpacing()} , and the new functions \texttt{get\_MeshBC()} ,the interfaces and descriptionsare all the same as for\\  \texttt{UniformCartesian}. (See Appendix \ref{app:unifcart}).
-\begin{smallcode}
-MFLOAT* get_meshSpacing(int d);
-\end{smallcode}
-Returns the array of mesh-spacing values along the specified direction. The number of elements in the arrays the number of cells in the mesh along that dimension. 
-\begin{smallcode}
-MeshBC_Eget_MeshBC (uns,igned face) ;
-\end{smallcode}
-Returns the value of the mesh boundary-condition specifier for the requested face of the mesh. The numbering convention for faces is: 0 means low face of 1st dimension, 1 means high face of 1 st dimension, 
-2 means low face of 2nd dimension, 3 means high face of 2nd dimension, and so on. 
-\begin{smallcode}
-MeshBC_E* get_MeshBC(); 
-\end{smallcode}
-Returns the array of values of mesh boundary-condition specifiers for all faces of the \texttt{Mesh}, following the numbering convention described in the description of the one-argument prototype 
-of this function above. The number of elements in the array is two times the number of dimensions. 
- 
-\subsubsection{Other Cartesian Methods} 
-As for \texttt{UniformCartesian}, most of the public member functions in \texttt{Cartesian} are designed to return some typical kinds of geometrical information about  the mesh that a user (programmer or class) 
-might want. So far, all of the member functions mirror \texttt{UniformCartesian} exactly, except for the occasional replacement of \\  "\texttt{Cartesian}" for 
-"\texttt{UniformCartesian}" in mesh template-parameters for \texttt{Field} arguments.
-
-
-
-
-
-
-
-
-
diff --git a/manual/ippl_particles.tex b/manual/ippl_particles.tex
deleted file mode 100644
index 0e144747c..000000000
--- a/manual/ippl_particles.tex
+++ /dev/null
@@ -1,301 +0,0 @@
-\chapter{Particles}
-\label{sec:particles}
-This section describes the \ippl framework classes which provide the capability to performing particle-based simulations. We first describe how to design and instantiate \texttt{Particle} classes customized to the needs of a specific application, and then discuss the possible operations and expressions in which a particle object may be employed and end with an ready to use example.
-
-\section{Basic \texttt{Particle} Object Characteristics}
-
-The \ippl framework treats \texttt{Particle} classes as containers which store the characteristic data for \texttt{N} individual particles. Each particle has several attributes, such as position, mass, velocity, etc. Looked at in another way, \texttt{Particle} classes store several attribute containers, where each attribute container holds the value of that attribute for all \texttt{N} particles. \texttt{Particle} objects in \ippl may be thought of as shown in the following diagram: ...
-
-There are two particle attributes predefined, namely R (position) and ID a global unique identifier.
-
-The data type of each attribute, the number of attributes, and the names for these attributes are completely customizable, and are specified in the manner described in the following sections. Any number of different \texttt{Particle} classes may be defined and used within a given simulation. Also, the \texttt{Particle} objects may interact with \ippl \texttt{Field} objects or may be used independently. In addition to the attributes, each \texttt{Particle} object uses a specific layout mechanism, which describes the data of the individual particles is spread across the processors in a parallel environment. The \ippl framework provides several different \texttt{Particle} layout classes, any of which may be selected to partition the particle data among processors. The choice of layout depends on the intended use of the \texttt{Particle} object, as discussed later. Once defined and instantiated, \texttt{Particle} objects in the \ippl framework may be used in many ways, including:
-\begin{itemize}
-    \item Operations involving all the particles within a \texttt{Particle} object may be specified using simple expressions, in a manner very similar to that used for \texttt{Field} objects. These expressions may involve any of the attributes of the particles as well as other scalar data, and they may use not only the standard mathematical operators +, -, *, /, etc., but also standard mathematical functions such a s cos ( ) , exp ( ) , mod ( ) , etc.
-    \item Alternatively, you may set up explicit loops that perform operations involving the attributes of a single particle or a subset of all the particles.
-    \item \texttt{Particle}s may be created or destroyed during a simulation.
-    \item \texttt{Particle}-to-\texttt{Field} and \texttt{Field}-to-\texttt{Particle} operations may be performed (e.g., a particular \texttt{Particle} attribute may be deposited onto a specified \texttt{Field} using a chosen interpolation method). 
-\end{itemize}
-
-\section{Defining a User-Specified \texttt{Particle} Class}
-
-There is no specific class within the \ippl framework called \texttt{Particle}. Rather, the first step in deploying particles within a \ippl application is to define a user-specified \texttt{Particle} class, which contains the attributes required for each particle, as well as any, specific methods or data the user may need. To do this, the \texttt{ParticleBase} and \texttt{ParticleAttrib} classes are used, along with a selected subclass of the \texttt{ParticleLayout} class. The steps to follow in creating a new \texttt{Particle} class are:
-\begin{itemize}
-    \item Based on the type of interactions which the particles have with each other and with external objects such as a \texttt{Field}, select a method of distributing the particles among the nodes in a parallel machine.
-    \item Next, decide what attributes each particle should possess.
-    \item Third, create a subclass of \texttt{ParticleBase} which includes these attributes (specified as instances of the \texttt{ParticleAttrib} class template).
-    \item Finally, instantiate this user-defined subclass of \texttt{ParticleBase} and create and initialize storage for the particles which are to be maintained by this object. 
-\end{itemize}
-
-The following sections describe in more detail how to accomplish these steps.
-
-\subsection{Selecting a Layout: \texttt{ParticleLayout} and Derived Classes}
-
-When used in a parallel environment, the \ippl framework partitions the particles in a \texttt{Particle} container among the separate processors and includes tools to spread the work of computing and the results of expressions involving \texttt{Particle} attributes among the processing nodes. There are, however, different ways in which particles may be distributed among the processors, and the method which should be used depends upon how the particles in a \texttt{Particle}
-object will interact with each other and with \texttt{Field} objects (if at all). The \ippl framework includes different \texttt{Particle} layout mechanisms, which are all derived from the \texttt{ParticleLayout} class. Each \texttt{Particle} object needs its own layout object; that is, you cannot create a layout object and give it to more than one \texttt{Particle} object. The methods typically used to determine how to assign particles to particular nodes are based on analysis of the
-position (\texttt{R} attribute) of each particle. Thus, \texttt{ParticleLayout} and its derived classes have two template parameters: the type and the dimensionality of the particle position attribute (this particle position attribute is discussed in more detail later). The following sections describe the particle layout mechanisms currently available in the \ippl framework.
-
-\subsection{The \texttt{{\color{red} ParticleUniformLayout} Class}}
-{\color{red} can be removed}
-
-\subsection{The \texttt{ParticleSpatialLayout} Class}
-
-\texttt{ParticleSpatialLayout}, in contrast to \texttt{ParticleUniformLayout}, assigns particles to nodes based upon their spatial location relative to a \texttt{FieldLayout}. It is useful when the particles will be interacting with other particles in their neighborhood or with a \texttt{Field} object. \texttt{ParticleSpatialLayout} will keep a particle on the same node as that which contains the section of the \texttt{Field} in which the particle is located. If the particle moves to a new position, this layout will reassign it to a new node when necessary. This will maintain locality between the particles and any \texttt{Field} distributed using this \texttt{FieldLayout}. Further more it will help keep particles which are spatially close to each other local to the same processor as well. As with all the layout classes, \texttt{ParticleSpatialLayout} requires the type and dimensionality of the particle position attribute as template parameters. The constructor for \texttt{ParticleSpatialLayout} takes one argument: a pointer to a \texttt{FieldLayout} object that tells the \texttt{ParticleSpatialLayout} how the \texttt{Field} is allocated among the parallel processors, so that the particles may be maintained local to this \texttt{Field}. Note that you do not, need to create a \texttt{Field} instance itself, you only need to give \texttt{ParticleSpatialLayout} a \texttt{FieldLayout} object. An example of creating an instance of this class is as follows:
-\begin{smallcode}
-FieldLayout<3> myfieldlayout(Index(l6), Index(16), Index(32)); 
-ParticleSpatialLayout<double,3> myparticlelayout(&myfieldlayout);
-\end{smallcode}
-
-
-Note that the dimensionality of the \texttt{FieldLayout} and the \texttt{ParticleSpatialLayout} (in this example, 3) must be the same. You may also create a \texttt{ParticleSpatialLayout} instance without providing a \texttt{FieldLayout}. In this case, particles will remain on the node on which they were created. If at some future time you wish to provide a \texttt{FieldLayout} object to tell the \texttt{ParticleSpatialLayout} where to place the particles, you may do so using the \texttt{setFieldLayout} (\texttt{FieldLayout<Dim>*}) method of \texttt{ParticleSpatialLayout}. This is useful when reading particles in from an external source and the size of the spatial domain containing the particles is not known until all the particles have been read. The following example demonstrates the use of the capability:
-\begin{smallcode}
-ParticleSpatiaILayout<double,3> myparticleLayout; 
-// calculate the size of the domain required to contain all the particles 
-// create a new FieldLayout object based on these calculations 
-FieldLayout<3> myfieldlayout(Index(minx, maxx), Index (miny, maxy), 
-                             Index(minz,maxz);   
-myparticlelayout.setFieldLayout(&myfieldlayout);
-\end{smallcode}
-
-\texttt{ParticleSpatialLayout} also provides functionality to maintain cached ghost particles from neighboring nodes which might be required for particle - particle interaction. A caching policy can be defined using the fourth template parameter of \texttt{ParticleSpatialLayout}:
-\begin{smallcode}
-typedef UniformCartesian<Dim, double> Mesh_t;
-typedef ParticleSpatialLayout<double,Dim,Mesh_t,
-        BoxParticleCachingPolicy<double, Dim, Mesh_t> > playout_t;
-\end{smallcode}
-The available chaching policies are: \texttt{NoParticleCachingPolicy},\texttt{BoxParticleCachingPolicy} and \texttt{CellParticleCachingPolicy}. With \texttt{NoParticleCachingPolicy} there is no caching whatsoever. \texttt{BoxParticleCachingPolicy} extends the interface of \texttt{ParticleSpatialLayout} by two functions \texttt{void setCacheDimension(int d, T length)} and \texttt{void setAllCacheDimensions(T length)} which are used to set the size of the cached region around the local domain in units of space. \texttt{CellParticleCachingPolicy} extends the interface of \texttt{ParticleSpatialLayout} by two functions \texttt{void setCacheCellRange(int d, int length)} and \texttt{void setCacheCellRanges(int d, int length)} which are used to set the size of the cached region around the local domain in units of grid cells of the mesh. \texttt{BoxParticleCachingPolicy} is the default policy.
-
-The caching can be enabled or disabled by calling the \texttt{enableCaching()} or \texttt{disableCaching()} member functions of \texttt{ParticleSpatialLayout}. Caching is disabled by default.
-
-
-\subsection{Selecting Particle Attributes: The \texttt{ParticleAttrib} \\Class}
-
-\texttt{ParticleAttrib} is a class template that represents a single attribute of the particles in a \texttt{Particle} object. Each \texttt{ParticleAttrib} contains the data for that attribute for all the particles. Within a user-defined \texttt{Particle} class, you declare an instance of \texttt{ParticleAttrib} for each attribute the particles will possess and assigns to it an arbitrary name. \texttt{ParticleAttrib} requires one template parameter, the type of the data for the attribute. As an example, the statement:
-\begin{smallcode}
-ParticleAttrib<double> density; 
-\end{smallcode}
-
-declares an instance of \texttt{ParticleAttrib} named 'density', which will store a quantity of type double for all the particles of the \texttt{Particle} class that contains this data member.
-
-\subsection{Specifying a User-Defined \texttt{Particle} Class: \\The \texttt{ParticleBase} Class}
-
-\texttt{ParticleBase} is the class that all user-defined \texttt{Particle} classes must specify as their base class. It stores the list of attributes for the particles (which are maintained as instances of \texttt{ParticleAttrib}) and a selected parallel layout mechanism. In addition to providing all the capabilities for performing operations on the particles and their attributes, \texttt{ParticleBase} also defines two specific attributes which all user-defined \texttt{Particle} classes inherit:
-\begin{smallcode}
-ParticleAttrib<Vektor<T,Dim>>  R; 
-ParticleAttrib<unsigned>      ID;
-\end{smallcode}
-
-
-The first attribute, \texttt{R}, represents the position of each particle. Each position is stored as a \texttt{Vektor<T, Dim>}, which is a \ippl data type representing a dim-dimensional vector with elements of type \texttt{T}. The second attribute, \texttt{ID}, stores a unique unsigned integer value for each particle. The values are not guaranteed to be in any particular order, but they are guaranteed to be unique for each particle. \texttt{ParticleBase} has one template parameter, the layout class to be used to assign particles
-to processors (e.g., \texttt{ParticleSpatialLayout}). The data type and dimensionality of the particle position attribute (\texttt{R}) will be the same as those used to create the specific \texttt{ParticleLayout} derived class. Each \texttt{ParticleBase} contains one instance of the chosen layout class. There are two constructors for \texttt{ParticleBase}: a default constructor that creates a new instance of the layout class using the layout's default constructor, and a constructor which takes a pointer to an instance of the
-layout class. The second version of the \texttt{ParticleBase} constructor is useful when the desired layout class requires arguments to its constructor (e.g., \texttt{ParticleSpatialLayout}, which may be give in a \texttt{FieldLayout} pointer).
-
-Using \texttt{ParticleBase}, \texttt{ParticleAttrib}, and a selected class derived from \texttt{ParticleLayout,} you can create a user-defined \texttt{Particle} class using the following code template: \\
-\clearpage
-\begin{codeln}
-class Bunch : public ParticleBase< ParticleSpatiaILayout<double,3> > 
-{ 
-public: 
-    // Attributes for this particle class (besides position and ID). 
-    ParticleAttrib<double>             qm;      // q/m ratio 
-    ParticleAttribs Vektor<double,2> > vel; 	// velocity 
-
-    // constructor 
-    Bunch(Layout\_t *L) : ParticleBase<Layout\_t>(L) { 
-        addAttribute(qm); 
-        addAttribute(vel); 
-    } 
-}; 
-\end{codeln}
-
-Let us describe this example in detail by discussing the important lines in the order of use.
-
-Line 1: You may select whatever name is appropriate for the specialized \texttt{Particle} class, but it must be derived from \texttt{ParticleBase}. 
-
-In this case, we explicitly specify the type of layout to use (\texttt{ParticleSpatialLayout}), with particle position attribute type and dimensionality template parameters of double and 3, respectively. Alternatively, \texttt{Bunch} may have been declared as a class template itself and may have passed on the layout template parameters to \texttt{ParticleBase}. In that case, the first line would instead look like
-\begin{smallcode}
-template <class PLayout> 
-class Bunch : public ParticleBase<PLayout> 
-\end{smallcode}
-
-Lines 5-6: Here is where the attributes for the particles in the \texttt{Particle} object are declared. They may be given any name other than \texttt{R} or \texttt{ID}. Instead of stating the type and dimensionality of this attribute specifically, you may also use one of the following typedefs and constants defined in \texttt{ParticleBase}:
-\begin{itemize}
-          \item \texttt{Dim} - the dimensionality of the particle position attribute (in this example, 3)
-          \item \texttt{Position\_t} - the type of data used to store the position attribute components (here, this type is double)
-          \item \texttt{Layout\_t} - a synonym for the specified layout class
-          \item \texttt{ParticlePos\_t} - a typedef for the particle position attribute; it is shorthand for \texttt{ParticleAttrib< Vektor<Position\_t,Dim> >}
-\end{itemize}
-and could have been used to specify the attribute \texttt{vel} in the above example as \texttt{ParticlePos\_t vel};
-\begin{itemize}
-\item \texttt{ParticleIndex\_t} - a typedef for the particle global \texttt{ID} attribute; it is short for \texttt{ParticleAttrib<unsigned>} 
-\end{itemize}
-The constructor for this user-defined class must initialize \texttt{ParticleBase} with a pointer to an instance of the selected layout class. 
-
-In this example, the layout class is \texttt{ParticleSpatialLayout}, but using one of the typedefs listed above, we can abbreviate this as \texttt{Layout\_t}. Note that we only define one constructor here, omitting the default constructor. This is done because \texttt{ParticleSpatialLayout} (which we have hard-coded as the layout for this user-defined \texttt{Particle} class) requires an argument to its constructor, and this can only be provided if we use a constructor for our \texttt{Particle} class as shown here. A new instance of this class would be declared in an application as follows:
-\begin{smallcode}
-Bunch myBunch (new ParticleSpatialLayout<double,3>(myFieldLayout)); 
-\end{smallcode}
-where my\texttt{FieldLayout} was a \texttt{FieldLayout} object created previously. The only action that is required in the constructor for the derived class is to inform the base class of the declared attributes, 
-using the \texttt{addAttribute(.)} method of \texttt{ParticleBase}, which registers the specified \texttt{ParticleAttrib} instance with the parent class \texttt{ParticleBase}. The order in which attributes are registered is not important.
-
-\subsection{Example \texttt{Particle} Classes: {\color{red} The \texttt{Genparticle} and \texttt{GenArrayParticle}} Classes}
-{\color{red} can be removed}
-
-
-\subsection{Using \texttt{Particle} Classes in an Application}
-
-After a specific \texttt{Particle} class has been defined and created in a \ippl application, you may create and initialize new particles, delete unwanted particles, and perform computations involving these particles. This section describes how to accomplish these tasks.
-
-\subsection{Creating New \texttt{Particle}s}
-
-When a \texttt{Particle} object is created, it is initially empty. Storage for new particles is allocated using the create (unsigned) method of \texttt{ParticleBase}. For example, if a \texttt{Particle} object bunch has been created already, the statement
-\begin{smallcode}
-bunch.create(100); 
-\end{smallcode}
-
-
-will allocate storage for 100 new particles. All the attributes for the particles in the \texttt{Particle} object will have this new storage allocated. The data is uninitialized, except for the global \texttt{ID} attribute; you must assign the proper values to the position and any other attributes that have been defined. The new storage is appended to the end of any existing storage.
-
-\texttt{ParticleBase} includes two methods that allow you to query how many particles exist. The function \texttt{getTotalNum()} will return the total number of particles being stored among all the processors; the function \texttt{getLocalNum()} will return the number of particles just on the local node. Although the new storage space is allocated on the local processor on which the call to create was executed, the \texttt{Particle} class will not officially add the particles to its
-local count (and will not tell any other processors it has created these new particles) until you call the \texttt{update()} method of \texttt{ParticleBase}. Thus, a call to \texttt{getLocalNum()} will report the same number just before and just after the call to create. The storage does exist after create is called, but only after the \texttt{update} method (which is discussed in more detail in a later section) has been called will all the processors have correct information on their local and total particle counts.
-
-\subsection{Initializing Attribute Data}
-
-After calling create to allocate new storage, you must initialize the data. This should be done after calling create and before calling \texttt{update} for the \texttt{Particle} object. After the data is initialized, the \texttt{update} routine will properly distribute the particles to their correct node based on the layout mechanism chosen for that \texttt{Particle} object and possibly the positions of the particles as set during their initialization. The following example shows one way to initialize the data for newly
-created particles when running on a single-processor machine. (This example will be modified in the following section for the case of running in parallel.) \\
-\begin{code}
-// create and'initialize data for an instance of Bunch 
-Bunch myBunch(new Bunch::Layout\_t(myFieldLayout)); 
-int currLocalPtcls = myPtcls.getLocalNum(); 
-myBunch.create(100); 
-for (int i = 0; i < 100; i++) { 
-    myBunch.R[currLocalPtcls + i] = Vektor<double,3>(0.0, 1.0, 0.0); 
-    myBunch.vel[currLocalPtcls + i] Vektor<double,3>(1.0, 1.0, 1.0); 
-} 
-myBunch.update(); 
-\end{code}
-
-
-In this example, 100 new particles are created, and the \texttt{R} and \texttt{vel} attributes are initialized to \texttt{Vektor} quantities. Notice that each attribute is accessed simply by specifying it as a data member of the \texttt{myBunch} object. After create was called, even though the 100 particles were not added to the \texttt{Particle} object's count of local particles, the storage was allocated and it was possible to assign values to the new elements in the attribute storage
-(accessed simply using the \texttt{[]} indexing operator). Finally, calling \texttt{update} added the new storage to the count, of particles stored in \texttt{myBunch}. Further calls to getLocalNum and getTotalNum would report the proper values.
-
-\subsection{Initializing Attribute Data on Parallel Architectures}
-
-The code shown in the previous example has one problem when used on parallel architectures: the call to create is performed on each processor, so if there were P processors a total of 100*P particles would be created. This may be the desired behavior, if so, the previous example is sufficient. However, if you are reading data on particle positions and other attributes from a file or some other source, you may wish to create particles on a single processor, and then distribute the
-data to the proper nodes. To do this, you need to call create and assign initial data on only one node but call update on all the processors. The \texttt{singlelnitNode()} method of \texttt{ParticleBase} will return a boolean value indicating whether the local processor should be used to create and initialize new particles in this way. The following example demonstrates how to use this method for initializing particles: \\
-\begin{code}
-// create and'initialize data for an instance of Bunch 
-Bunch myBunch(new Bunch::Layout\_t(myFieldLayout)); 
-int currLocalPtcls = myPtcls.getLocalNum();
-if (myBunch.singleInitNode()) { 
-    myBunch.create(100);  
-    for (int i = 0; i < 100; i++) { 
-        myBunch.R[currLocalPtcls + i] = Vektor<double,3>(0.0, 1.0, 0.0); 
-        myBunch.vel[currLocalPtcls + i] Vektor<double,3>(1.0, 1.0, 1.0); 
-    }
-} 
-myBunch.update(); 
-\end{code}
-
-
-\subsection{Deleting \texttt{Particle}s}
-
-\texttt{Particle}s may also be deleted during a simulation. The method \texttt{destroy (unsigned M, unsigned I)} of \texttt{ParticleBase} will delete \texttt{M} particles, starting with the \texttt{I}th particle. The index \texttt{I} here refers to the local particle index, not the global \texttt{ID} value. Thus \texttt{I = 0} means delete particles starting with the first one on the local processor.
-
-Unlike the situation when creating new particles, the storage locations for the deleted particles will not be removed from attribute data storage until \texttt{update} is called. Instead, the requests to delete particles are cached until the update phase, at which time all the deletions are performed. You are allowed to issue multiple delete requests between \texttt{update}s. For example, if there are 100 particles on a local node, and you request to delete particles 0 to 10
-and then request to delete particles 60 to 70, nothing will change in the attribute storage until you call \texttt{update}, and no change will occur to the local and total particle counts until \texttt{update()} is complete.
-
-\subsection{Updating \texttt{Particle}s: The \texttt{update()} Method}
-
-The \texttt{update()} method of \texttt{ParticleBase} is responsible for making sure that all processors have correct information about how many particles exist and where they are located in a parallel machine. As mentioned previously, \texttt{update} must be called by all processors after a sequence of particle creation or deletion operations. The \texttt{update} method is also responsible for maintaining a proper assignment of particles to processors, based on the particular
-\texttt{ParticleLayout} class used to create the
-\texttt{ParticleBase} object. Typically, this layout mechanism depends on the position of particles, so when particles change their position, they may need to be reassigned to a new processor to maintain the proper layout. In this case, the \texttt{update} method should be called whenever a computation is complete which alters the attributes (e.g. position) that a layout depends upon. The following short example demonstrates using \texttt{update} in conjunction with some operation that alters the x-coordinate of a
-set of particles. \\
-\begin{code}
-// do some computation involving myBunch for several time steps 
-while (computation_done == false) { 
-    // for each particle, add some constant to the x coordinate 
-    myBunch.R(0) += 0.li 
-    // update the Particle object; this may move particles between nodes 
-    myBunch.update(); 
-    // determine if the computation is done, etc.
-}
-\end{code}
-
-\subsection{Using Particle Attributes in Expressions}
-
-Computations involving particle attributes may be performed in many ways. Data-parallel expressions that involve all particles of a given \texttt{Particle} object may be used, or specific loops may be written that employ attribute iterators.
-
-
-\subsubsection{Attribute Expressions}
-
-Just as with the \texttt{Field} class, you may perform data-parallel operations on particle attributes using a simple expression syntax, which the \ippl framework will translate into efficient inlined code. These operations will be performed for every particle. The expressions may include any of the attributes in a \texttt{Particle} object as well as scalar values, may use mathematical operators such as +, -, *, / etc., and may call standard mathematical functions such as \texttt{cos(
-)}, \texttt{exp( )}, \texttt{mod( )} , etc. for an attribute value of each particle. Some examples are shown below.
-\begin{smallcode}
-double dt = 2.0; 
-myBunch.R += myBunch.vel* dt; 
-myBunch. vel = 1. - log (1. + myBunch. R * myBunch. R) ; 
-myBunch.update(); 
-\end{smallcode}
-
-
-Attribute expressions will perform their operations on all the particles in the \texttt{Particle} object, including any new particles allocated via a call to create, even before update has been called. This fact is useful when initializing the attributes for newly created particles (e.g., to set the init value for some scalar quantity to zero). Generally, however, unless you are performing an initialization of new particles, you should avoid using particle expressions of this type after calls to create or destroy and before a call to update.
-
-Some attributes, such as \texttt{Vektor}s or \texttt{Tenzor}s, have multiple components, and you may wish to involve only the \texttt{N}th component of the attribute in an expression. To do so, use the \texttt{()} operator to select the \texttt{N}th component of that attribute. For instance, using \texttt{myBunch} from the previous example, you can change just the x-coordinate of the particle position attribute \texttt{R} as follows: 
-\begin{smallcode}
-myBunch.R(0) = myBunch.R(l) - cos(myBunch.R(2));
-\end{smallcode}
-
-
-For 2D or 3D quantities, use two or three indices. For example, if rho is a 3x3 \texttt{Tenzor} attribute of myBunch, you can do the following:
-\begin{smallcode}
-myBunch.rho(0,0) = -(myBunch.rho(0,l) + myBunch.rho(0,2)); 
-\end{smallcode}
-
-Attribute expressions may also use the where operator in much the same way as for \texttt{Field} expressions. The first argument to where is some expression that results in a \texttt{boolean} value for each particle. The second and third arguments are expressions that will be evaluated for a particle if the first argument is \texttt{true} or \texttt{false}, respectively, for that particle. For example,
-\begin{smallcode}
-myBunch.vel = where(myBunch.R(0) > 0.0, -2.0 * myBunch.vel, myBunch.vel) 
-\end{smallcode}
-
-changes the value of the \texttt{vel} attribute in \texttt{myBunch} when the x-coordinate of the particle position is positive.
-
-\subsection{\texttt{Particle} Iterator Loop}
-
-You also have the capability of performing operations on specific particles using iterators or standard indexing operations. The \texttt{ParticleAttrib} containers in a \texttt{Particle} class may be used just as regular \texttt{STL} containers. The \texttt{begin()} and \texttt{end()} methods of the \texttt{ParticleAttrib} class will return an iterator pointing to the first element and just past the last element, respectively, of the attribute. These iterators may be used in an explicit loop just as if they were pointers into the attribute array.
-\begin{smallcode}
-ParticleAttrib<unsigned>::iterator idptr, idend = myBunch.ID.end(); 
-for (idptr = myBunch.ID.begin(); idptr != idend; ++idptr) 
-    cout << "Particle ID value: " << *idptr << endl; 
-\end{smallcode}
-
-
-Iterators are available for all \texttt{ParticleAttribs}. As an alternative, you may simply use the \texttt{[]} operator to access the attribute data of the \texttt{N}th particle on a node, treating \texttt{ParticleAttrib} as a regular array of data.
-\begin{smallcode}
-int nptcls = myBunch.getLocalNum(); 
-for(int i=0; i < nptcls ++i) { 
-    cout << "Particle ID value: " << myPtcls.ID[i] << endl; 
-}
-\end{smallcode}
-
-
-\section{{\color{red}Nearest-Neighbor Interactions (Jakob)}}
-{\color{red} can be removed}
-
-
-\subsection{{\color{red}\texttt{Particle} - \texttt{Particle} Interactions}}
-{\color{red} can be removed}
-
-\subsection{\texttt{Particle} - \texttt{Field} Interactions}
-
-%\section{\texttt{Particle} - \texttt{Field} Interactions}
-
-Many particle-based simulation methods, including "particle-in-cell" (PIC) simulations, rely on the ability of particles to interact with field quantities. For instance, in particle-based accelerator (plasma) simulations, you typically track the motions of charged plasma particles in a combination of externally applied and self-generated electromagnetic fields. In a \ippl application, such fields might be stored as \texttt{Field} objects of type \texttt{Vektor} existing on a pre-defined mesh. Particles moving through this mesh must be able to "gather" the current value of a \texttt{Field} to their exact positions. Additionally, in order to compute the values of self-generated fields, the particles must be able to "scatter" the value of an attribute onto nearby mesh points, producing a \texttt{Field}. These gather/scatter operations are done using a set of \ippl interpolation methods.
-
-\ippl provides a hierarchy of interpolation classes, each derived from the base class \texttt{Interpolate} and each containing the basic \texttt{gather} and \texttt{scatter} functions. The \texttt{gather} method allows you to gather one or more specified \texttt{Field}s into an equal number of \texttt{ParticleAttribs}. Similarly, \texttt{scatter} will accumulate one or more \texttt{ParticleAttribs} on to an equal number of \texttt{Field} objects. An example of how to scatter the particle density to a \texttt{Field} is shown below.
-\begin{smallcode}
-InterpolateNGP<Dim> mylnterpolater(myBunch);           // create NGP interpolater 
-Field<double,Dim> ptcl_density(myfieldlayout);         // create density field 
-myInterpolator.scatter(myBunch.density,ptcl_density);  // do scattet 
-\end{smallcode}
-The various classes derived from \texttt{Interpolate} implement these \texttt{gather} and \texttt{scatter} methods using different well-known interpolation schemes, such as nearest grid point (NGP), linear interpolation, and the subtracted-dipole scheme (SUDS). You may use these provided classes as a template for deriving new classes from \texttt{Interpolate} that implement other interpolation schemes of interest.
-
-In case of the CIC Interpolation and non-cyclic boundary condition, care has to be taken to not place particles in the outer half of boundary cells. Otherwise values will be scattered out of the grid and be irretrivable.
diff --git a/manual/ippl_setup.tex b/manual/ippl_setup.tex
deleted file mode 100644
index 689f6bb34..000000000
--- a/manual/ippl_setup.tex
+++ /dev/null
@@ -1,99 +0,0 @@
-\chapter{Framework Setup}
-\label{sec:setup}
-
-\section{Initialising \ippl}
-\ippl is initialized by passing \texttt{argc} and \texttt{argv} to \texttt{Ippl()} constructor or by creating an instance of \texttt{Ippl::Options}, configuring it, and then passing that options object to \texttt{Ippl::initialize()}. After the \texttt{Ippl()} constructor call MPI (or any other parallel subsystem) is proper initialized. \\
-With \texttt{Ippl::getNodes()} or \texttt{Ippl::myNode()} you can for example gather information how many compute nodes/cores are available and on which of the nodes you are running. \\
-\begin{code} 
-#include "Ippl.h"
-int main(int argc, char *argv[])
-{
-    Ippl ippl(argc,argv);
-    .....
-\end{code}
-
-\section{ Utility Classes in \ippl}
-\ippl provides, and uses internally, a number of useful utility classes which you may find helpful when developing new applications. 
-
-\subsection{Inform Class}
-The Inform class is used to print messages to the console or to a file. It has an interface which is very similar to the iostream classes in C++, and it is mostly used in those situation where you might print a message to cout or cerr. An Inform object is created with a prefix string, which is then appended to all lines of output from the Inform object. Inform essentially takes in data to be printed, formats it for printing just as an ostream object would, but also appends the prefix message to all lines of output. Most important Inform will also indicate which node printed the message when running in parallel.
-
-\subsubsection{Constructing New Inform Objects}
-
-The constructor for Inform has the form 
-\begin{smallcode}
-Inform(char *prefix = 0, int node = 0)
-\end{smallcode}
-where prefix is a string to prepend to all output lines, and node indicates on what node the Inform object should actually print out the information it is given. Notice that both of these arguments have default values; if no arguments are used when creating a new Inform object, no prefix will be used, if only one argument is given, then node default to 0, which means this Inform object will only print out messages on node 0.
-\begin{smallcode}
-Inform blankmsg; 
-blankmsg << "Some text." << endl; 
-\end{smallcode}
-This Inform object will print the text it is given to standard out. The final "\texttt{endl}" is a special manipulator object, which signals the Inform objec t to print out the message it has been given. It will automatically append an endline to the message if it does not already have one at the end. It is important to use endl with an Inform object if it is not ever used, the Inform object will never print out its accumulated text.
-\begin{smallcode}
-Inform testmsg("mytest"); 
-testmsg << "More text. argc = " << argc << endl; 
-\end{smallcode}
-Here, the prefix is given, if this is used when running in serial, the output will look like:
-\begin{smallcode}
-mytest> More text. argc = 1 
-\end{smallcode}
-or, if you use this when there is more than one processor in use, the prefix will also include the node number in curly brackets:
-\begin{smallcode}
-mytest{0}> More text. argc = 1 
-\end{smallcode}
-On all other nodes than node 0, when this Inform object is used, it will not print out the message.
-\begin{smallcode}
-Inform testmsg("testall", INFORM_ALL_NODES); 
-\end{smallcode}
-This example is similar to the previous example, except the second argument explicitly specifies which node to print on. This can be a number from 0 .... (num nodes - 1), or, as in this example, it can be \texttt{INFORM\_ALL\_NODES} which indicates the message should be printed on ALL the nodes instead of just one. You can also change the node on which an Inform object will print after it has been created by using the \texttt{setprintNode(int)} method of \texttt{Inform}. 
-
-\subsubsection{Predefined Inform Objects}
-Creating new Inform objects for printing messages is useful in contexts where you would like a unique prefix to indicate where the message originated, say in a specific class method. However, the \ippl framework provides a set of predefined Inform instances which may be used to quickly generate output message or to make sure all messages have a common prefix. These Inform objects are static members of the IPPL class, which is used to initialize the framework. The predefined instances are:
-\begin{smallcode}
-IPPL::Info = new Inform ("IPPL") ; 
-IPPL::Warn = new Inform("Warning"); 
-IPPL::Error = new Inform("Error", INFORM_ALL_NODES);
-\end{smallcode}
-These three instances are used to print generally informative messages, warning messages, and error messages. \texttt{Info} and \texttt{Warn} only print on node 0 by default; \texttt{Error} will print on all nodes. You may use these to printmessages in your own application:
-\begin{smallcode}
-*IPPL::Info << "An informative message." << endl; 
-\end{smallcode}
-Notice that here that \texttt{Info} was first dereferenced, since it actually is a pointer to an \texttt{Inform} object. A better (and recommended) way to use these predefined instances is to use a macro which is defined for each instance. The macros to use are \texttt{INFOMSG}, \texttt{WARNMSG}, and \texttt{ERRORMSG}; an example of their use is:
-\begin{smallcode}
-WARNMSG("rhis is a warning: value = " << warnvalue << endl); 
-\end{smallcode}
-The argument to the macro is then given to the associated \texttt{Inform} object for printing. 
-
-\subsection{Timer Class}
-Timer is used to perform simple timings within a program for use in, e.g., benchmarking. It tracks real (clock) time elapsed, user time, and system time. It acts essentially as a stopwatch: 
-initially it is stopped, and YOU tell it to stop and start with method calls. The Timer constructor takes no arguments; you create a new Timer object, and use the following methods:
-\begin{smallcode}
-//Start the clock running. Time only accumulates in the Timer when it is running. 
-void start()
-void stop()         //Stop the clock. The clock may be started again later. 
-void clear()        //Resets the accumulated time to zero
-float clock_time()  //Reports the accumulated "wall clock" time in seconds. 
-float user_time()   //Reports theaccurnulated user CPU time in seconds. 
-float system_time() //Reports the accumulated system CPU time in seconds. 
-float cpu_time()    //Reports user_time() + system_time() 
-\end{smallcode}
-
-\clearpage
-
-Example how to use the timer class: \\
-\begin{code}
-
-IpplTimings::TimerRef selfFieldTimer_m;    \\ definition
-
-selfFieldTimer_m = IpplTimings::getTimer("computeSelfField");  
- 
-selfFieldTimer_m.start(); 
-    /* compute something */
-selfFieldTimer_m.stop();
-
-IpplTimings::print();
-
-\end{code}
-
-
diff --git a/manual/ippl_user_guide.tex b/manual/ippl_user_guide.tex
deleted file mode 100644
index 7b0b0be5e..000000000
--- a/manual/ippl_user_guide.tex
+++ /dev/null
@@ -1,292 +0,0 @@
-\documentclass[12pt,a4paper]{report}
-%% does not work in Latex2Html mode
-%\usepackage{hyperref}
-\usepackage{url}
-\usepackage{html}
-\usepackage{epic}
-\usepackage{eepic}
-\usepackage{makeidx}
-\usepackage{array}
-\usepackage{times}
-\usepackage{amsmath}
-\usepackage[dvips]{epsfig,rotating}
-\usepackage{dingbat}
-\usepackage{listings}
-\usepackage{graphicx}
-
-\lstnewenvironment{code}[1][]
-{\textbf{Code Listing} \hspace{1cm} \hrulefill \lstset{language=C++, basicstyle=\ttfamily\scriptsize}}
-{\hrule\smallskip}
-%{\textbf{Code Listing} \hspace{1cm} \hrulefill \lstset{language=C++, basicstyle=\ttfamily\scriptsize, #1}}
-
-\lstnewenvironment{codeln}[1][]
-{\textbf{Code Listing} \hspace{1cm} \hrulefill \lstset{language=C++, basicstyle=\ttfamily\scriptsize, numbers=left, numberstyle=\tiny, stepnumber=1, numbersep=5pt}}
-{\hrule\smallskip}
-
-\lstnewenvironment{smallcode}[1][]
-{\lstset{language=C++, basicstyle=\ttfamily\scriptsize}}
-{\smallskip}
-
-\usepackage{pdfdraftcopy}             % Draft
-\draftstring{V 2.0 - with Kokos}
-%% Define a new 'leo' style for the package that will use a smaller font.
-%\makeatletter
-%\def\url@leostyle{%
- % \@ifundefined{selectfont}{\def\UrlFont{\sf}}{\def\UrlFont{\small\ttfamily}}}
-%\makeatother
-%% Now actually use the newly defined style.
-%\urlstyle{leo}
-
-\setlength\topmargin{0.0cm}
-%\setlength\oddsidemargin{3.501cm}
-%\setlength\evensidemargin{3.501cm}
-\renewcommand{\arraystretch}{1.5}
-
-
-% Definition neuer Zeichen
-\newcommand{\R}{{\mathbb R}}
-\newcommand{\N}{{\mathbb N}}
-\newcommand{\Z}{{\mathbb Z}}
-% Standard Notationen
-\newcommand{\vc}[1]{\mbox{\boldmath $#1$}}
-\newcommand{\sv}[1]{\mbox{\boldmath $\vec{#1}$}}
-\newcommand{\mx}[1]{\mbox{\boldmath $\underline{#1}$}}
-\newcommand{\op}[1]{\mathcal{#1}}
-% Sonstige Abkuerzungen
-\newcommand{\backpar}{\rule{1mm}{0mm}\\[-5ex]\rule{1mm}{0mm}}
-\newcommand{\ds}{\displaystyle}
-\newcommand{\AND}{\quad\mbox{and}\quad}
-\newcommand{\diag}{\mbox{diag }}
-\newcommand{\arrstr}[1]{\rule[0mm]{0mm}{#1}}
-\newcommand{\hstrut}[1]{\rule{0mm}{#1}}
-\newlength{\mylablen}
-\newlength{\mycaplen}
-\newlength{\myislen}
-% caption fuer Bilder
-\newcommand{\fcap}[2]{\refstepcounter{figure} \settowidth{\mycaplen}{#2}
-\settowidth{\mylablen}{\bf Figure \thefigure:~}
-\settowidth{\myislen}{\textwidth-\mylablen}
-\begin{center}
-{\bf Figure \thefigure:~}\ifthenelse{\mycaplen > \myislen}{\parbox[t]{\textwidth-\mylablen}{#2}\label{#1}}{#2\label{#1}}\end{center}}
-% caption fuer Tabellen
-\newcommand{\tcap}[2]{\refstepcounter{table} \settowidth{\mycaplen}{#2}
-\settowidth{\mylablen}{\bf Table \thetable:~}
-\settowidth{\myislen}{\textwidth-\mylablen}
-\begin{center}
-{\bf Table \thetable:~}\ifthenelse{\mycaplen > \myislen}{\parbox[t]{\textwidth-\mylablen}{#2}\label{#1}}{#2\label{#1}}\end{center}}
-%
-\newtheorem{theorem}{Theorem}
-\newtheorem{lemma}{Lemma}
-\newtheorem{corollary}{Corollary}
-\newtheorem{remark}{Remark}
-\newtheorem{definition}{Definition}
-\newtheorem{proposition}{Proposition}
-\newenvironment{proof}{{\bf Proof:}}{{}\hfill{$\square$}\par\smallskip}
-
-\renewcommand{\topfraction}{0.9}
-\renewcommand{\bottomfraction}{0.9}
-\renewcommand{\textfraction}{0.1}
-
-\newcommand{\ipplversion}{\text{2.0 }}
-\newcommand{\mad}{\textsc{mad }}
-\newcommand{\madnine}{\textsc{mad9 }}
-\newcommand{\madninep}{\textsc{mad9p }}
-\newcommand{\madeight}{\textsc{mad8 }}
-\newcommand{\pooma}{\textsc{pooma }}
-\newcommand{\classic}{\textsc{classic }}
-
-\newcommand{\ippl}{\textsc{I$\text{P}^2$L }}
-
-
-\newcommand{\opal}{\textsc{OPAL }}
-\newcommand{\opalt}{\textsc{OPAL-t }}
-\newcommand{\opalcycl}{\textsc{OPAL-cycl }}
-\newcommand{\opalmap}{\textsc{OPAL-map }}
-
-\newcommand{\partroot}{\textsc{H5PartROOT }}
-
-\newcommand{\lieop}[1]
-{{:}{#1}{:}}
-\renewcommand{\arraystretch}{2.0}
-
-\newcommand{\rms}[1]
-{\overset{\sim}{#1}}
-
-% Pfister stuff
-\def\C{{{{\rm {\mbox{\small l}}} \kern -.50em {\rm C}}}}
-\def\R{{{{\rm l} \kern -.15em {\rm R}}}}
-\def\N{{{{\rm l} \kern -.15em {\rm N}}}}
-\def\E{{{{\rm l} \kern -.15em {\rm E}}}}
-\def\P{{{{\rm l} \kern -.15em {\rm P}}}}
-\def\D{{{{\rm l} \kern -.15em {\rm D}}}}
-\def\L{{{{\rm l} \kern -.15em {\rm L}}}}
-\def\Z{{{{\rm Z} \kern -.35em {\rm Z}}}}
-\def\Q{{{{\rm {\mbox{\small l}}} \kern -.45em {\rm Q}}}}
-\def\qQ{{{{\rm {\mbox{\scriptsize l}}} \kern -.33em {\rm Q}}}}
-\def\v{\vspace{1ex}}
-\def\-v{\vspace{-1ex}}
-\def\vv{\vspace{2ex}}
-\def\vvv{\vspace{3ex}}
-\def\vn{\vspace{3ex}\noindent}
-\def\hs{\hspace{-1ex}}
-\def\n{\noindent}
-\def\dsl{\dis\sum\limits}
-\def\dis{\displaystyle}
-\def\O{\Omega}
-\def\o{\omega}
-\def\fr{\mbox{\footnotesize $\dis\frac{1}{2}$}}
-\def\frvier{\mbox{\footnotesize $\dis\frac{1}{4}$}}
-\def\ov{\overline}
-\def\b{\big[}
-\def\B{\big]}
-\def\i{\big\{}
-\def\g{\big\}}
-\def\e{\epsilon}
-\def\f{\footnotesize}
-\def\l{\ell^\prime}
-\def\ll{\ell,\ell^\prime}
-\def\r{\rightarrow}
-\def\point{{\mbox{\large $.$}}}
-\def\wl{\widetilde{\ell}}
-\def\wll{\widetilde{\ell},\widetilde{\ell}^\prime}
-\def\w{\widetilde}
-\def\wh{\widehat}
-\def\wt{\widetilde}
-\def\cA{{\cal A}}
-\def\cT{{\cal T}}
-\def\cE{{\cal E}}
-\def\oS{\overline{S}}
-\def\oT{\overline{T}}
-\def\cI{{\cal I}}
-\def\cK{{\cal K}}
-\def\cH{{\cal H}}
-\def\cP{{\cal P}}
-\def\cF{{\cal F}}
-\def\cS{{\cal S}}
-\def\cG{{\cal G}}
-\def\cO{{\cal O}}
-\def\cU{{\cal U}}
-
-%% REAL ADA STUFF
-\def\bx{{\bf x}}
-\def\br{{\bf r}}
-\def\bv{{\bf v}}
-\newcommand{\matr}[1]{\mathcal{#1}}
- \newcommand{\myvec}[1]{\bf{#1}}
-%\newcommand{\figref}[2]{#1 (see~Figure~\ref{fig:#2})}
-%\newcommand{\tabref}[2]{#1 (see~Table~\ref{tab:#2})}
-%\newcommand{\secref}[2]{#1 (see~Section~\ref{sec:#2})}
-\newcommand{\mytabline}[2]{\texttt{#1} & #2 \\}
-\renewcommand{\vec}{\myvec}
-
-\makeindex
-
-\renewcommand{\topfraction}{1.0}
-\renewcommand{\bottomfraction}{1.0}
-\renewcommand{\textfraction}{0.0}
-
-\newenvironment{tex2html_nowrap}{}{}
-
-\newcommand{\bibref}[2]{\hypercite{#1}{}{}{bib:#2}}
-
-\newcommand{\tabline}[3]{\hyperref{\texttt{#1}}%
-  {\texttt{#1} (}{)}{sec:#3} & #2 \\}
-\newcommand{\figref}[2]{\hyperref{#1}{#1 (see~Figure~}{)}{fig:#2}}
-\newcommand{\secref}[2]{\hyperref{#1}{#1 (see~Section~}{)}{sec:#2}}
-\newcommand{\tabref}[2]{\hyperref{#1}{#1 (see~Table~}{)}{tab:#2}}
-\begin{htmlonly}
-\bodytext{bgcolor = "#ffffff"}
-\end{htmlonly}
-
-%\newcommand{\documentlabel}{ }
-
-\begin{document}
-
-\begin{titlepage}
-
-\begin{htmlonly}
-\begin{rawhtml}
-<center>
-PAUL SCHERRER INSTITUT
-<br>
-<h1>The IPPL Framework , Version 2.0</h1>
-<h2>(Independent Parallel Particle Layer)</h2>
-<h2>User's Reference Manual</h2>
-<br>
-Andreas Adelmann  
-</center>
-\end{rawhtml}
-\end{htmlonly}
-
-\begin{latexonly}
-\begin{center}\normalsize
-\includegraphics[width=1.\linewidth,angle=0]{figures/psi_logo_wide}
-\end{center}
-\vskip 0.7cm
-PSI-PR-09-05
-\begin{flushright}
-%\documentlabel \\                    % document label
-\end{flushright}
-%\vskip 2.3cm
-\begin{center}\LARGE                 % document title
-{\bf The \ippl Framework} \\
-(Independent Parallel Particle Layer) \\
-Version \ipplversion \footnote{Release Date: \today} \\
-{\bf User's Reference Manual}
-\end{center}
-\vskip 1.5em
-\begin{center}                       % author
-Andreas Adelmann, ..... \vskip 2em
-{\large Abstract}
-\end{center}
-\end{latexonly}
-\begin{quotation}
- \ippl (Independent Parallel Particle Layer) is an object-oriented framework for particle based applications in computational science 
-requiring high-performance parallel computers. One of \ippl 's most attractive features is its high performance on both single-processor and  distributed-memory multicomputers machines. As future releases of the library will also support shared-memory multicomputers, \ippl 's authors have had to think very carefully about how to obtain the best possible performance across a wide range of applications on different architectures.
-\ippl  is a library of C++ classes designed to represent common abstractions in applications where {\em particles, fields} and operators like {\em FFT's} are needed.
-
-Application programmers use and derive from these classes, which present a data-parallel programming interface at the highest abstraction layer.
-
-Lower, to the user (programmer) hidden implementation layers encapsulate distribution and communication of data among processors. The supported platforms are: Linux based Beowulf clusters, Cray XT5/6, SGI Ultrix and the IBM Blue Gene series.
-
-The main goals of the \ippl  framework includes:
-\begin{itemize}
-    \item Portability across serial, distributed, and parallel architectures with no change to source code
-    \item Development of reusable, cross-problem-domain components to enable rapid application development
-    \item High efficiency for kernels and components relevant to scientific simulation
-    \item Framework design and development driven by applications from a diverse set of scientific problem domains
-    \item Shorter time from problem inception to working parallel simulations 
-\end{itemize}
- \ippl is currently in development the version here is the first "developer release". \ippl is inspired and partially based on POOMA r1 designed and implemented by scientists working at the Los Alamos National Laboratory's Advanced Computing Laboratory. 
- %Although \ippl  has received numerous additions the most importand are: 
-%Fully ANSI C++ compatible, full 64Bit, HDF5 support and a Trilinos interface.
-
-The report is organized as follow: in chapter 1 an introduction based on examples including installation instructions is presented. Chapter 2 and 3 are describing support classes followed by an discussion
-on 3D parallel FFT's in \ippl. The next two chapters explaining the use of particles and fields. Appendix A - F describing design and implementation details of the most important classes in the
-framework.
-\end{quotation}
-\vfill
-
-
-\end{titlepage}
-
-\tableofcontents
-\listoftables
-\listoffigures
-\include{introduction}
-\include{ippl_setup}
-\include{ippl_fft}
-\include{ippl_particles}
-\include{ippl_fields}
-
-\appendix
-\include{ippl_field_ref}
-\include{ippl_index_ref}
-\include{ippl_fieldlayout_ref}
-\include{ippl_mesh_ref}
-\include{ippl_centering_ref}
-\include{bibliography}
-
-\printindex
-
-\end{document}
diff --git a/manual/pdfdraftcopy.sty b/manual/pdfdraftcopy.sty
deleted file mode 100644
index 1390ba1e1..000000000
--- a/manual/pdfdraftcopy.sty
+++ /dev/null
@@ -1,198 +0,0 @@
-%%                                   
-%%
-%% This is file 'pdfdraftcopy.sty',
-%% generated with the docstrip utility.
-%%
-%% The original source files were:
-%%
-%%
-%% pdfdraftcopy.dtx  (with options: 'package')
-%%
-%% File: pdfdraftcopy.dtx Copyright (c) 2003, C. V. Radhakrishnan
-%%                                            C. V. Rajagopal
-%% River Valley Technologies, Floor III, SJP Buildings
-%% Cotton Hills, Trivandrum, India 695014
-%% http://www.river-valley.com
-%%
-%% This package may be distributed under the terms of the LaTeX Project 
-%% Public License, as described in lppl.txt in the base LaTeX distribution.
-%% Either version 1.0 or, at your option, any later version.
-%%
-%% $Id: pdfdraftcopy.sty,v 1.2 2003/08/11 20:31:07 cvr Exp cvr $
-%%
-\NeedsTeXFormat{LaTeX2e}
-\def\Fileversion$#1: #2 ${\gdef\fileversion{#2}}
-\def\Filedate$#1: #2 #3 ${\gdef\filedate{#2}}
-\Fileversion$Revision: 1.2 $
-\Filedate$Date: 2003/08/11 20:31:07 $
-\ProvidesPackage{pdfdraftcopy}
-   [\filedate\space\fileversion\space Draft copy in PDF (CVR)]
-\PackageWarningNoLine{pdfdraftcopy}
-   {****************************************\MessageBreak
-    Package pdfdraftcopy v,\fileversion\space loaded\MessageBreak
-    [Draft copy in PDF (CVR)]\MessageBreak
-    ****************************************}
-\DeclareOption{watermark}{\AtBeginDocument{%
-     \begingroup\watermark\endgroup}}
-\DeclareOption{draft}{\AtBeginDocument{%
-   \begingroup\draftcopy\endgroup}}
-\ExecuteOptions{draft}
-\ProcessOptions\relax
-
-\RequirePackage{color,graphicx}
-
-\let\@DRAFTout@Hook\@empty
-\newcommand{\DRAFTout}{\g@addto@macro\@DRAFTout@Hook}
-\newcommand{\@DRAFTout@Out}{%
-   \afterassignment\@DRAFTout@Test
-   \global\setbox\@cclv= %
-   }
-\newcommand{\@DRAFTout@Test}{%
-   \ifvoid\@cclv\relax
-      \aftergroup\@DRAFTout@Output
-   \else
-      \@DRAFTout@Output
-   \fi%
-   }
-\newcommand{\@DRAFTout@Output}{%
-   \@DRAFTout@Hook%
-   \@DRAFTout@Org@Out\box\@cclv%
-   }
-\newcommand{\@DRAFTout@Org@Out}{}
-\newcommand*{\@DRAFTout@Init}{%
-   \let\@DRAFTout@Org@Out\shipout
-   \let\shipout\@DRAFTout@Out
-   }
-\AtBeginDocument{\@DRAFTout@Init}
-\newcommand{\@DraftOverlay@Hook}{}
-\newcommand{\AddToDraftOverlay}{\g@addto@macro\@DraftOverlay@Hook}
-\newcommand{\ClearDraftOverlay}{\let\@DraftOverlay@Hook\@empty}
-\newcommand{\@DraftOverlay}{%
-  \ifx\@DraftOverlay@Hook\@empty
-  \else
-    \bgroup
-      \@tempdima=1in
-      \@tempcnta=\@tempdima
-      \@tempcntb=-\@tempdima
-      \advance\@tempcntb\paperheight
-      \global\setbox\@cclv\vbox{%
-      \vbox{\let\protect\relax%
-        \unitlength=1sp%
-        \pictur@(0,0)(\@tempcnta,\@tempcntb)%
-          \@DraftOverlay@Hook%
-        \endpicture}%
-        \box\@cclv%
-      }%
-    \egroup
-  \fi
-}
-
-\definecolor{gray30}{gray}{.7}
-\definecolor{gray20}{gray}{.8}
-\definecolor{gray10}{gray}{.9}
-
-\DRAFTout{\@DraftOverlay}
-\newdimen\LLY
-\newdimen\LLX
-\newdimen\URX
-\newdimen\URY
-\newdimen\topmargin
-\newdimen\bottommargin
-\def\@printdimen{%\ifthenelse{\equal{\@debug}{true}}%
-  {\PackageWarningNoLine{PDFdraftcopy}%
-    {\LLX::::::::::::=\the\LLX\MessageBreak
-     \LLY::::::::::::=\the\LLY\MessageBreak
-     \URX::::::::::::=\the\URX\MessageBreak
-     \URY::::::::::::=\the\URY\MessageBreak
-     \oddsidemargin::=\the\oddsidemargin\MessageBreak
-     \evensidemargin:=\the\evensidemargin\MessageBreak
-     \textheight:::::=\the\textheight\MessageBreak
-     \textwidth::::::=\the\textwidth\MessageBreak
-     \paperwidth:::::=\the\paperwidth\MessageBreak
-     \paperheight::::=\the\paperheight\MessageBreak
-     \topmargin::::::=\the\topmargin\MessageBreak
-     \headheight:::::=\the\headheight\MessageBreak
-     \headsep::::::::=\the\headsep\MessageBreak
-     \footskip:::::::=\the\footskip\MessageBreak
-     \topskip::::::::=\the\topskip\MessageBreak
-     Now fixing the overlay in place
-     }}{}
-}
-\def\@DRAFTdimen{%
- \setlength\LLY{\paperheight}
- \addtolength\LLY{-\textheight}
- \addtolength\LLY{-\headheight}
- \addtolength\LLY{-\headsep}
- \addtolength\LLY{-1in}
- \addtolength\LLY{-3pt}
- \setlength\LLX{1in}
- \ifodd\thepage
- \addtolength\LLX{\oddsidemargin}\else
- \addtolength\LLX{\evensidemargin}\fi
- \setlength\URX{\textwidth}
- \setlength\URY{\textheight}
-}
-\def\LoadWaterMark{\watermark}
-\def\watermark{\AddToDraftOverlay{%
-   \@DRAFTdimen%\@printdimen%
-   \setlength{\@tempdima}{0pt}
-   \setlength{\@tempdimb}{\paperwidth}
-   \addtolength{\@tempdimb}{-\@tempdima}
-   \addtolength{\@tempdimb}{-\@tempdima}
-   \setlength{\@tempdimc}{\paperheight}
-   \addtolength{\@tempdimc}{-\@tempdima}
-   \addtolength{\@tempdimc}{-\@tempdima}
-   \setlength{\unitlength}{1pt}\thinlines%
-%
-    \put(0,\strip@pt\paperheight){\fboxrule0pt\fboxsep0pt%
-     %\fcolorbox{white}{red}%
-     {\begin{minipage}[t][\paperheight][c]{\paperwidth}
-     \centering
-     \ifx\@@watermark\@empty\relax\else
-     \includegraphics%[width=\paperwidth,height=\paperheight]%
-     {\@@watermark}\fi%
-     \end{minipage}}}}}%
-
-\let\@@watermark\@empty
-\def\watermarkgraphic#1{\gdef\@@watermark{#1}}
-
-\def\draftcopy{\AddToDraftOverlay{%
-   \@DRAFTdimen%\@printdimen%
-   \setlength{\@tempdima}{0pt}
-   \setlength{\@tempdimb}{\paperwidth}
-   \addtolength{\@tempdimb}{-\@tempdima}
-   \addtolength{\@tempdimb}{-\@tempdima}
-   \setlength{\@tempdimc}{\paperheight}
-   \addtolength{\@tempdimc}{-\@tempdima}
-   \addtolength{\@tempdimc}{-\@tempdima}
-   \setlength{\unitlength}{1pt}\thinlines%
-%
-    \put(0,\strip@pt\paperheight){\fboxrule0pt\fboxsep0pt%
-     %\fcolorbox{white}{red}%
-     {\begin{minipage}[t][\paperheight][c]{\paperwidth}
-     \centering
-     \begingroup
-     \rotatebox{\@draftangle}{\color{\@draftcolor}
-     \fontfamily{\@draftfontfamily}%
-     \fontsize{\@draftfontsize}{\@draftfontsize}\selectfont
-     {\@draftfontattrib\@draftstring}
-     }\endgroup
-     \end{minipage}}}}}%
-
-\def\@draftangle{45}
-\def\@draftstring{DRAFT COPY}
-\def\@draftcolor{gray10}
-\def\@draftfontfamily{ptm}
-\def\@draftfontsize{80}
-\def\@draftfontattrib{\upshape}
-\def\draftstring#1{\gdef\@draftstring{#1}}
-\def\draftcolor#1{\gdef\@draftcolor{#1}}
-\def\draftfontfamily#1{\gdef\@draftfontfamily{#1}}
-\def\draftfontsize#1{\gdef\@draftfontsize{#1}}
-\def\draftfontattrib#1{\gdef\@draftfontattrib{#1}}
-\def\draftangle#1{\gdef\@draftangle{#1}}
-\endinput
-%%
-%%
-%% End of package 'pdfdraftcopy.sty'
-%%