alan-turing-institute
diff --git a/‎.gitignore‎
Lines changed: 4 additions & 0 deletions b/‎.gitignore‎
Lines changed: 4 additions & 0 deletions
diff --git a/‎docs/benchmarks/benchmarks.rst‎
Lines changed: 54 additions & 37 deletions b/‎docs/benchmarks/benchmarks.rst‎
Lines changed: 54 additions & 37 deletions
diff --git a/‎docs/benchmarks/mcmc_benchmark.rst‎
Lines changed: 0 additions & 7 deletions b/‎docs/benchmarks/mcmc_benchmark.rst‎
Lines changed: 0 additions & 7 deletions
diff --git a/‎docs/benchmarks/pivot_benchmark.rst‎
Lines changed: 7 additions & 0 deletions b/‎docs/benchmarks/pivot_benchmark.rst‎
Lines changed: 7 additions & 0 deletions
diff --git a/‎docs/demos/gp_demoGPU.rst‎
Lines changed: 16 additions & 0 deletions b/‎docs/demos/gp_demoGPU.rst‎
Lines changed: 16 additions & 0 deletions
diff --git a/‎docs/demos/historymatch_demos.rst‎
Lines changed: 12 additions & 0 deletions b/‎docs/demos/historymatch_demos.rst‎
Lines changed: 12 additions & 0 deletions
diff --git a/‎docs/demos/kdr_demos.rst‎
Lines changed: 13 additions & 0 deletions b/‎docs/demos/kdr_demos.rst‎
Lines changed: 13 additions & 0 deletions
diff --git a/‎docs/implementation/GaussianProcessGPU.rst‎
Lines changed: 15 additions & 0 deletions b/‎docs/implementation/GaussianProcessGPU.rst‎
Lines changed: 15 additions & 0 deletions
diff --git a/‎docs/implementation/implementation.rst‎
Lines changed: 2 additions & 1 deletion b/‎docs/implementation/implementation.rst‎
Lines changed: 2 additions & 1 deletion
diff --git a/‎docs/implementation/MCMC.rst‎ ‎docs/implementation/linalg.rst‎docs/implementation/MCMC.rst renamed to docs/implementation/linalg.rst
Lines changed: 3 additions & 3 deletions b/‎docs/implementation/MCMC.rst‎ ‎docs/implementation/linalg.rst‎docs/implementation/MCMC.rst renamed to docs/implementation/linalg.rst
Lines changed: 3 additions & 3 deletions
@@ -1,5 +1,9 @@
 *.pyc
 *.DS_Store
+*~
+docs/_build/*
+mogp_gpu/obj
+mogp_gpu/bin
 docs/_build/*
 mogp_emulator/benchmarks/*.png
 mogp_emulator/benchmarks/*.pdf
 
@@ -8,69 +8,86 @@ Benchmarks
    rosenbrock
    branin
    tsunami
-   mcmc_benchmark
    mice_benchmark
+   pivot_benchmark
    gkdr_benchmark
    histmatch_benchmark
 
-The code includes a series of benchmarks that illustrate various pieces of the implementation. Benchmarks
-can be run from the ``mogp_emulator/tests`` directory by entering ``make all`` or ``make benchmarks`` to
-run all benchmarks, or ``make rosenbrock``, ``make branin``, ``make tsunami``, ``make mcmc``, ``make mice``, ``make gKDR``, or ``make histmatch`` to run the individual benchmarks.
+The code includes a series of benchmarks that illustrate various
+pieces of the implementation. Benchmarks can be run from the
+``mogp_emulator/benchmarks`` directory by entering ``make all`` or ``make
+benchmarks`` to run all benchmarks, or ``make rosenbrock``, ``make
+branin``, ``make tsunami``, ``make mice``, ``make pivot``, ``make
+gKDR``, or ``make histmatch`` to run the individual benchmarks.
 
 Single Emulator Convergence Tests
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-The first benchmark examines the convergence of a single emulator applied to the Rosenbrock function in
-several different dimensions (more details can be found `here <https://www.sfu.ca/~ssurjano/rosen.html>`__).
-This illustrates how the emulator predictions improve as the number of training points is increased
-for different numbers of input parameters. The benchmark evaluates the Rosenbrock function in 4, 6, and
-8 dimensions and shows that the mean squared prediction error and the mean variance improve with the
-number of training points used. Matplotlib can optionally be used to visualize the results.
+The first benchmark examines the convergence of a single emulator
+applied to the Rosenbrock function in several different dimensions
+(more details can be found `here
+<https://www.sfu.ca/~ssurjano/rosen.html>`__).  This illustrates how
+the emulator predictions improve as the number of training points is
+increased for different numbers of input parameters. The benchmark
+evaluates the Rosenbrock function in 4, 6, and 8 dimensions and shows
+that the mean squared prediction error and the mean variance improve
+with the number of training points used. Matplotlib can optionally be
+used to visualize the results.
 
 Multi-Output Convergence Tests
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-The second benchmark examines the convergence of multiple emulators derived from the same input values.
-This benchmark is based on the 2D Branin function (more details on this function can be found `here <https://www.sfu.ca/~ssurjano/branin.html>`__)
-. The code uses 8 different realizations of the Branin
-function using different parameter values, and then examines the convergence of the 8 different
-emulators fit using different number of parameter values based on the prediction errors and
-variance values. The results can optionally be visualized using Matplotlib.
+The second benchmark examines the convergence of multiple emulators
+derived from the same input values.  This benchmark is based on the 2D
+Branin function (more details on this function can be found `here
+<https://www.sfu.ca/~ssurjano/branin.html>`__) . The code uses 8
+different realizations of the Branin function using different
+parameter values, and then examines the convergence of the 8 different
+emulators fit using different number of parameter values based on the
+prediction errors and variance values. The results can optionally be
+visualized using Matplotlib.
 
 Multi-Output Performance Benchmark
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-A performance benchmark is included that uses a set of Tsunami simulation results to examine the
-speed at which the code fits multiple emulators in parallel. The code fits 8, 16, 32, and 64 emulators
-using 1, 2, 4, and 8 processess and notes the time required to perform the fitting. Note that the results
-will depend on the number of cores on the computer -- once you exceed the number of cores, the performance
-will degrade. As with the other benchmarks, Matplotlib can optionally be used to plot the results.
+A performance benchmark is included that uses a set of Tsunami
+simulation results to examine the speed at which the code fits
+multiple emulators in parallel. The code fits 8, 16, 32, and 64
+emulators using 1, 2, 4, and 8 processess and notes the time required
+to perform the fitting. Note that the results will depend on the
+number of cores on the computer -- once you exceed the number of
+cores, the performance will degrade. As with the other benchmarks,
+Matplotlib can optionally be used to plot the results.
 
-MCMC Benchmark
+MICE Benchmark
 ~~~~~~~~~~~~~~
 
-A benchmark applying the software to fitting an emulator with MCMC sampling is included. The code
-draws hyperparameter samples and compares the resulting posterior distributions with the values
-found via maximum likelihood estimation. If Matplotlib is installed, a histogram of the parameter
-samples is shown.
+A benchmark comparing the MICE Sequential design method to Latin
+Hypercube sampling is also available.  This creates designs of a
+variety of sizes and computes the error on unseen data for the 2D
+Branin function. It compares the accuracy of the sequential design to
+the Latin Hypercube for both the predictions and uncertainties.
 
-MICE Benchmark
-~~~~~~~~~~~~~~
+Pivoted Cholesky Benchmark
+~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-A benchmark comparing the MICE Sequential design method to Latin Hypercube sampling is also available.
-This creates designs of a variety of sizes and computes the error on unseen data for the 2D Branin
-function. It compares the accuracy of the sequential design to the Latin Hypercube for both the
-predictions and uncertainties.
+This benchmark shows how a duplicated input can degrade emulator performance
+and how using pivoting can fix this more effectively than adding a nugget.
+It compares the accuracy of the emulator and its uncertainty for pivoting
+and adaptive nugget handling to the 2D Branin function.
 
 Dimension Reduction Benchmark
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-A benchmark illustrating gradient-based kernel dimension reduction is available in ``tests/benchmark_kdr_GP.py``
-This problem contains a 100 dimension function with a single active dimension and shows how the loss depends
-on the number of dimensions included in the reduced dimension space.
+A benchmark illustrating gradient-based kernel dimension reduction is
+available in ``tests/benchmark_kdr_GP.py`` This problem contains a 100
+dimension function with a single active dimension and shows how the
+loss depends on the number of dimensions included in the reduced
+dimension space.
 
 History Matching Benchmark
 ~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-A benchmark illustrating use of the ``HistoryMatching`` class to rule out parts of the input space
-using a GP emulator to make predictions. The benchmark contains a 1D and a 2D example.
+A benchmark illustrating use of the ``HistoryMatching`` class to rule
+out parts of the input space using a GP emulator to make
+predictions. The benchmark contains a 1D and a 2D example.
@@ -0,0 +1,7 @@
+.. _pivot_benchmark:
+
+**********************************
+Pivoted Cholesky Benchmark
+**********************************
+
+.. automodule:: mogp_emulator.benchmarks.benchmark_pivot
@@ -0,0 +1,16 @@
+.. _gpdemoGPU:
+
+Gaussian Process Demo (GPU)
+=========================
+This demo illustrates a simple example of fitting a GP emulator to results of the projectile
+problem discussed in the :ref:`tutorial`, using the GPU implementation of the emulator.
+
+Note that in order for this to work, it must be run on a machine with an Nvidia GPU, and with
+CUDA libraries available.  It also depends on Eigen and pybind.
+
+The example uses Maximum Likelihood Estimation with a Squared Exponential kernel, which is currently
+the only kernel supported by the GPU implementation.
+
+
+.. literalinclude::
+   ../../mogp_emulator/demos/gp_demo_gpu.py
@@ -0,0 +1,12 @@
+.. _historymatch_demos:
+
+History Matching Demos
+========================================================
+
+This demo shows how to carry out History Matching using a GP emulator.
+The two examples show how a fit GP can be passed directly to the
+`HistoryMatching` class, or how the predictions object can be passed
+instead. The demo also shows how other options can be set.
+
+.. literalinclude::
+   ../../mogp_emulator/demos/historymatch_demos.py
@@ -0,0 +1,13 @@
+.. _kdr_demos:
+
+Kernel Dimension Reduction (KDR) Demos
+========================================================
+
+This demo shows how to use the ``gKDR`` class to perform dimension reduction
+on the inputs to an emulator. The examples show how dimension reduction
+with a known number of dimensions can be fit, as well as how the class
+can use cross validation to infer a best number of dimensions from the
+data itself.
+
+.. literalinclude::
+   ../../mogp_emulator/demos/kdr_demos.py
@@ -0,0 +1,15 @@
+.. _GaussianProcessGPU:
+
+**********************************
+The ``GaussianProcessGPU`` Class
+**********************************
+
+.. automodule:: mogp_emulator.GaussianProcessGPU
+    :noindex:
+
+.. autoclass:: mogp_emulator.GaussianProcessGPU.GaussianProcessGPU
+    :members:
+    
+    .. automethod:: __init__
+
+.. automodule:: libgpgpu
@@ -8,6 +8,7 @@ mogp_emulator Implementation Details
    :caption: Class and Function Implementation Details:
 
    GaussianProcess
+   GaussianProcessGPU
    MultiOutputGP
    fitting
    MeanFunction
@@ -18,4 +19,4 @@ mogp_emulator Implementation Details
    ExperimentalDesign
    SequentialDesign
    HistoryMatching
-   MCMC
+   linalg
@@ -1,8 +1,8 @@
-.. _MCMC:
+.. _linalg:
 
 **********************************
-The ``MCMC`` Module
+The ``linalg`` Module
 **********************************
 
-.. automodule:: mogp_emulator.MCMC
+.. automodule:: mogp_emulator.linalg.cholesky
     :members: