MultiNest gives erroneous posterior weights when outfile=0

[gregorydavidmartinez]

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.

[williamjameshandley]

Hi @farhanferoz -- I think that this is something that my update from 3.10 -> 3.11 (back in CCPForge days) overlooked. This change introduced an additional 'birth contour' column, which I regularly use to reconstruct nested sampling runs using anesthetic, and to recompute weights.

I made efforts to ensure that the reading/writing output files did not change (i.e. an evidence data file remained as before), but had not appreciated that only in branches where outfile is off, the in-memory posterior weight calculation would assume the old layout of evDataAll

As far as I can see this is the only place the bug occurs, and it really is this two-line fix. Apologies that this has gone unnoticed for so long. I believe @gregorydavidmartinez is submitting a pull request.