Speed blocking in PolyChord reduces ints by common denominator about cobaya HOT 12 CLOSED

I need to put an update out, since there are quite a few bugs fixed since the last release (thanks to you, @lukashergt, in a bug part!).

I am leaving 5d, but making sure reducing it to d is suggested for exploratory run, and making d=d_block, which I think makes sense.

Thanks all!

from cobaya.

That is a pretty important bug to be fixed (I am using an old version of cobaya where all grade_frac < 1) for my relief.

from cobaya.

Hi both,

I take note and will try to fix it this week.

Thanks for the report!

from cobaya.

Hi both,

Having given it a little more thought, I agree, of course, that num_repeats should not be ignored (I hadn't notice it was in this case, sorry!). I am making the number of steps in the slow block are at least its dimension times num_repeats in 2.0 (released later today, or tomorrow) and in the archived 1.X version.

Once that has been taken into account, so one has direct control on the number of repeats, I'd say there is no need to remove the division by the highest common denominator (otherwise, #repeats may be kept too high just because of small changes in speeds). Do you agree? (I'll keep this issue open until at least one of you has answered, but we can of course keep discussing this here).

from cobaya.

Yes, if num_repeats is no longer ignored but applied to all speeds then that should be fine. However, the default value num_repeats: 5d might be problematic.

If we have 6 slow parameters and say 21 parameters overall, then we wouldn't want 5 * 21 repeats for the slow parameters, but 5 * 6 or maybe even just 2 * 6 repeats. We definitely need > 6 but since they are slow parameters we don't want the number to get unreasonably large either.

Obviously num_repeats can be set by hand, but maybe it would make sense to have this automatically adapt to blocking input. Or does it already work like that?

from cobaya.

It it (at least), dimension of slow params times num_repeats

from cobaya.

If I don't specify num_repeats then it is automatically set to 5*nDims which in the case of Planck TTlowTEB amounts to 5*21=105. If I am now to set speed blocking to say [1, 10, 20] this produces:

[polychord]   grade_dims: [6, 1, 14]
[polychord]   grade_frac: [630, 1050, 29400]
[polychord]   num_repeats: 105

where grade_frac is now much too high. It was produced by

grade_frac = grade_dims * num_repeats = grade_dims * 5 * nDims

If blocking is specified it would make more sense for num_repeats to default to 5 instead of 5*nDims. It might be worth considering changing this default behaviour in the long run. Currently, if one is to set blocking manually, then num_repeats needs to be adjusted manually as well.

from cobaya.

I've been thinking a little bit about this, and propose to do the following:

1. Change default num_repeats from 5d (PolyChord default, recommended for high-precision evidences) to d (enough for MC sampling).

2. When blocking is manually specified, make it so that the d for dimension in num_repeats means the dimension of each particular block, to avoid inflating the number of slice steps if there are a lot of fast directions.

What do you think?

@williamjameshandley do you have an opinion about the 2nd point?

from cobaya.

Change default num_repeats from 5d (PolyChord default, recommended for high-precision evidences) to d (enough for MC sampling).

This would make the runs 5x faster, which is a good thing, although in my experience that is a little low to ensure proper decorrelation.

When blocking is manually specified, make it so that the d for dimension in num_repeats means the dimension of each particular block, to avoid inflating the number of slice steps if there are a lot of fast directions.

In the fast directions there shouldn't be any serious slow-down even for the 'inflated case'. Perhaps a good compromise would be the sum of the dimensions up to that block, so that if you have say 6 slow, 4 semi-slow and 20 fast, you would have d=[6,10,30]

from cobaya.

This would make the runs 5x faster, which is a good thing, although in my experience that is a little low to ensure proper decorrelation.

Would 2d be a safer option?

In the fast directions there shouldn't be any serious slow-down even for the 'inflated case'. Perhaps a good compromise would be the sum of the dimensions up to that block, so that if you have say 6 slow, 4 semi-slow and 20 fast, you would have d=[6,10,30]

I don't find the cumulative dimensions very intuitive. This is for the situation where someone specifies blocking which defines the oversampling, i.e. the desired oversampling should be taken care of by blocking and does not need to enter into d.

The problem that I was facing previously was that d used to be 6+4+20 (using numbers from example mentioned above) making num_repeats = 5d = 150 which then got multiplied with each block in blocking causing extremely high grade_frac (i.e. 150 slow repeats...).

I think there are 2 options that would make sense here:

1. As @JesusTorrado suggests: Have d equal to grade_dims: [6, 4, 20] (when blocking is specified!) which is then used for num_repeats: 2d. This multiplied by blocking: [1, 10, 20] will give grade_frac: [12, 80, 800].
   (Note: Need to be careful that this doesn't interfere with the d in 25d for nlive...)

2. Keep d as is for use with nlive: 25d. Have num_repeat: 2 not 2d (when blocking is specified!) and calculate grade_frac: [12, 80, 800] from num_repeat * grade_dims * blocking (with grade_dims: [6, 4, 20] and blocking: [1, 10, 20]).

Not sure which one fits better or is easier to implement.

from cobaya.

There are pros and cons for either option regarding change of defaults on the one hand and consistency of the use of d in the yaml file on the other hand...

from cobaya.

Sorry for taking so long to come back to this.

@williamjameshandley do you think 2d is enough for proper decorrelation? 3d maybe?

Defining d cumulatively has the problem, as @lukashergt points out, that the fast directions are already oversampled according to their speed, it would be too much oversampling, probably. So I'd keep the d=block_dimension.

In any case, @williamjameshandley, I guess it's clear that this interpretation of num_repeats is applied by Cobaya, while for now PolyChord's behaviour is ignoring for integer grade_frac, right? Or are you thinking of doing something with it inside PolyChord for integer grade_frac?

from cobaya.