farhanferoz / multinest

MultiNest is a Bayesian inference tool which calculates the evidence and explores the parameter space which may contain multiple posterior modes and pronounced (curving) degeneracies in moderately high dimensions.

MultiNest

MultiNest Farhan Feroz, Mike Hobson [email protected] arXiv:0704.3704, arXiv:0809.3437 & arXiv:1306.2144 Released Nov 2019

---

MultiNest Licence

Users are required to accept to the licence agreement given in LICENCE file.

Users are also required to cite the MultiNest papers (arXiv:0704.3704, arXiv:0809.3437 & arXiv:1306.2144) in their publications.

---

Required Libraries:

MultiNest requires lapack. To use MPI support, some MPI library must also be installed.

---

MPI Support:

The code is MPI compatible. In order to disable the MPI parallelization, remove -DMPI compilation flag.

---

gfortran compiler:

You might need to use the following flag while compiling MultiNest with gfortran compiler to remove the restriction imposed by gfortran on line length.

-ffree-line-length-none

---

The subtoutine to begin MultiNest are as follows:

subroutine nestRun(IS, mmodal, ceff, nlive, tol, efr, ndims, nPar, nCdims, maxModes, updInt, Ztol, root, seed, pWrap, feedback, resume, outfile, initMPI, logZero, maxiter, loglike, dumper, context)

logical IS !do Importance Nested Sampling (INS)?

logical mmodal !do mode separation?

integer nlive !number of live points

logical ceff !run in constant efficiency mode

double precision tol !evidence tolerance factor

double precision efr !sampling efficiency

integer ndims !number of dimensions

integer nPar !total no. of parameters

integer nCdims !no. of parameters on which clustering should be performed (read below)

integer maxModes !maximum no. of modes (for memory allocation)

integer updInt !iterations after which the output files should be written

double precision Ztol !null log-evidence (read below)

character(LEN=1000) root !root for MultiNest output files

integer seed !random no. generator seed, -ve value for seed from the sys clock

integer pWrap[ndims] !wraparound parameters?

logical feedback !need update on sampling progress?

logical resume !resume from a previous run?

logical outfile !write output files?

logical initMPI !initialize MPI routines?, relevant only if compiling with MPI. Set it to F if you want your main program to handle MPI initialization

double precision logZero !points with loglike < logZero will be ignored by MultiNest

integer maxiter !max no. of iterations, a non-positive value means infinity. MultiNest will terminate if either it has done max no. of iterations or convergence criterion (defined through tol) has been satisfied

loglike(Cube,ndims,nPar,lnew) !subroutine which gives lnew=loglike(Cube(ndims))

dumper(nSamples,nlive,nPar,physLive,posterior, paramConstr,maxloglike,logZ,INSlogZ,logZerr,c) !subroutine called after every updInt*10 iterations with the posterior distribution, parameter constraints, max loglike & log evidence values integer context. Not required by MultiNest, any additional information user wants to pass

---

likelihood routine: slikelihood(Cube,ndims,nPar,lnew,context)

Cube(1:nPar) has nonphysical parameters.

Scale Cube(1:n_dim) & return the scaled parameters in Cube(1:n_dim) & additional parameters that you want to be returned by MultiNest along with the actual parameters in Cube(n_dim+1:nPar).

Return the log-likelihood in lnew.

---

Dumper routine: dumper(nSamples,nlive,nPar,physLive,posterior,paramConstr,maxloglike,logZ,INSlogZ,logZerr,context)

This routine is called after every updInt*10 iterations & at the end of the sampling allowing the posterior distribution & parameter constraints to be passed on to the user in the memory. The argument are as follows:

nSamples = total number of samples in posterior distribution

nlive = total number of live points

nPar = total number of parameters (free + derived)

physLive(nlive, nPar+1) = 2D array containing the last set of live points (physical parameters plus derived parameters) along with their loglikelihood values

posterior(nSamples, nPar+2) = posterior distribution containing nSamples points. Each sample has nPar parameters (physical + derived) along with the their loglike value & posterior probability

paramConstr(1, 4nPar): paramConstr(1, 1) to paramConstr(1, nPar) = mean values of the parameters paramConstr(1, nPar+1) to paramConstr(1, 2nPar) = standard deviation of the parameters paramConstr(1, nPar2+1) to paramConstr(1, 3nPar) = best-fit (maxlike) parameters paramConstr(1, nPar4+1) to paramConstr(1, 4nPar) = MAP (maximum-a-posteriori) parameters

maxLogLike = maximum loglikelihood value

logZ = log evidence value from the default (non-INS) mode

INSlogZ = log evidence value from the INS mode

logZerr = error on log evidence value

context= not required by MultiNest, any additional information user wants to pass

The 2D arrays are Fortran arrays which are different to C/C++ arrays. In the example dumper routine provided with C & C++ eggbox examples, the Fortran arrays are copied on to C/C++ arrays.

---

Tranformation from hypercube to physical parameters:

MultiNest native space is unit hyper-cube in which all the parameter are uniformly distributed in [0, 1]. User is required to transform the hypercube parameters to physical parameters. This transformation is described in Sec 5.1 of arXiv:0809.3437. The routines to tranform hypercube parameters to most commonly used priors are provided in module priors (in file priors.f90).

---

Checkpointing:

MultiNest is able to checkpoint. It creates [root]resume.dat file & stores information in it after every updInt iterations to checkpoint, where updInt is set by the user. If you don't want to resume your program from the last run run then make sure that you either delete [root]resume.dat file or set the parameter resume to F before starting the sampling.

---

Periodic Boundary Conditions:

In order to sample from parameters with periodic boundary conditions (or wraparound parameters), set pWrap[i], where i is the index of the parameter to be wraparound, to a non-zero value. If pWrap[i] = 0, then the ith parameter is not wraparound.

---

Constant Efficiency Mode:

If ceff is set to T, then the enlargement factor of the bounding ellipsoids are tuned so that the sampling efficiency is as close to the target efficiency (set by efr) as possible. This does mean however, that the evidence value may not be accurate.

---

Sampling Parameters:

The recommended paramter values to be used with MultiNest are described below. For detailed description please refer to the paper arXiv:0809.3437

nPar:

Total no. of parameters, should be equal to ndims in most cases but if you need to store some additional parameters with the actual parameters then you need to pass them through the likelihood routine.

efr:

defines the sampling efficiency. 0.8 and 0.3 are recommended for parameter estimation & evidence evalutaion respectively.

tol:

A value of 0.5 should give good enough accuracy.

nCdims:

If mmodal is T, MultiNest will attempt to separate out the modes. Mode separation is done through a clustering algorithm. Mode separation can be done on all the parameters (in which case nCdims should be set to ndims) & it can also be done on a subset of parameters (in which case nCdims < ndims) which might be advantageous as clustering is less accurate as the dimensionality increases. If nCdims < ndims then mode separation is done on the first nCdims parameters.

Ztol:

If mmodal is T, MultiNest can find multiple modes & also specify which samples belong to which mode. It might be desirable to have separate samples & mode statistics for modes with local log-evidence value greater than a particular value in which case Ztol should be set to that value. If there isn't any particularly interesting Ztol value, then Ztol should be set to a very large negative number (e.g. -1.d90).

---

Progress Monitoring:

MultiNest produces [root]phys_live.dat & [root]ev.dat files after every updInt iterations which can be used to monitor the progress. The format & contents of these two files are as follows:

[root]phys_live.dat:

This file contains the current set of live points. It has nPar+2 columns. The first nPar columns are the ndim parameter values along with the (nPar-ndim) additional parameters that are being passed by the likelihood routine for MultiNest to save along with the ndim parameters. The nPar+1 column is the log-likelihood value & the last column is the node no. (used for clustering).

[root]ev.dat:

This file contains the set of rejected points. It has nPar+3 columns. The first nPar columns are the ndim parameter values along with the (nPar-ndim) additional parameters that are being passed by the likelihood routine for MultiNest to save along with the ndim parameters. The nPar+1 column is the log-likelihood value, nPar+2 column is the log(prior mass) & the last column is the node no. (used for clustering).

---

Posterior Files:

These files are created after every updInt*10 iterations of the algorithm & at the end of sampling.

MultiNest will produce five posterior sample files in the root, given by the user, as following

[root].txt

Compatable with getdist with 2+nPar columns. Columns have sample probability, -2*loglikehood, parameter values. Sample probability is the sample prior mass multiplied by its likelihood & normalized by the evidence.

[root]post_separate.dat

This file is only created if mmodal is set to T. Posterior samples for modes with local log-evidence value greater than Ztol, separated by 2 blank lines. Format is the same as [root].txt file.

[root]stats.dat

Contains the global log-evidence, its error & local log-evidence with error & parameter means & standard deviations as well as the best fit & MAP parameters of each of the mode found with local log-evidence > Ztol.

[root]post_equal_weights.dat

Contains the equally weighted posterior samples. Columns have parameter values followed by loglike value.

[root]summary.txt

There are nmode+1 (nmode = number of modes) rows in this file. First row has the statistics for the global posterior. After the first line there is one row per mode with nPar*4+2 values in each line in this file. Each row has the following values in its column mean parameter values, standard deviations of the parameters, bestfit (maxlike) parameter values, MAP (maximum-a-posteriori) parameter values, local log-evidence, maximum loglike value. If IS = T (i.e. INS being used), first row has an additional value right at the end, INS log-evidence estimate.

---

INS Output Files:

In INS mode (when IS = T), MultiNest will produce 3 additional binary files: [root]IS.iterinfo, IS.points, IS.ptprob These files are used for resuming job with IS (Importance Nested sampling) mode set to T. They can be quite large and can be deleted once the job has finished.

---

Birth contour files:

MultiNest produces [root]phys_live-birth.txt & [root]dead-birth.txt files after every updInt iterations which can be used to reconstruct a full nested sampling run, as well as simulate dynamic nested sampling. The format & contents of these two files are as follows:

[root]phys_live-birth.txt:

This file contains the current set of live points. It has nPar+3 columns. The first nPar columns are the ndim parameter values along with the (nPar-ndim) additional parameters that are being passed by the likelihood routine for MultiNest to save along with the ndim parameters. The nPar+1 column is the log-likelihood value. The nPar+2 column is the log-likelihood value that the point was born at & the last column is the node no. (used for clustering). This is identical to the [root]phys_live-birth.dat file, except for an additional column including the birth contours

[root]dead-birth.txt:

This file contains the set of rejected points. It has nPar+4 columns. The first nPar columns are the ndim parameter values along with the (nPar-ndim) additional parameters that are being passed by the likelihood routine for MultiNest to save along with the ndim parameters. The nPar+1 column is the log-likelihood value, the nPar+2 column is the log-likelihood value that the point was born at and the nPar+2 column is the log(prior mass) & the last column is the node no. (used for clustering). This is identical to the [root]ev.dat file, except for an additional column including the birth contours.

---

C/C++ Interface:

Starting in MultiNest v2.18 there is a common C/C++ interface to MultiNest. The file is located in the "includes" directory. Examples of how it may be used are found in the example_eggboxC and example_eggboxC++ directories.

You may need to check the symbol table for your platform (nm libmulitnest.a | grep nestrun) and edit the multinest.h file to define NESTRUN. Please let us know of any modifications made so they may be included in future releases.

---

Python Interface:

Johannes Buchner has written an easy-to-use Python interface to MultiNest called PyMultiNest which provides integration with existing scientific Python code (numpy, scipy). It allows you to write Prior & likelihood functions in Python. It is available from:

https://github.com/JohannesBuchner/PyMultiNest

---

R Interface:

Johannes Buchner has written an R bridge for MultiNest called RMultiNest. It allows likelihood functions written in R (http://www.r-project.org) to be used by MultiNest. It is available from:

https://github.com/JohannesBuchner/RMultiNest

---

Matlab version of MultiNest:

Matthew Pitkin and Joe Romano have created a simple Matlab version of MultiNest. It doesn't have all the bells-and-whistles of the full implementation and just uses the basic Algorithm 1 from arXiv:0809.3437. It is available for download the MultiNest website:

http://ccpforge.cse.rl.ac.uk/gf/project/multinest/

---

Visualization of MultiNest Output:

[root].txt file created by MultiNest is compatable with the format required by getdist package which is part of CosmoMC package. Refer to the following website in order to download or get more information about getdist: http://cosmologist.info/cosmomc/readme.html#Analysing

Johannes Buchner's PyMultiNest can also be used on exisiting MultiNest output to plot & visualize results. https://github.com/JohannesBuchner/PyMultiNest

---

Toy Problems

There are 8 toy programs included with MultiNest.

example_obj_detect:

The object detection problem discussed in arXiv:0704.3704. The positions, amplitudes & widths of the Gaussian objects can be modified through params.f90 file. Sampling parameters are also set in params.f90.

example_gauss_shell:

The Gaussian shells problem discussed in arXiv:0809.3437. The dimensionality, positions and thickness of these shells can be modified through params.f90 file. Sampling parameters are also set in params.f90.

example_gaussian:

The Gaussian shells problem discussed in arXiv:1001.0719. The dimensionality of the problem can be modified through params.f90 file. Sampling parameters are also set in params.f90.

example_eggboxC/example_eggboxC++:

The C/C++ interface includes the egg box problem discussed in arXiv:0809.3437. The toy problem and sampling parameters are set in eggbox.c & eggbox.cc files.

example_ackley:

The Ackley mimimization problem (see T. Bäck, Evolutionary Algorithms in Theory and Practice, Oxford University Press, New York (1996).)

example_himmelblau:

The Himmelblau's minimization problem. (see http://en.wikipedia.org/wiki/Himmelblau's_function)

example_rosenbrock:

Rosenbrock minimization problem. (see http://en.wikipedia.org/wiki/Rosenbrock_function)

example_gaussian:

Multivariate Gaussian with uncorrelated paramters.

---

Common Problems & FAQs:

1. MultiNest crashes after segmentation fault.

Try increasing the stack size (ulimit -s unlimited on Linux) & resume your job.

2. Output files (.txt & post_equal_weights.dat) files have very few (of order tens) points.

If tol is set to a reasonable value (tol <= 1) & the job hasn't finished then it is possible for these files to have very few points in them. If even after the completion of job these files have very few points then increase the stack size (ulimit -s unlimited on Linux) & resume the job again.

3. Not all modes are being reported in the stats file.

stats file reports all the modes with local log-evidence value greater than Ztol. Set Ztol to a very large negative number (e.g. -1.d90) in order for the stats file to report all the modes found.

4. Compilation fails with error something like 'can not find nestrun function'.

Check the symbol table for your platform (nm libnest3.a | grep nestrun) & edit multinest.h file to define NESTRUN appropriately.

5. When to use the constant efficiency mode?

If the sampling efficiency with the standard MultiNest (when ceff = F) is very low & no. of free parameters is relatively high (roughly greater than 30) then constant efficiency mode can be used to get higher sampling efficiency. Users should use ask for around 5% or lower targer efficiency (efr <= 0.05) in constant efficiency mode & ensure that posteriors are stable when a slightly lower value is used for target efficiency. Evidence values obtained with constant efficiency mode will not be accurate in the default mode (IS = F). With INS (IS = T) accurate evidences can be calculated (read arXiv:1306.2144) for more details.

---

Importance Nested Sampling:

Sampling Parameters:

INS can calculate an order of magnitude more accurate evidence values than the vanilla nested sampling, for the same number of live points & target efficiency (efr). INS can also calculate reasonably accurate evidence values in constant efficiency mode (when ceff = T). However, users should always check that the posterior distributions & evidence values are stable for reasonable change in these sampling parameters. Potentially users can use fewer live points &/or higher target efficiency (efr) with INS to get the same level of accuracy on evidence & therefore analysis can be sped-up.

Quoted Error on Log-Evidence:

The quoted error on log-evidence in INS mode is generally an overestimate. Users should use the quoted error on log-evidence from vanilla nested sampling as an upper bound on the error on INS log-evidence.

Output Files:

In INS mode, MultiNest will produce 3 additional binary output files (see output files section) in which it will record information about all the points it has collected. These files can be quite large. It is recommended that the user sets updint parameter (which sets the number of iterations after which posterior files are updated) to 1000 or more otherwise a lot of time might be wasted in writing these large files. These binary files are only used while resuming jobs & can be deleted once the job has finished.

Memory Requirements:

INS requires a lot more memory than the defult mode (when IS = F). With nlive <= 1000, memory requirements are feasible on modern computers but with nlive >= 4000, segfaults may results due to not enough memory available.

Multi-Modal Mode:

Multi-modal mode is not supported yet when IS = T. If mmodal = T along with IS = T, MultiNest will set mmodal = F.

---

multinest's Issues

MKL FATAL ERROR

Dear Farhan,

I am trying to use MultiNest, built-in in BSMArts (Goodsell et al) , for a scan of a model parameter space.
I am using an OpenMPI module for the MPI executables . OpenMPI is working fine for another in-built
scanner like 'Diver'. The other module that I loaded for my purpose is gcc-v8.2.

The scan is aborting after running for a while by spitting out the following on the screen (pl see below).
I tried several proposed fixes that I found on the Internet, but to no avail.

Could you please help.

I am also pasting below the "cmake" output (while building MultiNest by hand within BSMArt;
the MultiNest MPI libraries are NOT being automatically built while building BSMArt) for your
kind reference.

Best regards.
Asesh K Datta

---

time mpiexec -n 16 python3 -m mpi4py ../BSMArt_v1.01/bin/BSMArt input-file

::::::::::::::::::::::::::::::::::::
::::::::::::::::::::::::::::::::::::
By M. Goodsell and A. Joury (R. Moutafis)
Version 1.01 [14 January 2023]

MultiNest Warning: no resume file found, starting from scratch

---

MultiNest v3.12
Copyright Farhan Feroz & Mike Hobson
Release Nov 2019

no. of live points = 5
dimensionality = 2

---

Intel MKL FATAL ERROR: Cannot load libmkl_avx2.so or libmkl_def.so.

Primary job terminated normally, but 1 process returned
a non-zero exit code. Per user-direction, the job has been aborted.

---

mpirun detected that one or more processes exited with non-zero status, thus causing
the job to be terminated. The first process to do so was:

Process name: [[10443,1],0]
Exit code: 1

==============================================================

[asesh@ws2 build]$FC=mpif90 CC=mpicc CXX=mpicxx cmake ..
CMake Deprecation Warning at CMakeLists.txt:1 (cmake_minimum_required):
Compatibility with CMake < 2.8.12 will be removed from a future version of
CMake.

Update the VERSION argument value or use a ... suffix to tell
CMake that the project does not need compatibility with older versions.

-- The Fortran compiler identification is GNU 8.2.0
-- The C compiler identification is GNU 8.2.0
-- The CXX compiler identification is GNU 8.2.0
-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - done
-- Check for working Fortran compiler: /ws2scratch/pkg/openmpi-4.1.4/bin/mpif90 - skipped
-- Checking whether /ws2scratch/pkg/openmpi-4.1.4/bin/mpif90 supports Fortran 90
-- Checking whether /ws2scratch/pkg/openmpi-4.1.4/bin/mpif90 supports Fortran 90 - yes
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /ws2scratch/pkg/openmpi-4.1.4/bin/mpicc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /ws2scratch/pkg/openmpi-4.1.4/bin/mpicxx - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Deprecation Warning at src/CMakeLists.txt:1 (cmake_minimum_required):
Compatibility with CMake < 2.8.12 will be removed from a future version of
CMake.

Update the VERSION argument value or use a ... suffix to tell
CMake that the project does not need compatibility with older versions.

-- Looking for Fortran sgemm
-- Looking for Fortran sgemm - not found
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE
-- Looking for Fortran sgemm
-- Looking for Fortran sgemm - found
-- Found BLAS: /opt/ICS_2013/composer_xe_2013_sp1.2.144/mkl/lib/intel64/libmkl_gf_lp64.so;/opt/ICS_2013/composer_xe_2013_sp1.2.144/mkl/lib/intel64/libmkl_gnu_thread.so;/opt/ICS_2013/composer_xe_2013_sp1.2.144/mkl/lib/intel64/libmkl_core.so;/opt/gcc-8.2/lib64/libgomp.so;-lm;-ldl
-- Looking for Fortran cheev
-- Looking for Fortran cheev - found
-- Found LAPACK: /opt/ICS_2013/composer_xe_2013_sp1.2.144/mkl/lib/intel64/libmkl_gf_lp64.so;/opt/ICS_2013/composer_xe_2013_sp1.2.144/mkl/lib/intel64/libmkl_gnu_thread.so;/opt/ICS_2013/composer_xe_2013_sp1.2.144/mkl/lib/intel64/libmkl_core.so;/opt/gcc-8.2/lib64/libgomp.so;-lm;-ldl;-lm;-ldl
-- Detected gfortran, adding -ffree-line-length-none compiler flag.
-- Found MPI_C: /ws2scratch/pkg/openmpi-4.1.4/bin/mpicc (found version "3.1")
-- Found MPI_CXX: /ws2scratch/pkg/openmpi-4.1.4/bin/mpicxx (found version "3.1")
-- Found MPI_Fortran: /ws2scratch/pkg/openmpi-4.1.4/bin/mpif90 (found version "3.1")
-- Found MPI: TRUE (found version "3.1")
CMake Deprecation Warning at src/example_ackley/CMakeLists.txt:1 (cmake_minimum_required):
Compatibility with CMake < 2.8.12 will be removed from a future version of
CMake.

Update the VERSION argument value or use a ... suffix to tell
CMake that the project does not need compatibility with older versions.

CMake Deprecation Warning at src/example_eggbox_C/CMakeLists.txt:1 (cmake_minimum_required):
Compatibility with CMake < 2.8.12 will be removed from a future version of
CMake.

Update the VERSION argument value or use a ... suffix to tell
CMake that the project does not need compatibility with older versions.

CMake Deprecation Warning at src/example_eggbox_C++/CMakeLists.txt:1 (cmake_minimum_required):
Compatibility with CMake < 2.8.12 will be removed from a future version of
CMake.

Update the VERSION argument value or use a ... suffix to tell
CMake that the project does not need compatibility with older versions.

CMake Deprecation Warning at src/example_gaussian/CMakeLists.txt:1 (cmake_minimum_required):
Compatibility with CMake < 2.8.12 will be removed from a future version of
CMake.

Update the VERSION argument value or use a ... suffix to tell
CMake that the project does not need compatibility with older versions.

CMake Deprecation Warning at src/example_gauss_shell/CMakeLists.txt:1 (cmake_minimum_required):
Compatibility with CMake < 2.8.12 will be removed from a future version of
CMake.

Update the VERSION argument value or use a ... suffix to tell
CMake that the project does not need compatibility with older versions.

CMake Deprecation Warning at src/example_himmelblau/CMakeLists.txt:1 (cmake_minimum_required):
Compatibility with CMake < 2.8.12 will be removed from a future version of
CMake.

Update the VERSION argument value or use a ... suffix to tell
CMake that the project does not need compatibility with older versions.

CMake Deprecation Warning at src/example_obj_detect/CMakeLists.txt:1 (cmake_minimum_required):
Compatibility with CMake < 2.8.12 will be removed from a future version of
CMake.

Update the VERSION argument value or use a ... suffix to tell
CMake that the project does not need compatibility with older versions.

CMake Deprecation Warning at src/example_rosenbrock/CMakeLists.txt:1 (cmake_minimum_required):
Compatibility with CMake < 2.8.12 will be removed from a future version of
CMake.

Update the VERSION argument value or use a ... suffix to tell
CMake that the project does not need compatibility with older versions.

-- Configuring done
-- Generating done
-- Build files have been written to: /ws2scratch/asesh/HEPTools-18032023/MultiNest-master/MultiNest_v3.12_CMake/multinest/build

[asesh@ws2 build]$make
:::::::::::::::::::::::::::::::::::::::::::::::
:::::::::::::::::::::::::::::::::::::::::::::::
[ 92%] Built target obj_detect
Scanning dependencies of target rosenbrock
[ 94%] Building Fortran object src/example_rosenbrock/CMakeFiles/rosenbrock.dir/params.f90.o
[ 95%] Building Fortran object src/example_rosenbrock/CMakeFiles/rosenbrock.dir/like.f90.o
[ 97%] Building Fortran object src/example_rosenbrock/CMakeFiles/rosenbrock.dir/nestwrap.f90.o
[ 98%] Building Fortran object src/example_rosenbrock/CMakeFiles/rosenbrock.dir/main.f90.o
[100%] Linking Fortran executable ../../../bin/rosenbrock
[100%] Built target rosenbrock
[asesh@ws2 build]$

cmake version number bump

Presumably this should be 3.12?

MultiNest/MultiNest_v3.12_CMake/multinest/CMakeLists.txt

Line 13 in ba3e7d8

SET(MultiNest_VERSION "3.11")

restart earlier?

There was an error during the run time when the disk was full. Therefore, files that should be outputted and would be needed for calculating the likelihood were not created properly, leading the program to crash and eventually MultiNest to crash as well.

I'd like to restart the sampler but this error has lead to some points being written into the output files with a log-evidence being some random number (e.g. 0.60821407-291). It also leads to wrong statistics in the stats and summary files (and potentially the IS files). Could you please help me figure out a way to restart MultiNest from an earlier time or tell me how to delete the parameter sets that have been affected by this error? I could delete those points with random log-evidence, but I'm not sure how to do it with the IS files.

I've posted this on PyMultiNest repo and was informed that I might need to ask MultiNest developers about how to alter resume.dat. Here is one example of the file.

F
6030 8898 1 1600
-0.115342802692509476E+02 -0.897317674491690020E+01
T
0
T F 0 1600
0.631732074795355314E-01 -0.115342802692509476E+02 -0.897317674491690020E+01

Thanks!

"resume" file names get truncated with no error raised

Hello! I've run into an issue where if the multinest output file name base is longer than 100 characters, they just get truncated. I ran into this when running on a computing cluster where I was outputting to a scratch directory with a long path name, and it ended up trimming off the suffix of all the output files that I would have used to resume the multinest run if it got stopped early. This prevented me from being able to resume the job. It would be helpful to add a check so that the code would raise an error or warning if the output file base is going to be too long.

MultiNest gives erroneous posterior weights when outfile=0

This is only urgent if someone is running MultiNest 3.11/3.12 with the output files turned off (outfile=0). In such a case, posterior weights passed into the dumper function will be erroneous. In my experience, this resulted in either abnormally thin or multi-modal posteriors. This occurs because in version 3.11/3.12 an extra column was added to a data array (line 2354-2360 in nested.F90)

					!data for ev.dat file
					j1=mod(sff-1,updInt)+1
					evData(j1,1:totPar)=lowphyP(1:totPar)
					evData(j1,totPar+1)=lowlike
					evData(j1,totPar+2)=lowl0            !<-- Added column, not in version 3.10
					evData(j1,totPar+3)=log(h)
					evData(j1,totPar+4)=dble(nd)

When this data array is saved to "ev.dat" (the file that is used to calculate the posteriors weights for the dumper function when outfile=1) this column is skipped and thus has no effect on the posterior weight calculation. But, when the output files are turned off (outfile=0) then the posteriors weights are calculated directly from this array. Unfortunately, when this happens, the added column is not skipped and, because of this, "log(h)" is replaced with "lowl0" when calculating the posterior weights. Locally, I fixed this by having the algorithm also skip this column when this array is used to calculate posterior weights. I replaced the line (line 165 in posterior.F90):

 			ltmp(1:nPar+2)=evDataAll((i-1)*(nPar+4)+1:(i-1)*(nPar+4)+nPar+2)

with

 			ltmp(1:nPar+1)=evDataAll((i-1)*(nPar+4)+1:(i-1)*(nPar+4)+nPar+1)
 			ltmp(nPar+2)=evDataAll((i-1)*(nPar+4)+nPar+3)

This seemed to fix the problem.

MAP and maximum likelihood parameters identical in all modes

In one of my MultiNest runs four modes were found, and the maximum likelihood and MAP parameter vector was reported to be exactly the same in all of them. Could there be an issue with the numbers printed in the stats file, or is it normal? None of the local MAP vectors matches the global MAP vector that is reported in the summary file. In my all other runs (with very similar models) maximum likelihood and MAP parameters are never exactly the same, and the global MAP vector is just one of the mode-specific MAP vectors.

Here the stats and summary files for this run:
run1_nlive10k_eff0p3_noCONST_MMon_noIS_tol-1stats.txt
run1_nlive10k_eff0p3_noCONST_MMon_noIS_tol-1summary.txt

Type and rank mismatch errors when compiling with gcc 10

Hi @farhanferoz, thanks a lot for offering this great tool.

When compiling MultiNest with gcc version 10, I got the following errors about type and rank mismatches:

error.log

I could solve the issue by downgrading gcc version to 9.3.0 in which case the errors did not appear.

Output file missing E with numbers smaller than 10^-101

Version 3.12-3 from AUR
Running from nmma
After lines

Sampling finished. Exiting MultiNest
     analysing data from tmp/...../.txt

From pymultinest
The file it mentions contains numbers very close to 0 in 2nd column
Instead of ending with E-308, the numbers look like -0.13905330402186892-308
This causes severe indigestion in numpy preventing further analysis of the data

Seems like Fortran default 2 digits exponent cannot handle this, so replacing your formats with E28.18E3 will solve this issue