Built-in NLA vs calculation with generalized tracers and nl_pt

[jablazek]

This issue is linked to this PR in CCLX: LSSTDESC/CCLX#17
for the notebook: PerturbationTheoryPk.ipynb

I have found two things. They are probably separate, but there might be a connection, so I will put them together here.

[jablazek]

1. When defining the PTTracers, the z range is less than the z range later required by the n(z) of the Tracers. If passing a constant bias, this seems to be not a problem. get_pt_pk2d by default does the following:

if a_arr is None:
status = 0
na = lib.get_pk_spline_na(cosmo.cosmo)
a_arr, status = lib.get_pk_spline_a(cosmo.cosmo, na, status)
check(status)

So the specified z range for the PTTracers doesn't matter. For the IA tracers, we have passed defined (z,C1) etc. In this case, it looks like the PTTracers have the following method:

def _get_bias_function(self, b):
# If None, assume it's zero
if b is None:
b = 0
# If it's a scalar, then assume it's a constant function
if np.ndim(b) == 0:
def _const(z):
if np.ndim(z) == 0:
return b
else:
return b * np.ones_like(z)
return _const
else: # Otherwise interpolate
z, b = _check_array_params(b)
return interp1d(z, b, bounds_error=False,
fill_value=b[-1])

So if get_pt_pk2d needs z outside the defined range for the PTTracer, it uses the last given bias value (rather than try to extrapolate with some function). And it does this at both the high and low z end. Is my understanding correct?

In this case, the code should run even if n(z) goes outside the specified b(z) - it just might lose accuracy if b(z) continues to change outside this range.

[jablazek]

2. When I compare the built-in NLA C_ells from WLTracers with what I get using nl_pt and generalized power spectra, I get differences of a few percent when I have a broad n(z) (e.g. sigma_z = 1). This seems to be partly due to extrapolation in z as mentioned above, but only partly. I tested increasing the input z range, and much of the difference persists.

For a narrow z range (e.g. sigma_z = 0.1), the difference between the two methods is much smaller - 1e-5 to 1e-7, depending on the ell.

I will keep looking into this. Ideas?

[jablazek]

@elisachisari : can you point me towards the built-in NLA normalization? or paste it here?

[jablazek]

UPDATE: It looks like much of the issue happens when n(z) is non-trivial near its edge. The two methods must be treating the edge differently. This is especially true at z=0, much more than z=zmax.

[jablazek]

UPDATE: This is almost certainly related to how get_pt_pk2d creates the Pk interpolation. If I instead pass P_NL calculated in the standard ccl way as a generalized power spectrum (i.e. skip the path through nl_pt) the agreement is back to 1e-5 or better.

It's definitely NOT related to the internal IA normalization. Using that vs. the normalization calculated by hand gives ratios of exactly 1.

[jablazek]

There is also a difference in how the k extrapolation is done. Internally, the nl_pt grid defaults to log10k = -4 to 2. Extrapolation beyond this AFTER the pk2d object is created must be done differently than when CCL evaluates power spectra, e.g. with ccl.nonlin_matter_power. Is this something people understand?

[c-d-leonard]

Good to see you narrowed this down a little. @damonge can probably best answer questions about pk2d?

[damonge]

Sorry I've only been able to get to this now. I've read the above but I'm not sure what the problem really is. @jablazek Is there a code reproducing the problem I could look at?

[jablazek]

@damonge : see JAB_updates branch in CCLX. The PerturbationTheoryPk notebook has the NLA C_ells calculated a few different ways. They should agree, but in some cases don't. I have been exploring with this, so it isn't very well documented right now.

[c-d-leonard]

@jablazek is this still work in progress?

[jablazek]

@c-d-leonard : indeed it is. Fell down a bit on my to-do list, but will revisit asap.