├── .gitignore ├── .readthedocs.yml ├── .travis.yml ├── CODE_OF_CONDUCT.md ├── CONTRIBUTING.md ├── LICENSE ├── README.md ├── docs ├── Makefile ├── benchmarks │ ├── benchmarks.rst │ ├── branin.rst │ ├── gkdr_benchmark.rst │ ├── histmatch_benchmark.rst │ ├── mice_benchmark.rst │ ├── pivot_benchmark.rst │ ├── rosenbrock.rst │ └── tsunami.rst ├── conf.py ├── demos │ ├── excalibur_workshop_demo.rst │ ├── gp_demoGPU.rst │ ├── gp_demoR.rst │ ├── gp_demos.rst │ ├── gp_kernel_demos.rst │ ├── historymatch_demos.rst │ ├── kdr_demos.rst │ ├── mice_demos.rst │ └── multioutput_tutorial.rst ├── implementation │ ├── DimensionReduction.rst │ ├── ExperimentalDesign.rst │ ├── GPParams.rst │ ├── GaussianProcess.rst │ ├── GaussianProcessGPU.rst │ ├── HistoryMatching.rst │ ├── Kernel.rst │ ├── MeanFunction.rst │ ├── MultiOutputGP.rst │ ├── Priors.rst │ ├── SequentialDesign.rst │ ├── fitting.rst │ ├── formula.rst │ ├── implementation.rst │ ├── linalg.rst │ └── validation.rst ├── index.rst ├── intro │ ├── installation.rst │ ├── methoddetails.rst │ ├── overview.rst │ ├── projectile.png │ ├── tutorial.rst │ ├── tutorial_nroy.png │ └── uq_workflow.png ├── methods │ ├── alt │ │ ├── AltBLPriors.rst │ │ ├── AltBasisFunctions.rst │ │ ├── AltCoreDesign.rst │ │ ├── AltCorrelationFunction.rst │ │ ├── AltDynamicEmulationApproach.rst │ │ ├── AltEstimateDelta.rst │ │ ├── AltGPPriors.rst │ │ ├── AltGPorBLEmulator.rst │ │ ├── AltImplausibilityMeasure.rst │ │ ├── AltIteratingSingleStepEmulators.rst │ │ ├── AltMeanFunction.rst │ │ ├── AltMeanFunctionMultivariate.rst │ │ ├── AltMultipleOutputsApproach.rst │ │ ├── AltMultivariateCovarianceStructures.rst │ │ ├── AltMultivariateGPPriors.rst │ │ ├── AltNumericalSolutionForKarhunenLoeveExpansion.rst │ │ ├── AltOptimalCriteria.rst │ │ ├── AltOptimalDesignAlgorithms.rst │ │ └── AltScreeningChoice.rst │ ├── def │ │ ├── DefActiveInput.rst │ │ ├── DefAdjoint.rst │ │ ├── DefAssessment.rst │ │ ├── DefBLAdjust.rst │ │ ├── DefBLVarianceLearning.rst │ │ ├── DefBasisFunctions.rst │ │ ├── DefBayesLinear.rst │ │ ├── DefBayesian.rst │ │ ├── DefBestInput.rst │ │ ├── DefCalibration.rst │ │ ├── DefCodeUncertainty.rst │ │ ├── DefConjugate.rst │ │ ├── DefCorrelationLength.rst │ │ ├── DefDataAssimilation.rst │ │ ├── DefDecisionBasedSA.rst │ │ ├── DefDesign.rst │ │ ├── DefDeterministic.rst │ │ ├── DefDynamic.rst │ │ ├── DefElicitation.rst │ │ ├── DefEmulator.rst │ │ ├── DefExchangeability.rst │ │ ├── DefForcingInput.rst │ │ ├── DefGP.rst │ │ ├── DefHistoryMatching.rst │ │ ├── DefHyperparameter.rst │ │ ├── DefImplausibilityMeasure.rst │ │ ├── DefInactiveInput.rst │ │ ├── DefMUCM.rst │ │ ├── DefModelBasedDesign.rst │ │ ├── DefModelDiscrepancy.rst │ │ ├── DefMultilevelEmulation.rst │ │ ├── DefMultivariateGP.rst │ │ ├── DefMultivariateTProcess.rst │ │ ├── DefNugget.rst │ │ ├── DefPrincipalComponentAnalysis.rst │ │ ├── DefProper.rst │ │ ├── DefRegularity.rst │ │ ├── DefReification.rst │ │ ├── DefScreening.rst │ │ ├── DefSecondOrderExch.rst │ │ ├── DefSecondOrderSpec.rst │ │ ├── DefSensitivityAnalysis.rst │ │ ├── DefSeparable.rst │ │ ├── DefSimulator.rst │ │ ├── DefSingleStepFunction.rst │ │ ├── DefSmoothingKernel.rst │ │ ├── DefSmoothness.rst │ │ ├── DefSpaceFillingDesign.rst │ │ ├── DefStateVector.rst │ │ ├── DefStochastic.rst │ │ ├── DefTProcess.rst │ │ ├── DefTrainingSample.rst │ │ ├── DefUncertaintyAnalysis.rst │ │ ├── DefValidation.rst │ │ ├── DefVarianceBasedSA.rst │ │ └── DefWeakPrior.rst │ ├── disc │ │ ├── DiscActiveInputs.rst │ │ ├── DiscAdjustExchBeliefs.rst │ │ ├── DiscBayesLinearTheory.rst │ │ ├── DiscBestInput.rst │ │ ├── DiscBuildCoreGP.rst │ │ ├── DiscCore.rst │ │ ├── DiscCoreDesign.rst │ │ ├── DiscCoreValidationDesign.rst │ │ ├── DiscCovarianceFunction.rst │ │ ├── DiscDecisionBasedSA.rst │ │ ├── DiscExchangeableModels.rst │ │ ├── DiscExpertAssessMD.rst │ │ ├── DiscFactorialDesign.rst │ │ ├── DiscFormalAssessMD.rst │ │ ├── DiscGPBasedEmulator.rst │ │ ├── DiscGaussianAssumption.rst │ │ ├── DiscImplausibilityCutoff.rst │ │ ├── DiscInformalAssessMD.rst │ │ ├── DiscIterativeRefocussing.rst │ │ ├── DiscKarhunenLoeveExpansion.rst │ │ ├── DiscMonteCarlo.rst │ │ ├── DiscObservations.rst │ │ ├── DiscPostModeDelta.rst │ │ ├── DiscRealisationDesign.rst │ │ ├── DiscReification.rst │ │ ├── DiscReification │ │ │ └── ReifNetwork1.png │ │ ├── DiscReificationTheory.rst │ │ ├── DiscReificationTheory │ │ │ ├── ReifNetwork2.png │ │ │ └── ReifNetwork3.png │ │ ├── DiscSensitivityAndDecision.rst │ │ ├── DiscSensitivityAndOutputUncertainty.rst │ │ ├── DiscSensitivityAndSimplification.rst │ │ ├── DiscSobol.rst │ │ ├── DiscStructuredMD.rst │ │ ├── DiscStructuredMeanFunction.rst │ │ ├── DiscToolkitSensitivityAnalysis.rst │ │ ├── DiscUANugget.rst │ │ ├── DiscUncertaintyAnalysis.rst │ │ ├── DiscVarianceBasedSA.rst │ │ ├── DiscVarianceBasedSATheory.rst │ │ ├── DiscWhyModelDiscrepancy.rst │ │ └── DiscWhyProbabilisticSA.rst │ ├── exam │ │ ├── Exam1DHistoryMatch.rst │ │ ├── Exam1DHistoryMatch │ │ │ ├── GradPoints14.pdf │ │ │ ├── GradPoints14.png │ │ │ ├── GradPoints17.pdf │ │ │ └── GradPoints17.png │ │ ├── ExamCoreGP1Dim.rst │ │ ├── ExamCoreGP1Dim │ │ │ ├── Figure1.png │ │ │ ├── Figure2.png │ │ │ ├── Figure3.png │ │ │ ├── Figure4.png │ │ │ ├── Figure5.png │ │ │ ├── Figure6.png │ │ │ ├── Figure7.png │ │ │ └── Figure8.png │ │ ├── ExamCoreGP2Dim.rst │ │ ├── ExamCoreGP2Dim │ │ │ ├── Figure1.png │ │ │ ├── Figure2.png │ │ │ ├── Figure3.png │ │ │ ├── Figure4.png │ │ │ ├── Figure5.png │ │ │ ├── Figure6.png │ │ │ └── Figure7.png │ │ ├── ExamDecisionBasedSA.rst │ │ ├── ExamMultipleOutputs.rst │ │ ├── ExamMultipleOutputs │ │ │ ├── CONVpreds.png │ │ │ ├── INDpreds.png │ │ │ ├── LMCpreds.png │ │ │ ├── SEPpreds.png │ │ │ ├── ellipse_samescale.png │ │ │ ├── ellipse_zoom.png │ │ │ ├── output1.png │ │ │ └── output2.png │ │ ├── ExamMultipleOutputsPCA.rst │ │ ├── ExamMultipleOutputsPCA │ │ │ ├── pca.png │ │ │ ├── z-scores-dist.png │ │ │ └── z-scores.png │ │ ├── ExamScreeningAutomaticRelevanceDetermination.rst │ │ ├── ExamScreeningAutomaticRelevanceDetermination │ │ │ ├── exampleARD.png │ │ │ └── exampleARD2D.png │ │ ├── ExamScreeningMorris.rst │ │ ├── ExamScreeningMorris │ │ │ └── morrisToolkitExample.png │ │ ├── ExamVariantWithDerivatives1Dim.rst │ │ └── ExamVariantWithDerivatives1Dim │ │ │ ├── Figure1.png │ │ │ ├── Figure2.png │ │ │ ├── Figure3.png │ │ │ ├── Figure4.png │ │ │ ├── Figure5.png │ │ │ └── Figure6.png │ ├── meta │ │ ├── MetaComments.rst │ │ ├── MetaCopyrightNotice.rst │ │ ├── MetaHomePage.rst │ │ ├── MetaNotation.rst │ │ ├── MetaSoftwareDisclaimer.rst │ │ ├── MetaToolkitPageList.rst │ │ ├── MetaToolkitStructure.rst │ │ ├── MetaToolkitTutorial.rst │ │ └── MetaToolkitTutorial │ │ │ ├── Fig1.png │ │ │ └── Fig2.png │ ├── methods.rst │ ├── proc │ │ ├── ProcASCM.rst │ │ ├── ProcApproxDeltaPosterior.rst │ │ ├── ProcApproximateIterateSingleStepEmulator.rst │ │ ├── ProcApproximateUpdateDynamicMeanandVariance.rst │ │ ├── ProcAutomaticRelevanceDetermination.rst │ │ ├── ProcBLAdjust.rst │ │ ├── ProcBLPredict.rst │ │ ├── ProcBLVarianceLearning.rst │ │ ├── ProcBranchAndBoundAlgorithm.rst │ │ ├── ProcBuildCoreBL.rst │ │ ├── ProcBuildCoreBLEmpirical.rst │ │ ├── ProcBuildCoreGP.rst │ │ ├── ProcBuildEmulateDerivsGP.rst │ │ ├── ProcBuildMultiOutputGP.rst │ │ ├── ProcBuildMultiOutputGPSep.rst │ │ ├── ProcBuildWithDerivsGP.rst │ │ ├── ProcDataPreProcessing.rst │ │ ├── ProcExactIterateSingleStepEmulator.rst │ │ ├── ProcExchangeAlgorithm.rst │ │ ├── ProcExploreFullSimulatorDesignRegion.rst │ │ ├── ProcFourierExpansionForKL.rst │ │ ├── ProcHaarWaveletExpansionForKL.rst │ │ ├── ProcHaltonDesign.rst │ │ ├── ProcLHC.rst │ │ ├── ProcLatticeDesign.rst │ │ ├── ProcMCMCDeltaCoreGP.rst │ │ ├── ProcMorris.rst │ │ ├── ProcOptimalLHC.rst │ │ ├── ProcOutputSample.rst │ │ ├── ProcOutputTransformation.rst │ │ ├── ProcOutputsPrincipalComponents.rst │ │ ├── ProcPivotedCholesky.rst │ │ ├── ProcPredictGP.rst │ │ ├── ProcPredictMultiOutputFunction.rst │ │ ├── ProcPredictMultipleEmulators.rst │ │ ├── ProcSimulationBasedInference.rst │ │ ├── ProcSobolSequence.rst │ │ ├── ProcUABL.rst │ │ ├── ProcUADynamicEmulator.rst │ │ ├── ProcUAGP.rst │ │ ├── ProcUAMultipleEmulators.rst │ │ ├── ProcUpdateDynamicMeanAndVariance.rst │ │ ├── ProcValidateCoreGP.rst │ │ ├── ProcVarSAGP.rst │ │ ├── ProcVariogram.rst │ │ └── ProcWeylDesign.rst │ └── thread │ │ ├── ThreadCoreBL.rst │ │ ├── ThreadCoreGP.rst │ │ ├── ThreadGenericEmulateDerivatives.rst │ │ ├── ThreadGenericHistoryMatching.rst │ │ ├── ThreadGenericMultipleEmulators.rst │ │ ├── ThreadTopicExperimentalDesign.rst │ │ ├── ThreadTopicScreening.rst │ │ ├── ThreadTopicSensitivityAnalysis.rst │ │ ├── ThreadVariantDynamic.rst │ │ ├── ThreadVariantModelDiscrepancy.rst │ │ ├── ThreadVariantMultipleOutputs.rst │ │ ├── ThreadVariantTwoLevelEmulation.rst │ │ └── ThreadVariantWithDerivatives.rst └── requirements.txt ├── mogp_emulator ├── DimensionReduction.py ├── ExperimentalDesign.py ├── GPParams.py ├── GaussianProcess.py ├── GaussianProcessGPU.py ├── HistoryMatching.py ├── Kernel.py ├── LibGPGPU.py ├── MeanFunction.py ├── MultiOutputGP.py ├── MultiOutputGP_GPU.py ├── Priors.py ├── SequentialDesign.py ├── __init__.py ├── benchmarks │ ├── Makefile │ ├── __init__.py │ ├── benchmark_MICE.py │ ├── benchmark_branin.py │ ├── benchmark_gpu_parallel.py │ ├── benchmark_historymatching.py │ ├── benchmark_kdr_GP.py │ ├── benchmark_pivot.py │ ├── benchmark_rosenbrock.py │ ├── benchmark_tsunami.py │ ├── timingtestdata.npz │ └── tsunamidata.npz ├── demos │ ├── __init__.py │ ├── excalibur_workshop_demo.py │ ├── gp_demo.R │ ├── gp_demo_gpu.py │ ├── gp_demos.py │ ├── gp_kernel_demos.py │ ├── historymatch_demos.py │ ├── kdr_demos.py │ ├── mice_demos.py │ ├── multioutput_tutorial.py │ ├── projectile.py │ └── tutorial.py ├── fitting.py ├── formula.py ├── linalg │ ├── __init__.py │ ├── cholesky.py │ └── linalg_utils.py ├── tests │ ├── Makefile │ ├── __init__.py │ ├── benchmark_MICE.py │ ├── benchmark_branin.py │ ├── benchmark_historymatching.py │ ├── benchmark_kdr_GP.py │ ├── benchmark_rosenbrock.py │ ├── benchmark_tsunami.py │ ├── test_DimensionReduction.py │ ├── test_ExperimentalDesign.py │ ├── test_GPParams.py │ ├── test_GPUMeanFunction.py │ ├── test_GaussianProcess.py │ ├── test_HistoryMatching.py │ ├── test_Kernel.py │ ├── test_MeanFunction.py │ ├── test_MultiOutputGP.py │ ├── test_Priors.py │ ├── test_SequentialDesign.py │ ├── test_fitting.py │ ├── test_formula.py │ ├── test_linalg.py │ └── test_validation.py ├── utils.py └── validation.py ├── mogp_gpu ├── Makefile ├── src │ ├── bindings.cu │ ├── densegp_gpu.hpp │ ├── fitting.hpp │ ├── gpparams.hpp │ ├── gppriors.hpp │ ├── kernel.cu │ ├── kernel.hpp │ ├── meanfunc.hpp │ ├── multioutputgp_gpu.hpp │ ├── strided_range.hpp │ ├── types.hpp │ ├── util.cu │ └── util.hpp └── test │ ├── test_basic_fitting.cu │ ├── test_densegp_gpu.cu │ ├── test_gp_fitting.cu │ ├── test_gpparams.cu │ ├── test_gppriors.cu │ ├── test_gpu_basic.cu │ ├── test_gpu_cholesky.cu │ ├── test_gpu_kernel.cu │ ├── test_gpu_utils.cu │ ├── test_meanfunc.cu │ ├── test_mogp_gpu.cu │ └── test_openmp.cu ├── requirements-dev.txt ├── requirements-optional.txt ├── requirements.txt └── setup.py /.gitignore: -------------------------------------------------------------------------------- 1 | *.pyc 2 | *.DS_Store 3 | *~ 4 | docs/_build/* 5 | mogp_gpu/obj 6 | mogp_gpu/bin 7 | docs/_build/* 8 | mogp_emulator/benchmarks/*.png 9 | mogp_emulator/benchmarks/*.pdf 10 | mogp_emulator/benchmarks/*.npy 11 | mogp_emulator/version.py 12 | -------------------------------------------------------------------------------- /.readthedocs.yml: -------------------------------------------------------------------------------- 1 | version: 2 2 | 3 | sphinx: 4 | configuration: docs/conf.py 5 | 6 | formats: all 7 | 8 | python: 9 | version: 3.6 10 | install: 11 | - requirements: requirements.txt 12 | - method: setuptools 13 | path: . 14 | -------------------------------------------------------------------------------- /.travis.yml: -------------------------------------------------------------------------------- 1 | language: python 2 | dist: focal 3 | python: 4 | - "3.9" 5 | install: 6 | - pip install 'numpy>=1.19' 7 | - pip install -r requirements.txt 8 | - pip install -r requirements-dev.txt 9 | - pip install -r requirements-optional.txt 10 | - python setup.py install 11 | script: 12 | - pytest --cov=./ 13 | after_success: 14 | - codecov 15 | -------------------------------------------------------------------------------- /CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | # Code of Conduct 2 | 3 | We value the participation of every member of our community and want to ensure 4 | that every contributer has an enjoyable and fulfilling experience. Accordingly, 5 | everyone who participates in the `mogp_emulator` project is expected to show respect and 6 | courtesy to other community members at all time. 7 | 8 | In the interest of fostering an open and welcoming environment, we as 9 | contributors and maintainers are dedicated to making participation in our project 10 | a harassment-free experience for everyone, regardless of age, body 11 | size, disability, ethnicity, sex characteristics, gender identity and expression, 12 | level of experience, education, socio-economic status, nationality, personal 13 | appearance, race, religion, or sexual identity and orientation. 14 | 15 | ## Our Standards 16 | 17 | Examples of behavior that contributes to creating a positive environment 18 | include: 19 | 20 | - Using welcoming and inclusive language 21 | - Being respectful of differing viewpoints and experiences 22 | - Gracefully accepting constructive criticism 23 | - Focusing on what is best for the community 24 | - Showing empathy towards other community members 25 | 26 | Examples of unacceptable behavior by participants include: 27 | 28 | - The use of sexualized language or imagery and unwelcome sexual attention or 29 | advances 30 | - Trolling, insulting/derogatory comments, and personal or political attacks 31 | - Public or private harassment 32 | - Publishing others' private information, such as a physical or electronic 33 | address, without explicit permission 34 | - Other conduct which could reasonably be considered inappropriate in a 35 | professional setting 36 | 37 | ## Our Responsibilities 38 | 39 | Project maintainers are responsible for clarifying the standards of acceptable 40 | behavior and are expected to take appropriate and fair corrective action in 41 | response to any instances of unacceptable behavior. 42 | 43 | Project maintainers have the right and responsibility to remove, edit, or 44 | reject comments, commits, code, wiki edits, issues, and other contributions 45 | that are not aligned to this Code of Conduct, or to ban temporarily or 46 | permanently any contributor for other behaviors that they deem inappropriate, 47 | threatening, offensive, or harmful. 48 | 49 | ## Enforcement 50 | 51 | Instances of abusive, harassing, or otherwise unacceptable behavior may be 52 | reported by contacting the project team at [edaub@turing.ac.uk](mailto:edaub@turing.ac.uk). All 53 | complaints will be reviewed and investigated and will result in a response that 54 | is deemed necessary and appropriate to the circumstances. The project team is 55 | obligated to maintain confidentiality with regard to the reporter of an incident. 56 | Further details of specific enforcement policies may be posted separately. 57 | 58 | Project maintainers who do not follow or enforce the Code of Conduct in good 59 | faith may face temporary or permanent repercussions as determined by other 60 | members of the project's leadership. 61 | 62 | ## Attribution 63 | 64 | This Code of Conduct is adapted from the [scona project Code of Conduct](https://github.com/WhitakerLab/scona/blob/master/CODE_OF_CONDUCT.md) 65 | and the [Contributor Covenant](https://www.contributor-covenant.org), version [1.4](https://www.contributor-covenant.org/version/1/4/code-of-conduct.html) 66 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2019 The Alan Turing Institute 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Multi-Output Gaussian Process Emulator 2 | 3 | `mogp_emulator` is a Python package for fitting Gaussian Process Emulators to computer simulation results. 4 | The code contains routines for fitting GP emulators to simulation results with a single or multiple target 5 | values, optimizing hyperparameter values, and making predictions on unseen data. The library also implements 6 | experimental design, dimension reduction, and calibration tools to enable modellers to understand complex 7 | computer simulations. 8 | 9 | [![Build Status](https://travis-ci.com/alan-turing-institute/mogp-emulator.svg?branch=master)](https://travis-ci.com/alan-turing-institute/mogp-emulator) 10 | [![codecov](https://codecov.io/gh/alan-turing-institute/mogp-emulator/branch/master/graph/badge.svg)](https://codecov.io/gh/alan-turing-institute/mogp-emulator) 11 | [![Documentation Status](https://readthedocs.org/projects/mogp-emulator/badge/?version=latest)](https://mogp-emulator.readthedocs.io/en/latest/?badge=latest) 12 | 13 | ## Installation 14 | 15 | `mogp_emulator` requires Python version 3.6 or later. The code and all of its dependencies can be 16 | installed via `pip`: 17 | 18 | ```bash 19 | pip install mogp-emulator 20 | ``` 21 | 22 | Optionally, you may want to install some additional packages. In particular, `matplotlib` is useful for 23 | visualising some of the results of the benchmarks. These can be found in the 24 | [requirements-optional.txt](requirements-optional.txt) file in the main repository. 25 | 26 | Additionally, packages used in testing and developing the code base are listed in 27 | [requirements-dev.txt](requirements-dev.txt). 28 | 29 | ## Documentation 30 | 31 | The documentation is available at [readthedocs](https://mogp-emulator.readthedocs.io) for the current 32 | builds of the `master` and `devel` versions, plus any previous tagged releases. The documentation 33 | is available there in HTML, PDF, or e-Pub format. 34 | 35 | ## Getting Help 36 | 37 | This package is under active development by the Research Engineering Group at the Alan Turing Institute 38 | as part of several projects on Uncertainty Quantification. Questions about the code or any feedback on 39 | the usability and features that you would find useful can be sent to Eric Daub 40 | <[edaub@turing.ac.uk](mailto:edaub@turing.ac.uk)>. If you encounter any bugs or problems with installing 41 | the software, please see the Issues tab on the Github page, and if the issue is not present, create a new one. 42 | 43 | ## Contributing 44 | 45 | If you find this software useful, please consider taking part in its development! We aim to make 46 | this a welcoming, collaborative, open-source project where users of any background or skill levels feel that they 47 | can make valuable contributions. Please see the [Code of Conduct](CODE_OF_CONDUCT.md) for more on our 48 | expectations for participation in this project, and our [Contributing Guidelines](CONTRIBUTING.md) 49 | for how to get involved. -------------------------------------------------------------------------------- /docs/Makefile: -------------------------------------------------------------------------------- 1 | # Minimal makefile for Sphinx documentation 2 | # 3 | 4 | # You can set these variables from the command line. 5 | SPHINXOPTS = 6 | SPHINXBUILD = sphinx-build 7 | SOURCEDIR = . 8 | BUILDDIR = _build 9 | 10 | # Put it first so that "make" without argument is like "make help". 11 | help: 12 | @$(SPHINXBUILD) -M help "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O) 13 | 14 | .PHONY: help Makefile 15 | 16 | # Catch-all target: route all unknown targets to Sphinx using the new 17 | # "make mode" option. $(O) is meant as a shortcut for $(SPHINXOPTS). 18 | %: Makefile 19 | @$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O) -------------------------------------------------------------------------------- /docs/benchmarks/branin.rst: -------------------------------------------------------------------------------- 1 | .. _branin: 2 | 3 | ********************************** 4 | Branin Function Benchmark 5 | ********************************** 6 | 7 | .. automodule:: mogp_emulator.benchmarks.benchmark_branin -------------------------------------------------------------------------------- /docs/benchmarks/gkdr_benchmark.rst: -------------------------------------------------------------------------------- 1 | .. _gkdr_benchmark: 2 | 3 | ********************************** 4 | Dimension Reduction Benchmark 5 | ********************************** 6 | 7 | .. automodule:: mogp_emulator.benchmarks.benchmark_kdr_GP -------------------------------------------------------------------------------- /docs/benchmarks/histmatch_benchmark.rst: -------------------------------------------------------------------------------- 1 | .. _histmatch_benchmark: 2 | 3 | ********************************** 4 | History Matching Benchmark 5 | ********************************** 6 | 7 | .. automodule:: mogp_emulator.benchmarks.benchmark_historymatching -------------------------------------------------------------------------------- /docs/benchmarks/mice_benchmark.rst: -------------------------------------------------------------------------------- 1 | .. _mice_benchmark: 2 | 3 | ********************************** 4 | MICE Benchmark 5 | ********************************** 6 | 7 | .. automodule:: mogp_emulator.benchmarks.benchmark_MICE -------------------------------------------------------------------------------- /docs/benchmarks/pivot_benchmark.rst: -------------------------------------------------------------------------------- 1 | .. _pivot_benchmark: 2 | 3 | ********************************** 4 | Pivoted Cholesky Benchmark 5 | ********************************** 6 | 7 | .. automodule:: mogp_emulator.benchmarks.benchmark_pivot 8 | -------------------------------------------------------------------------------- /docs/benchmarks/rosenbrock.rst: -------------------------------------------------------------------------------- 1 | .. _rosenbrock: 2 | 3 | ********************************** 4 | Rosenbrock Function Benchmark 5 | ********************************** 6 | 7 | .. automodule:: mogp_emulator.benchmarks.benchmark_rosenbrock -------------------------------------------------------------------------------- /docs/benchmarks/tsunami.rst: -------------------------------------------------------------------------------- 1 | .. _tsunami: 2 | 3 | ********************************** 4 | Tsunami Data Benchmark 5 | ********************************** 6 | 7 | .. automodule:: mogp_emulator.tests.benchmark_tsunami -------------------------------------------------------------------------------- /docs/demos/excalibur_workshop_demo.rst: -------------------------------------------------------------------------------- 1 | .. _excalibur_workshop_demo: 2 | 3 | Gaussian Process Demo with Small Sample Size 4 | ============================================ 5 | 6 | This demo includes an example shown at the ExCALIBUR workshop held online on 7 | 24-25 September, 2020. The example shows the challenges of fitting a GP 8 | emulator to data that is poorly sampled, and how a mean function and 9 | hyperparameter priors can help constrain the model in a situation where 10 | a zero mean and Maximum Likelikhood Estimation perform poorly. 11 | 12 | The specific example uses the projectile problem discussed in the 13 | :ref:`tutorial`. It draws 6 samples, which might be a typical sampling 14 | density for a high dimensional simulator that is expensive to run, where 15 | you might be able to draw a few samples per input parameter. It shows the 16 | true function, and then the emulator means predicted at the same points 17 | using Maximum Likelihood Estimation and a linear mean function combined with 18 | Maximum A Posteriori Estimation. The MLE emulator is completely useless, 19 | while the MAP estimation technique leads to significantly better performance 20 | and an emulator that is useful despite only drawing a small number of samples. 21 | 22 | .. literalinclude:: 23 | ../../mogp_emulator/demos/excalibur_workshop_demo.py 24 | -------------------------------------------------------------------------------- /docs/demos/gp_demoGPU.rst: -------------------------------------------------------------------------------- 1 | .. _gpdemoGPU: 2 | 3 | Gaussian Process Demo (GPU) 4 | ========================= 5 | This demo illustrates a simple example of fitting a GP emulator to results of the projectile 6 | problem discussed in the :ref:`tutorial`, using the GPU implementation of the emulator. 7 | 8 | Note that in order for this to work, it must be run on a machine with an Nvidia GPU, and with 9 | CUDA libraries available. It also depends on Eigen and pybind. 10 | 11 | The example uses Maximum Likelihood Estimation with a Squared Exponential kernel, which is currently 12 | the only kernel supported by the GPU implementation. 13 | 14 | 15 | .. literalinclude:: 16 | ../../mogp_emulator/demos/gp_demo_gpu.py 17 | -------------------------------------------------------------------------------- /docs/demos/gp_demoR.rst: -------------------------------------------------------------------------------- 1 | .. _gpdemoR: 2 | 3 | Gaussian Process Demo (R) 4 | ========================= 5 | 6 | .. literalinclude:: 7 | ../../mogp_emulator/demos/gp_demo.R -------------------------------------------------------------------------------- /docs/demos/gp_demos.rst: -------------------------------------------------------------------------------- 1 | .. _gpdemos: 2 | 3 | Gaussian Process Demo (Python) 4 | ============================== 5 | 6 | This demo illustrates some various examples of fitting a GP emulator to results of the projectile 7 | problem discussed in the :ref:`tutorial`. It shows a few different ways of estimating the 8 | hyperparameters. The first two use Maximum Likelihood Estimation with two different kernels 9 | (leading to similar performance), while the third uses a linear mean function and places prior 10 | distributions on the hyperparameter values. The MAP estimation technique generally leads to 11 | significantly better performance for this problem, illustrating the benefit of setting priors. 12 | 13 | .. literalinclude:: 14 | ../../mogp_emulator/demos/gp_demos.py -------------------------------------------------------------------------------- /docs/demos/gp_kernel_demos.rst: -------------------------------------------------------------------------------- 1 | .. _gpkerneldemos: 2 | 3 | Gaussian Process Kernel Demos (Python) 4 | ====================================== 5 | 6 | This demo illustrates use of some of the different kernels available 7 | in the package and how they can be set. In particular, it shows use 8 | of the ``ProductMat52`` kernel and the ``UniformSqExp`` kernel and 9 | how these kernels give slightly different optimal hyperparameters 10 | on the same input data. 11 | 12 | .. literalinclude:: 13 | ../../mogp_emulator/demos/gp_kernel_demos.py -------------------------------------------------------------------------------- /docs/demos/historymatch_demos.rst: -------------------------------------------------------------------------------- 1 | .. _historymatch_demos: 2 | 3 | History Matching Demos 4 | ======================================================== 5 | 6 | This demo shows how to carry out History Matching using a GP emulator. 7 | The two examples show how a fit GP can be passed directly to the 8 | `HistoryMatching` class, or how the predictions object can be passed 9 | instead. The demo also shows how other options can be set. 10 | 11 | .. literalinclude:: 12 | ../../mogp_emulator/demos/historymatch_demos.py 13 | -------------------------------------------------------------------------------- /docs/demos/kdr_demos.rst: -------------------------------------------------------------------------------- 1 | .. _kdr_demos: 2 | 3 | Kernel Dimension Reduction (KDR) Demos 4 | ======================================================== 5 | 6 | This demo shows how to use the ``gKDR`` class to perform dimension reduction 7 | on the inputs to an emulator. The examples show how dimension reduction 8 | with a known number of dimensions can be fit, as well as how the class 9 | can use cross validation to infer a best number of dimensions from the 10 | data itself. 11 | 12 | .. literalinclude:: 13 | ../../mogp_emulator/demos/kdr_demos.py 14 | -------------------------------------------------------------------------------- /docs/demos/mice_demos.rst: -------------------------------------------------------------------------------- 1 | .. _mice_demos: 2 | 3 | Mutual Information for Computer Experiments (MICE) Demos 4 | ======================================================== 5 | 6 | This demo shows how to use the ``MICEDesign`` class to run a sequential experimental design. 7 | The predictions of a GP on some test points is compared between an LHD and the MICE design, 8 | showing that the performance of the MICE design is a significant improvement. 9 | 10 | .. literalinclude:: 11 | ../../mogp_emulator/demos/mice_demos.py -------------------------------------------------------------------------------- /docs/demos/multioutput_tutorial.rst: -------------------------------------------------------------------------------- 1 | .. _multioutput_tutorial: 2 | 3 | Multi-Output Tutorial 4 | ===================== 5 | 6 | *Note: This tutorial requires Scipy version 1.4 or later to run the simulator.* 7 | 8 | This page includes an end-to-end example of using ``mogp_emulator`` to perform model calibration 9 | with a simulator with multiple outputs. Note that this builds on the main tutorial with a 10 | second output (in this case, the velocity of the projectile at the end of the simulation), 11 | which is able to further constrain the NROY space as described in the first tutorial. 12 | 13 | .. literalinclude:: ../../mogp_emulator/demos/multioutput_tutorial.py 14 | 15 | One thing to note about multiple outputs is that they must be run as a script with a 16 | ``if __name__ == __main__`` block in order to correctly use the multiprocessing 17 | library. This can usually be done as in the example for short scripts, while for more 18 | complex analyses it is usually better to define functions (as in the benchmark for 19 | multiple outputs). 20 | 21 | More Details 22 | ------------ 23 | 24 | More details about these steps can be found in the :ref:`methods` section, or on the following page 25 | that goes into :ref:`more details ` on the options available in this software library. 26 | For more on the specific implementation detials, see the various 27 | :ref:`implementation pages ` describing the software components. 28 | -------------------------------------------------------------------------------- /docs/implementation/DimensionReduction.rst: -------------------------------------------------------------------------------- 1 | .. _DimensionReduction: 2 | 3 | ********************************* 4 | The ``DimensionReduction`` module 5 | ********************************* 6 | 7 | .. automodule:: mogp_emulator.DimensionReduction 8 | 9 | 10 | --------------------------- 11 | Dimension Reduction Classes 12 | --------------------------- 13 | 14 | .. autoclass:: mogp_emulator.gKDR 15 | 16 | .. automethod:: __init__ 17 | .. automethod:: __call__ 18 | .. automethod:: tune_parameters 19 | 20 | --------- 21 | Utilities 22 | --------- 23 | 24 | .. automethod:: mogp_emulator.DimensionReduction.gram_matrix 25 | 26 | .. automethod:: mogp_emulator.DimensionReduction.gram_matrix_sqexp 27 | 28 | .. automethod:: mogp_emulator.DimensionReduction.median_dist 29 | 30 | .. rubric:: References 31 | .. [Fukumizu1] https://www.ism.ac.jp/~fukumizu/software.html 32 | .. [FL13] Fukumizu, Kenji and Chenlei Leng. "Gradient-based kernel dimension reduction for regression." Journal of the American Statistical Association 109, no. 505 (2014): 359-370 33 | .. [LG17] Liu, Xiaoyu and Guillas, Serge. "Dimension Reduction for Gaussian Process Emulation: An Application to the Influence of Bathymetry on Tsunami Heights." SIAM/ASA Journal on Uncertainty Quantification 5, no. 1 (2017): 787-812 https://doi.org/10.1137/16M1090648 34 | -------------------------------------------------------------------------------- /docs/implementation/ExperimentalDesign.rst: -------------------------------------------------------------------------------- 1 | .. _ExperimentalDesign: 2 | 3 | ********************************** 4 | The ``ExperimentalDesign`` Class 5 | ********************************** 6 | 7 | .. automodule:: mogp_emulator.ExperimentalDesign.ExperimentalDesign 8 | :noindex: 9 | 10 | .. autoclass:: mogp_emulator.ExperimentalDesign.ExperimentalDesign 11 | :members: 12 | 13 | .. automethod:: __init__ 14 | 15 | 16 | ********************************** 17 | The ``MonteCarloDesign`` Class 18 | ********************************** 19 | 20 | .. _MonteCarloDesign: 21 | 22 | .. automodule:: mogp_emulator.ExperimentalDesign.MonteCarloDesign 23 | :noindex: 24 | 25 | .. autoclass:: mogp_emulator.ExperimentalDesign.MonteCarloDesign 26 | :members: 27 | :inherited-members: 28 | 29 | .. automethod:: __init__ 30 | 31 | 32 | ********************************** 33 | The ``LatinHypercubeDesign`` Class 34 | ********************************** 35 | 36 | .. _LatinHypercubeDesign: 37 | 38 | .. automodule:: mogp_emulator.ExperimentalDesign.LatinHypercubeDesign 39 | :noindex: 40 | 41 | .. autoclass:: mogp_emulator.ExperimentalDesign.LatinHypercubeDesign 42 | :members: 43 | :inherited-members: 44 | 45 | .. automethod:: __init__ 46 | 47 | ********************************** 48 | The ``MaxiMinLHC`` Class 49 | ********************************** 50 | 51 | .. _MaxiMinLHC: 52 | 53 | .. automodule:: mogp_emulator.ExperimentalDesign.MaxiMinLHC 54 | :noindex: 55 | 56 | .. autoclass:: mogp_emulator.ExperimentalDesign.MaxiMinLHC 57 | :members: 58 | :inherited-members: 59 | 60 | .. automethod:: __init__ -------------------------------------------------------------------------------- /docs/implementation/GPParams.rst: -------------------------------------------------------------------------------- 1 | .. _GPParams: 2 | 3 | ********************************** 4 | The ``GPParams`` Module 5 | ********************************** 6 | 7 | .. automodule:: mogp_emulator.GPParams 8 | :members: 9 | 10 | .. autoclass:: mogp_emulator.GPParams.GPParams 11 | :members: -------------------------------------------------------------------------------- /docs/implementation/GaussianProcess.rst: -------------------------------------------------------------------------------- 1 | .. _GaussianProcess: 2 | 3 | ********************************** 4 | The ``GaussianProcess`` Class 5 | ********************************** 6 | 7 | .. automodule:: mogp_emulator.GaussianProcess.GaussianProcess 8 | :noindex: 9 | 10 | .. autoclass:: mogp_emulator.GaussianProcess.GaussianProcess 11 | :members: 12 | 13 | 14 | ********************************** 15 | The ``PredictResult`` Class 16 | ********************************** 17 | 18 | .. autoclass:: mogp_emulator.GaussianProcess.PredictResult 19 | :members: 20 | -------------------------------------------------------------------------------- /docs/implementation/GaussianProcessGPU.rst: -------------------------------------------------------------------------------- 1 | .. _GaussianProcessGPU: 2 | 3 | ********************************** 4 | The ``GaussianProcessGPU`` Class 5 | ********************************** 6 | 7 | .. automodule:: mogp_emulator.GaussianProcessGPU 8 | :noindex: 9 | 10 | .. autoclass:: mogp_emulator.GaussianProcessGPU.GaussianProcessGPU 11 | :members: 12 | 13 | .. automethod:: __init__ 14 | 15 | .. automodule:: libgpgpu 16 | -------------------------------------------------------------------------------- /docs/implementation/HistoryMatching.rst: -------------------------------------------------------------------------------- 1 | .. _HistoryMatching: 2 | 3 | ********************************** 4 | The ``HistoryMatching`` Class 5 | ********************************** 6 | 7 | .. automodule:: mogp_emulator.HistoryMatching 8 | :noindex: 9 | 10 | .. autoclass:: mogp_emulator.HistoryMatching 11 | :members: 12 | 13 | .. automethod:: __init__ 14 | -------------------------------------------------------------------------------- /docs/implementation/Kernel.rst: -------------------------------------------------------------------------------- 1 | .. _Kernel: 2 | 3 | ********************************** 4 | The ``Kernel`` Module 5 | ********************************** 6 | 7 | .. _SquaredExponential: 8 | 9 | .. autoclass:: mogp_emulator.Kernel.SquaredExponential 10 | :members: 11 | 12 | .. _Matern52: 13 | 14 | .. autoclass:: mogp_emulator.Kernel.Matern52 15 | :members: 16 | 17 | .. _ProductMat52: 18 | 19 | .. autoclass:: mogp_emulator.Kernel.ProductMat52 20 | :members: 21 | 22 | .. _UniformSqExp: 23 | 24 | .. autoclass:: mogp_emulator.Kernel.UniformSqExp 25 | :members: 26 | 27 | .. _UniformMat52: 28 | 29 | .. autoclass:: mogp_emulator.Kernel.UniformMat52 30 | :members: 31 | 32 | .. autoclass:: mogp_emulator.Kernel.KernelBase 33 | :members: 34 | 35 | .. autoclass:: mogp_emulator.Kernel.UniformKernel 36 | :members: 37 | 38 | .. autoclass:: mogp_emulator.Kernel.StationaryKernel 39 | :members: 40 | 41 | .. autoclass:: mogp_emulator.Kernel.ProductKernel 42 | :members: 43 | 44 | .. autoclass:: mogp_emulator.Kernel.SqExp 45 | :members: 46 | 47 | .. autoclass:: mogp_emulator.Kernel.Mat52 48 | :members: -------------------------------------------------------------------------------- /docs/implementation/MeanFunction.rst: -------------------------------------------------------------------------------- 1 | .. _MeanFunction: 2 | 3 | ********************************** 4 | The ``MeanFunction`` Module 5 | ********************************** 6 | 7 | .. automodule:: mogp_emulator.MeanFunction 8 | :members: MeanFunction 9 | :noindex: 10 | 11 | .. autoclass:: mogp_emulator.MeanFunction.MeanBase 12 | :members: 13 | 14 | .. autoclass:: mogp_emulator.MeanFunction.MeanSum 15 | :members: 16 | 17 | .. autoclass:: mogp_emulator.MeanFunction.MeanProduct 18 | :members: 19 | 20 | .. autoclass:: mogp_emulator.MeanFunction.MeanPower 21 | :members: 22 | 23 | .. autoclass:: mogp_emulator.MeanFunction.MeanComposite 24 | :members: 25 | 26 | .. autoclass:: mogp_emulator.MeanFunction.FixedMean 27 | :members: 28 | 29 | .. autoclass:: mogp_emulator.MeanFunction.ConstantMean 30 | :members: 31 | 32 | .. autoclass:: mogp_emulator.MeanFunction.LinearMean 33 | :members: 34 | 35 | .. autoclass:: mogp_emulator.MeanFunction.Coefficient 36 | :members: 37 | 38 | .. autoclass:: mogp_emulator.MeanFunction.PolynomialMean 39 | :members: 40 | 41 | -------------------------------------------------------------------------------- /docs/implementation/MultiOutputGP.rst: -------------------------------------------------------------------------------- 1 | .. _MultiOutputGP: 2 | 3 | ********************************** 4 | The ``MultiOutputGP`` Class 5 | ********************************** 6 | 7 | .. automodule:: mogp_emulator.MultiOutputGP.MultiOutputGP 8 | :noindex: 9 | 10 | .. autoclass:: mogp_emulator.MultiOutputGP.MultiOutputGP 11 | :members: 12 | 13 | .. automethod:: __init__ -------------------------------------------------------------------------------- /docs/implementation/Priors.rst: -------------------------------------------------------------------------------- 1 | .. _Priors: 2 | 3 | ********************************** 4 | The ``Priors`` Module 5 | ********************************** 6 | 7 | .. automodule:: mogp_emulator.Priors 8 | :members: 9 | 10 | .. _GPPriors: 11 | 12 | .. autoclass:: mogp_emulator.Priors.GPPriors 13 | :members: 14 | 15 | .. _MeanPriors: 16 | 17 | .. autoclass:: mogp_emulator.Priors.MeanPriors 18 | :members: 19 | 20 | .. _WeakPrior: 21 | 22 | .. autoclass:: mogp_emulator.Priors.WeakPrior 23 | :members: 24 | 25 | .. _NormalPrior: 26 | 27 | .. autoclass:: mogp_emulator.Priors.NormalPrior 28 | :members: 29 | 30 | .. _LogNormalPrior: 31 | 32 | .. autoclass:: mogp_emulator.Priors.LogNormalPrior 33 | :members: 34 | 35 | .. _GammaPrior: 36 | 37 | .. autoclass:: mogp_emulator.Priors.GammaPrior 38 | :members: 39 | 40 | .. _InvGammaPrior: 41 | 42 | .. autoclass:: mogp_emulator.Priors.InvGammaPrior 43 | :members: -------------------------------------------------------------------------------- /docs/implementation/SequentialDesign.rst: -------------------------------------------------------------------------------- 1 | .. _SequentialDesign: 2 | 3 | ********************************** 4 | The ``SequentialDesign`` Class 5 | ********************************** 6 | 7 | .. automodule:: mogp_emulator.SequentialDesign.SequentialDesign 8 | :noindex: 9 | 10 | .. autoclass:: mogp_emulator.SequentialDesign.SequentialDesign 11 | :members: 12 | 13 | .. automethod:: __init__ 14 | 15 | 16 | ********************************** 17 | The ``MICEDesign`` Class 18 | ********************************** 19 | 20 | .. _MICEDesign: 21 | 22 | .. automodule:: mogp_emulator.SequentialDesign.MICEDesign 23 | :noindex: 24 | 25 | .. autoclass:: mogp_emulator.SequentialDesign.MICEDesign 26 | :members: 27 | :inherited-members: 28 | 29 | .. automethod:: __init__ 30 | 31 | 32 | ********************************** 33 | The ``MICEFastGP`` Class 34 | ********************************** 35 | 36 | .. automodule:: mogp_emulator.SequentialDesign.MICEFastGP 37 | :noindex: 38 | 39 | .. autoclass:: mogp_emulator.SequentialDesign.MICEFastGP 40 | :members: 41 | -------------------------------------------------------------------------------- /docs/implementation/fitting.rst: -------------------------------------------------------------------------------- 1 | .. _fitting: 2 | 3 | ********************************** 4 | The ``fitting`` Module 5 | ********************************** 6 | 7 | .. automodule:: mogp_emulator.fitting 8 | :members: 9 | :noindex: 10 | -------------------------------------------------------------------------------- /docs/implementation/formula.rst: -------------------------------------------------------------------------------- 1 | .. _formula: 2 | 3 | ********************************** 4 | The ``formula`` Module 5 | ********************************** 6 | 7 | .. automodule:: mogp_emulator.formula 8 | :members: 9 | :noindex: 10 | -------------------------------------------------------------------------------- /docs/implementation/implementation.rst: -------------------------------------------------------------------------------- 1 | .. _implementation: 2 | 3 | mogp_emulator Implementation Details 4 | ==================================== 5 | 6 | .. toctree:: 7 | :maxdepth: 1 8 | :caption: Class and Function Implementation Details: 9 | 10 | GaussianProcess 11 | GaussianProcessGPU 12 | MultiOutputGP 13 | fitting 14 | validation 15 | MeanFunction 16 | formula 17 | Kernel 18 | Priors 19 | GPParams 20 | linalg 21 | DimensionReduction 22 | ExperimentalDesign 23 | SequentialDesign 24 | HistoryMatching 25 | -------------------------------------------------------------------------------- /docs/implementation/linalg.rst: -------------------------------------------------------------------------------- 1 | .. _linalg: 2 | 3 | ********************************** 4 | The ``linalg`` Module 5 | ********************************** 6 | 7 | .. automodule:: mogp_emulator.linalg.cholesky 8 | :members: 9 | -------------------------------------------------------------------------------- /docs/implementation/validation.rst: -------------------------------------------------------------------------------- 1 | .. _validation: 2 | 3 | ********************************** 4 | The ``validation`` Module 5 | ********************************** 6 | 7 | .. automodule:: mogp_emulator.validation 8 | :members: 9 | :noindex: 10 | -------------------------------------------------------------------------------- /docs/index.rst: -------------------------------------------------------------------------------- 1 | .. Multi-Output GP Emulator documentation master file, created by 2 | sphinx-quickstart on Mon Mar 11 13:49:57 2019. 3 | You can adapt this file completely to your liking, but it should at least 4 | contain the root `toctree` directive. 5 | 6 | Welcome to Multi-Output GP Emulator's documentation! 7 | ==================================================== 8 | 9 | ``mogp_emulator`` is a Python package for fitting Gaussian Process Emulators to computer simulation results. 10 | The code contains routines for fitting GP emulators to simulation results with a single or multiple target 11 | values, optimizing hyperparameter values, and making predictions on unseen data. The library also implements 12 | experimental design, dimension reduction, and calibration tools to enable modellers to understand complex 13 | computer simulations. 14 | 15 | The following pages give a brief overview of the package, instructions for installation, and an end-to-end 16 | tutorial describing a Uncertainty Quantification workflow using ``mogp_emulator``. Further pages outline 17 | some additional examples, more background details on the methods in the MUCM Toolkit, full implementation 18 | details, and some included benchmarks. 19 | 20 | .. toctree:: 21 | :maxdepth: 1 22 | :caption: Introduction and Installation: 23 | 24 | intro/overview 25 | intro/installation 26 | intro/tutorial 27 | intro/methoddetails 28 | 29 | .. toctree:: 30 | :maxdepth: 1 31 | :caption: Some more specific demos and tutorial illustrating how the various package components can 32 | be used are: 33 | 34 | demos/gp_demos 35 | demos/multioutput_tutorial 36 | demos/gp_kernel_demos 37 | demos/mice_demos 38 | demos/historymatch_demos 39 | demos/kdr_demos 40 | demos/gp_demoGPU 41 | demos/gp_demoR 42 | demos/excalibur_workshop_demo 43 | 44 | .. toctree:: 45 | :maxdepth: 1 46 | :caption: For a more detailed description of some of the Uncertainty Quantification methods used in 47 | this package, see the MUCM toolkit pages: 48 | 49 | methods/methods 50 | 51 | .. toctree:: 52 | :maxdepth: 1 53 | :caption: Detailed information on all implemented classes and functions are described in the following pages: 54 | 55 | implementation/implementation 56 | 57 | .. toctree:: 58 | :maxdepth: 1 59 | :caption: For some more speicifs on benchmarks involving the implementation, see the following benchmark examples: 60 | 61 | benchmarks/benchmarks 62 | 63 | 64 | 65 | Indices and tables 66 | ================== 67 | 68 | * :ref:`genindex` 69 | * :ref:`modindex` 70 | * :ref:`search` 71 | -------------------------------------------------------------------------------- /docs/intro/overview.rst: -------------------------------------------------------------------------------- 1 | .. _overview: 2 | 3 | Overview 4 | ======== 5 | 6 | Computer simulations are frequently used in science to understand physical systems, but in practice 7 | it can be difficult to understand their limitations and quantify the uncertainty associated with 8 | their outputs. This library provides a range of tools to facilitate this process for domain experts 9 | that are not necessarily well-versed in uncertainty quantification methods. 10 | 11 | This page covers an overview of the workflow. For much more detail, see the :ref:`methoddetails` 12 | section of the introduction, or the :ref:`methods` section. 13 | 14 | UQ Basics 15 | --------- 16 | 17 | The UQ workflow here describes the process of understanding a complex simulator. The simulator here is 18 | assumed to be a deterministic function mapping multiple inputs to one or more outputs with some general 19 | knowledge about the input space. We would like to understand what inputs are reasonable given some 20 | observations about the world, and understand how uncertain we are about this knowledge. The inputs 21 | may not be something that is physically observable, as they may be standing in for missing physics 22 | from the simulator. 23 | 24 | .. figure:: uq_workflow.png 25 | :align: left 26 | 27 | The Uncertainty Quantification workflow. To determine the plausible inputs for a 28 | complex simulator given some data and a parameter space, we use an 29 | **experimental design** to sample from the space, run those points through the 30 | simulator. To approximate the simulator, we fit a **Gaussian Process Emulator** 31 | to the simulator output. Then, to explore the parameter space, we sample many, 32 | many times from the experimental design, query the emulator, and determine the 33 | plausible inputs that are consistent with the data using **History Matching**. 34 | 35 | The simulation is assumed to be too expensive to run as many times as needed to explore the entire 36 | space. Instead, we will train a **surrogate model** or **emulator** model that approximates the simulator and 37 | efficiently estimates its value (plus an uncertainty). We will then query that model many times to 38 | explore the input space. 39 | 40 | Because the simulator is expensive to run, we would like to be judicious about how to sample from the 41 | space. This requires designing an experiment to choose the points that are run to fit the surrogate 42 | model, referred to as an **Experimental Design**. Once these points are run, the emulator can be fit and predictions made on arbitrary input 43 | points. These predictions are compared to observations for a large number of points to examine the 44 | inputs space and see what inputs are reasonable given the observations and what points can be excluded. 45 | This is a type of model calibration, and the specific approach we use here is **History Matching**, 46 | which attempts to find the parts of the input space that are plausible given the data and all 47 | uncertainties involved in the problem. 48 | 49 | Next, we describe the :ref:`installation` prodecure and provide an example :ref:`tutorial` to 50 | illustrate how this process works. 51 | -------------------------------------------------------------------------------- /docs/intro/projectile.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alan-turing-institute/mogp-emulator/72dc73a49dbab621ef5748546127da990fd81e4a/docs/intro/projectile.png -------------------------------------------------------------------------------- /docs/intro/tutorial_nroy.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alan-turing-institute/mogp-emulator/72dc73a49dbab621ef5748546127da990fd81e4a/docs/intro/tutorial_nroy.png -------------------------------------------------------------------------------- /docs/intro/uq_workflow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alan-turing-institute/mogp-emulator/72dc73a49dbab621ef5748546127da990fd81e4a/docs/intro/uq_workflow.png -------------------------------------------------------------------------------- /docs/methods/alt/AltIteratingSingleStepEmulators.rst: -------------------------------------------------------------------------------- 1 | .. _AltIteratingSingleStepEmulators: 2 | 3 | Alternatives: Iterating single step emulators 4 | ============================================= 5 | 6 | Overview 7 | -------- 8 | 9 | This page is concerned with task of :ref:`emulating` a 10 | :ref:`dynamic simulator`, as set out in the variant 11 | thread for dynamic emulation 12 | (:ref:`ThreadVariantDynamic`). 13 | 14 | We have an emulator for the :ref:`single step 15 | function` :math:`w_t=f(w_{t-1},a_t,\phi)` 16 | in a dynamic simulator, and wish to iterate the emulator to obtain the 17 | distribution of :math:`w_1,\ldots,w_T` given :math:`w_0,a_1,\ldots,a_T` 18 | and :math:`\phi`. For a :ref:`Gaussian Process` emulator, it 19 | is not possible to do so analytically, and so we consider two 20 | alternatives: a simulation based approach and an approximation based on 21 | the normal distribution. 22 | 23 | The Nature of the Alternatives 24 | ------------------------------ 25 | 26 | #. Recursively simulate random outputs from the single step emulator, 27 | adding the simulated outputs to the training data at each iteration 28 | to obtain an exact draw from the distribution of :math:`w_1,\ldots,w_T` 29 | (:ref:`ProcExactIterateSingleStepEmulator`). 30 | #. Approximate the distribution of :math:`w_t=f(w_{t-1},a_t,\phi)` at 31 | each time step with a normal distribution. The mean and variance of 32 | :math:`w_t` for each :math:`t` are computed recursively. 33 | (:ref:`ProcApproximateIterateSingleStepEmulator`). 34 | 35 | Choosing the Alternatives 36 | ------------------------- 37 | 38 | The simulation method can be computationally intensive, but has the 39 | advantage of producing exact draws from the distribution of 40 | :math:`w_1,\ldots,w_T`. The approximation method is computationally faster 41 | to implement, and so is to be preferred if the normal approximation is 42 | sufficiently accurate. The approximation is likely to be accurate when 43 | 44 | - uncertainty about :math:`f(\cdot)` is small, and 45 | - the simulator is approximately linear over any small part of the 46 | input space. 47 | 48 | As always, it is important to validate the emulator (see the procedure 49 | page on validating a GP emulator 50 | (:ref:`ProcValidateCoreGP`)), but particular 51 | attention should be paid to emulator uncertainty in addition to emulator 52 | predictions. 53 | 54 | Additional comments 55 | ------------------- 56 | 57 | If the approximation method is to be used for many different choices 58 | :math:`w_0,a_1,\ldots,a_T` and :math:`\phi`, it is recommended that both 59 | methods are tried for a subset of these choices, to test the accuracy of 60 | the approximation. 61 | -------------------------------------------------------------------------------- /docs/methods/alt/AltMeanFunctionMultivariate.rst: -------------------------------------------------------------------------------- 1 | .. _AltMeanFunctionMultivariate: 2 | 3 | Alternatives: Multivariate emulator prior mean function 4 | ======================================================= 5 | 6 | Overview 7 | -------- 8 | 9 | In the process of building a :ref:`multivariate 10 | GP` emulator it is necessary to specify a 11 | mean function for the GP model. The mean function for a set of outputs 12 | is a vector function. Its elements are the mean functions for each 13 | output, defining a prior expectation of the form of that output's 14 | response to the simulator's inputs. Alternative choices on the emulator 15 | prior mean function for an individual output are discussed in 16 | :ref:`AltMeanFunction`. Here we discuss how these 17 | may be adapted for use in the multivariate emulator. 18 | 19 | Choosing the alternatives 20 | ------------------------- 21 | 22 | If the linear form of mean function is chosen with the same :math::ref:`q\times 23 | 1` vector :math:`h(\cdot)` of `basis functions` 24 | for each output, then the vector mean function can be expressed simply 25 | as :math:`\beta^T h(\cdot)`, where :math:`\beta` is a :math:`q\times r` matrix of 26 | regression coefficients and :math:`r` is the number of outputs. The choice 27 | of regressors for the two simple cases shown in 28 | :ref:`AltMeanFunction` can then be adapted as 29 | follows: 30 | 31 | \* For :math:`q=1` and :math:`h(x)=1`, the mean function becomes :math:`m(x) = 32 | \\beta`, where :math:`\beta` is a :math:`r`-dimension vector of 33 | hyperparameters representing an unknown multivariate overall mean (i.e. 34 | the mean vector) for the simulator output. 35 | 36 | \* For :math:`h(x)^T=(1,x)`, so that :math:`q=1+p`, where :math:`p` is the number 37 | of inputs and the mean function is an :math:`r`-dimensional vector whose 38 | :math:`j`th element is the scalar: :math:`\{m(x)\}_j=\beta_{1,j} + 39 | \\beta_{2,j}\,x_1 + \\ldots + \\beta_{1+p,j}\,x_p`. 40 | 41 | This linear form of mean function in which all outputs have the same set 42 | of basis functions is generally used in the multivariate emulator 43 | described in 44 | :ref:`ThreadVariantMultipleOutputs`, 45 | where it is the natural choice for the :ref:`multivariate Gaussian 46 | process` and has mathematical and 47 | computational advantages. However, the linear form does not have to be 48 | used, and there may be situations in which we believe the outputs behave 49 | like a function that is non-linear in the unknown coefficients, such as 50 | :math:`\{m(x)\}_j = x / (\beta_{1,j} + \\beta_{2,j} x)`. The general theory 51 | still holds for a non-linear form, albeit without the mathematical 52 | simplification which allow the analytic integration of the regression 53 | parameters :math:`\beta`. 54 | 55 | It would also be possible to use different mean functions for different 56 | outputs, but this is not widely done in practice and renders the 57 | notation more verbose. 58 | -------------------------------------------------------------------------------- /docs/methods/alt/AltNumericalSolutionForKarhunenLoeveExpansion.rst: -------------------------------------------------------------------------------- 1 | .. _AltNumericalSolutionForKarhunenLoeveExpansion: 2 | 3 | Alternatives: Numerical solution for Karhunen Loeve expansion 4 | ============================================================= 5 | 6 | Overview 7 | -------- 8 | 9 | The analytical solutions of the Fredholm equation only exist for some 10 | particular processes, that is, for particular covariance functions. For 11 | this reason the numerical solutions are usually essential. There are two 12 | main methods: the integral method and the expansion method. 13 | 14 | Choosing the Alternatives 15 | ------------------------- 16 | 17 | The eigenfunction is not explicitly defined when using the integral 18 | method.Therefore the expansion method is preferred where the 19 | eigenfunction is approximated using some orthonormal basis functions. 20 | 21 | The Nature of the Alternatives 22 | ------------------------------ 23 | 24 | Integral method 25 | ~~~~~~~~~~~~~~~ 26 | 27 | This is a direct approximation for the integral, i.e. 28 | :math:`\int_{0}^{1}f(t)dt \approx \sum_{i=0}^{n+1}\omega_if(t_i).` 29 | 30 | The bigger the :math:`n`, the better the approximation. 31 | 32 | Expansion method 33 | ~~~~~~~~~~~~~~~~ 34 | 35 | This method is known as Galerkin method. It employs a set of basis 36 | functions. The commonly used basis functions are Fourier (trigonometric) 37 | or wavelets. Implementation is discussed in 38 | :ref:`ProcFourierExpansionForKL` and 39 | :ref:`ProcHaarWaveletExpansionForKL`. 40 | Note that although we have presented the methods separately, there are 41 | many common features which would comprise a generic method which could 42 | be used, in principle, for any approximation based on a particularly 43 | basis. 44 | 45 | Additional Comments, References, and Links 46 | ------------------------------------------ 47 | 48 | The solution of Fredholm equations of the second kind has a strong 49 | background in applied mathematics and numerical analysis. A useful 50 | volume is: 51 | 52 | K. E. Atkinson. Numerical solutions of integral equations of the second 53 | kind. Cambridge, 1997. 54 | -------------------------------------------------------------------------------- /docs/methods/def/DefActiveInput.rst: -------------------------------------------------------------------------------- 1 | .. _DefActiveInput: 2 | 3 | Definition of Term: Active input 4 | ================================ 5 | 6 | A :ref:`simulator` will typically have many inputs. In 7 | general, the larger the number of inputs the more complex it becomes to 8 | build a good :ref:`emulator`, and the larger the number 9 | of simulator runs required for the :ref:`training 10 | sample`. There is therefore motivation for 11 | reducing the number of inputs. 12 | 13 | Fortunately, it is also generally found that not all inputs affect the 14 | output(s) of interest appreciably over the required range of input 15 | variation. The number of inputs having appreciable impact on outputs for 16 | the purpose of the analysis is often small. The term 'active input' 17 | loosely means one which does have such an impact. More precisely, the 18 | active inputs are those that are deemed to be inputs when building the 19 | emulator. 20 | -------------------------------------------------------------------------------- /docs/methods/def/DefAdjoint.rst: -------------------------------------------------------------------------------- 1 | .. _DefAdjoint: 2 | 3 | Definition of Term: Adjoint 4 | =========================== 5 | 6 | An adjoint is an extension to a :ref:`simulator` which 7 | produces derivatives of the simulator output with respect to its inputs. 8 | 9 | Technically, an adjoint is the transpose of a tangent linear 10 | approximation; written either by hand or with the application of 11 | automatic differentiation, it produces partial derivatives in addition 12 | to the standard output of the simulator. An adjoint is computationally 13 | more expensive to run than the standard simulator, but efficiency is 14 | achieved in comparison to the finite differences method to generating 15 | derivatives. This is because where computing partial derivatives by 16 | finite differences requires at least two runs of the simulator for each 17 | input parameter, the corresponding derivatives can all be generated by 18 | one single run of an appropriate adjoint. 19 | -------------------------------------------------------------------------------- /docs/methods/def/DefAssessment.rst: -------------------------------------------------------------------------------- 1 | .. _DefAssessment: 2 | 3 | Definition of Term: Assessment 4 | ============================== 5 | 6 | When dealing with an uncertain quantity, the term "assessment" is used 7 | to refer to the process of identifying a suitable probabilistic form to 8 | represent the current knowledge/uncertainty related to that quantity. 9 | This process may for example involve 10 | :ref:`elicitation`, or other more formal methods. 11 | 12 | The term is often used in the context of the assessment of the :ref:`model 13 | discrepancy`. 14 | -------------------------------------------------------------------------------- /docs/methods/def/DefBLAdjust.rst: -------------------------------------------------------------------------------- 1 | .. _DefBLAdjust: 2 | 3 | Definition of Term: Bayes linear adjustment 4 | =========================================== 5 | 6 | In the context of the :ref:`Bayes linear` approach, 7 | suppose that we have specified prior means, variances and covariances 8 | for a collection of uncertain quantities. If the values of some of the 9 | quantities become known, then we reassess our judgements about the 10 | remaining quantities. As the Bayes linear approach is 11 | :ref:`Bayesian`, we modify our prior beliefs in light of 12 | the data, which (under the Bayes linear approach) yields the *adjusted 13 | expectation* and *adjusted variance* for each quantity and the *adjusted 14 | covariance* for every pair. 15 | 16 | See the procedure page on calculation of adjusted expectation and 17 | variance (:ref:`ProcBLAdjust`) for details on 18 | calculating the adjusted expectations, variances and covariances, and 19 | the discussion page on theoretical aspects of Bayes linear 20 | (:ref:`DiscBayesLinearTheory`) for further 21 | discussion of the theory behind Bayes linear. 22 | -------------------------------------------------------------------------------- /docs/methods/def/DefBLVarianceLearning.rst: -------------------------------------------------------------------------------- 1 | .. _DefBLVarianceLearning: 2 | 3 | Definition of Term: Bayes linear variance learning 4 | ================================================== 5 | 6 | Learning about the variance :math:`\sigma^2` of a complex model can be a 7 | challenging problem. The Bayes Linear approach is to make a standard 8 | Bayes Linear :ref:`adjustment` of our prior beliefs 9 | about :math:`\sigma^2` using the observed sample variance and exploiting 10 | certain weak assumptions about model behaviour (:ref:`second-order 11 | exchangeability`). 12 | -------------------------------------------------------------------------------- /docs/methods/def/DefBasisFunctions.rst: -------------------------------------------------------------------------------- 1 | .. _DefBasisFunctions: 2 | 3 | Definition of Term: Basis functions 4 | =================================== 5 | 6 | The mean function of an emulator, :math:`m(x)`, expresses the global 7 | behaviour of the computer model and can be written in a variety of forms 8 | as described in the alternatives page on emulator prior mean function 9 | (:ref:`AltMeanFunction`). When the mean function 10 | takes a linear form it can be expressed as :math:`m(x)=\beta^Th(x)` 11 | where :math:`h(x)` is a :math:`q`-vector of known *basis functions* of :math:`x` 12 | which describe global features of the simulator's behaviour and 13 | :math:`\beta` is a vector of unknown coefficients. 14 | 15 | The task of specifying appropriate forms for :math:`h(x)` is addressed in 16 | the alternatives page on basis functions for the emulator mean 17 | (:ref:`AltBasisFunctions`). 18 | -------------------------------------------------------------------------------- /docs/methods/def/DefBayesLinear.rst: -------------------------------------------------------------------------------- 1 | .. _DefBayesLinear: 2 | 3 | Definition of Term: Bayes linear 4 | ================================ 5 | 6 | Like the fully :ref:`Bayesian` approach in 7 | :ref:`MUCM`, the Bayes linear approach is founded on a 8 | personal (or subjective) interpretation of probability. Unlike the 9 | Bayesian approach, however, probability is not the fundamental primitive 10 | concept in the Bayes linear philosophy. Instead, expectations are 11 | primitive and updating is carried out by orthogonal projection. In the 12 | simple case of a vector of real quantities, some of which are observed, 13 | this projection is equivalent to minimising expected quadratic loss over 14 | a linear combination of the observed quantities, and the adjusted mean 15 | and variance that result are computationally the same as the Bayesian 16 | conditional mean and variance of a Gaussian vector. If the observation 17 | vector consists of the indicator functions for a partition, then the 18 | Bayes linear adjustment is equivalent to Bayesian conditioning on the 19 | partition. 20 | 21 | Further details on the theory behind the Bayes linear approach are given 22 | in the discussion page on theoretical aspects of Bayes linear 23 | (:ref:`DiscBayesLinearTheory`). 24 | -------------------------------------------------------------------------------- /docs/methods/def/DefBayesian.rst: -------------------------------------------------------------------------------- 1 | .. _DefBayesian: 2 | 3 | Definition of Term: Bayesian 4 | ============================ 5 | 6 | The adjective 'Bayesian' refers to ideas and methods arising in the 7 | field of Bayesian Statistics. 8 | 9 | Bayesian statistics is an approach to constructing statistical 10 | inferences that is fundamentally and philosophically different from the 11 | approach that is more commonly taught, known as frequentist statistics. 12 | 13 | In Bayesian statistics, all inferences are probability statements about 14 | the true, but unknown, values of the parameters of interest. The formal 15 | interpretation of those probability statements is as the personal 16 | beliefs of the person providing them. 17 | 18 | The fact that Bayesian inferences are essentially personal judgements 19 | has been the basis of heated debate between proponents of the Bayesian 20 | approach and those who espouse the frequentist approach. Frequentists 21 | claim that Bayesian methods are subjective and that subjectivity should 22 | have no role in science. Bayesians counter that frequentist inferences 23 | are not truly objective, and that the practical methods of Bayesian 24 | statistics are designed to minimise the undesirable aspects of 25 | subjectivity (such as prejudice). 26 | 27 | As in any scientific debate, the arguments and counter-arguments are 28 | many and complex, and it is certainly not the intention of this brief 29 | definition to go into any of that detail. In the context of the MUCM 30 | toolkit, the essence of an :ref:`emulator` is that it 31 | makes probability statements about the outputs of a 32 | :ref:`simulator`, and the frequentist approach does not 33 | formally allow such statements. Therefore emulators are necessarily 34 | Bayesian. 35 | 36 | In the :ref:`MUCM` field, there is a recognised alternative 37 | to the fully Bayesian approach of characterising uncertainty about 38 | unknown parameters by complete probability distributions. This is the 39 | :ref:`Bayes linear` approach, in which uncertainty is 40 | represented only through means, variances and covariances. 41 | -------------------------------------------------------------------------------- /docs/methods/def/DefBestInput.rst: -------------------------------------------------------------------------------- 1 | .. _DefBestInput: 2 | 3 | Definition of Term: Best Input 4 | ============================== 5 | 6 | No matter how careful a particular model of a real system has been 7 | formulated, there will always be a discrepancy between reality, 8 | represented by the system value :math:`y`, and the 9 | :ref:`simulator` output :math:`f(x)` for any valid 10 | input :math:`\strut{x}`. Perhaps, the simplest way of incorporating this 11 | :ref:`model discrepancy` into our analysis is to 12 | postulate a best input :math:`x^+`, representing the best fitting 13 | values of the input parameters in some sense, such that the difference 14 | :math:`d=y-f(x^+)` is independent or uncorrelated with :math:`f`, 15 | :math:`f(x^+)` and :math:`x^+`. 16 | 17 | While there are subtleties in the precise interpretation of 18 | :math:`x^+`, especially when certain inputs do not correspond to 19 | clearly defined features of the system, the notion of a best input is 20 | vital for procedures such as :ref:`calibration`, 21 | history matching and prediction for the real system. 22 | -------------------------------------------------------------------------------- /docs/methods/def/DefCalibration.rst: -------------------------------------------------------------------------------- 1 | .. _DefCalibration: 2 | 3 | Definition of Term: Calibration 4 | =============================== 5 | 6 | The inputs to a :ref:`simulator` that are the correct 7 | or best values to use to predict a particular real-world system are very 8 | often uncertain. 9 | 10 | *Example*: An atmospheric dispersion simulator models the way that 11 | pollutants are spread through the atmosphere when released. Its outputs 12 | concern how much of a pollutant reaches various places or susceptible 13 | targets. In order to use the simluator to predict the effects of a 14 | specific pollutant release, we need to specif the appropriate input 15 | values for the location of the release, the quantity released, the wind 16 | speed and direction and so on. All of these may in practice be 17 | uncertain. 18 | 19 | If we can make observations of the real-world system, then we can use 20 | these to learn about those uncertain inputs. A crude way to do this is 21 | to adjust the inputs so as to make the simulator predict as closely as 22 | possible the actual observation points. This is widely done by model 23 | users, and is called calibration. The best fitting values of the 24 | uncertain parameters are then used to make predictions of the system. 25 | 26 | *Example*: Observing the amount of pollutant reaching some specific 27 | points, we can then calibrate the model and use the best fitting input 28 | values to predict the amounts reaching other points and hence assess the 29 | consequences for key susceptible targets. 30 | 31 | In :ref:`MUCM`, we take the broader view that such 32 | observations allow us to learn about the uncertain inputs, but not to 33 | eliminate uncertainty. We therefore consider calibration to be the 34 | process of using observations of the real system to modify (and usually 35 | to reduce) the uncertainty about specific inputs. 36 | 37 | See also :ref:`data assimilation`. 38 | -------------------------------------------------------------------------------- /docs/methods/def/DefCodeUncertainty.rst: -------------------------------------------------------------------------------- 1 | .. _DefCodeUncertainty: 2 | 3 | Definition of Term: Code uncertainty 4 | ==================================== 5 | 6 | An :ref:`emulator` is a probabilistic representation of 7 | the output(s) of a :ref:`simulator`. For any given 8 | input configuration the output is uncertain (unless this input 9 | configuration was included in the :ref:`training 10 | sample`). This uncertainty is known as code 11 | uncertainty. The emulator defines exactly what the code uncertainty is 12 | about the output(s) from any given configuration(s) of inputs. 13 | 14 | Because the output(s) are uncertain, we are also uncertain about 15 | properties of those outputs, such as the uncertainty mean in an 16 | :ref:`uncertainty analysis`. The code 17 | uncertainty expressed in the emulator then implies code uncertainty 18 | about the properties of interest. Statements that we can make about 19 | those properties are therefore *inferences*. For instance, we may 20 | estimate a property by its mean, which is evaluated with respect to its 21 | code uncertainty distribution. 22 | -------------------------------------------------------------------------------- /docs/methods/def/DefConjugate.rst: -------------------------------------------------------------------------------- 1 | .. _DefConjugate: 2 | 3 | Definition of Term: Conjugate prior 4 | =================================== 5 | 6 | In the :ref:`Bayesian` approach to statistics, a prior 7 | distribution expresses prior knowledge about parameters in a statistical 8 | analysis. The prior distribution is then combined with the information 9 | in the data using Bayes' theorem, and the resulting posterior 10 | distribution is used for making inference statements (such as estimates 11 | or credible intervals) about the parameters. Specification of the prior 12 | distribution is therefore an important task in Bayesian statistics. Two 13 | simplifying techniques that are often used are to employ 14 | :ref:`weak` prior distributions (that represent prior 15 | information that is supposed to be weak relative to the information in 16 | the data) and conjugate prior distributions. 17 | 18 | A conjugate distribution is of a mathematical form that combines 19 | conveniently with the information in the data, so that the posterior 20 | distribution is easy to work with. The specification of prior 21 | information is generally an imprecise process, and the particular choice 22 | of distributional form is to some extent arbitrary. (It is this 23 | arbitrariness that is objected to by those who advocate the :ref:`Bayes 24 | linear` approach rather than the fully Bayesian 25 | approach; both may be found in the toolkit.) So as long as the conjugate 26 | form would not obviously be an inappropriate representation of prior 27 | information it is sensible to use a conjugate prior distribution. 28 | -------------------------------------------------------------------------------- /docs/methods/def/DefCorrelationLength.rst: -------------------------------------------------------------------------------- 1 | .. _DefCorrelationLength: 2 | 3 | Definition of Term: Correlation length 4 | ====================================== 5 | 6 | The degree of :ref:`smoothness` of an 7 | :ref:`emulator` is determined by its correlation 8 | function. Smoothness is in practice controlled by 9 | :ref:`hyperparameters` in the correlation function 10 | that define how slowly the correlation between the simulator outputs at 11 | two input points declines as the distance between the points increases. 12 | These hyperparameters are typically called correlation length 13 | parameters. Their precise role in determining smoothness depends on the 14 | form of correlation function. 15 | -------------------------------------------------------------------------------- /docs/methods/def/DefDataAssimilation.rst: -------------------------------------------------------------------------------- 1 | .. _DefDataAssimilation: 2 | 3 | Definition of Term: Data Assimilation 4 | ===================================== 5 | 6 | Data assimilation is a term that is widely used in the context of using 7 | observations of the real-world process to update a 8 | :ref:`simulator`. It generally applies to a 9 | :ref:`dynamic` simulator that models a real-world process 10 | that is evolving in time. At each time step, the simulator simulates the 11 | current state of the system as expressed in the :ref:`state 12 | vector`. In data assimilation, observation of 13 | the real-world process at a given time point is used to learn about the 14 | true status of the process and hence to adjust the state vector of the 15 | simulator. Then the simulator's next time step starts from the adjusted 16 | state vector, and should therefore predict the system state better at 17 | subsequent time steps. 18 | 19 | Data assimilation is thus also a dynamic process. It is similar to 20 | :ref:`calibration` in the sense that it uses 21 | real-world observations to learn about simulator parameters, but the 22 | term calibration is generally applied to imply a one-off learning about 23 | fixed parameters/inputs. 24 | -------------------------------------------------------------------------------- /docs/methods/def/DefDecisionBasedSA.rst: -------------------------------------------------------------------------------- 1 | .. _DefDecisionBasedSA: 2 | 3 | Definition of Term: Decision-based sensitivity analysis 4 | ======================================================= 5 | 6 | In decision-based :ref:`sensitivity analysis` 7 | we consider the effect on a decision which will be based on the output 8 | :math:`f(X)` of a :ref:`simulator` as we vary the inputs 9 | :math:`X`, when the variation of those inputs is described by a (joint) 10 | probability distribution. This probability distribution can be 11 | interpreted as describing uncertainty about the best or true values for 12 | the inputs. 13 | 14 | We measure the sensitivity to an individual input :math:`X_i` by the extent 15 | to which we would be able to make a better decision if we could remove 16 | the uncertainty in that input. 17 | 18 | A decision problem is characterised by a set of possible decisions and a 19 | utility function that gives a value :math:`U(d,f(x))` if we take decision 20 | :math:`d` and the true value for the input vector is :math:`x`. The optimal 21 | decision, given the uncertainty in :math:`X`, is the one which maximises 22 | the expected utility. Let :math:`U^*` be the resulting maximised expected 23 | utility based on the current uncertainty in the inputs. 24 | 25 | If we were to remove the uncertainty in the i-th input by learning that 26 | its true value is :math:`X_i = x_i`, then we might make a different 27 | decision. We would now take the expected utility with respect to the 28 | *conditional* distribution of :math:`X` given that :math:`X_i = x_i`, and then 29 | maximise this with respect to the decision :math:`d`. Let :math:`U^*_i(x_i)` 30 | be the resulting maximised expected utility. This of course depends on 31 | the true value :math:`x_i` of :math:`X_i`, which we do not know. The 32 | decision-based sensitivity measure for the i-th input is then the value 33 | of learning the true value of :math:`X_i` in terms of improved expected 34 | utility, i.e. :math:`V_i = \text{E}[U^*_i(X_i)] - U^*`, where the 35 | expectation in the first term is with respect to the marginal 36 | distribution of :math:`X_i`. 37 | 38 | We can similarly define the sensitivity measure for two or more inputs 39 | as being the value of learning the true values of all of these. 40 | 41 | :ref:`Variance-based` sensitivity analysis is a 42 | special case of decision-based analysis, when the decision is simply to 43 | estimate the true output :math:`f(X)` and the utility function is negative 44 | squared error. In practice, though, variance-based sensitivity analysis 45 | provides natural measures of sensitivity when there is no specific 46 | decision problem. 47 | -------------------------------------------------------------------------------- /docs/methods/def/DefDesign.rst: -------------------------------------------------------------------------------- 1 | .. _DefDesign: 2 | 3 | Definition of Term: Design 4 | ========================== 5 | 6 | In order to build an :ref:`emulator` for a 7 | :ref:`simulator`, we need data comprising a :ref:`training 8 | sample` of simulator runs. The training 9 | sample design is the set of points in the space of simulator inputs at 10 | which the simulator is run. 11 | 12 | There are a number of related design contexts which arise in the 13 | :ref:`MUCM` toolkit. 14 | 15 | - A validation sample design is a set of points in the input space at 16 | which additional simulator runs are made to 17 | :ref:`validate` the emulator. 18 | 19 | - In the context of :ref:`calibrating` a simulator, 20 | we may design an observational study by specifying a set of points in 21 | the space of input values which we can control when making 22 | observations of the real-world process. 23 | 24 | - Where we have more than one simulator available, a design may specify 25 | sets of points in the input spaces of the various simulators. 26 | 27 | - For complex tasks using the emulator, a general solution is via 28 | simulated realisations of the output function :math:`f(\cdot)`. For this 29 | purpose we need a set of input configurations at which to simulate 30 | outputs, which we refer to as a realisation design. 31 | 32 | Some general remarks on design options for the core problem are 33 | discussed in the alternatives page on training sample design for the 34 | core problem (:ref:`AltCoreDesign`). 35 | -------------------------------------------------------------------------------- /docs/methods/def/DefDeterministic.rst: -------------------------------------------------------------------------------- 1 | .. _DefDeterministic: 2 | 3 | Definition of Term: Deterministic 4 | ================================= 5 | 6 | A :ref:`simulator` is referred to as deterministic if, 7 | whenever it is run with a given input configuration it gives the same 8 | output(s). 9 | -------------------------------------------------------------------------------- /docs/methods/def/DefDynamic.rst: -------------------------------------------------------------------------------- 1 | .. _DefDynamic: 2 | 3 | Definition of Term: Dynamic simulator 4 | ===================================== 5 | 6 | A dynamic :ref:`simulator` models a real-world process 7 | that evolves over time (or sometimes in space, or both time and space). 8 | Its inputs typically include an initial :ref:`state 9 | vector` that defines the initial state of the 10 | process, as well as other fixed inputs governing the operation of the 11 | system. It often also has external :ref:`forcing 12 | inputs` that provide time-varying impacts on 13 | the system. The dynamic nature of the simulator means that as it runs it 14 | updates the state vector on a regular time step, to model the evolving 15 | state of the process. 16 | 17 | *Example:* A simulator of a growing plant will have a state vector 18 | describing the sizes of various parts of the plant, the presence of 19 | nutrients and so on. Fixed inputs parameterise the biological processes 20 | within the plant, while forcing inputs may include the temperature, 21 | humidity and intensity of sunlight at a given time point. 22 | 23 | At time :math:`t`, the simulator uses the time :math:`t` value 24 | of its state vector, the fixed inputs and the time :math:`t` values 25 | of the forcing inputs to compute the value of its state vector at time 26 | :math:`t+\Delta t` (where :math:`\Delta t` is the length of the simulator's 27 | time step). It then repeats this process using the new state vector, the 28 | fixed inputs and new forcing input values to move forward to time 29 | :math:`t+2\Delta t`, and so on. 30 | -------------------------------------------------------------------------------- /docs/methods/def/DefElicitation.rst: -------------------------------------------------------------------------------- 1 | .. _DefElicitation: 2 | 3 | Definition of Term: Elicitation 4 | =============================== 5 | 6 | Probability distributions are needed to express uncertainty about 7 | unknown quantities in various contexts. In the :ref:`MUCM` 8 | toolkit, there are two principal areas where such probability 9 | distributions may be required. One is to specify prior knowledge about 10 | :ref:`hyperparameters` associated with building a 11 | :ref:`Gaussian process` :ref:`emulator`, while 12 | the other is to formulate uncertainty about inputs to the 13 | :ref:`simulator` (for instance, for the purposes of 14 | :ref:`uncertainty` or 15 | :ref:`sensitivity` analyses). These 16 | probability distributions may be created in various ways, but the most 17 | basic is to represent the knowledge/beliefs of a relevant expert. 18 | 19 | The process of formulating an expert's knowledge about an uncertain 20 | quantity as a probability distribution is called elicitation. 21 | -------------------------------------------------------------------------------- /docs/methods/def/DefEmulator.rst: -------------------------------------------------------------------------------- 1 | .. _DefEmulator: 2 | 3 | Definition of Term: Emulator 4 | ============================ 5 | 6 | An emulator is a statistical representation of a 7 | :ref:`simulator`. For any given configuration of input 8 | values for the simulator, the emulator provides a probabilistic 9 | prediction of one or more of the outputs that the simulator would 10 | produce if it were run at those inputs. 11 | 12 | Furthermore, for any set of input configurations, the emulator will 13 | provide a joint probabilistic prediction of the corresponding set of 14 | simulator outputs. 15 | 16 | *Example*: A simulator of a nuclear power station reactor requires 17 | inputs that specify the flow of gas through the reactor, and produces an 18 | output which is the steady state mean temperature of the reactor core. A 19 | simulator of this output would provide probabilistic predictions of the 20 | mean temperature (as output by the actual simulator) at any single 21 | configuration of gas flow inputs, or at any set of such configurations. 22 | 23 | The probabilistic predictions may take one of two forms depending on the 24 | approach used to build the emulator. In the fully 25 | :ref:`Bayesian` approach, the predictions are complete 26 | probability distributions. 27 | 28 | *Example*: In the previous example, the fully Bayesian approach would 29 | provide a complete probability distribution for the output from any 30 | single configuration of inputs. This would give the probability that the 31 | output (mean temperature) lies in any required range. In particular, it 32 | would also provide any desired summaries of the probability 33 | distribution, such as the mean or variance. For a given set of input 34 | configurations, it would produce a joint probability distribution for 35 | the corresponding set of outputs, and in particular would give means, 36 | variances and covariances. 37 | 38 | In the :ref:`Bayes linear` approach, the emulator's 39 | probabilistic specification of outputs comprises (adjusted) means, 40 | variances and covariances. 41 | 42 | *Example*: The Bayes linear emulator in the above example would provide 43 | the (adjusted) mean and (adjusted) variance for the simulator output 44 | (mean temperature) from a given single configuration of gas flow inputs. 45 | When the emulator is used to predict a set of outputs from more than one 46 | input configuration, it will also provide (adjusted) covariances between 47 | each pair of outputs. 48 | 49 | Strictly, these 'adjusted' means, variances and covariances have a 50 | somewhat different meaning from the means, variances and covariances in 51 | a fully Bayesian emulator. Nevertheless, they are in practice 52 | interpreted the same way - thus, the (adjusted) mean is a point estimate 53 | of the simulator output and the square-root of the (adjusted) variance 54 | is a measure of accuracy for that estimate in the sense of being a 55 | root-mean-square distance from the estimate to the true simulator 56 | output. In practice, we would drop the word 'adjusted' and simply call 57 | them means, variances and covariances, but the distinction can be 58 | important. 59 | -------------------------------------------------------------------------------- /docs/methods/def/DefExchangeability.rst: -------------------------------------------------------------------------------- 1 | .. _DefExchangeability: 2 | 3 | Definition of Term: Exchangeability 4 | =================================== 5 | 6 | Exchangeability is regarded as a fundamental concept in any statistical 7 | modelling -- regardless of whether that analysis is performed from a 8 | :ref:`Bayesian` or frequentist perspective. A sequence 9 | of random variables is described as exchangeable if our beliefs about 10 | that collection are unaffected by the order in which they appear. For 11 | example, if we perform 100 tosses of a coin, then, if the coin tosses 12 | are exchangeable, our beliefs about the fairness of the coin will be 13 | unaffected by the order in which we observe the heads and tails. 14 | 15 | In formal terms, when our beliefs about a sequence of random variables 16 | :math:`X_1, X_2, \ldots` are characterised by a joint probability 17 | distribution, if the :math:`X_i`\s are exchangeable then the joint 18 | probability distribution of the sequence is the same as the joint 19 | distribution over any re-ordering of the :math:`X_i`\s. In fact, the 20 | assertion of exchangeability implies the existence of this underlying 21 | joint distribution. 22 | 23 | This idea of exchangeability underpins the concept of prediction, as 24 | when past observations and future observations are exchangeable then the 25 | future will be predictable on the basis of the data gathered in the 26 | past. 27 | -------------------------------------------------------------------------------- /docs/methods/def/DefForcingInput.rst: -------------------------------------------------------------------------------- 1 | .. _DefForcingInput: 2 | 3 | Definition of Term: Forcing Input 4 | ================================= 5 | 6 | A :ref:`dynamic` :ref:`simulator` models 7 | a process that is evolving, usually in time. Many dynamic simulators 8 | have forcing inputs that specify external influences on the process that 9 | vary in time. In order to simulate the evolution of the process at each 10 | point in time, the simulator must take account of the values of the 11 | forcing inputs at that time point. 12 | 13 | *Example:* A simulator of water flow through a river catchment will have 14 | forcing inputs that specify the rainfall over time. Humidity may be 15 | another forcing input, since it will govern the rate at which water in 16 | the catchment evaporates. 17 | -------------------------------------------------------------------------------- /docs/methods/def/DefGP.rst: -------------------------------------------------------------------------------- 1 | .. _DefGP: 2 | 3 | Definition of Term: Gaussian process 4 | ==================================== 5 | 6 | A Gaussian process (GP) is a probability model for an unknown function. 7 | 8 | If a function :math:`f` has argument :math:`x`, then the value of the function 9 | at that argument is :math:`f(x)`. A probability model for such a function 10 | must provide a probability distribution for :math:`f(x)`, for any possible 11 | argument value :math:`x`. Furthermore, if we consider a set of possible 12 | values for the argument, which we can denote by :math:`x_1, x_2, ..., x_N`, 13 | then the probability model must provide a joint probability distribution 14 | for the corresponding function values :math:`f(x_1), f(x_2),\cdots, 15 | f(x_N)`. 16 | 17 | In :ref:`MUCM` methods, an :ref:`emulator` 18 | is (at least in the fully Bayesian approach) a probability model for the 19 | corresponding :ref:`simulator`. The simulator is 20 | regarded as a function, with the simulator inputs comprising the 21 | function's argument and the simulator output(s) comprising the function 22 | value. 23 | 24 | A GP is a particular probability model in which the distribution for a 25 | single function value is a normal distribution (also often called a 26 | Gaussian distribution), and the joint distribution of a set of function 27 | values is multivariate normal. In the same way that normal distributions 28 | play a central role in statistical practice by virtue of their 29 | mathematical simplicity, the GP plays a central role in (fully Bayesian) 30 | MUCM methods. 31 | 32 | Just as a normal distribution is identified by its mean and its 33 | variance, a GP is identified by its mean function and its covariance 34 | function. The mean function is :math:`\text{E}[f(x)]`, regarded as a 35 | function of :math:`x`, and the covariance function is :math:`\text{Cov}[f(x_1), 36 | f(x_2)]`, regarded as a function of both :math:`x_1` and :math:`x_2`. Note in 37 | particular that the variance of :math:`f(x)` is the value of the covariance 38 | function when both :math:`x_1` and :math:`x_2` are equal to :math:`x` . 39 | 40 | A GP emulator represents beliefs about the corresponding simulator as a 41 | GP, although in practice this is always conditional in the sense that 42 | the mean and covariance functions are specified in terms of uncertain 43 | parameters. The representation of beliefs about simulator output values 44 | as a GP implies that the probability distributions for those outputs are 45 | normal, and this is seen as an assumption or an approximation. In the 46 | Bayes linear approach in MUCM, the assumption of normality is not made, 47 | and the mean and covariance functions alone comprise the Bayes linear 48 | emulator. 49 | -------------------------------------------------------------------------------- /docs/methods/def/DefHistoryMatching.rst: -------------------------------------------------------------------------------- 1 | .. _DefHistoryMatching: 2 | 3 | Definition of Term: History Matching 4 | ==================================== 5 | 6 | History matching is a process that involves identifying the set of all 7 | inputs :math:`x` that would give rise to acceptable matches between 8 | the simulator output :math:`f(x)` and the observed data 9 | :math:`z`. 10 | 11 | Often the process involves the iterative removal of regions of the input 12 | space by the application of cutoffs to various :ref:`implausibility 13 | measures`. 14 | -------------------------------------------------------------------------------- /docs/methods/def/DefHyperparameter.rst: -------------------------------------------------------------------------------- 1 | .. _DefHyperparameter: 2 | 3 | Definition of Term: Hyperparameter 4 | ================================== 5 | 6 | A parameter is any variable in a probability distribution. For instance, 7 | a normal distribution is generally defined to have two parameters, its 8 | mean and its variance. 9 | 10 | The term hyperparameter is used (fairly loosely) in Bayesian statistics 11 | to mean a parameter in the prior distribution. 12 | 13 | For the :ref:`Gaussian process` 14 | :ref:`emulator` the term denotes the parameters in the 15 | :ref:`mean` or 16 | :ref:`variance` functions. 17 | -------------------------------------------------------------------------------- /docs/methods/def/DefImplausibilityMeasure.rst: -------------------------------------------------------------------------------- 1 | .. _DefImplausibilityMeasure: 2 | 3 | Definition of Term: Implausibility Measure 4 | ========================================== 5 | 6 | An implausibility measure is a function :math:`I(x)` defined over 7 | the whole input space which, if large for a particular :math:`x`, 8 | suggests that there would be a substantial disparity between the 9 | simulator output :math:`f(x)` and the observed data :math:`z`, 10 | were we to evaluate the model at :math:`\strut{x}`. 11 | 12 | In the simplest case where :math:`f(x)` represents a single 13 | output and :math:`z` a single observation, the univariate 14 | implausibility would look like: 15 | 16 | .. math:: 17 | I^2(x) = \frac{ ({\rm E}[f(x)] - z )^2}{ {\rm Var}[{\rm E}[f(x)]-z] } 18 | = \frac{ ({\rm E}[f(x)] - z )^2}{{\rm Var}[f(x)] + {\rm Var}[d] + {\rm Var}[e]} 19 | 20 | where :math:`{\rm E}[f(x)]` and :math:`{\rm Var}[f(x)]` 21 | are the emulator expectation and variance respectively; :math:`d` 22 | is the :ref:`model discrepancy`, and :math:`e` 23 | is the observational error. The second equality follows from the 24 | definition of the :ref:`best input approach`. 25 | 26 | Several different implausibility measures can be defined in the case 27 | where the simulator produces multiple outputs. 28 | -------------------------------------------------------------------------------- /docs/methods/def/DefInactiveInput.rst: -------------------------------------------------------------------------------- 1 | .. _DefInactiveInput: 2 | 3 | Definition of Term: Inactive input 4 | ================================== 5 | 6 | An inactive input is a :ref:`simulator` input that is 7 | not an :ref:`active input`. Loosely, it is an input 8 | that does not influence the output(s) of interest appreciably when it is 9 | varied over the required range of input values. More precisely, the 10 | values given to inactive inputs in the simulator runs for the :ref:`training 11 | sample` are ignored when building the 12 | :ref:`emulator`. 13 | -------------------------------------------------------------------------------- /docs/methods/def/DefMUCM.rst: -------------------------------------------------------------------------------- 1 | .. _DefMUCM: 2 | 3 | Definition of Term: MUCM 4 | ======================== 5 | 6 | MUCM stands for 'Managing Uncertainty in Complex Models.' The MUCM 7 | project is funded by a research grant from Research Councils UK, in 8 | their Basic Technology programme. The objectives of the project are to 9 | develop methods for analysing and managing the uncertainty in the 10 | outputs produced by :ref:`simulators` of physical 11 | systems, and as far as possible to show how these methods can be used 12 | practically and simply in a wide variety of application areas. 13 | 14 | More information about MUCM can be found on the `MUCM website 15 | `_. 16 | -------------------------------------------------------------------------------- /docs/methods/def/DefModelBasedDesign.rst: -------------------------------------------------------------------------------- 1 | .. _DefModelBasedDesign: 2 | 3 | Definition of Term: Model Based Design 4 | ====================================== 5 | 6 | Several toolkit operations call for a set of points to be specified in 7 | the :ref:`simulator’s` space of inputs, and the choice 8 | of such a set is called a design. For instance, to create an 9 | :ref:`emulator` of the simulator we need a set of 10 | points, the :ref:`training sample`, at which the 11 | simulator is to be run to provide data in order to build the emulator. 12 | The question can then be posed, what constitutes a good, or an optimal, 13 | design? We cannot answer without having some idea of what the results 14 | might be of different choices of design, and in general the results are 15 | not known at the time of creating the design – for instance, when 16 | choosing a training sample we do not know what the simulator outputs 17 | will be at the design points, and so do not know how good the resulting 18 | emulator will be. General-purpose designs rely on qualitative generic 19 | features of the problem and aim to be good for a wide variety of 20 | situations. 21 | 22 | In general we should only pick an optimal design, however, if we can 23 | specify (a) an optimality criterion (see the alternatives page 24 | :ref:`AltOptimalCriteria` for some commonly used 25 | criteria) and (b) a model for the results (e.g. simulator outputs) that 26 | we expect to observe from any design. If one has a reliable model for a 27 | prospective emulator, perhaps derived from knowledge of the physical 28 | process being modelled by the simulator, then an optimal design may give 29 | a more focused experiment. For these reasons we may use the terms 30 | "model-based design" which is short for "model based optimal design" . 31 | 32 | For optimal design the choice of design points becomes an optimisation 33 | problem; e.g. minimise, over the choice of the design, some special 34 | criterion. Since the objective is very often to produce an emulator that 35 | is as accurate as possible, the optimality criteria are typically 36 | phrased in terms of posterior variances (in the case of a fully 37 | :ref:`Bayesian` emulator, or adjusted variances in the 38 | case of a :ref:`Bayes linear` emulator). 39 | 40 | There are related areas where choice of sites at which to observe or 41 | evaluate a function are important. Optimisation is itself such an area 42 | and one can also mention search problems involving "queries" in computer 43 | science, numerical integration and approximation theory. 44 | -------------------------------------------------------------------------------- /docs/methods/def/DefModelDiscrepancy.rst: -------------------------------------------------------------------------------- 1 | .. _DefModelDiscrepancy: 2 | 3 | Definition of Term: Model Discrepancy 4 | ===================================== 5 | 6 | No matter how careful a particular model of a real system has been 7 | formulated, there will always be a difference between reality, 8 | represented by the system value :math:`y`, and the 9 | :ref:`simulator` output :math:`f(x)` for any valid input 10 | :math:`x`. The difference :math:`d=y-f(x^+)`, where :math:`\strut{x}^+` 11 | is the :ref:`best input`, is referred to as the model 12 | discrepancy, which should be incorporated into our analysis in order to 13 | make valid statements about the real system. In particular, model 14 | discrepancy is vital for procedures such as 15 | :ref:`calibration`, history matching and prediction 16 | for the real system. 17 | -------------------------------------------------------------------------------- /docs/methods/def/DefMultilevelEmulation.rst: -------------------------------------------------------------------------------- 1 | .. _DefMultilevelEmulation: 2 | 3 | Definition of Term: Multilevel Emulation 4 | ======================================== 5 | 6 | Multilevel emulation (or *multiscale emulation*) is the application of 7 | :ref:`emulation` methodology to problems where we have 8 | two or more versions of the same :ref:`simulator` that 9 | produce outputs at different levels of accuracy or resolution. 10 | Typically, the lower-accuracy simulators are less expensive to evaluate 11 | than the high accuracy models. Multilevel emulation seeks to supplement 12 | the restricted amount of information on the most-accurate model, with 13 | information gained from larger numbers of evaluations of lower-accuracy 14 | simulators to improve the performance of the final emulator. 15 | -------------------------------------------------------------------------------- /docs/methods/def/DefNugget.rst: -------------------------------------------------------------------------------- 1 | .. _DefNugget: 2 | 3 | Definition of Term: Nugget 4 | ========================== 5 | 6 | A covariance function :math:`v(x,x^\prime)` expresses the covariance 7 | between the outputs of a :ref:`simulator` at input 8 | configurations :math:`x` and :math:`x^\prime`. When :math:`x=x^\prime`, 9 | :math:`v(x,x)` is the variance of the output at input :math:`x`. A nugget is 10 | an additional component of variance when :math:`x=x^\prime`. Technically 11 | this results in the covariance function being a discontinuous function 12 | of its arguments, because :math:`v(x,x)` does not equal the limit as 13 | :math:`x^\prime` tends to :math:`x` of :math:`v(x,x^\prime)`. 14 | 15 | A nugget may be introduced in a variance function in 16 | :ref:`MUCM` methods for various reasons. For instance, it 17 | may represent random noise in a :ref:`stochastic` 18 | simulator, or the effects of :ref:`inactive inputs` 19 | that are not included explicitly in the :ref:`emulator`. 20 | A small nugget term may also be added for computational reasons when 21 | working with a :ref:`deterministic` simulator. 22 | -------------------------------------------------------------------------------- /docs/methods/def/DefPrincipalComponentAnalysis.rst: -------------------------------------------------------------------------------- 1 | .. _DefPrincipalComponentAnalysis: 2 | 3 | Definition of Term: Principal Component Analysis 4 | ================================================ 5 | 6 | Principal Component Analysis (PCA) is a technique used in multivariate 7 | data analysis for dimension reduction. Given a sample of vector random 8 | variables, the aim is to find a set of orthogonal coordinate axes, known 9 | as principal components, with a small number of principal components 10 | describing most of the variation in the data. Projecting the data onto 11 | the first principal component maximises the variance of the projected 12 | points, compared to all other linear projections. Projecting the data 13 | onto the second principal component maximises the variance of the 14 | projected points, compared to all other linear projections that are 15 | orthogonal to the first principal component. Subsequent principal 16 | components are defined likewise. 17 | 18 | The principal components are obtained using an eigendecomposition of the 19 | variance matrix of the data. The eigenvectors give the principal 20 | components, and the eigenvalues divided by their sum give the proportion 21 | of variation in the data explained by each associated eigenvector (hence 22 | the eigenvector with the largest eigenvalue is the first principal 23 | component and so on). 24 | 25 | If a :ref:`simulator` output is multivariate, for 26 | example a time series, PCA can be used to reduce the dimension of the 27 | output before constructing an :ref:`emulator`. 28 | -------------------------------------------------------------------------------- /docs/methods/def/DefProper.rst: -------------------------------------------------------------------------------- 1 | .. _DefProper: 2 | 3 | Definition of Term: Proper (or improper) distribution 4 | ===================================================== 5 | 6 | A proper distribution is one that integrates (in the case of a 7 | probability density function for a continuous random variable) or sums 8 | (in the case of a probability mass function for a discrete random 9 | variable) to unity. According to probability theory, all probability 10 | distributions must have this property. 11 | 12 | The concept is relevant in the context of so-called 13 | :ref:`weak` prior distributions which are claimed to 14 | represent (or approximate) a state of ignorance. Such distributions are 15 | often improper in the following sense. 16 | 17 | Consider a random variable that can take any positive value. One weak 18 | prior distribution for such a random variable is the uniform 19 | distribution that assigns equal density to all positive values. Such a 20 | density function would be given by 21 | 22 | .. math:: 23 | \pi(x) = k 24 | 25 | for some positive constant :math:`k` and for all positive values :math:`x` of 26 | the random variable. However, there is no value of :math:`k` for which this 27 | is a proper distribution. If :math:`k` is not zero, then the density 28 | function integrates to infinity, while if :math:`k=0` it integrates to 29 | zero. For no value of :math:`k` does it integrate to one. So such a uniform 30 | distribution simply does not exist. 31 | 32 | Nevertheless, analysis can often proceed as if this distribution were 33 | genuinely proper for some :math:`k`. That is, by using it as a prior 34 | distribution and combining it with the evidence in the data using Bayes' 35 | theorem, we will usually obtain a posterior distribution that is proper. 36 | The fact that the prior distribution is improper is then unimportant; we 37 | regard the resulting posterior distribution as a good approximation to 38 | the posterior distribution that we would have obtained from any prior 39 | distribution that was actually proper but represented very great prior 40 | uncertainty. This use of weak prior distributions is discussed in the 41 | definition of the weak prior distribution 42 | (:ref:`DefWeakPrior`), and is legitimate provided that 43 | the supposed approximation really applies. One situation in which it 44 | would not is when the improper prior leads to an improper posterior. 45 | 46 | Formally, we write the uniform prior as 47 | 48 | .. math:: 49 | \pi(x) \propto 1\,, 50 | 51 | using the proportionality symbol to indicate the presence of an 52 | unspecified scaling constant :math:`k` (despite the fact that no such 53 | constant can exist). Other improper distributions are specified in like 54 | fashion as being proportional to some function, implying a scaling 55 | constant which nevertheless cannot exist. An example is another commonly 56 | used weak prior distribution for a positive random variable, 57 | 58 | .. math:: 59 | \pi(x) \propto x^{-1}\,, 60 | 61 | known as the log-uniform prior. 62 | -------------------------------------------------------------------------------- /docs/methods/def/DefRegularity.rst: -------------------------------------------------------------------------------- 1 | .. _DefRegularity: 2 | 3 | Definition of Term: Regularity 4 | ============================== 5 | 6 | The output of a :ref:`simulator` is regarded as a 7 | function of its inputs. One consideration in building an 8 | :ref:`emulator` for the simulator is whether the output 9 | is expected to be a continuous function of its inputs, and if so whether 10 | it is differentiable. Within the :ref:`MUCM` toolkit, we 11 | refer to the continuity and differentiability properties of a simulator 12 | as regularity. 13 | 14 | The minimal level of regularity would be a simulator whose output is 15 | everywhere a continuous function of the inputs, but is not always 16 | differentiable. A function which is differentiable everywhere has 17 | greater degree of regularity the more times it is differentiable. The 18 | most regular of functions are those that are differentiable infinitely 19 | many times. 20 | -------------------------------------------------------------------------------- /docs/methods/def/DefReification.rst: -------------------------------------------------------------------------------- 1 | .. _DefReification: 2 | 3 | Definition of Term: Reification 4 | =============================== 5 | 6 | Perhaps the simplest technique for linking a model to reality is given 7 | by the :ref:`Best Input` approach. Although very useful 8 | and suitable for many applications, often a more detailed approach is 9 | required. 10 | 11 | A more careful treatment of the link between model and reality, is given 12 | by a technique known as Reification. This involves linking the current 13 | model :math:`f` to a Reified model :math:`f^+` which would 14 | contain all known improvements to the current model. This is often done 15 | via an intermediate model :math:`f'` that represents specific 16 | improvements to the current model. The Reified model is subsequently 17 | linked to reality. 18 | 19 | Emulators are often used to describe each model in this process, as they 20 | provide useful representations of the relevant uncertainties involved. 21 | -------------------------------------------------------------------------------- /docs/methods/def/DefScreening.rst: -------------------------------------------------------------------------------- 1 | .. _DefScreening: 2 | 3 | Definition of Term: Screening 4 | ============================= 5 | 6 | Screening is the process of identifying the :ref:`active 7 | inputs` that drive a simulator's behaviour, so 8 | that only these inputs need to be considered when building and using the 9 | emulator. It is common to find that only a small number of inputs to the 10 | simulator are relevant to the prediction of the output of interest. 11 | -------------------------------------------------------------------------------- /docs/methods/def/DefSecondOrderExch.rst: -------------------------------------------------------------------------------- 1 | .. _DefSecondOrderExch: 2 | 3 | Definition of Term: Second-order Exchangeability 4 | ================================================ 5 | 6 | A sequence of random variables is described as 7 | :ref:`exchangeable` when our beliefs (in terms of 8 | a joint probability distribution) about that collection are unaffected 9 | by the order in which they appear. 10 | 11 | A less-restrictive specification is that of second-order 12 | exchangeability. A sequence of random vectors is described as 13 | second-order exchangeable if our beliefs in terms of the mean, variance 14 | and covariance for that collection are unaffected by the permutation of 15 | the order of the vectors. In other words, this requires that every 16 | random vector has the same expectation and variance, and every pair of 17 | vectors have the same covariance. 18 | 19 | Second-order exchangeability is a concept that is expressed in terms of 20 | expectations and variances rather than full probability distributions. 21 | It is therefore often exploited in :ref:`Bayes 22 | linear` analyses. 23 | -------------------------------------------------------------------------------- /docs/methods/def/DefSecondOrderSpec.rst: -------------------------------------------------------------------------------- 1 | .. _DefSecondOrderSpec: 2 | 3 | Definition of Term: Second-order belief specification 4 | ===================================================== 5 | 6 | A belief specification for a collection of uncertain quantities is 7 | described as *second order* when the beliefs are expressed solely in 8 | terms of expectations and variances for every uncertain quantity, and 9 | covariances between every pair of quantities. This differs from a fully 10 | probabilistic specification which requires a joint probability 11 | distribution over all unknown quantities. The second-order specification 12 | is the basis for :ref:`Bayes Linear` methods. 13 | -------------------------------------------------------------------------------- /docs/methods/def/DefSeparable.rst: -------------------------------------------------------------------------------- 1 | .. _DefSeparable: 2 | 3 | Definition of Term: Separable 4 | ============================= 5 | 6 | An :ref:`emulator`'s correlation function specifies the 7 | correlation between the outputs of a :ref:`simulator` 8 | at two different points in its input space. The input space is almost 9 | always multi-dimensional, since the simulator will typically have more 10 | than one input. Suppose that there are :math:`p` inputs, so that a point in 11 | the input space is a vector :math:`x` of :math:`p` elements 12 | :math:`x_1,x_2,\ldots,x_p`. Then a correlation function :math:`c(x,x^\prime)` 13 | specifies the correlation between simulator outputs at input vectors 14 | :math:`x` and :math:`x^\prime`. The inputs are said to be separable if the 15 | correlation function has the form of a product of one-dimensional 16 | correlation functions: 17 | 18 | .. math:: 19 | c(x,x^\prime) = \prod_{i=1}^p c_i(x_i,x_i^\prime). 20 | 21 | Specifying the correlation between points that differ in more than one 22 | input dimension is potentially a very complex task, particularly because 23 | of the constraints involved in creating a valid correlation function. 24 | Separability is a property that greatly simplifies this task. 25 | 26 | Separability is also used in the context of emulators with multiple 27 | outputs. In this case the term 'separable' is typically used to denote 28 | separability between the outputs and the inputs, i.e. that all the 29 | outputs have the same correlation function :math:`c(x,x')` (which is often 30 | itself separable as defined above). The general covariance then takes 31 | the form: 32 | 33 | .. math:: 34 | \text{Cov}[f_u(x), f_{u'}(x')] = \sigma_{uu'}c(x,x') 35 | 36 | where :math:`u` and :math:`u'` denote two different outputs and 37 | :math:`\sigma_{uu'}` is a covariance between these two outputs. 38 | -------------------------------------------------------------------------------- /docs/methods/def/DefSimulator.rst: -------------------------------------------------------------------------------- 1 | .. _DefSimulator: 2 | 3 | Definition of Term: Simulator 4 | ============================= 5 | 6 | A simulator is a representation of some real-world system, usually 7 | implemented as a computer program. Given appropriate inputs, the outputs 8 | of the simulator are intended to represent specific properties of the 9 | real system. 10 | 11 | *Example*: A simulator of a nuclear power station reactor would take as 12 | inputs a whole range of quantities describing the detailed design of the 13 | reactor and the fuel. Its outputs might include values of heat energy 14 | produced by the reactor (perhaps a sustained output level or a time 15 | series). 16 | 17 | The essence of the :ref:`MUCM` toolkit is to describe ways 18 | to analyse simulator outputs using the techniques of first building an 19 | :ref:`emulator`. 20 | -------------------------------------------------------------------------------- /docs/methods/def/DefSingleStepFunction.rst: -------------------------------------------------------------------------------- 1 | .. _DefSingleStepFunction: 2 | 3 | Definition of Term: Single step function 4 | ======================================== 5 | 6 | We consider :ref:`dynamic simulators` of the form that 7 | model the evolution of a :ref:`state vector` by 8 | iteratively applying a **single step function**. For example, suppose 9 | the dynamic simulator takes as inputs an initial state vector :math:`w_0`, 10 | a time series of :ref:`forcing inputs` 11 | :math:`a_1,\ldots,a_T`, and some constant parameters :math:`\phi`, to produce 12 | a time series output :math:`w_1,\ldots,w_T`. If the evolution of the time 13 | series :math:`w_1,\ldots,w_T` is defined by the equation 14 | :math:`w_t=f(w_{t-1},a_t,\phi)`, then :math:`f(.)` is known as the single 15 | step function. 16 | -------------------------------------------------------------------------------- /docs/methods/def/DefSmoothingKernel.rst: -------------------------------------------------------------------------------- 1 | .. _DefSmoothingKernel: 2 | 3 | Definition of term: Smoothing kernel 4 | ==================================== 5 | 6 | A smoothing kernel is a non-negative real-valued integrable function 7 | :math:`\kappa()` satisfying the following two requirements: 8 | 9 | #. :math:`\int_{-\infty}^{+\infty}\kappa(u)\,du` is finite 10 | 11 | #. :math:`\kappa(-u) = \kappa(u)` for all values of :math:`u` 12 | 13 | In other words, any scalar multiple of a symmetric probability density 14 | function constitutes a smoothing kernel. 15 | 16 | Smoothing kernels are used in constructing multivariate covariance 17 | functions (as discussed in 18 | :ref:`AltMultivariateCovarianceStructures`), 19 | in which case they depend on some hyperparameters. An example of a 20 | smoothing kernel in this context is 21 | 22 | .. math:: 23 | \kappa(x)=\exp\{-0.5 \sum_{i=1}^p (x_i/\delta_i)^2 \} \, , 24 | 25 | where :math:`p` is the length of the vector :math:`x`. In this case the 26 | hyperparameters are :math:`\delta=(\delta_1,...,\delta_p)`. 27 | -------------------------------------------------------------------------------- /docs/methods/def/DefSmoothness.rst: -------------------------------------------------------------------------------- 1 | .. _DefSmoothness: 2 | 3 | Definition of Term: Smoothness 4 | ============================== 5 | 6 | The output of a :ref:`simulator` is regarded as a 7 | function of its inputs. One consideration in building an 8 | :ref:`emulator` for the simulator is whether the output 9 | is expected to be a smooth function of the inputs. 10 | 11 | Smoothness might be measured formally in a variety of ways. For 12 | instance, we might refer to the expected number of times that the output 13 | crosses zero in a given range, or the expected number of local maxima or 14 | minima it will have in that range (which for a differentiable output 15 | corresponds to the number of times its derivative crosses zero). In the 16 | toolkit we do not adopt any specific measure of smoothness, but the 17 | concept is an important one. 18 | -------------------------------------------------------------------------------- /docs/methods/def/DefSpaceFillingDesign.rst: -------------------------------------------------------------------------------- 1 | .. _DefSpaceFillingDesign: 2 | 3 | Definition of Term: Space filling design 4 | ======================================== 5 | 6 | Several toolkit operations call for a set of points to be specified in 7 | the :ref:`simulator` space of inputs, and the choice of 8 | such a set is called a design. Space-filling designs are a class of a 9 | simple general purpose designs giving sets of points, or :ref:`training 10 | samples` at which the simulator is run to 11 | provide data to build the emulator. They spread points in an 12 | approximately uniform way over the design space. They could be any 13 | design of the following types. 14 | 15 | - a design based on restricted sampling methods. 16 | - a design based on measures of distance between points. 17 | - a design known to have low "discrepancy" interpreted as a formal 18 | measure of the closeness to uniformity. 19 | - a design that is a hybrid of, or variation on, these designs. 20 | -------------------------------------------------------------------------------- /docs/methods/def/DefStateVector.rst: -------------------------------------------------------------------------------- 1 | .. _DefStateVector: 2 | 3 | Definition of Term: State Vector 4 | ================================ 5 | 6 | The state vector of a :ref:`dynamic` 7 | :ref:`simulator` comprises a description of the state 8 | of the real-world process being modelled by the simulator at any given 9 | time point. 10 | 11 | *Example:* A simple simulator of the passage of a drug through a 12 | person's body will represent the body as a set of compartments, and its 13 | state vector will specify the quantity of the drug in each compartment 14 | at a given time point. 15 | -------------------------------------------------------------------------------- /docs/methods/def/DefStochastic.rst: -------------------------------------------------------------------------------- 1 | .. _DefStochastic: 2 | 3 | Definition of Term: Stochastic 4 | ============================== 5 | 6 | A :ref:`simulator` is referred to as stochastic if 7 | running it more than once with a given input configuration will produce 8 | randomly different output(s). 9 | 10 | *Example*: A simulator of a hospital admissions system has as inputs a 11 | description of the system in terms of number of beds, average time spent 12 | in a bed, demand for beds, etc. Its primary output is the number of days 13 | in a month in which the hospital is full (all beds occupied). The 14 | simulator generates random numbers of patients requiring admission each 15 | day, and random lengths of stay for each patient. As a result, the 16 | output is random. Running the simulator again with the same inputs 17 | (number of beds, etc) will produce different random numbers of patients 18 | needing admission and different random lengths of stay, and so the 19 | output will also be random. 20 | -------------------------------------------------------------------------------- /docs/methods/def/DefTProcess.rst: -------------------------------------------------------------------------------- 1 | .. _DefTProcess: 2 | 3 | Definition of Term: T-process 4 | ============================= 5 | 6 | A t-process is a probability model for an unknown function. 7 | 8 | If a function f has argument :math:`x`, then the value of the function at 9 | that argument is :math:`f(x)`. A probability model for such a function must 10 | provide a probability distribution for :math:`f(x)`, for any possible 11 | argument value :math:`x`. Furthermore, if we consider a set of possible 12 | values for the argument, which we can denote by :math:`x_1, x_2, ..., x_n`, 13 | then the probability model must provide a joint probability distribution 14 | for the corresponding function values :math:`f(x_1), f(x_2), ..., f(x_n)`. 15 | 16 | In :ref:`MUCM` methods, an :ref:`emulator` 17 | is (at least in the fully Bayesian approach) a probability model for the 18 | corresponding :ref:`simulator`. The simulator is 19 | regarded as a function, with the simulator inputs comprising the 20 | function's argument and the simulator output(s) comprising the function 21 | value. 22 | 23 | A t-process is a particular probability model in which the distribution 24 | for a single function value is a t distribution (also often called a 25 | Student-t distribution), and the joint distribution of a set of function 26 | values is multivariate t. The t-process is related to the :ref:`Gaussian 27 | process` (GP) in the same way that a univariate or 28 | multivariate t distribution is related to a univariate or multivariate 29 | normal (or Gaussian) distribution. That is, we can think of a t-process 30 | as a GP with an uncertain (or random) scaling parameter in its 31 | covariance function. Normal and t distributions play a central role in 32 | statistical practice by virtue of their mathematical simplicity, and for 33 | similar reasons the GP and t-process play a central role in (fully 34 | :ref:`Bayesian`) MUCM methods. 35 | 36 | A t-process is identified by its mean function, its covariance function 37 | and a degrees of freedom. If the degrees of freedom is sufficiently 38 | large, which will in practice always be the case in MUCM applications, 39 | the mean function is :math:`\text{E}[f(x)]`, regarded as a function of 40 | :math:`x`, and the covariance function is :math:`\text{Cov}[f(x_1), f(x_2)]`, 41 | regarded as a function of both :math:`x_1` and :math:`x_2`. Note in particular 42 | that the variance of :math:`f(x)` is the value of the covariance function 43 | when both :math:`x_1` and :math:`x_2` are equal to :math:`x`. 44 | -------------------------------------------------------------------------------- /docs/methods/def/DefTrainingSample.rst: -------------------------------------------------------------------------------- 1 | .. _DefTrainingSample: 2 | 3 | Definition of Term: Training sample 4 | =================================== 5 | 6 | In order to build an :ref:`emulator` for a 7 | :ref:`simulator`, we need data comprising the value of 8 | the simulator output (or outputs) at each of a set of points in the 9 | space of the simulator inputs. Each point in the set is specified as a 10 | configuration of input values. 11 | -------------------------------------------------------------------------------- /docs/methods/def/DefUncertaintyAnalysis.rst: -------------------------------------------------------------------------------- 1 | .. _DefUncertaintyAnalysis: 2 | 3 | Definition of Term: Uncertainty analysis 4 | ======================================== 5 | 6 | One of the most common tasks for users of 7 | :ref:`simulators` is to assess the uncertainty in the 8 | simulator output(s) that is induced by their uncertainty about the 9 | inputs. Input uncertainty is a feature of most applications, since 10 | simulators typically require very many input values to be specified and 11 | the user will be unsure of what should be the best or correct values for 12 | some or all of these. 13 | 14 | Uncertainty regarding inputs is characterised by a (joint) probability 15 | distribution for their values. This distribution induces a (joint) 16 | probability distribution for the output, and uncertainty analysis 17 | involves identifying that distribution. Specific tasks might be to 18 | compute the mean and variance of the output uncertainty distribution. 19 | The mean can be considered as a best estimate for the output in the face 20 | of input uncertainty, while the variance measures the amount of output 21 | uncertainty. In some applications, it is important to evaluate the 22 | probability that the output would lie above or below some threshhold. 23 | 24 | A simple way to compute these things in practice is the Monte Carlo 25 | method, whereby random configurations of inputs are drawn from their 26 | input uncertainty distribution, the model is run for each such 27 | configuration, and the set of outputs obtained comprises a random sample 28 | from the output distribution. If a sufficiently large sample can be 29 | taken, then this allows the uncertainty distribution, mean, variance, 30 | probabilities etc., to be evaluated to any desired accuracy. However, 31 | this is often impractical because the simulator takes too long to run. 32 | Monte Carlo methods will typically require 1,000 to 10,000 runs to 33 | achieve accurate estimates of the uncertainty measures, and if a single 34 | simulator run takes more than a few seconds the computing time can 35 | become prohibitive. 36 | 37 | The :ref:`MUCM` approach of first building an 38 | :ref:`emulator` has been developed to enable tasks such 39 | as uncertainty analysis to be carried out more efficiently. 40 | 41 | Another group of tools that are commonly required are known as 42 | :ref:`sensitivity analysis`. In particular, 43 | the :ref:`variance-based` form of sensitivity 44 | analysis identifies what proportion of the variance of the uncertainty 45 | distribution is attributable to uncertainty in individual inputs, or 46 | groups of inputs. 47 | -------------------------------------------------------------------------------- /docs/methods/def/DefValidation.rst: -------------------------------------------------------------------------------- 1 | .. _DefValidation: 2 | 3 | Definition of Term: Validation 4 | ============================== 5 | 6 | An :ref:`emulator` for a 7 | :ref:`simulator` is a statistical representation of our 8 | knowledge about the simulator. In particular, it enables us to predict 9 | what outputs the simulator would produce at any given configurations of 10 | input values. The process of validation consists of checking whether the 11 | actual simulator outputs at those input configurations are consistent 12 | with the statistical predictions made by the emulator. 13 | 14 | In conjunction with a comparable statistical specification of knowledge 15 | about how the simulator relates to the real-world process that it is 16 | intended to represent, we can use an emulator to make statistical 17 | predictions of the real-world process. These can then also be validated 18 | by comparison with the corresponding real-world values. 19 | 20 | The validation of a Gaussian process emulator is described in the 21 | procedure for validating a Gaussian process emulator 22 | (:ref:`ProcValidateCoreGP`). 23 | -------------------------------------------------------------------------------- /docs/methods/def/DefWeakPrior.rst: -------------------------------------------------------------------------------- 1 | .. _DefWeakPrior: 2 | 3 | Definition of Term: Weak prior distribution 4 | =========================================== 5 | 6 | In :ref:`Bayesian` statistics, prior knowledge about a 7 | parameter is specified in the form of a probability distribution called 8 | its prior distribution (or simply its prior). The use of prior 9 | information is a feature of Bayesian statistics, and one which is 10 | contentious in the field of statistical inference. Most opponents of the 11 | Bayesian approach disagree with the use of prior information. In this 12 | context, there has been considerable study of the notion of a prior 13 | distribution that represents prior ignorance, or at least a state of 14 | very weak prior information, since by using such a prior it may be 15 | possible to evade this particular criticism of the Bayesian approach. In 16 | this toolkit, we will call such prior distributions "weak priors," 17 | although they may be found answering to many other names in the 18 | literature (such as reference priors, noninformative priors, default 19 | priors or objective priors). 20 | 21 | The use of weak priors has itself been criticised on various grounds. 22 | Strict adherents of the Bayesian view argue that genuine prior 23 | information invariably exists (i.e. a state of prior ignorance is 24 | unrealistic) and that to deny prior information is wasteful. On more 25 | pragmatic grounds, it is clear that despite all the research into weak 26 | priors there is nothing like a consensus on what is *the* weak prior to 27 | use in any situation, and there are numerous competing theories leading 28 | to alternative weak prior formulations. On theoretical grounds, others 29 | point to logical inconsistencies in any systematic use of weak priors. 30 | 31 | In the :ref:`MUCM` toolkit, we adopt a Bayesian approach (or 32 | a variant known as the :ref:`Bayes Linear` approach) 33 | and so take the view that prior information should be used. Nevertheless 34 | we see a pragmatic value in weak priors. When prior information is 35 | genuinely weak relative to the information that may be gained from the 36 | data in a statistical analysis, it can be shown that the precise choice 37 | of prior distribution has little effect on the statistical results 38 | (inferences). Then the use of a weak prior can be justified as being an 39 | adequate replacement for spending unnecessary effort on specifying the 40 | prior. (And in this context, the existence of alternative weak prior 41 | formulations is not a problem because it should not matter which we 42 | use.) 43 | 44 | Note that conventional weak priors are often 45 | :ref:`improper`. 46 | -------------------------------------------------------------------------------- /docs/methods/disc/DiscExchangeableModels.rst: -------------------------------------------------------------------------------- 1 | .. _DiscExchangeableModels: 2 | 3 | Discussion: Exchangeable Computer Models 4 | ======================================== 5 | 6 | This page is under construction. 7 | -------------------------------------------------------------------------------- /docs/methods/disc/DiscRealisationDesign.rst: -------------------------------------------------------------------------------- 1 | .. _DiscRealisationDesign: 2 | 3 | Discussion: Design for generating emulator realisations 4 | ======================================================= 5 | 6 | Description and Background 7 | -------------------------- 8 | 9 | The procedure page for simulating realisations of an emulator 10 | (:ref:`ProcSimulationBasedInference`) 11 | presents a method for drawing random realisations of an 12 | :ref:`emulator`. In order to do this it is necessary to 13 | sample values of the emulator's predictive distributions for a finite 14 | set of input points 15 | :math:`x^\prime_1,x^\prime_2,\ldots,x^\prime_{n^\prime}`. We discuss here 16 | the choice of these points, the realisation design. 17 | 18 | Discussion 19 | ---------- 20 | 21 | The underlying principle is that if we rebuild the emulator, augmenting 22 | the original training data with the sampled values at the realisation 23 | design points, then the resulting emulator would be sufficiently 24 | accurate that it would have negligible uncertainty in its predictions. 25 | To create a suitable realisation design, we need to decide how many 26 | points it should have, and where in the input space those points should 27 | be. 28 | 29 | If we consider the second decision first, suppose we have decided on 30 | :math:`n^\prime`. Then it is clear that the combined design of :math:`n` 31 | original training design points and the :math:`n^\prime` realisation design 32 | points must be a good design, since good design involves getting an 33 | accurate emulator - see the alternatives page on training sample design 34 | for the core problem (:ref:`AltCoreDesign`). For 35 | instance, we might choose this design by generating random Latin 36 | hypercubes (LHCs) of :math:`n^\prime` points and then choosing the 37 | composite design (original training design plus LHC) to satisfy the 38 | maximin criterion - see the procedure for generating an optimised Latin 39 | hypercube design (:ref:`ProcOptimalLHC`). 40 | 41 | To determine a suitable value for :math:`n^\prime` will typically involve a 42 | degree of trial and error. If we generate a design with a certain 43 | :math:`n^\prime` and the predictive variances are not all small, then we 44 | need a larger sample! 45 | 46 | Additional Comments 47 | ------------------- 48 | 49 | This topic is under investigation in MUCM, and fuller advice may be 50 | available in due course. 51 | -------------------------------------------------------------------------------- /docs/methods/disc/DiscReification/ReifNetwork1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alan-turing-institute/mogp-emulator/72dc73a49dbab621ef5748546127da990fd81e4a/docs/methods/disc/DiscReification/ReifNetwork1.png -------------------------------------------------------------------------------- /docs/methods/disc/DiscReificationTheory/ReifNetwork2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alan-turing-institute/mogp-emulator/72dc73a49dbab621ef5748546127da990fd81e4a/docs/methods/disc/DiscReificationTheory/ReifNetwork2.png -------------------------------------------------------------------------------- /docs/methods/disc/DiscReificationTheory/ReifNetwork3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alan-turing-institute/mogp-emulator/72dc73a49dbab621ef5748546127da990fd81e4a/docs/methods/disc/DiscReificationTheory/ReifNetwork3.png -------------------------------------------------------------------------------- /docs/methods/disc/DiscSobol.rst: -------------------------------------------------------------------------------- 1 | .. _DiscSobol: 2 | 3 | Discussion: Sobol sequence 4 | =========================== 5 | 6 | Description and background 7 | -------------------------- 8 | 9 | A Sobol sequence is a sequence of points in a design space which has 10 | the general property of being :ref:`space 11 | filling`. The procedure page 12 | :ref:`ProcSobolSequence` provides a detailed 13 | algorithm for constructing Sobol sequences based on Sobol's original 14 | description, and a worked example. Sobol's construction is based on 15 | bit-wise XOR operations between special generators called direction 16 | numbers. The first impression is that the construction of a Sobol 17 | sequence is a complex task. However, by constructiong a few Sobol 18 | numbers by hand, using the procedure in 19 | :ref:`ProcSobolSequence`, it is easy to understand 20 | the underlying structure. 21 | 22 | Discussion 23 | ---------- 24 | 25 | For users of the R programming language, we suggest the function 26 | ``runif.sobol(n,d)`` from the package fOptions in the `R 27 | repository `_. 28 | 29 | A well known concern about Sobol sequences is the correlation between 30 | points in high dimensional sequences. A solution to this is by 31 | scrambling the sequence. The R package above described allows for the 32 | sequence to be scrambled, if desired. In this case, either of the two 33 | functions described above can be called with the arguments :: 34 | 35 | (n,d,scrambling,seed,init) 36 | 37 | The argument scrambling takes an integer which is 0 if no scrambling is 38 | to be used, 1 for Owen type of scrambling, 2 for Faure-Tezuka scrambling 39 | and 3 for a combination of both. The argument seed is the integer seed 40 | to trigger the scrambling process and init is a logical flag which 41 | allows the Sobol sequence to restart if set to ``TRUE``. 42 | -------------------------------------------------------------------------------- /docs/methods/disc/DiscUANugget.rst: -------------------------------------------------------------------------------- 1 | .. _DiscUANugget: 2 | 3 | Discussion: Nugget effects in uncertainty and sensitivity analyses 4 | ================================================================== 5 | 6 | Description and Background 7 | -------------------------- 8 | 9 | The possibility of including a :ref:`nugget` term in the 10 | correlation function for a :ref:`Gaussian process` 11 | :ref:`emulator` is discussed in the alternatives page on 12 | emulator prior correlation function 13 | (:ref:`AltCorrelationFunction`). In the 14 | procedure pages for uncertainty analysis (:ref:`ProcUAGP`) 15 | and variance based sensitivity analysis 16 | (:ref:`ProcVarSAGP`) using a GP emulator, concerned 17 | respectively with :ref:`uncertainty analysis` 18 | and :ref:`variance based` :ref:`sensitivity 19 | analysis` for the :ref:`core 20 | problem`, closed form expresssions are given for 21 | various integrals for some cases where a nugget term may be included. 22 | This page provides a technical discussion of the reason for some 23 | apparent anomalies in those formulae. 24 | 25 | Discussion 26 | ---------- 27 | 28 | The closed form expressions are derived for the generalised Gaussian 29 | correlation function with nugget (see 30 | :ref:`AltCorrelationFunction`) 31 | 32 | .. math:: 33 | c(x,x') = \nu I_{x=x'} + (1-\nu)\exp\{-(x-x')^T C (x-x')\} 34 | 35 | where :math:`I_{x=x'}` equals 1 if :math:`x=x'` but is otherwise zero, and 36 | :math:`\nu` represents the nugget term. They also assume a normal 37 | distribution for the uncertain inputs. 38 | 39 | In both :ref:`ProcUAGP` and 40 | :ref:`ProcVarSAGP` a number of integrals are computed 41 | depending on :math:`c(x,x')`, and we might expect the resulting integrals 42 | in each case to have two parts, one multiplied by :math:`\nu` and the other 43 | multiplied by :math:`(1-\nu)`. In most cases, however, only the second term 44 | is found. 45 | 46 | The reason for this is the fact that the nugget only arises when the two 47 | arguments of the correlation function are equal. The integrals all 48 | integrate with respect to the distribution of the uncertain inputs 49 | :math:`x`, and since this is a normal distribution it gives zero 50 | probability to :math:`x` equalling any particular value. We therefore find 51 | that in almost all of these integrals the nugget only appears in the 52 | integrand for a set of probability zero, and so it does not appear in 53 | the result of evaluating that integral. The sole exception is the 54 | integral denoted by :math:`U_p`, where the nugget does appear leading to a 55 | result :math:`U_p=\nu+(1-\nu)=1`. 56 | 57 | The heuristic explanation for this is that a nugget term is a white 58 | noise addition to the smooth simulator output induced by the generalised 59 | Gaussian correlation term. If we average white noise over even a short 60 | interval the result is necessarily zero because in effect we are 61 | averaging an infinite number of independent terms. 62 | 63 | The practical implication is that the nugget reduces the amount that we 64 | learn from the training data, and also reduces the amount that we could 65 | learn in sensitivity analysis calculations by learning the values of a 66 | subset of inputs. 67 | -------------------------------------------------------------------------------- /docs/methods/disc/DiscUncertaintyAnalysis.rst: -------------------------------------------------------------------------------- 1 | .. _DiscUncertaintyAnalysis: 2 | 3 | Discussion: Uncertainty analysis 4 | ================================ 5 | 6 | In uncertainty analysis, we wish to quantify uncertainty about simulator 7 | outputs due to uncertainty about simulator inputs. We define :math:`X` 8 | to be the uncertain true inputs, and :math:`f(X)` to be the 9 | corresponding simulator output(s). In the emulator framework, :math:`f(.)` 10 | is also treated as an uncertain function, and it is important to 11 | consider both uncertainty in :math:`X` and uncertainty in :math:`f(.)` 12 | when investigating uncertainty about :math:`f(X)`. In particular, it is 13 | important to distinguish between the unconditional distribution of 14 | :math:`f(X)`, and the distribution of :math:`f(X)` conditional on :math:`f(.)`. 15 | For example: 16 | 17 | #. :math:`\textrm{E}[f(X)]` is the expected value of :math:`f(X)`, 18 | where the expectation is taken with respect to both :math:`f(.)` and 19 | :math:`X`. The value of this expectation can, in principle, be obtained 20 | for any emulator and input distribution. 21 | #. :math:`\textrm{E}[f(X)|f(.)]` is the expected value of :math:`f(X)`, 22 | where the expectation is taken with respect to :math:`X` only as 23 | :math:`f(.)` is given. If :math:`f(.)` is a computationally cheap function, 24 | we could, for example, obtain the value of this expectation using 25 | Monte Carlo, up to an arbitrary level of precision. However, when 26 | :math:`f(.)` is computationally expensive such that we require an emulator 27 | for :math:`f(.)`, **this expectation is an uncertain quantity**. We are 28 | uncertain about the value of :math:`\textrm{E}[f(X)|f(.)]`, because 29 | we are are uncertain about :math:`f(.)`. 30 | 31 | There is no sense in which :math:`\textrm{E}[f(X)]` can be 'wrong': it 32 | is simply a probability statement resulting from a choice of emulator 33 | (good or bad) and input distribution. But an estimate of 34 | :math:`\textrm{E}[f(X)|f(.)]` obtained using an emulator can be poor if we 35 | have a poor emulator (in the :ref:`validation` sense) 36 | for :math:`f(.)`. Alternatively, we may be very uncertain about 37 | :math:`\textrm{E}[f(X)|f(.)]` if we don't have sufficient training data for 38 | the emulator of :math:`f(.)`. Hence in practice, the distinction is 39 | important for considering *whether we have enough simulator runs for our 40 | analysis of interest*. 41 | -------------------------------------------------------------------------------- /docs/methods/exam/Exam1DHistoryMatch/GradPoints14.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alan-turing-institute/mogp-emulator/72dc73a49dbab621ef5748546127da990fd81e4a/docs/methods/exam/Exam1DHistoryMatch/GradPoints14.pdf -------------------------------------------------------------------------------- /docs/methods/exam/Exam1DHistoryMatch/GradPoints14.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alan-turing-institute/mogp-emulator/72dc73a49dbab621ef5748546127da990fd81e4a/docs/methods/exam/Exam1DHistoryMatch/GradPoints14.png -------------------------------------------------------------------------------- /docs/methods/exam/Exam1DHistoryMatch/GradPoints17.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alan-turing-institute/mogp-emulator/72dc73a49dbab621ef5748546127da990fd81e4a/docs/methods/exam/Exam1DHistoryMatch/GradPoints17.pdf -------------------------------------------------------------------------------- /docs/methods/exam/Exam1DHistoryMatch/GradPoints17.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alan-turing-institute/mogp-emulator/72dc73a49dbab621ef5748546127da990fd81e4a/docs/methods/exam/Exam1DHistoryMatch/GradPoints17.png -------------------------------------------------------------------------------- /docs/methods/exam/ExamCoreGP1Dim/Figure1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alan-turing-institute/mogp-emulator/72dc73a49dbab621ef5748546127da990fd81e4a/docs/methods/exam/ExamCoreGP1Dim/Figure1.png -------------------------------------------------------------------------------- /docs/methods/exam/ExamCoreGP1Dim/Figure2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alan-turing-institute/mogp-emulator/72dc73a49dbab621ef5748546127da990fd81e4a/docs/methods/exam/ExamCoreGP1Dim/Figure2.png -------------------------------------------------------------------------------- /docs/methods/exam/ExamCoreGP1Dim/Figure3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alan-turing-institute/mogp-emulator/72dc73a49dbab621ef5748546127da990fd81e4a/docs/methods/exam/ExamCoreGP1Dim/Figure3.png -------------------------------------------------------------------------------- /docs/methods/exam/ExamCoreGP1Dim/Figure4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alan-turing-institute/mogp-emulator/72dc73a49dbab621ef5748546127da990fd81e4a/docs/methods/exam/ExamCoreGP1Dim/Figure4.png -------------------------------------------------------------------------------- /docs/methods/exam/ExamCoreGP1Dim/Figure5.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alan-turing-institute/mogp-emulator/72dc73a49dbab621ef5748546127da990fd81e4a/docs/methods/exam/ExamCoreGP1Dim/Figure5.png -------------------------------------------------------------------------------- /docs/methods/exam/ExamCoreGP1Dim/Figure6.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alan-turing-institute/mogp-emulator/72dc73a49dbab621ef5748546127da990fd81e4a/docs/methods/exam/ExamCoreGP1Dim/Figure6.png -------------------------------------------------------------------------------- /docs/methods/exam/ExamCoreGP1Dim/Figure7.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alan-turing-institute/mogp-emulator/72dc73a49dbab621ef5748546127da990fd81e4a/docs/methods/exam/ExamCoreGP1Dim/Figure7.png -------------------------------------------------------------------------------- /docs/methods/exam/ExamCoreGP1Dim/Figure8.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alan-turing-institute/mogp-emulator/72dc73a49dbab621ef5748546127da990fd81e4a/docs/methods/exam/ExamCoreGP1Dim/Figure8.png -------------------------------------------------------------------------------- /docs/methods/exam/ExamCoreGP2Dim/Figure1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alan-turing-institute/mogp-emulator/72dc73a49dbab621ef5748546127da990fd81e4a/docs/methods/exam/ExamCoreGP2Dim/Figure1.png -------------------------------------------------------------------------------- /docs/methods/exam/ExamCoreGP2Dim/Figure2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alan-turing-institute/mogp-emulator/72dc73a49dbab621ef5748546127da990fd81e4a/docs/methods/exam/ExamCoreGP2Dim/Figure2.png -------------------------------------------------------------------------------- /docs/methods/exam/ExamCoreGP2Dim/Figure3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alan-turing-institute/mogp-emulator/72dc73a49dbab621ef5748546127da990fd81e4a/docs/methods/exam/ExamCoreGP2Dim/Figure3.png -------------------------------------------------------------------------------- /docs/methods/exam/ExamCoreGP2Dim/Figure4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alan-turing-institute/mogp-emulator/72dc73a49dbab621ef5748546127da990fd81e4a/docs/methods/exam/ExamCoreGP2Dim/Figure4.png -------------------------------------------------------------------------------- /docs/methods/exam/ExamCoreGP2Dim/Figure5.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alan-turing-institute/mogp-emulator/72dc73a49dbab621ef5748546127da990fd81e4a/docs/methods/exam/ExamCoreGP2Dim/Figure5.png -------------------------------------------------------------------------------- /docs/methods/exam/ExamCoreGP2Dim/Figure6.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alan-turing-institute/mogp-emulator/72dc73a49dbab621ef5748546127da990fd81e4a/docs/methods/exam/ExamCoreGP2Dim/Figure6.png -------------------------------------------------------------------------------- /docs/methods/exam/ExamCoreGP2Dim/Figure7.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alan-turing-institute/mogp-emulator/72dc73a49dbab621ef5748546127da990fd81e4a/docs/methods/exam/ExamCoreGP2Dim/Figure7.png -------------------------------------------------------------------------------- /docs/methods/exam/ExamMultipleOutputs/CONVpreds.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alan-turing-institute/mogp-emulator/72dc73a49dbab621ef5748546127da990fd81e4a/docs/methods/exam/ExamMultipleOutputs/CONVpreds.png -------------------------------------------------------------------------------- /docs/methods/exam/ExamMultipleOutputs/INDpreds.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alan-turing-institute/mogp-emulator/72dc73a49dbab621ef5748546127da990fd81e4a/docs/methods/exam/ExamMultipleOutputs/INDpreds.png -------------------------------------------------------------------------------- /docs/methods/exam/ExamMultipleOutputs/LMCpreds.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alan-turing-institute/mogp-emulator/72dc73a49dbab621ef5748546127da990fd81e4a/docs/methods/exam/ExamMultipleOutputs/LMCpreds.png -------------------------------------------------------------------------------- /docs/methods/exam/ExamMultipleOutputs/SEPpreds.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alan-turing-institute/mogp-emulator/72dc73a49dbab621ef5748546127da990fd81e4a/docs/methods/exam/ExamMultipleOutputs/SEPpreds.png -------------------------------------------------------------------------------- /docs/methods/exam/ExamMultipleOutputs/ellipse_samescale.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alan-turing-institute/mogp-emulator/72dc73a49dbab621ef5748546127da990fd81e4a/docs/methods/exam/ExamMultipleOutputs/ellipse_samescale.png -------------------------------------------------------------------------------- /docs/methods/exam/ExamMultipleOutputs/ellipse_zoom.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alan-turing-institute/mogp-emulator/72dc73a49dbab621ef5748546127da990fd81e4a/docs/methods/exam/ExamMultipleOutputs/ellipse_zoom.png -------------------------------------------------------------------------------- /docs/methods/exam/ExamMultipleOutputs/output1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alan-turing-institute/mogp-emulator/72dc73a49dbab621ef5748546127da990fd81e4a/docs/methods/exam/ExamMultipleOutputs/output1.png -------------------------------------------------------------------------------- /docs/methods/exam/ExamMultipleOutputs/output2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alan-turing-institute/mogp-emulator/72dc73a49dbab621ef5748546127da990fd81e4a/docs/methods/exam/ExamMultipleOutputs/output2.png -------------------------------------------------------------------------------- /docs/methods/exam/ExamMultipleOutputsPCA/pca.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alan-turing-institute/mogp-emulator/72dc73a49dbab621ef5748546127da990fd81e4a/docs/methods/exam/ExamMultipleOutputsPCA/pca.png -------------------------------------------------------------------------------- /docs/methods/exam/ExamMultipleOutputsPCA/z-scores-dist.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alan-turing-institute/mogp-emulator/72dc73a49dbab621ef5748546127da990fd81e4a/docs/methods/exam/ExamMultipleOutputsPCA/z-scores-dist.png -------------------------------------------------------------------------------- /docs/methods/exam/ExamMultipleOutputsPCA/z-scores.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alan-turing-institute/mogp-emulator/72dc73a49dbab621ef5748546127da990fd81e4a/docs/methods/exam/ExamMultipleOutputsPCA/z-scores.png -------------------------------------------------------------------------------- /docs/methods/exam/ExamScreeningAutomaticRelevanceDetermination.rst: -------------------------------------------------------------------------------- 1 | .. _ExamScreeningAutomaticRelevanceDetermination: 2 | 3 | Example: Using Automatic Relevance Determination (ARD) 4 | ====================================================== 5 | 6 | In this page we demonstrate the implementation of the ARD (see the 7 | procedure page 8 | :ref:`ProcAutomaticRelevanceDetermination`) 9 | method on a simple 1D synthetic example. 10 | 11 | The simulator function is :math:`f(x_1,x_2) = sin(x_1/10) + 0 \times x_2`, 12 | i.e. a two variable function which ignores the second input altogether. 13 | 14 | A 7 point design was used to train a emulator with a squared exponential 15 | function: 16 | 17 | Table of Data 18 | 19 | =================== ====== ====== ======= ======= ====== ====== ====== 20 | Variable Value 21 | ------------------- ------ ------ ------- ------- ------ ------ ------ 22 | :math:`x_1` 0.1000 0.2333 0.3667 0.5000 0.6333 0.7667 0.9000 23 | :math:`x_2` 0.2433 0.3767 0.9100 0.6433 0.1100 0.5100 0.7767 24 | :math:`f(x_1,x_2)` 0.8415 0.7231 -0.5013 -0.9589 0.0501 0.9825 0.4121 25 | =================== ====== ====== ======= ======= ====== ====== ====== 26 | 27 | Note that both input factors are operating on the same scale so no 28 | standardisation is needed in this case. 29 | 30 | The inference is done by using a scaled conjugate gradient algorithm to 31 | maximise the log likelihood of the Gaussian Process emulator (that is in 32 | this case no priors are placed over the length scales). 33 | 34 | To check the fit of the emulator we used a grid test set of 1000 points. 35 | The simulator values are plotted in black dots and the emulation mean 36 | prediction is the smooth coloured surface. We can clearly see from the 37 | plot that the both the simulator and emulator responses are insensitive 38 | to the value of :math:`x_2`. 39 | 40 | .. image:: ExamScreeningAutomaticRelevanceDetermination/exampleARD2D.png 41 | :width: 600px 42 | :align: center 43 | 44 | To further validate the emulator and examine the output predictive 45 | variance, we plot below a profile of the simulator function at 46 | :math:`x_2=1` and :math:`x_1` a grid design of 1000 points. The simulator 47 | function is shown in **green** against the emulator prediction in 48 | **black** with the predictive variance in **grey**. The training data 49 | are also shown as crosses (although the :math:`x_2` coordinate varies in 50 | the training data but clearly this has no effect on the output value 51 | from the simulator). 52 | 53 | .. image:: ExamScreeningAutomaticRelevanceDetermination/exampleARD.png 54 | :width: 600px 55 | :align: center 56 | 57 | The length scales obtained through maximum likelihood are :math:`\delta_1 = 58 | 0.16` and :math:`\delta_2 = 48.6` which can be interpreted as the emulator 59 | using the first variable and ignoring the second. 60 | 61 | 62 | 63 | -------------------------------------------------------------------------------- /docs/methods/exam/ExamScreeningAutomaticRelevanceDetermination/exampleARD.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alan-turing-institute/mogp-emulator/72dc73a49dbab621ef5748546127da990fd81e4a/docs/methods/exam/ExamScreeningAutomaticRelevanceDetermination/exampleARD.png -------------------------------------------------------------------------------- /docs/methods/exam/ExamScreeningAutomaticRelevanceDetermination/exampleARD2D.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alan-turing-institute/mogp-emulator/72dc73a49dbab621ef5748546127da990fd81e4a/docs/methods/exam/ExamScreeningAutomaticRelevanceDetermination/exampleARD2D.png -------------------------------------------------------------------------------- /docs/methods/exam/ExamScreeningMorris/morrisToolkitExample.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alan-turing-institute/mogp-emulator/72dc73a49dbab621ef5748546127da990fd81e4a/docs/methods/exam/ExamScreeningMorris/morrisToolkitExample.png -------------------------------------------------------------------------------- /docs/methods/exam/ExamVariantWithDerivatives1Dim/Figure1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alan-turing-institute/mogp-emulator/72dc73a49dbab621ef5748546127da990fd81e4a/docs/methods/exam/ExamVariantWithDerivatives1Dim/Figure1.png -------------------------------------------------------------------------------- /docs/methods/exam/ExamVariantWithDerivatives1Dim/Figure2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alan-turing-institute/mogp-emulator/72dc73a49dbab621ef5748546127da990fd81e4a/docs/methods/exam/ExamVariantWithDerivatives1Dim/Figure2.png -------------------------------------------------------------------------------- /docs/methods/exam/ExamVariantWithDerivatives1Dim/Figure3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alan-turing-institute/mogp-emulator/72dc73a49dbab621ef5748546127da990fd81e4a/docs/methods/exam/ExamVariantWithDerivatives1Dim/Figure3.png -------------------------------------------------------------------------------- /docs/methods/exam/ExamVariantWithDerivatives1Dim/Figure4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alan-turing-institute/mogp-emulator/72dc73a49dbab621ef5748546127da990fd81e4a/docs/methods/exam/ExamVariantWithDerivatives1Dim/Figure4.png -------------------------------------------------------------------------------- /docs/methods/exam/ExamVariantWithDerivatives1Dim/Figure5.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alan-turing-institute/mogp-emulator/72dc73a49dbab621ef5748546127da990fd81e4a/docs/methods/exam/ExamVariantWithDerivatives1Dim/Figure5.png -------------------------------------------------------------------------------- /docs/methods/exam/ExamVariantWithDerivatives1Dim/Figure6.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alan-turing-institute/mogp-emulator/72dc73a49dbab621ef5748546127da990fd81e4a/docs/methods/exam/ExamVariantWithDerivatives1Dim/Figure6.png -------------------------------------------------------------------------------- /docs/methods/meta/MetaComments.rst: -------------------------------------------------------------------------------- 1 | .. _MetaComments: 2 | 3 | Meta-pages: Comments 4 | ====================== 5 | 6 | The MUCM team is interested to receive your comments on the toolkit. You 7 | can send comments about particular pages (to tell us of errors or 8 | alternative approaches, or to give us the benefit of your own knowledge 9 | and experience with MUCM-related ideas and methods). You can also send 10 | us comments about the toolkit in general: (Do you like it? How could we 11 | improve it generally? What features would you like to see? How could we 12 | organise it better?). 13 | 14 | Please send your comments to the 15 | `webmaster `__. 16 | -------------------------------------------------------------------------------- /docs/methods/meta/MetaCopyrightNotice.rst: -------------------------------------------------------------------------------- 1 | .. _MetaCopyrightNotice: 2 | 3 | Meta-pages: Copyright Notice 4 | ============================ 5 | 6 | The MUCM toolkit is produced by the MUCM project and copyright in all 7 | the toolkit pages is held on behalf of the participating institutions 8 | (University of Sheffield, Durham University, Aston University, London 9 | School of Economics and the National Oceanography Centre, Southampton) 10 | by the MUCM Management Board. 11 | 12 | Pages may not be copied in whole or in part or quoted from without full 13 | acknowledgement being made to the MUCM toolkit. The URL(s) of the 14 | page(s) concerned must be included in all such acknowledgements. 15 | 16 | Further information, requests and enquiries concerning reproduction and 17 | rights should be addressed to: 18 | 19 | | Managing Uncertainty in Complex Models 20 | | Department of Probability & Statistics 21 | | University of Sheffield 22 | | Hicks Building 23 | | Hounsfield Road 24 | | Sheffield 25 | | S3 7RH 26 | | UK 27 | | Tel : +44 (0) 114 222 3753 28 | | E mail: `mucm@sheffieldNOSPAM.ac.uk `_ 29 | 30 | Disclaimer 31 | 32 | Information at this site is general information provided as part of the 33 | RCUK Managing Uncertainty in Complex Models project. We aim to ensure 34 | that all information we maintain is accurate, current and fit for the 35 | purpose intended. However it does not constitute legal or other 36 | professional advice. Neither the MUCM consortium, or its funders RCUK, 37 | nor any of the sources of the information shall be responsible for any 38 | errors or omissions, or for the use of or results obtained from the use 39 | of this information. 40 | 41 | Links to and from this site are for convenience only and do not mean 42 | that MUCM endorses or approves them. We cannot guarantee that these 43 | links will work all of the time and we have no control over the 44 | availability of linked pages. We will strive to maintain them and would 45 | be grateful to receive information on any broken links if found in order 46 | that we can review them. It is the responsibility of the internet user 47 | to make their own decisions about the accuracy, currency, reliability 48 | and correctness of information found at sites linked from this website. 49 | -------------------------------------------------------------------------------- /docs/methods/meta/MetaSoftwareDisclaimer.rst: -------------------------------------------------------------------------------- 1 | .. _MetaSoftwareDisclaimer: 2 | 3 | Meta-pages: Software Disclaimer 4 | =============================== 5 | 6 | Information at this site is general information provided as part of the 7 | RCUK Manging Uncertainties in Complex Models project. We aim to ensure 8 | that all information we maintain is accurate, current and fit for the 9 | purpose intended. However it does not constitute legal or other 10 | professional advice. Neither the :ref:`MUCM` consortium, or 11 | its funders RCUK, nor any of the sources of the information shall be 12 | responsible for any errors or omissions, or for the use of or results 13 | obtained from the use of this information. 14 | 15 | The :ref:`MUCM` toolkit includes references in various 16 | places to software that we believe is available to carry out some of the 17 | toolkit procedures. Users of the toolkit should note, however, that 18 | software does not form part of the toolkit and such references are for 19 | convenience only. The MUCM consortium makes no endorsement or warranties 20 | about any software referred to in the toolkit, and is not responsible 21 | for the quality, reliability, accuracy or safety of such software. This 22 | includes both software produced by consortium members or by others. 23 | -------------------------------------------------------------------------------- /docs/methods/meta/MetaToolkitTutorial/Fig1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alan-turing-institute/mogp-emulator/72dc73a49dbab621ef5748546127da990fd81e4a/docs/methods/meta/MetaToolkitTutorial/Fig1.png -------------------------------------------------------------------------------- /docs/methods/meta/MetaToolkitTutorial/Fig2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alan-turing-institute/mogp-emulator/72dc73a49dbab621ef5748546127da990fd81e4a/docs/methods/meta/MetaToolkitTutorial/Fig2.png -------------------------------------------------------------------------------- /docs/methods/proc/ProcApproximateUpdateDynamicMeanandVariance.rst: -------------------------------------------------------------------------------- 1 | .. _ProcApproximateUpdateDynamicMeanandVariance: 2 | 3 | Procedure: Use simulation to recursively update the dynamic emulator mean and variance in the approximation method 4 | ================================================================================================================== 5 | 6 | Description and Background 7 | -------------------------- 8 | 9 | This page is concerned with task of :ref:`emulating` a 10 | :ref:`dynamic simulator`, as set out in the variant 11 | thread on dynamic emulation 12 | (:ref:`ThreadVariantDynamic`). 13 | 14 | The approximation procedure for iterating the single step emulator 15 | (:ref:`ProcApproximateIterateSingleStepEmulator`) 16 | recursively defines 17 | 18 | .. math:: 19 | \mu_{t+1} &= \mathrm{E}[ m^*(w_t,a_{t+1},\phi)|f(D)], \\ 20 | V_{t+1} &= \mathrm{E}[ 21 | v^*\{(w_t,a_{t+1},\phi),(w_t,a_{t+1},\phi)\}|f(D)] + 22 | \mathrm{Var}[m^*(w_t,a_{t+1},\phi)|f(D)], 23 | 24 | where the expectations and variances are taken with respect to :math:`w_{t}`, 25 | with :math:`w_{t} \sim N_r(\mu_{t},V_{t})`. If the :ref:`single 26 | step` emulator has a linear mean and a 27 | separable Gaussian covariance function, then :math:`\mu_{t+1}` and 28 | :math:`V_{t+1}` can be computed explicitly, as described in the procedure 29 | page for recursively updating the dynamic emulator mean and variance 30 | (:ref:`ProcUpdateDynamicMeanAndVariance`). 31 | Otherwise, simulation can be used, which we describe here. 32 | 33 | Inputs 34 | ------ 35 | 36 | - :math:`\mu_{t}` and :math:`V_{t}` 37 | - The single step emulator, conditioned on training inputs :math:`D ` and 38 | outputs :math:`f(D)`, and hyperparameters :math:`\theta`, with posterior 39 | mean and covariance functions :math:`m^*(\cdot)` and :math:`v^*(\cdot,\cdot)` 40 | respectively. 41 | 42 | Outputs 43 | ------- 44 | 45 | - Estimates of :math:`\mu_{t+1}` and :math:`V_{t+1}` 46 | 47 | Procedure 48 | --------- 49 | 50 | We describe a Monte Carlo procedure using :math:`N` Monte Carlo iterations. 51 | For discussion of the choice of :math:`N`, see the discussion page on Monte 52 | Carlo estimation (:ref:`DiscMonteCarlo`). 53 | 54 | #. For :math:`i=1,\ldots,N`, sample :math:`w_t^{(i)}` from :math:`N(\mu_t,V_t)` 55 | #. Estimate :math:`\mu_{t+1}` by 56 | :math:`\hat{\mu}_{t+1}=\frac{1}{N}\sum_{i=1}^N 57 | m^*(w_t^{(i)},a_{t+1},\phi)` 58 | #. Estimate :math:`V_{t+1}` by 59 | 60 | .. math:: 61 | \hat{V}_{t+1}=\frac{1}{N}\sum_{i=1}^N 62 | v^*\{(w_t^{(i)},a_{t+1},\phi),(w_t^{(i)},a_{t+1},\phi)\} 63 | +\frac{1}{N-1}\sum_{i=1}^N\left(m^*(w_t^{(i)},a_{t+1},\phi)-\hat{\mu}_{t+1}\right)^2 64 | -------------------------------------------------------------------------------- /docs/methods/proc/ProcBLAdjust.rst: -------------------------------------------------------------------------------- 1 | .. _ProcBLAdjust: 2 | 3 | Procedure: Calculation of adjusted expectation and variance 4 | =========================================================== 5 | 6 | Description and Background 7 | -------------------------- 8 | 9 | In the context of :ref:`Bayes linear` methods, the 10 | Bayes linear :ref:`adjustment` is the appropriate method 11 | for updating prior :ref:`second-order beliefs` 12 | given observed data. The adjustment takes the form of linear fitting of 13 | our beliefs on the observed data quantities. Specifically, given two 14 | random vectors, :math:`B`, :math:`D`, the *adjusted expectation* for element 15 | :math:`B_i`, given :math:`D`, is the linear combination :math:`a_0 + a^T D` 16 | minimising :math:`\textrm{E}[B_i - a_0 - a^T D)^2]` over choices of 17 | :math:`\{a_0, a\}`. 18 | 19 | Inputs 20 | ------ 21 | 22 | - :math:`\textrm{E}[B]`, :math:`\textrm{Var}[B]` - prior expectation and 23 | variance for the vector :math:`B` 24 | - :math:`\textrm{E}[D]`, :math:`\textrm{Var}[D]` - prior expectation and 25 | variance for the vector :math:`D` 26 | - :math:`\textrm{Cov}[B,D]` - prior covariance between the vector :math:`B` 27 | and the vector :math:`B` 28 | - :math:`D_{obs}` - observed values of the vector :math:`D` 29 | 30 | Outputs 31 | ------- 32 | 33 | - :math:`\textrm{E}_D[B]` - adjusted expectation for the uncertain 34 | quantity :math:`B` given the observations :math:`D` 35 | - :math:`\textrm{Var}_D[B]`- adjusted variance matrix for the uncertain 36 | quantity :math:`B` given the observations :math:`D` 37 | 38 | Procedure 39 | --------- 40 | 41 | The adjusted expectation vector, :math:`\textrm{E}_D[B]` is evaluated as 42 | 43 | .. math:: 44 | \textrm{E}_D[B] = \textrm{E}[B] + \textrm{Cov}[B,D] 45 | \textrm{Var}[D]^{-1} (D_{obs}-\textrm{E}[D]) 46 | 47 | (If :math:`\textrm{Var}[D]` is not invertible, then we use a generalised 48 | inverse such as Moore-Penrose). 49 | 50 | The *adjusted variance matrix* for :math:`B` given :math:`D` is 51 | 52 | .. math:: 53 | \textrm{Var}_D[B] = \textrm{Var}[B] - 54 | \textrm{Cov}[B,D]\textrm{Var}[D]^{-1}\textrm{Cov}[D,B] 55 | 56 | Additional Comments 57 | ------------------- 58 | 59 | See :ref:`DiscBayesLinearTheory` for a full 60 | description of Bayes linear methods. 61 | -------------------------------------------------------------------------------- /docs/methods/proc/ProcHaltonDesign.rst: -------------------------------------------------------------------------------- 1 | .. _ProcHaltonDesign: 2 | 3 | Procedure: Generate a Halton design 4 | =================================== 5 | 6 | Description and Background 7 | -------------------------- 8 | 9 | A Halton design is one of a number of non-random space-filling designs 10 | suitable for defining a set of points in the 11 | :ref:`simulator` input space for creating a :ref:`training 12 | sample`. 13 | 14 | The :math:`n` point Halton design in :math:`p` dimensions is generated by a 15 | generator set :math:`g=(g_1,\ldots,g_p)` of prime numbers. See the 16 | "Additional Comments" below for discussion of the choice of generators. 17 | 18 | Inputs 19 | ------ 20 | 21 | - Number of dimensions :math:`p` 22 | - Number of points desired :math:`n` 23 | - Set of prime generators :math:`g_1,\ldots,g_p` 24 | 25 | Outputs 26 | ------- 27 | 28 | - Halton design :math:`D = \{x_1, x_2, \ldots, x_n\}` 29 | 30 | Procedure 31 | --------- 32 | 33 | #. For each :math:`i=1,2,\ldots,p` and :math:`j=1,2,\ldots,n`, let :math:`a_{ij}` 34 | be the representation in prime base :math:`g_i` of the number :math:`j`. 35 | Let :math:`n_{ij}` be the number of digits used for :math:`a_{ij}` (i.e. 36 | :math:`n_{ij}` is the logarithm to base :math:`g_i` of :math:`j`, rounded up 37 | to the nearest integer), and let :math:`R_{ij}` be the result of 38 | reversing the digits of :math:`a_{ij}` and evaluating this as a number 39 | in base :math:`g_i`. 40 | #. For each :math:`i=1,2,\ldots,p` and :math:`j=1,2,\ldots,n`, let :math:`x_{ij} = 41 | R_{ij} /g_i^{n_{ij}}`. 42 | #. For :math:`j=1,2,\ldots,n`, the j-th design point is :math:`x_j = (x_{1j}, 43 | x_{2j}, \ldots, x_{pj})`. 44 | 45 | For example, if :math:`j=10` and :math:`g_i=2`, then :math:`a_{ij}=1010`, from 46 | which we have :math:`n_{ij}=4`. Then :math:`R_{ij}` is the binary number 0101, 47 | i.e 5, so that :math:`x_{ij}=5/2^4=0.3125`. 48 | 49 | Additional Comments 50 | ------------------- 51 | 52 | A potential problem with Halton designs is the difficulty in finding 53 | suitable generators. One suggestion is to let :math:`g_i` be the :math:`i`-th 54 | prime, but this may not work well when :math:`p` is large. 55 | 56 | References 57 | ---------- 58 | 59 | The following is a link to the repository for Matlab code for the Halton 60 | sequence in up to 11 dimensions: 61 | `CPHaltonSequence.m `_ 62 | (:ref:`disclaimer`). 63 | -------------------------------------------------------------------------------- /docs/methods/proc/ProcLHC.rst: -------------------------------------------------------------------------------- 1 | .. _ProcLHC: 2 | 3 | Procedure: Generate a Latin hypercube 4 | ===================================== 5 | 6 | Description and Background 7 | -------------------------- 8 | 9 | A Latin hypercube (LHC) is a random set of points in :math:`[0,1]^p` 10 | constructed so that for :math:`i=1,2,\ldots,p` the i-th coordinates of the 11 | points are spread evenly along [0,1]. 12 | 13 | Inputs 14 | ------ 15 | 16 | - Number of dimensions :math:`p` 17 | - Number of points desired :math:`n` 18 | 19 | Outputs 20 | ------- 21 | 22 | - LHC :math:`D = \{x_1, x_2, \ldots, x_n\}` 23 | 24 | Procedure 25 | --------- 26 | 27 | #. For each :math:`i=1,2,\ldots,p`, independently generate :math:`n` random 28 | numbers :math:`u_{i1}, u_{i2}, \ldots, u_{in}` in [0,1] and a random 29 | permutation :math:`b_{i1}, b_{i2}, \ldots, b_{in}` of the integers 30 | :math:`0,1,\ldots,n-1`. 31 | #. For each :math:`i=1,2,\ldots,p` and :math:`j=1,2,\ldots,n` let :math:`x_{ij} = 32 | (b_{ij}+u_{ij})/n`. 33 | #. For :math:`j=1,2,\ldots,n`, the j-th LHC point is :math:`x_j = (x_{1j}, 34 | x_{2j}, \ldots, x_{pj})`. 35 | 36 | Additional Comments 37 | ------------------- 38 | 39 | The construction of a LHC implies that the projection of the set of 40 | points into the i-th dimension results in :math:`n` points that are evenly 41 | spread over that dimension. If we project into two or more of the :math:`p` 42 | dimensions, a LHC may also appear to be well spread (space-filling) in 43 | that projection, but this is not guaranteed. 44 | -------------------------------------------------------------------------------- /docs/methods/proc/ProcLatticeDesign.rst: -------------------------------------------------------------------------------- 1 | .. _ProcLatticeDesign: 2 | 3 | Procedure: Generate a lattice design 4 | ==================================== 5 | 6 | Description and Background 7 | -------------------------- 8 | 9 | A lattice design is one of a number of non-random space-filling designs 10 | suitable for defining a set of points in the 11 | :ref:`simulator` input space for creating a :ref:`training 12 | sample`. 13 | 14 | The :math:`n` point lattice in :math:`p` dimensions is generated by a positive 15 | integer generator set :math:`g=(g_1,\ldots,g_p)`. See the "Additional 16 | Comments" below for discussion of the choice of generators. 17 | 18 | Inputs 19 | ------ 20 | 21 | - Number of dimensions :math:`p` 22 | - Number of runs desired :math:`n` 23 | - Set of positive integer generators :math:`g_1,\ldots,g_p` 24 | 25 | Outputs 26 | ------- 27 | 28 | - Lattice design :math:`D = \{x_1, x_2, \ldots, x_n\}` 29 | 30 | Procedure 31 | --------- 32 | 33 | For :math:`j=0,\ldots,n-1`, generate lattice points as 34 | 35 | .. math:: 36 | x_{j+1}=\left(\frac{j}{n}g_1{\rm mod} 1,\ldots,\frac{j}{n}g_d{\rm 37 | mod} 1\right). 38 | 39 | Note that the operator "mod 1" here has the effect of returning the 40 | fractional part of each number. For instance, if :math:`j=7, n=50` and 41 | :math:`g_1 = 13`, then 42 | 43 | .. math:: 44 | \frac{j}{n}g_1 = 1.82 45 | 46 | and so 47 | 48 | .. math:: 49 | \frac{j}{n}g_1 {\rm mod} 1=0.82. 50 | 51 | Additional Comments 52 | ------------------- 53 | 54 | A potential problem with lattice designs is the difficulty in finding 55 | suitable generators for a lattice. A condition for generators is that 56 | :math:`g_1,\ldots,g_d` and :math:`n` should form a set of relatively prime 57 | numbers. However, this seems to be a necessary but not sufficient 58 | condition to obtain a lattice that fills the design space well. 59 | 60 | References 61 | ---------- 62 | 63 | Bates, R.A., Riccomagno, E., Schwabe, R., Wynn, H. (1998). The use of 64 | lattices in the design of high-dimensional experiments. IMS Lecture 65 | Notes, 34, 26-35. 66 | 67 | Sloan, I.H., Joe, S. (1994). Lattice methods for multiple integration. 68 | Clarendon Press, Oxford. 69 | 70 | Matlab code for generating lattice designs is available from `Ron 71 | Bates `_ 72 | (:ref:`disclaimer`). 73 | -------------------------------------------------------------------------------- /docs/methods/proc/ProcOptimalLHC.rst: -------------------------------------------------------------------------------- 1 | .. _ProcOptimalLHC: 2 | 3 | Procedure: Generate an optimised Latin hypercube design 4 | ======================================================= 5 | 6 | Description and Background 7 | -------------------------- 8 | 9 | A Latin hypercube (LHC) is a random set of points in :math:`[0,1]^p` 10 | constructed so that for :math:`i=1,2,\ldots,p` the i-th coordinates of the 11 | points are spread evenly along [0,1]. However, a single random LHC will 12 | rarely have good enough space-filling properties in the whole of 13 | :math:`[0,1]^p` or satisfy other desirable criteria. Therefore, it is usual 14 | to generate many LHCs and then select the one having the best value of a 15 | suitable criterion. 16 | 17 | We present here the procedure for a general optimality criterion and 18 | also include details of the most popular criterion, known as maximin. A 19 | thorough consideration of optimality criteria may be found in the 20 | discussion page on technical issues in training sample design for the 21 | core problem (:ref:`DiscCoreDesign`). 22 | 23 | Inputs 24 | ------ 25 | 26 | - Number of dimensions :math:`p` 27 | - Number of points desired :math:`n` 28 | - Number of LHCs to be generated :math:`N` 29 | - Optimality criterion :math:`C(D)` 30 | 31 | Outputs 32 | ------- 33 | 34 | - Optimised LHC design :math:`D = \{x_1, x_2, \ldots, x_n\}` 35 | 36 | Procedure 37 | --------- 38 | 39 | Procedure for a general criterion 40 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 41 | 42 | #. For :math:`k=1,2,\ldots,N` independently, generate a random LHC :math:`D_k` 43 | using the procedure page on generating a Latin hypercube 44 | (:ref:`ProcLHC`) and evaluate the criterion :math:`C_k = 45 | C(D_k)`. 46 | #. Let :math:`K=\arg\max\{D_k\}` (i.e. :math:`K` is the number of the LHC with 47 | the highest criterion value). 48 | #. Set :math:`D=D_K`. 49 | 50 | Note that the second step here assumes that high values of the criterion 51 | are desirable. If low values are desirable, then change argmax to 52 | argmin. 53 | 54 | Maximin criterion 55 | ~~~~~~~~~~~~~~~~~ 56 | 57 | A commonly used criterion is 58 | 59 | .. math:: 60 | C(D) = \min_{j\ne j^\prime}|x_j - x_{j^\prime}|, 61 | 62 | where :math:`|x_j - x_{j^\prime}|` denotes a measure of distance between 63 | the two points :math:`x_j` and :math:`x_{j^\prime}` in the design. The 64 | distance measure is usually taken to be squared Euclidean distance: that 65 | is, if :math:`u=(u_1,u_2,\ldots,u_p)` then we define 66 | 67 | .. math:: 68 | |u| = u^T u = \sum_{i=1}^p u_i^2. 69 | 70 | High values of this criterion are desirable. 71 | 72 | Additional Comments 73 | ------------------- 74 | 75 | Note that the resulting design will not truly be optimal with respect to 76 | the chosen criterion because only a finite number of LHCs will be 77 | generated. 78 | -------------------------------------------------------------------------------- /docs/methods/proc/ProcWeylDesign.rst: -------------------------------------------------------------------------------- 1 | .. _ProcWeylDesign: 2 | 3 | Procedure: Generate a Weyl design 4 | ================================= 5 | 6 | Description and Background 7 | -------------------------- 8 | 9 | A Weyl design (also known as a Richtmyer design) is one of a number of 10 | non-random space-filling designs suitable for defining a set of points 11 | in the :ref:`simulator` input space for creating a 12 | :ref:`training sample`. 13 | 14 | The :math:`n` point Weyl design in :math:`p` dimensions is generated by a 15 | generator set :math:`g=(g_1,\ldots,g_p)` of irrational numbers. See the 16 | "Additional Comments" below for discussion of the choice of generators. 17 | 18 | Inputs 19 | ------ 20 | 21 | - Number of dimensions :math:`p` 22 | - Number of points desired :math:`n` 23 | - Set of irrational generators :math:`g_1,\ldots,g_p` 24 | 25 | Outputs 26 | ------- 27 | 28 | - Weyl design :math:`D = \{x_1, x_2, \ldots, x_n\}` 29 | 30 | Procedure 31 | --------- 32 | 33 | For :math:`j=0,\ldots,n-1`, generate points as 34 | 35 | .. math:: 36 | x_{j+1}=\left(j\times g_1{\rm mod} 1, j\times g_2{\rm mod} 37 | 1,\ldots,j\times g_d{\rm mod} 1\right). 38 | 39 | Note that the operator "mod 1" here has the effect of returning the 40 | fractional part of each number. For instance, if :math:`j=7` and :math:`g_1 = 41 | \sqrt{2} = 1.414\ldots`, then 42 | 43 | .. math:: 44 | j\times g_1 = 9.89949\ldots 45 | 46 | and so 47 | 48 | .. math:: 49 | j\times g_1 {\rm mod} 1 = 0.89949\ldots. 50 | 51 | Additional Comments 52 | ------------------- 53 | 54 | A potential problem with Weyl designs is the difficulty in finding 55 | suitable generators. One suggestion is to let :math:`g_i` be the square 56 | root of the :math:`i`-th prime, but this may not work well when :math:`p` is large. 57 | 58 | References 59 | ---------- 60 | 61 | The following is a link to the repository for Matlab code for the Weyl 62 | sequence in up to 100 dimensions: 63 | `CPWeylSequence.m `_ 64 | (:ref:`disclaimer`). 65 | -------------------------------------------------------------------------------- /docs/requirements.txt: -------------------------------------------------------------------------------- 1 | sphinx>3 2 | -------------------------------------------------------------------------------- /mogp_emulator/LibGPGPU.py: -------------------------------------------------------------------------------- 1 | """ 2 | Wrapper for the optional GPU interface library, libgpgpu.so 3 | """ 4 | 5 | HAVE_LIBGPGPU = False 6 | try: 7 | from libgpgpu import * 8 | HAVE_LIBGPGPU = True 9 | except ModuleNotFoundError: 10 | pass 11 | 12 | 13 | def gpu_usable(): 14 | return HAVE_LIBGPGPU and have_compatible_device() 15 | -------------------------------------------------------------------------------- /mogp_emulator/__init__.py: -------------------------------------------------------------------------------- 1 | from .version import version as __version__ 2 | 3 | from .GaussianProcess import GaussianProcess 4 | try: 5 | from .GaussianProcessGPU import GaussianProcessGPU 6 | from .GaussianProcessGPU import GPUUnavailableError 7 | except: 8 | pass 9 | from .MultiOutputGP import MultiOutputGP 10 | from .MultiOutputGP_GPU import MultiOutputGP_GPU 11 | from .fitting import fit_GP_MAP 12 | from .MeanFunction import MeanFunction 13 | from .ExperimentalDesign import MonteCarloDesign, LatinHypercubeDesign, MaxiMinLHC 14 | from .SequentialDesign import MICEDesign 15 | from .HistoryMatching import HistoryMatching 16 | from .DimensionReduction import gKDR 17 | -------------------------------------------------------------------------------- /mogp_emulator/benchmarks/Makefile: -------------------------------------------------------------------------------- 1 | # Makefile for running tests and benchmarks for multi-output emulator problems 2 | 3 | # To get help, simply enter make into the shell to see a list of options 4 | 5 | ## help : Display this message (same as make with no argument) 6 | .PHONY : help 7 | help : Makefile 8 | @sed -n 's/^##//p' $< 9 | 10 | ## all : Run all benchmarks 11 | .PHONY: all 12 | all: benchmarks 13 | 14 | ## benchmarks : Run the Branin, Rosenbrock (convergence), Tsunami (performance), 15 | ## : Pivoted Cholesky, MICE, dimension reduction, 16 | ## : and History Matching benchmarks 17 | .PHONY: benchmarks 18 | benchmarks: branin tsunami rosenbrock pivot mice gKDR histmatch 19 | 20 | ## branin : Run the 2D Branin tests of convergence. Produces the plots 21 | ## : branin_2d_error.png and branin_2d_unc.png 22 | .PHONY: branin 23 | branin: branin_2d_error.png branin_2d_unc.png 24 | 25 | ## tsunami : Run the benchmarks on a tsunami emulator problem. Produces the 26 | ## : plot tsunami_scaling.png 27 | .PHONY: tsunami 28 | tsunami: tsunami_scaling.png 29 | 30 | ## rosenbrock : Run the Rosenbrock test of convergence. Produces the plots 31 | ## : rosenbrock_error.png and rosenbrock_unc.png 32 | .PHONY: rosenbrock 33 | rosenbrock: rosenbrock_error.png rosenbrock_unc.png 34 | 35 | ## mice : Run the MICE Experimental Design applied to the 2D Branin function. 36 | ## : Produces the plots mice_error.png and mice_unc.png 37 | .PHONY: mice 38 | mice: mice_error.png mice_unc.png 39 | 40 | ## histmatch : Run the History Matching demo showing 1D and 2D examples. 41 | ## : Produces the plots histmatch_1D.png and histmatch_2D.png 42 | .PHONY: histmatch 43 | histmatch: histmatch_1D.png histmatch_2D.png 44 | 45 | ## gKDR : Run the dimension reduction benchmark 46 | ## : Produces the plot benchmark_kdr_GP_loss.pdf 47 | .PHONY: gKDR 48 | gKDR: benchmark_kdr_GP_loss.pdf 49 | 50 | ## pivot : Run the pivoted Cholesky decomposition benchmark 51 | ## : Produces the plots pivot_error.png and pivot_unc.png 52 | .PHONY: pivot 53 | pivot: pivot_error.png pivot_unc.png 54 | 55 | ## gpu_parallel : Run comparison of timings for fitting and prediction on GPU and CPU. 56 | ## Produces the plot gpu_timing_plots.png 57 | .PHONY: gpu_parallel 58 | gpu_parallel: gpu_timing_plots.png 59 | 60 | # commands above are shortcuts to the targets below 61 | 62 | branin_2d_unc.png branin_2d_error.png: benchmark_branin.py 63 | python3 benchmark_branin.py 64 | 65 | rosenbrock_unc.png rosenbrock_error.png: benchmark_rosenbrock.py 66 | python3 benchmark_rosenbrock.py 67 | 68 | tsunami_scaling.png: benchmark_tsunami.py 69 | python3 benchmark_tsunami.py 70 | 71 | mice_unc.png mice_error.png: benchmark_MICE.py 72 | python3 benchmark_MICE.py 73 | 74 | histmatch_1D.png histmatch_2D.png: benchmark_historymatching.py 75 | python3 benchmark_historymatching.py 76 | 77 | benchmark_kdr_GP_loss.pdf benchmark_kdr_GP_loss.npy: benchmark_kdr_GP.py 78 | python3 benchmark_kdr_GP.py 79 | 80 | pivot_error.png pivot_unc.png: benchmark_pivot.py 81 | python3 benchmark_pivot.py 82 | 83 | gpu_timing_plots.png: benchmark_gpu_parallel.py 84 | python3 benchmark_gpu_parallel.py 85 | -------------------------------------------------------------------------------- /mogp_emulator/benchmarks/__init__.py: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alan-turing-institute/mogp-emulator/72dc73a49dbab621ef5748546127da990fd81e4a/mogp_emulator/benchmarks/__init__.py -------------------------------------------------------------------------------- /mogp_emulator/benchmarks/benchmark_kdr_GP.py: -------------------------------------------------------------------------------- 1 | """Dimension reduction benchmark (gKDR) 2 | 3 | Plot L_1 model error against reduced dimension, for a one-hundred 4 | dimensional problem. The model is a Gaussian process (with 5 | maximum-likelihood hyperparameters), with inputs determined by gKDR, 6 | varying structural dimension and with a selection of scale parameters. 7 | The inputs to the model are 100 points chosen uniformly at random in 8 | 100 dimensions, and the observations are a linear mapping of these 9 | into one dimension. 10 | """ 11 | 12 | import os 13 | from contextlib import redirect_stdout 14 | import numpy as np 15 | from mogp_emulator import fit_GP_MAP 16 | from mogp_emulator import DimensionReduction 17 | from mogp_emulator import gKDR 18 | try: 19 | import matplotlib.pyplot as plt 20 | have_plt = True 21 | except ImportError: 22 | print("matplotlib.pyplot import error: skipping plots") 23 | have_plt = False 24 | 25 | dev_null = open(os.devnull, "w") 26 | 27 | def fn(x): 28 | return x[0] 29 | 30 | 31 | def make_plot(loss): 32 | """Produce a plot of loss as a function of structural dimension.""" 33 | plt.xlabel("Structural dimension") 34 | plt.ylabel("Loss ($L_1$)") 35 | for ic in range(loss.shape[0]): 36 | assert(np.all(loss[ic,:,2:] == loss[ic,0,2:])) 37 | cX, cY = loss[ic,0,2:] 38 | plt.plot(loss[ic,:,0], loss[ic,:,1], 'x-', label = "$c_X = {}, c_Y = {}$".format(cX, cY)) 39 | 40 | plt.ylim(bottom=0.0) 41 | plt.legend() 42 | # plt.show() 43 | plt.savefig("benchmark_kdr_GP_loss.pdf") 44 | 45 | 46 | def run(): 47 | """Run the benchmark""" 48 | N = 100 49 | D = 100 50 | np.random.seed(3) 51 | X = np.random.random((N, D)) 52 | Y = np.apply_along_axis(fn, 1, X) 53 | 54 | def compute_loss(k): 55 | ## ignore occasional warning messages from the GP fitting 56 | with redirect_stdout(dev_null): 57 | loss = gKDR._compute_loss(X, Y, fit_GP_MAP, 58 | cross_validation_folds = 5, 59 | K = k, X_scale = cX, Y_scale = cY) 60 | 61 | print("loss(K={}, cX={}, cY={}) = {}".format(k, cX, cY, loss)) 62 | return loss 63 | 64 | K = np.arange(1,101) 65 | scale_params = [(1.0, 1.0), (2.0, 2.0), (5.0, 5.0)] 66 | 67 | loss = np.zeros((len(scale_params), len(K), 4)) 68 | 69 | for ic in range(len(scale_params)): 70 | cX, cY = scale_params[ic] 71 | loss[ic,:,:] = np.array([[k, compute_loss(k), cX, cY] for k in K]) 72 | 73 | np.save("benchmark_kdr_GP_loss", loss) 74 | 75 | if have_plt: 76 | make_plot(loss) 77 | 78 | 79 | if __name__ == '__main__': 80 | run() 81 | -------------------------------------------------------------------------------- /mogp_emulator/benchmarks/timingtestdata.npz: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alan-turing-institute/mogp-emulator/72dc73a49dbab621ef5748546127da990fd81e4a/mogp_emulator/benchmarks/timingtestdata.npz -------------------------------------------------------------------------------- /mogp_emulator/benchmarks/tsunamidata.npz: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alan-turing-institute/mogp-emulator/72dc73a49dbab621ef5748546127da990fd81e4a/mogp_emulator/benchmarks/tsunamidata.npz -------------------------------------------------------------------------------- /mogp_emulator/demos/__init__.py: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alan-turing-institute/mogp-emulator/72dc73a49dbab621ef5748546127da990fd81e4a/mogp_emulator/demos/__init__.py -------------------------------------------------------------------------------- /mogp_emulator/demos/gp_demo_gpu.py: -------------------------------------------------------------------------------- 1 | import numpy as np 2 | import mogp_emulator 3 | from projectile import simulator, print_results 4 | 5 | # GP example using the projectile demo on a GPU 6 | 7 | # To run this demo you must be on a machine with an Nvidia GPU, and with 8 | # CUDA libraries available. There are also dependencies on eigen and pybind11 9 | # If you are working on a managed cluster, these may be available via commands 10 | # 11 | # module load cuda/11.2 12 | # module load py-pybind11-2.2.4-gcc-5.4.0-tdtz6iq 13 | # module load gcc/7 14 | # module load eigen 15 | # 16 | # You should then be able to compile the cuda code at the same time as installing the mogp_emulator package, by doing (from the main mogp_emulator/ directory: 17 | # pip install . 18 | # (note that if you don't have write access to the global directory 19 | # (e.g. if you are on a cluster such as CSD3), you should add the 20 | # `--user` flag to this command) 21 | 22 | 23 | # define some common variables 24 | 25 | n_samples = 20 26 | n_preds = 10 27 | 28 | # Experimental design -- requires a list of parameter bounds if you would like to use 29 | # uniform distributions. If you want to use different distributions, you 30 | # can use any of the standard distributions available in scipy to create 31 | # the appropriate ppf function (the inverse of the cumulative distribution). 32 | # Internally, the code creates the design on the unit hypercube and then uses 33 | # the distribution to map from [0,1] to the real parameter space. 34 | 35 | ed = mogp_emulator.LatinHypercubeDesign([(-5., 1.), (0., 1000.)]) 36 | 37 | # sample space 38 | 39 | inputs = ed.sample(n_samples) 40 | 41 | # run simulation 42 | 43 | targets = np.array([simulator(p) for p in inputs]) 44 | 45 | ################################################################################### 46 | 47 | # Basic example -- fit GP using MLE and Squared Exponential Kernel and predict 48 | 49 | print("Example: Basic GP") 50 | 51 | # create GP and then fit using MLE 52 | # the only difference between this and the standard CPU implementation 53 | # is to use the GaussianProcessGPU class rather than GaussianProcess. 54 | 55 | gp = mogp_emulator.GaussianProcessGPU(inputs, targets) 56 | 57 | gp = mogp_emulator.fit_GP_MAP(gp) 58 | 59 | # create 20 target points to predict 60 | 61 | predict_points = ed.sample(n_preds) 62 | 63 | means, variances, derivs = gp.predict(predict_points) 64 | 65 | print_results(predict_points, means) 66 | -------------------------------------------------------------------------------- /mogp_emulator/demos/kdr_demos.py: -------------------------------------------------------------------------------- 1 | import mogp_emulator 2 | import numpy as np 3 | 4 | # simple Dimension Reduction examples 5 | 6 | # simulator function -- returns a single "important" dimension from 7 | # at least 4 inputs 8 | 9 | def f(x): 10 | return (x[0]-x[1]+2.*x[3])/3. 11 | 12 | # Experimental design -- create a design with 5 input parameters 13 | # all uniformly distributed over [0,1]. 14 | 15 | ed = mogp_emulator.LatinHypercubeDesign(5) 16 | 17 | # sample space 18 | 19 | inputs = ed.sample(100) 20 | 21 | # run simulation 22 | 23 | targets = np.array([f(p) for p in inputs]) 24 | 25 | ################################################################################### 26 | 27 | # First example -- dimension reduction given a specified number of dimensions 28 | # (note that in real life, we do not know that the underlying simulation only 29 | # has a single dimension) 30 | 31 | print("Example 1: Basic Dimension Reduction") 32 | 33 | # create DR object with a single reduced dimension (K = 1) 34 | 35 | dr = mogp_emulator.gKDR(inputs, targets, K=1) 36 | 37 | # use it to create GP 38 | 39 | gp = mogp_emulator.fit_GP_MAP(dr(inputs), targets) 40 | 41 | # create 5 target points to predict 42 | 43 | predict_points = ed.sample(5) 44 | predict_actual = np.array([f(p) for p in predict_points]) 45 | 46 | means = gp(dr(predict_points)) 47 | 48 | for pp, m, a in zip(predict_points, means, predict_actual): 49 | print("Target point: {} Predicted mean: {} Actual mean: {}".format(pp, m, a)) 50 | 51 | ################################################################################### 52 | 53 | # Second Example: Estimate dimensions from data 54 | 55 | print("Example 2: Estimate the number of dimensions from the data") 56 | 57 | # Use the tune_parameters method to use cross validation to create DR object 58 | # Note this is more realistic than the above as it does not know the 59 | # number of dimensions in advance 60 | 61 | dr_tuned, loss = mogp_emulator.gKDR.tune_parameters(inputs, targets, 62 | mogp_emulator.fit_GP_MAP, 63 | cXs=[3.], cYs=[3.]) 64 | 65 | # Get number of inferred dimensions (usually gives 2) 66 | 67 | print("Number of inferred dimensions is {}".format(dr_tuned.K)) 68 | 69 | # use object to create GP 70 | 71 | gp_tuned = mogp_emulator.fit_GP_MAP(dr_tuned(inputs), targets) 72 | 73 | # create 10 target points to predict 74 | 75 | predict_points = ed.sample(5) 76 | predict_actual = np.array([f(p) for p in predict_points]) 77 | 78 | means = gp_tuned(dr_tuned(predict_points)) 79 | 80 | for pp, m, a in zip(predict_points, means, predict_actual): 81 | print("Target point: {} Predicted mean: {} Actual mean: {}".format(pp, m, a)) 82 | -------------------------------------------------------------------------------- /mogp_emulator/demos/mice_demos.py: -------------------------------------------------------------------------------- 1 | import mogp_emulator 2 | import numpy as np 3 | from projectile import simulator, print_results 4 | 5 | # simple MICE examples using the projectile demo 6 | 7 | # Base design -- requires a list of parameter bounds if you would like to use 8 | # uniform distributions. If you want to use different distributions, you 9 | # can use any of the standard distributions available in scipy to create 10 | # the appropriate ppf function (the inverse of the cumulative distribution). 11 | # Internally, the code creates the design on the unit hypercube and then uses 12 | # the distribution to map from [0,1] to the real parameter space. 13 | 14 | lhd = mogp_emulator.LatinHypercubeDesign([(-5., 1.), (0., 1000.)]) 15 | 16 | ################################################################################### 17 | 18 | # first example -- run entire design internally within the MICE class. 19 | 20 | # first argument is base design (required), second is simulator function (optional, 21 | # but required if you want the code to run the simualtions internally) 22 | 23 | # Other optional arguments include: 24 | # n_samples (number of sequential design steps, optional, default is not specified 25 | # meaning that you will specify when running the sequential design) 26 | # n_init (size of initial design, default 10) 27 | # n_cand (number of candidate points, default is 50) 28 | # nugget (nugget parameter for design GP, default is to set adaptively) 29 | # nugget_s (nugget parameter for candidate GP, default is 1.) 30 | 31 | n_init = 5 32 | n_samples = 20 33 | n_cand = 100 34 | 35 | md = mogp_emulator.MICEDesign(lhd, simulator, n_samples=n_samples, n_init=n_init, n_cand=n_cand) 36 | 37 | md.run_sequential_design() 38 | 39 | # get design and outputs 40 | 41 | inputs = md.get_inputs() 42 | targets = md.get_targets() 43 | 44 | print("Example 1:") 45 | print("Design inputs:\n", inputs) 46 | print("Design targets:\n", targets) 47 | print() 48 | 49 | ################################################################################### 50 | 51 | # second example: run design manually 52 | 53 | md2 = mogp_emulator.MICEDesign(lhd, n_init=n_init, n_cand=n_cand) 54 | 55 | init_design = md2.generate_initial_design() 56 | 57 | print("Example 2:") 58 | print("Initial design:\n", init_design) 59 | 60 | # run initial points manually 61 | 62 | init_targets = np.array([simulator(s) for s in init_design]) 63 | 64 | # set initial targets 65 | 66 | md2.set_initial_targets(init_targets) 67 | 68 | # run 20 sequential design steps 69 | 70 | for d in range(n_samples): 71 | next_point = md2.get_next_point() 72 | next_target = simulator(next_point) 73 | md2.set_next_target(next_target) 74 | 75 | # look at design and outputs 76 | 77 | inputs = md2.get_inputs() 78 | targets = md2.get_targets() 79 | 80 | print("Final inputs:\n", inputs) 81 | print("Final targets:\n", targets) 82 | 83 | # look at final GP emulator and make some predictions to compare with lhd 84 | 85 | lhd_design = lhd.sample(n_init + n_samples) 86 | 87 | gp_lhd = mogp_emulator.fit_GP_MAP(lhd_design, np.array([simulator(p) for p in lhd_design])) 88 | 89 | gp_mice = mogp_emulator.GaussianProcess(inputs, targets) 90 | 91 | gp_mice = mogp_emulator.fit_GP_MAP(inputs, targets) 92 | 93 | test_points = lhd.sample(10) 94 | 95 | print("LHD:") 96 | print_results(test_points, gp_lhd(test_points)) 97 | print() 98 | print("MICE:") 99 | print_results(test_points, gp_mice(test_points)) -------------------------------------------------------------------------------- /mogp_emulator/demos/projectile.py: -------------------------------------------------------------------------------- 1 | import numpy as np 2 | import scipy 3 | from scipy.integrate import solve_ivp 4 | 5 | assert scipy.__version__ >= '1.4', "projectile.py requires scipy version 1.4 or greater" 6 | 7 | # Create our simulator, which solves a nonlinear differential equation describing projectile 8 | # motion with drag. A projectile is launched from an initial height of 2 meters at an 9 | # angle of 45 degrees and falls under the influence of gravity and air resistance. 10 | # Drag is proportional to the square of the velocity. We would like to determine the distance 11 | # travelled by the projectile as a function of the drag coefficient and the launch velocity. 12 | 13 | # define functions needed for simulator 14 | 15 | def f(t, y, c): 16 | "Compute RHS of system of differential equations, returning vector derivative" 17 | 18 | # check inputs and extract 19 | 20 | assert len(y) == 4 21 | assert c >= 0. 22 | 23 | vx = y[0] 24 | vy = y[1] 25 | 26 | # calculate derivatives 27 | 28 | dydt = np.zeros(4) 29 | 30 | dydt[0] = -c*vx*np.sqrt(vx**2 + vy**2) 31 | dydt[1] = -9.8 - c*vy*np.sqrt(vx**2 + vy**2) 32 | dydt[2] = vx 33 | dydt[3] = vy 34 | 35 | return dydt 36 | 37 | def event(t, y, c): 38 | "event to trigger end of integration" 39 | 40 | assert len(y) == 4 41 | assert c >= 0. 42 | 43 | return y[3] 44 | 45 | event.terminal = True 46 | 47 | # now can define simulator 48 | 49 | def simulator_base(x): 50 | "simulator to solve ODE system for projectile motion with drag. returns distance projectile travels" 51 | 52 | # unpack values 53 | 54 | assert len(x) == 2 55 | assert x[1] > 0. 56 | 57 | c = 10.**x[0] 58 | v0 = x[1] 59 | 60 | # set initial conditions 61 | 62 | y0 = np.zeros(4) 63 | 64 | y0[0] = v0/np.sqrt(2.) 65 | y0[1] = v0/np.sqrt(2.) 66 | y0[3] = 2. 67 | 68 | # run simulation 69 | 70 | results = solve_ivp(f, (0., 1.e8), y0, events=event, args = (c,)) 71 | 72 | return results 73 | 74 | def simulator(x): 75 | "simulator to solve ODE system for projectile motion with drag. returns distance projectile travels" 76 | 77 | results = simulator_base(x) 78 | 79 | return results.y_events[0][0][2] 80 | 81 | def simulator_multioutput(x): 82 | "simulator to solve ODE system with multiple outputs" 83 | 84 | results = simulator_base(x) 85 | 86 | return (results.y_events[0][0][2], 87 | np.sqrt(results.y_events[0][0][0]**2 + results.y_events[0][0][1]**2)) 88 | 89 | # functions for printing out results 90 | 91 | def print_results(inputs, arg, var): 92 | "convenience function for printing out generic results" 93 | 94 | print("---------------------------------------------------------------------------------") 95 | 96 | for pp, m, v in zip(inputs, arg, var): 97 | print("{} {} {}".format(pp, m, v)) 98 | 99 | def print_predictions(inputs, pred, var): 100 | "convenience function for printing predictions" 101 | 102 | print("Target Point Predicted Mean Predictive Variance") 103 | print_results(inputs, pred, var) 104 | 105 | def print_errors(inputs, errors, var): 106 | "convenience function for printing out results and computing mean square error" 107 | 108 | print("Target Point Standard Error Predictive Variance") 109 | print_results(inputs, errors, var) 110 | print("Mean squared error: {}".format(np.sum(errors**2)/len(errors))) -------------------------------------------------------------------------------- /mogp_emulator/demos/tutorial.py: -------------------------------------------------------------------------------- 1 | import numpy as np 2 | from mogp_emulator.demos.projectile import simulator, print_results 3 | import mogp_emulator 4 | import mogp_emulator.validation 5 | 6 | try: 7 | import matplotlib.pyplot as plt 8 | makeplots = True 9 | except ImportError: 10 | makeplots = False 11 | 12 | # An end-to-end tutorial illustrating model calibration using mogp_emulator 13 | 14 | # First, we need to set up our experimental design. We would like our drag coefficient to be 15 | # on a logarithmic scale and initial velocity to be on a linear scale. However, our simulator 16 | # does the drag coefficient transformation for us, so we simply can specity the exponent on 17 | # a linear scale. 18 | 19 | # We will use a Latin Hypercube Design. To specify, we give the distribution that we would like 20 | # the parameter to take. By default, we assume a uniform distribution between two endpoints, which 21 | # we will use for this simulation. 22 | 23 | # Once we construct the design, can draw a specified number of samples as shown. 24 | 25 | lhd = mogp_emulator.LatinHypercubeDesign([(-5., 1.), (0., 1000.)]) 26 | 27 | n_simulations = 50 28 | simulation_points = lhd.sample(n_simulations) 29 | simulation_output = np.array([simulator(p) for p in simulation_points]) 30 | 31 | # Next, fit the surrogate GP model using MAP with the default priors 32 | # Print out hyperparameter values as correlation lengths and sigma 33 | 34 | gp = mogp_emulator.GaussianProcess(simulation_points, simulation_output, nugget="fit") 35 | gp = mogp_emulator.fit_GP_MAP(gp, n_tries=1) 36 | 37 | print("Correlation lengths = {}".format(gp.theta.corr)) 38 | print("Sigma = {}".format(np.sqrt(gp.theta.cov))) 39 | print("Nugget = {}".format(np.sqrt(gp.theta.nugget))) 40 | 41 | # Validate emulator by comparing to true simulated value and compute standard 42 | # errors 43 | # Errors are sorted with the largest variance first, idx values can be used to 44 | # similarly sort inputs or prediction results 45 | 46 | n_valid = 10 47 | validation_points = lhd.sample(n_valid) 48 | validation_output = np.array([simulator(p) for p in validation_points]) 49 | 50 | mean, var, _ = gp.predict(validation_points) 51 | 52 | errors, idx = mogp_emulator.validation.standard_errors(gp, validation_points, validation_output) 53 | 54 | print_results(validation_points[idx], errors, var[idx]) 55 | 56 | # Finally, perform history matching. Sample densely from the experimental design and 57 | # determine which points are consistent with the data using the GP predictions 58 | # We compute which points are "Not Ruled Out Yet" (NROY) 59 | 60 | n_predict = 10000 61 | prediction_points = lhd.sample(n_predict) 62 | 63 | hm = mogp_emulator.HistoryMatching(gp=gp, coords=prediction_points, obs=[2000., 400.]) 64 | 65 | nroy_points = hm.get_NROY() 66 | 67 | print("Ruled out {} of {} points".format(n_predict - len(nroy_points), n_predict)) 68 | 69 | # If plotting enabled, visualize results 70 | 71 | if makeplots: 72 | plt.figure() 73 | plt.plot(prediction_points[nroy_points,0], prediction_points[nroy_points,1], "o", label="NROY points") 74 | plt.plot(simulation_points[:,0], simulation_points[:,1],"o", label="Simulation Points") 75 | plt.plot(validation_points[:,0], validation_points[:,1],"o", label="Validation Points") 76 | plt.xlabel("log Drag Coefficient") 77 | plt.ylabel("Launch velocity (m/s)") 78 | plt.legend() 79 | plt.show() -------------------------------------------------------------------------------- /mogp_emulator/linalg/__init__.py: -------------------------------------------------------------------------------- 1 | from mogp_emulator.linalg.cholesky import cholesky_factor 2 | from mogp_emulator.linalg.linalg_utils import calc_Ainv, calc_A_deriv, calc_mean_params, calc_R, logdet_deriv 3 | -------------------------------------------------------------------------------- /mogp_emulator/tests/Makefile: -------------------------------------------------------------------------------- 1 | # Makefile for running tests for multi-output emulator problems 2 | 3 | # To get help, simply enter make into the shell to see a list of options 4 | 5 | ## help : Display this message (same as make with no argument) 6 | .PHONY : help 7 | help : Makefile 8 | @sed -n 's/^##//p' $< 9 | 10 | ## all : Run unit tests and benchmarks 11 | .PHONY: all 12 | all: tests 13 | 14 | ## tests : Run unit tests 15 | .PHONY: tests 16 | tests: 17 | pytest 18 | -------------------------------------------------------------------------------- /mogp_emulator/tests/__init__.py: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alan-turing-institute/mogp-emulator/72dc73a49dbab621ef5748546127da990fd81e4a/mogp_emulator/tests/__init__.py -------------------------------------------------------------------------------- /mogp_emulator/tests/benchmark_MICE.py: -------------------------------------------------------------------------------- 1 | ../benchmarks/benchmark_MICE.py -------------------------------------------------------------------------------- /mogp_emulator/tests/benchmark_branin.py: -------------------------------------------------------------------------------- 1 | ../benchmarks/benchmark_branin.py -------------------------------------------------------------------------------- /mogp_emulator/tests/benchmark_historymatching.py: -------------------------------------------------------------------------------- 1 | ../benchmarks/benchmark_historymatching.py -------------------------------------------------------------------------------- /mogp_emulator/tests/benchmark_kdr_GP.py: -------------------------------------------------------------------------------- 1 | ../benchmarks/benchmark_kdr_GP.py -------------------------------------------------------------------------------- /mogp_emulator/tests/benchmark_rosenbrock.py: -------------------------------------------------------------------------------- 1 | ../benchmarks/benchmark_rosenbrock.py -------------------------------------------------------------------------------- /mogp_emulator/tests/benchmark_tsunami.py: -------------------------------------------------------------------------------- 1 | ../benchmarks/benchmark_tsunami.py -------------------------------------------------------------------------------- /mogp_emulator/utils.py: -------------------------------------------------------------------------------- 1 | # -*- coding: utf-8 -*- 2 | """ 3 | Created on Wed Apr 24 05:32:45 2013 4 | 5 | @author: tisimst 6 | """ 7 | import random 8 | from copy import copy 9 | import numpy as np 10 | import scipy.stats as ss 11 | 12 | def k_fold_cross_validation(X, K, randomise=False): 13 | """ 14 | Generates K (training, validation) pairs from the items in X. 15 | 16 | Each pair is a partition of X, where validation is an iterable 17 | of length len(X)/K. So each training iterable is of length (K-1)*len(X)/K. 18 | 19 | If randomise is true, a copy of X is shuffled before partitioning, 20 | otherwise its order is preserved in training and validation. 21 | ## {{{ http://code.activestate.com/recipes/521906/ (r3) 22 | """ 23 | if randomise: 24 | X = list(X) 25 | random.shuffle(X) 26 | for k in range(K): 27 | training = [x for i, x in enumerate(X) if i % K != k] 28 | validation = [x for i, x in enumerate(X) if i % K == k] 29 | yield training, validation 30 | 31 | 32 | def integer_bisect(bound, f): 33 | """ 34 | Finds a pair of integers (a,b) such that f(a) <= 0 < f(b) and |a - b| == 1. 35 | On entry, assumes that f(bound[0]) <= 0 < f(bound[1]) 36 | """ 37 | if bound[1] - bound[0] == 1: 38 | return bound 39 | else: 40 | midpoint = round(bound[0] + bound[1] / 2.0) 41 | if f(midpoint) <= 0: 42 | return integer_bisect((midpoint, bound[1]), f) 43 | else: 44 | return integer_bisect((bound[0], midpoint), f) 45 | -------------------------------------------------------------------------------- /mogp_gpu/Makefile: -------------------------------------------------------------------------------- 1 | # Makefile for standalone C++ tests of CUDA functionality. 2 | # Note that this Makefile is NOT used when building mogp_emulator. 3 | # (The logic in setup.py that builds the Extension takes care of that). 4 | # The targets in this Makefile are mainly standalone tests of low-level functionality. 5 | # 6 | # If running on CSD3, run the following commands to ensure dependencies are in place: 7 | # 8 | # module load anaconda #(not needed here, but needed for mogp_emulator) 9 | # module load py-pybind11-2.2.4-gcc-5.4.0-tdtz6iq #(only needed for mogp_emulator) 10 | # module load cuda/11.2 11 | # module load gcc/7 12 | # module load eigen 13 | # 14 | 15 | CXX=g++ 16 | CXXFLAGS=-std=c++14 -O3 17 | NVCCFLAGS=--compiler-options -Wall,-Wextra -arch=sm_60 --generate-code arch=compute_60,code=sm_60 --generate-code arch=compute_37,code=sm_37 18 | EXTRAFLAGS=-Xcompiler "-fPIC -fopenmp" 19 | 20 | CUDA_INC=/usr/local/cuda/include 21 | PYBIND_INC=$(shell python3 -m pybind11 --includes) 22 | DLIB_INC=-I/usr/local/software/dlib/19.17/include 23 | 24 | all: lib/libgpgpu.so 25 | 26 | clean: 27 | rm -rf obj lib bin 28 | 29 | lib/libgpgpu.so: src/densegp_gpu.cu obj/cov_gpu.o obj/util.o 30 | mkdir -p lib 31 | nvcc $(CXXFLAGS) $(NVCCFLAGS) $(EXTRAFLAGS) -shared $(PYBIND_INC) $< obj/cov_gpu.o obj/util.o -o $@ -lcusolver -lcublas -lcudart 32 | 33 | obj/%.o: src/%.cu src/%.hpp 34 | mkdir -p obj 35 | nvcc $(CXXFLAGS) $(NVCCFLAGS) $(EXTRAFLAGS) -c $< -o $@ 36 | 37 | bin/test/test_gpu_basic: test/test_gpu_basic.cu obj/util.o 38 | mkdir -p bin/test 39 | nvcc $(CXXFLAGS) $(NVCCFLAGS) $< obj/util.o -o $@ 40 | 41 | bin/test/test_gpu_kernel: test/test_gpu_kernel.cu obj/kernel.o obj/util.o 42 | mkdir -p bin/test 43 | nvcc $(CXXFLAGS) $(NVCCFLAGS) $< obj/kernel.o obj/util.o -o $@ 44 | 45 | bin/test/test_gpu_utils: test/test_gpu_utils.cu obj/util.o 46 | mkdir -p bin/test 47 | nvcc $(CXXFLAGS) $(NVCCFLAGS) $< obj/util.o -o $@ 48 | 49 | bin/test/test_gpu_cholesky: test/test_gpu_cholesky.cu 50 | mkdir -p bin/test 51 | nvcc $(CXXFLAGS) $(NVCCFLAGS) -lcusolver -lcublas $< -o $@ 52 | 53 | bin/test/test_basic_fitting: test/test_basic_fitting.cu 54 | mkdir -p bin/test 55 | nvcc $(CXXFLAGS) $(NVCCFLAGS) $(DLIB_INC) -lopenblas $< -o $@ 56 | 57 | bin/test/test_meanfunc: test/test_meanfunc.cu obj/util.o 58 | mkdir -p bin/test 59 | nvcc $(CXXFLAGS) $(NVCCFLAGS) $< obj/util.o -o $@ 60 | 61 | bin/test/test_densegp_gpu: test/test_densegp_gpu.cu obj/util.o obj/kernel.o 62 | mkdir -p bin/test 63 | nvcc $(CXXFLAGS) $(NVCCFLAGS) -lcublas -lcusolver $< obj/kernel.o obj/util.o -o $@ 64 | 65 | bin/test/test_gp_fitting: test/test_gp_fitting.cu obj/util.o obj/kernel.o 66 | mkdir -p bin/test 67 | nvcc $(CXXFLAGS) $(NVCCFLAGS) $(DLIB_INC) -lopenblas -lcublas -lcusolver $< obj/kernel.o obj/util.o -o $@ 68 | 69 | bin/test/test_openmp: test/test_openmp.cu obj/util.o 70 | mkdir -p bin/test 71 | nvcc $(CXXFLAGS) $(NVCCFLAGS) $(EXTRAFLAGS) $< obj/util.o -o $@ 72 | 73 | bin/test/test_mogp_gpu: test/test_mogp_gpu.cu obj/util.o obj/kernel.o 74 | mkdir -p bin/test 75 | nvcc $(CXXFLAGS) $(NVCCFLAGS) -lcublas -lcusolver $< obj/kernel.o obj/util.o -o $@ 76 | 77 | 78 | bin/test/test_gpparams: test/test_gpparams.cu 79 | mkdir -p bin/test 80 | nvcc $(CXXFLAGS) $(NVCCFLAGS) $< -o $@ 81 | 82 | bin/test/test_gppriors: test/test_gppriors.cu 83 | mkdir -p bin/test 84 | nvcc $(CXXFLAGS) $(NVCCFLAGS) $< -o $@ 85 | 86 | .PHONY: all clean 87 | -------------------------------------------------------------------------------- /mogp_gpu/src/strided_range.hpp: -------------------------------------------------------------------------------- 1 | #ifndef STRIDED_RANGE_HPP 2 | #define STRIDED_RANGE_HPP 3 | 4 | #include 5 | #include 6 | #include 7 | #include 8 | #include 9 | #include 10 | 11 | // ---------------------------------------- 12 | // The `strided_range` class, from a portion of the file found at: 13 | // 14 | // https://github.com/thrust/thrust/blob/master/examples/strided_range.cu 15 | // 16 | // Copyright NVIDIA Corporation 17 | // 18 | // Licensed under the Apache License, Version 2.0 (the "License") 19 | // 20 | // You may obtain a copy of the License at 21 | // 22 | // http://www.apache.org/licenses/LICENSE-2.0 23 | // 24 | // Unless required by applicable law or agreed to in writing, software 25 | // distributed under the License is distributed on an "AS IS" BASIS, 26 | // WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 27 | // See the License for the specific language governing permissions and 28 | // limitations under the License. 29 | // 30 | template 31 | class strided_range 32 | { 33 | public: 34 | 35 | typedef typename thrust::iterator_difference::type difference_type; 36 | 37 | struct stride_functor : public thrust::unary_function 38 | { 39 | difference_type stride; 40 | 41 | stride_functor(difference_type stride) 42 | : stride(stride) {} 43 | 44 | __host__ __device__ 45 | difference_type operator()(const difference_type& i) const 46 | { 47 | return stride * i; 48 | } 49 | }; 50 | 51 | typedef typename thrust::counting_iterator CountingIterator; 52 | typedef typename thrust::transform_iterator TransformIterator; 53 | typedef typename thrust::permutation_iterator PermutationIterator; 54 | 55 | // type of the strided_range iterator 56 | typedef PermutationIterator iterator; 57 | 58 | // construct strided_range for the range [first,last) 59 | strided_range(Iterator first, Iterator last, difference_type stride) 60 | : first(first), last(last), stride(stride) {} 61 | 62 | iterator begin(void) const 63 | { 64 | return PermutationIterator(first, TransformIterator(CountingIterator(0), stride_functor(stride))); 65 | } 66 | 67 | iterator end(void) const 68 | { 69 | return begin() + ((last - first) + (stride - 1)) / stride; 70 | } 71 | 72 | protected: 73 | Iterator first; 74 | Iterator last; 75 | difference_type stride; 76 | }; 77 | 78 | // ---------------------------------------- 79 | 80 | template 81 | strided_range make_strided_range( 82 | Iterator first, Iterator last, 83 | typename thrust::iterator_difference::type stride) 84 | { 85 | return strided_range(first, last, stride); 86 | } 87 | 88 | #endif // STRIDED_RANGE_HPP 89 | -------------------------------------------------------------------------------- /mogp_gpu/src/types.hpp: -------------------------------------------------------------------------------- 1 | #ifndef TYPES_HPP 2 | #define TYPES_HPP 3 | 4 | #include 5 | #include 6 | #include 7 | #include 8 | #include 9 | 10 | // ---------------------------------------- 11 | // ------- Some useful typedefs for vectors and matrices 12 | 13 | typedef double REAL; 14 | typedef int obs_kind; 15 | typedef typename Eigen::Matrix mat; 16 | typedef typename Eigen::Ref > mat_ref; 17 | typedef typename Eigen::Matrix vec; 18 | typedef typename Eigen::Ref > vec_ref; 19 | 20 | /// Extract the raw pointer from a device vector 21 | template 22 | T *dev_ptr(thrust::device_vector& dv) 23 | { 24 | return dv.data().get(); 25 | } 26 | 27 | // ---------------------------------------- 28 | // enum to allow the python code to select the type of "nugget" 29 | enum nugget_type {NUG_ADAPTIVE, NUG_FIT, NUG_FIXED}; 30 | 31 | // enum to allow python code to select Kernel function 32 | enum kernel_type {SQUARED_EXPONENTIAL, MATERN52}; 33 | 34 | // enum for Prior types 35 | enum prior_type {INVGAMMA, GAMMA, LOGNORMAL, WEAK}; 36 | 37 | #endif 38 | -------------------------------------------------------------------------------- /mogp_gpu/src/util.cu: -------------------------------------------------------------------------------- 1 | #include "util.hpp" 2 | 3 | // Create an NxN Identity matrix A on the device 4 | __global__ void identity_kernel(int N, double *A) 5 | { 6 | int i = blockDim.x*blockIdx.x + threadIdx.x; 7 | int j = blockDim.y*blockIdx.y + threadIdx.y; 8 | if (i < N && j < N) A[i + N * j] = (i == j)?1.0:0.0; 9 | } 10 | 11 | void identity_device(int N, double *A) 12 | { 13 | const int Nx = 8, Ny = 8; 14 | dim3 threads_per_block(Nx, Ny); 15 | dim3 blocks((N + Nx - 1)/Nx, (N + Ny - 1)/Ny); 16 | identity_kernel<<>>(N, A); 17 | } 18 | 19 | // Add b to the diagonal of NxN matrix A 20 | __global__ void add_diagonal_kernel(int N, double b, double *A) 21 | { 22 | int i = blockDim.x*blockIdx.x + threadIdx.x; 23 | int j = blockDim.y*blockIdx.y + threadIdx.y; 24 | if (i < N && j < N && i == j) A[i + N * j] += b; 25 | } 26 | 27 | void add_diagonal(int N, double b, double *A) 28 | { 29 | const int Nx = 8, Ny = 8; 30 | dim3 threads_per_block(Nx, Ny); 31 | dim3 blocks((N + Nx - 1)/Nx, (N + Ny - 1)/Ny); 32 | add_diagonal_kernel<<>>(N, b, A); 33 | } 34 | 35 | // CUDA kernel for summing log diagonal elements of a matrix, 36 | // using cub::DeviceReduce 37 | 38 | struct LogSq : public thrust::unary_function 39 | { 40 | __host__ __device__ double operator()(double x) const { return 2.0 * log(x); } 41 | }; 42 | 43 | void sum_log_diag(int N, double *A, double *result, double *work, size_t work_size) 44 | { 45 | auto transform_it = thrust::make_transform_iterator(A, LogSq()); 46 | auto sr = make_strided_range(transform_it, transform_it + N*N, N+1); 47 | 48 | cub::DeviceReduce::Sum(work, work_size, sr.begin(), result, N); 49 | } 50 | 51 | // Implementation of trace using cub::DeviceReduce 52 | 53 | void trace(int N, double *A, double *result, double *work, size_t work_size) 54 | { 55 | auto sr = make_strided_range(A, A + N*N, N+1); 56 | cub::DeviceReduce::Sum(work, work_size, sr.begin(), result, N); 57 | } -------------------------------------------------------------------------------- /mogp_gpu/src/util.hpp: -------------------------------------------------------------------------------- 1 | #ifndef UTIL_HPP 2 | #define UTIL_HPP 3 | 4 | #include 5 | #include 6 | #include 7 | #include 8 | #include 9 | #include 10 | #include 11 | #include 12 | #include 13 | #include 14 | #include 15 | 16 | #include 17 | 18 | #include "types.hpp" 19 | #include "strided_range.hpp" 20 | 21 | #define WARP_SIZE 32 22 | #define FULL_MASK 0xffffffff 23 | 24 | // ---------------------------------------------- 25 | // ---- Utility functions --------------------- 26 | 27 | 28 | /// Fail if a recent cusolver call did not succeed 29 | inline void check_cusolver_status(cusolverStatus_t status, int info_h) 30 | { 31 | if (status || info_h) { 32 | std::string msg; 33 | std::stringstream smsg(msg); 34 | smsg << "Error in potrf: return code " << status << ", info " << info_h; 35 | throw std::runtime_error(smsg.str()); 36 | } 37 | } 38 | 39 | /// Can a usable CUDA capable device be found? 40 | inline bool have_compatible_device(void) 41 | { 42 | int device_count = 0; 43 | cudaError_t err = cudaGetDeviceCount(&device_count); 44 | 45 | return (err == cudaSuccess && device_count > 0); 46 | 47 | } 48 | // ---------------------------------------------- 49 | 50 | 51 | void identity_device(int N, double *A); 52 | void add_diagonal(int N, double b, double *A); 53 | void sum_log_diag(int N, double *A, double *result, double *work, size_t work_size); 54 | void trace(int N, double *A, double *result, double *work, size_t work_size); 55 | 56 | template 57 | inline bool instanceof(const T *ptr) { 58 | return dynamic_cast(ptr) != nullptr; 59 | } 60 | 61 | #endif 62 | -------------------------------------------------------------------------------- /mogp_gpu/test/test_densegp_gpu.cu: -------------------------------------------------------------------------------- 1 | /// Test instantiating and using a DenseGP_GPU object 2 | 3 | #include 4 | #include 5 | #include 6 | #include 7 | #include 8 | #include 9 | #include 10 | 11 | #include 12 | 13 | #include "../src/densegp_gpu.hpp" 14 | 15 | typedef double REAL; 16 | 17 | 18 | void testGP() { 19 | 20 | mat inputs(2,3); 21 | 22 | inputs << 1., 2., 3., 23 | 4., 5., 6.; 24 | vec targets(2); 25 | targets << 4., 6.; 26 | 27 | unsigned int max_batch_size = 2000; 28 | ZeroMeanFunc* meanfunc = new ZeroMeanFunc(); 29 | 30 | kernel_type kernel = SQUARED_EXPONENTIAL; 31 | // instantiate the GP 32 | DenseGP_GPU gp(inputs, targets, max_batch_size, meanfunc); 33 | vec theta = vec::Constant(gp.get_n_data(),1, -1.0); 34 | 35 | gp.fit(theta); 36 | mat x_predict(2,3); 37 | x_predict << 2., 3., 4., 38 | 7., 8., 9.; 39 | vec result(2); 40 | gp.predict_batch(x_predict, result); 41 | 42 | std::cout<<" result "<< result < 4 | #include 5 | #include 6 | #include 7 | #include 8 | #include 9 | #include 10 | 11 | #include 12 | 13 | #include "../src/fitting.hpp" 14 | #include "../src/meanfunc.hpp" 15 | 16 | typedef double REAL; 17 | 18 | 19 | void testSingleFit() { 20 | /// fit a single GP 21 | mat inputs(2,3); 22 | inputs << 1., 2., 3., 23 | 4., 5., 6.; 24 | vec targets(2); 25 | targets << 4., 6.; 26 | 27 | unsigned int max_batch_size = 2000; 28 | 29 | ZeroMeanFunc* meanfunc = new ZeroMeanFunc(); 30 | 31 | DenseGP_GPU gp(inputs, targets, max_batch_size, meanfunc); 32 | 33 | //vec theta = vec::Constant(gp.get_n_params(),1, -1.0); 34 | 35 | /// gp.fit(theta, NUG_ADAPTIVE); 36 | 37 | fit_single_GP_MAP(gp); 38 | 39 | } 40 | 41 | void testMultiFit() { 42 | // fit a MultiOutputGP 43 | std::cout< targets; 49 | 50 | vec targ0(2); 51 | targ0 << 4., 6. ; 52 | targets.push_back(targ0); 53 | vec targ1(2); 54 | targ0 << 5., 6. ; 55 | targets.push_back(targ1); 56 | 57 | unsigned int max_batch_size = 2000; 58 | // make a polynomial mean function 59 | std::vector< std::pair > dims_powers; 60 | dims_powers.push_back(std::make_pair(0,1)); 61 | dims_powers.push_back(std::make_pair(0,2)); 62 | PolyMeanFunc* meanfunc = new PolyMeanFunc(dims_powers); 63 | // instantiate the GP 64 | MultiOutputGP_GPU mgp(inputs, targets, max_batch_size, meanfunc); 65 | 66 | fit_GP_MAP(mgp); 67 | 68 | // see what parameters we now have 69 | DenseGP_GPU* em0 = mgp.get_emulator(0); 70 | std::cout<<" n params is "<get_n_params()<get_theta()<get_theta()< 2 | 3 | #include 4 | #include 5 | #include 6 | #include 7 | #include 8 | #include 9 | #include 10 | #include "../src/types.hpp" 11 | #include "../src/gpparams.hpp" 12 | 13 | typedef double REAL; 14 | 15 | void test_corr_transforms() 16 | { 17 | std::cout<<"testing corr transforms"< 2 | 3 | #include 4 | #include 5 | #include 6 | #include 7 | #include 8 | #include 9 | #include 10 | #include 11 | #include 12 | #include 13 | #include 14 | #include 15 | #include 16 | #include 17 | #include 18 | #include 19 | 20 | #include "../src/util.hpp" 21 | 22 | #define WARP_SIZE 32 23 | #define FULL_MASK 0xffffffff 24 | 25 | typedef double REAL; 26 | 27 | template 28 | T *dev_ptr(thrust::device_vector& dv) 29 | { 30 | return dv.data().get(); 31 | } 32 | 33 | 34 | void test_add_diagonal() 35 | { 36 | const size_t N=3; 37 | /// create 3x3 matrix and copy to device 38 | const double a[] = {1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 8.0, 9.0}; 39 | thrust::device_vector a_d(N*N); 40 | thrust::copy(a, a + N*N, a_d.begin()); 41 | // add b to the diagonal 42 | const REAL b = 0.5; 43 | 44 | add_diagonal(N, b, dev_ptr(a_d)); 45 | std::vector expected = { 1.5, 2.0, 3.0, 4.0, 5.5, 6.0, 7.0, 8.0, 9.5}; 46 | for (unsigned int i=0; i< a_d.size(); ++i) { 47 | std::cout<<"Element "< 2 | 3 | #include 4 | #include 5 | #include 6 | #include 7 | #include 8 | #include 9 | 10 | #include "../src/meanfunc.hpp" 11 | 12 | typedef double REAL; 13 | 14 | void test_const_meanfunc() 15 | { 16 | const size_t N=5; 17 | vec x(5); 18 | x << 1.0, 2.0, 3.0, 4.0, 5.0; 19 | 20 | vec params(1); 21 | params << 4.4; 22 | 23 | 24 | ConstMeanFunc* mf = new ConstMeanFunc(); 25 | vec mean = mf->mean_f(x,params); 26 | vec deriv = mf->mean_deriv(x,params); 27 | vec inputderiv = mf->mean_inputderiv(x,params); 28 | 29 | std::cout<<" mean: "; 30 | for (unsigned int i=0; i > dims_powers; 55 | dims_powers.push_back(std::make_pair(0,1)); 56 | dims_powers.push_back(std::make_pair(0,2)); 57 | PolyMeanFunc* mf = new PolyMeanFunc(dims_powers); 58 | vec mean = mf->mean_f(x,params); 59 | vec deriv = mf->mean_deriv(x,params); 60 | vec inputderiv = mf->mean_inputderiv(x,params); 61 | 62 | std::cout<<" mean: "; 63 | for (unsigned int i=0; i > dims_powers; 78 | dims_powers.push_back(std::make_pair(0,1)); 79 | dims_powers.push_back(std::make_pair(0,2)); 80 | // PolyMeanFunc* mf = new PolyMeanFunc(dims_powers); 81 | PolyMeanFunc mf(dims_powers); 82 | 83 | PolyMeanFunc* new_mf = mf.clone(); 84 | const size_t N=5; 85 | vec x(5); 86 | x << 1.0, 2.0, 3.0, 4.0, 5.0; 87 | 88 | vec params(3); 89 | params << 4.4, 3.3, 2.2; 90 | 91 | vec mean = new_mf->mean_f(x,params); 92 | std::cout<<" mean: "; 93 | for (unsigned int i=.0; i 2 | 3 | #include 4 | #include 5 | #include 6 | #include 7 | #include 8 | #include 9 | 10 | #include "../src/multioutputgp_gpu.hpp" 11 | #include "../src/types.hpp" 12 | 13 | typedef double REAL; 14 | 15 | void testMOGP() { 16 | mat inputs(2,3); 17 | 18 | inputs << 1., 2., 3., 19 | 4., 5., 6.; 20 | std::vector targets; 21 | 22 | vec targ0(2); 23 | targ0 << 4., 6. ; 24 | targets.push_back(targ0); 25 | vec targ1(2); 26 | targ0 << 5., 6. ; 27 | targets.push_back(targ1); 28 | vec targ2(2); 29 | targ2 << 7., 9. ; 30 | targets.push_back(targ2); 31 | 32 | unsigned int max_batch_size = 2000; 33 | // make a polynomial mean function 34 | std::vector< std::pair > dims_powers; 35 | dims_powers.push_back(std::make_pair(0,1)); 36 | dims_powers.push_back(std::make_pair(0,2)); 37 | PolyMeanFunc* meanfunc = new PolyMeanFunc(dims_powers); 38 | // instantiate the GP 39 | MultiOutputGP_GPU mgp(inputs, targets, max_batch_size); //, meanfunc); 40 | 41 | std::cout<<"Num emulators "<get_n_params(),1, -1.0); 46 | em0->fit(theta); 47 | DenseGP_GPU* em1 = mgp.get_emulator(1); 48 | em1->fit(theta); 49 | 50 | mat x_predict(2,3); 51 | x_predict << 2., 3., 4., 52 | 7., 8., 9.; 53 | mat result(3,2); 54 | mgp.predict_batch(x_predict, result); 55 | std::cout<<"result"< > dims_powers; 71 | dims_powers.push_back(std::make_pair(0,1)); 72 | dims_powers.push_back(std::make_pair(0,2)); 73 | PolyMeanFunc* mf = new PolyMeanFunc(dims_powers); 74 | vec mean = mf->mean_f(x,params); 75 | vec deriv = mf->mean_deriv(x,params); 76 | vec inputderiv = mf->mean_inputderiv(x,params); 77 | 78 | std::cout<<" mean: "; 79 | for (unsigned int i=0; i 2 | #include 3 | #include 4 | 5 | #define THREAD_NUM 4 6 | 7 | int main() 8 | { 9 | 10 | omp_set_num_threads(THREAD_NUM); // set number of threads in "parallel" blocks 11 | #pragma omp parallel 12 | { 13 | // usleep(5000 * omp_get_thread_num()); // do this to avoid race condition while printing 14 | std::cout << "Number of available threads: " << omp_get_num_threads() << std::endl; 15 | // each thread can also get its own number 16 | std::cout << "Current thread number: " << omp_get_num_threads() << std::endl; 17 | std::cout << "Hello, World!" << std::endl; 18 | } 19 | 20 | return 0; 21 | 22 | } -------------------------------------------------------------------------------- /requirements-dev.txt: -------------------------------------------------------------------------------- 1 | pytest>=4.6 2 | pytest-cov 3 | -------------------------------------------------------------------------------- /requirements-optional.txt: -------------------------------------------------------------------------------- 1 | matplotlib 2 | -------------------------------------------------------------------------------- /requirements.txt: -------------------------------------------------------------------------------- 1 | numpy>=1.13.3 2 | scipy>=1.4 3 | patsy 4 | --------------------------------------------------------------------------------