CosmoMC (November 2013): updating proposal matrix, matrix not invertible?

[Brent Follin]

I'm running a chain with two additional parameters I've added to the InitPower vector to parameterize changes to the primordial spectrum, and I keep getting singular matrix errors when cosmomc tries to update the proposal density:

Chain1, MPI done 'burn', Samples =2730, like = 14994.76
Time: 2347.97304701805 output lines= 67
MPI_Min_Sample_Update 138 2730
1 all_burn done
1 DoUpdates
Chain 1 MPI communicating
updating proposal density
Matrix_Cholesky: not positive definite 5
MpiStop: 0
application called MPI_Abort(MPI_COMM_WORLD, 1) - process 0

I'm using the same settings as test.ini, with the only changes being (a) priors for the two new parameters, and (b) switching to vanilla Metropolis-Hastings, though fast/slow also causes the error.

I've checked the following things, which have been of little help:

• 1. The variation in each parameter (the 20 in vanilla CosmoMC + the 2 I added) are all nonzero.
  2. I've changed the initial propose matrix, and turned it off, to no avail.
  3. I've varied the priors on both parameters I added, also to no effect.
  4. Turning off proposal update of course bypasses the error, and in this case all other aspects of the chain (other than convergence) work beautifully. This seems to rule out any obvious stupidity in the way I changed cosmomc.
  5. I've also tried re-purposing r and n_t (and manually setting the tensor power to 0), to eliminate the need to add new parameters in the fear that's what's caused the problem. I get the same error message.
  6. Of course, running vanilla CosmoMC on LCDM works fine.

Any ideas what I've accidentally messed up?

[Antony Lewis]

I would look at your output chains, make sure .paramnames match values as you'd expect, and mabe plot the two new parameters against each other to see if something obvious is going wrong.
You can also change the settings to increase number of samples before attempting to update.

[Brent Follin]

Thanks for the response!

The only thing odd I've found when doing that is that the chain is obviously far from the best-fit point, and is still falling into the max-likelihood region (and has obviously not converged). Also, one of the two parameters is up against the lower edge of the prior, which I expect. It does vary, though, so I don't understand how either of these things could cause problems with inverting the covariance.

[Brent Follin]

For posterity's sake, I solved this problem by moving closer to the best-fit point. Not sure why that affects whether the parameter covariance is positive-definite, but a work-around is to either manually determine a more realistic starting location, or set start_at_bestfit = T in the .ini file.