The master chain doesn't load the updated covmat when running in python 3 if the --update value isn't divisible by 3.
Line 638 of montepython/mcmc.py needs to be updated from
if not (k-1) % (command_line.update/3):
to
if not (k-1) % (command_line.update//3):
Additionally line 753 needs to be updated from
if not (k-1) % (command_line.update/10):
to
if not (k-1) % (command_line.update//10):
although at least for this one the recommended --update value of 20 works.
The implications of the bug is the rate of convergence will be slowed down and it may be harder to obtain proper convergence. The final result may also be biased (although I suspect not very likely except for a low number of chains), unless the offending chain is excluded from the analysis. I recommend reanalysis of previous chains excluding the master chain, which will usually be chain __1 (you can see this running info mode with default settings: whichever chain doesn't have steps removed due to non-markovian points is erroneous, unless that's the case for all chains, in which case the covmat wasn't updated at all and everything is fine). If the offending chain is excluded from the analysis (the easiest is to remove it from the folder), the results should be consistent, just having more slowly reached convergence. If the bug is fixed and runs are restarted with -r the default analysis will lead to all chains being consistent only if the covmat is updated by the code.
The master chain doesn't load the updated covmat when running in python 3 if the
--update
value isn't divisible by 3.Line 638 of montepython/mcmc.py needs to be updated from
if not (k-1) % (command_line.update/3):
toif not (k-1) % (command_line.update//3):
Additionally line 753 needs to be updated from
if not (k-1) % (command_line.update/10):
toif not (k-1) % (command_line.update//10):
although at least for this one the recommended--update
value of 20 works.The implications of the bug is the rate of convergence will be slowed down and it may be harder to obtain proper convergence. The final result may also be biased (although I suspect not very likely except for a low number of chains), unless the offending chain is excluded from the analysis. I recommend reanalysis of previous chains excluding the master chain, which will usually be chain __1 (you can see this running info mode with default settings: whichever chain doesn't have steps removed due to non-markovian points is erroneous, unless that's the case for all chains, in which case the covmat wasn't updated at all and everything is fine). If the offending chain is excluded from the analysis (the easiest is to remove it from the folder), the results should be consistent, just having more slowly reached convergence. If the bug is fixed and runs are restarted with
-r
the default analysis will lead to all chains being consistent only if the covmat is updated by the code.Apologies for problems this has caused!
Best, Thejs