Inconsistent dimensions of output quantities

[Martin Modrák]

This is a minor bug (probably - maybe I am misssing something) found during review for JOSS.

In SamplingAlgorithms/MCMC/Example3_MultilevelGaussianSampling/MultilevelGaussianSampling.cpp when I call SLMCMC::WriteToFile, the stored samples array has dimension NumSamples x 2, while the stored QOIs have dimension NumSamples - 1 x 2

In SamplingAlgorithms/MCMC/Example2_GaussianInverseGamma when I call SampleCollection::WriteToFile, the stored samples array has dimension NumSamples - BurnIn + 1 x 3. So it is unclear when I actually get only post-burnin samples and when I get all samples. The +/- 1 also looks a bit fishy.

[Matthew Parno]

@Linus Seelinger Could you take a look at this? Thanks!

[Linus Seelinger]

Thanks for pointing this out!

Example3 does not set a burnin, so defaults to zero. When you specify a burnin, it behaves as you see in example2. SLMCMC directly passes given parameters to the underlying SingleChainMCMC, so should behave identically. So that should all be fine.

About the missing QOI, for a starting point in a chain we currently don’t evaluate the target density and quantity of interest (which is why it’s missing in the hdf5). When using a burnin, the starting point is not written out, so that is not visible. So I think the main question is: Do we really want to write the starting point at all @Matthew Parno ? Or should we write target density and QOI for the starting point? In the latter case we’d have to keep the SamplingProblem in SingleChainMCMC as well, currently it’s only kept in the kernel.

‌

[Matthew Parno]

Thanks @Linus Seelinger !

I think we just need to be consistent between what get’s saved by SLMCMC::WriteToFile and SampleCollection::WriteToFile. Currently, the SampleCollection::WriteToFile function should save the samples in a DxN matrix, where D is the dimension of the parameter and N=(NumSamps-BurnIn)*NumBlocks + 1. (The +1 comes from including x0 or samp[burnIn]). The QoI matrix saved by SampleCollection::WriteToFile should have the same number of columns as the sample matrix, but with NaNs for columns that don’t have QoI metadata (e.g., x0). Is this what the SLMCMC::WriteToFile function is doing?

I think it makes sense to store the initial point x0 in the SampleCollection when burnIn==0. It makes it easy to see exactly where the chain was started. What do you think?