Analysis of David sim (20201026)

[cramirezpe]

Box located at:

/global/cscratch1/sd/damonge/CoLoRe_sims/sim1000/

There are also three new scripts that include magnification.

[cramirezpe]

Scripts out of the box have some easy to fix problems. However, the box shows problems in the scripts (even the previous ones). I think the bias is not correctly handled in the scripts.

I'll start with the previous script (which is the one I have implemented in the code right now, I'll called it Sept. code). That code gives the following result:

Where the bad result for dm; md and the really bad result for mm will be explained by an error in the bias.

Using the new script (I'll call it Oct) with no modifications (just the ones to make it work), I get:

First, the g1l0 plot should not worry us as these are non-correlated fields. Then there are two problematic things:

Shotnoise

If I remove shotnoise I get the correct (roughly) value for g0g0 and g1g1. This can be an error on my side if I didn't compute the shotnoise properly. (I'll take a look at it)

Bias

In the script where the theoretical predictions are computed (both in Sept. and Oct.) one can find:

pks_dd = np.array(pks_dd)[::-1, :] / h**3
pks_dm = 2*np.array(pks_dm)[::-1, :] / h**3
pks_mm = 4*np.array(pks_mm)[::-1, :] / h**3

This (If I understand the code correctly) is correcting the bias, and made other scripts work but not this one. My hypothesis is that this new box has a different value of bias and then it is breaking something in the scripts (because they are not prepared for this).

Removing the 2 and 4 factors and getting rid of shotnoise (temporarily) yields:

Now it doesn't look that bad.

Then, there are two things that should be addressed:

• If the bias has changed for this new simulation, why the scripts are not working with a different value of bias? I have an idea to fix this.
• What is happening with shotnoise? I think this is a typo in the changes I made to the code, I'll investigate.

[andreufont]

Hi @cramirezpe - these values of (1,2,4) can not be related to the values of galaxy bias, since you should not multiply the lensing power by bias^2. I seem to remember that these were introduced in the scripts temporarily to correct a bug in the prediction code, that was later fixed?

I'd remove these numbers from the script, but make sure to document the change very well and confirm with David.

I'm surprised that you had to modify the scripts from David that much... It would be good to understand each change you had to do, and confirm with him soon (he said he would reply quickly to issues with the scripts).

[cramirezpe]

Hi, I don't think is worth it to mention the modifications as they are:

• maps reader/cls computation: Scripts asking for an inexistent seed parameter (it was used in previous scripts, but not anymore).
• theory computation: As with the Sept. scripts, galaxy count should be loaded from files but is not done in the scripts. These two quantities are computed in the maps script and saved into npz files. They are used to compute the Tracers for pyccl and also to compute the shot noise.

The previous problem with shot noise was caused by me loading incorrectly one of the npz files and now it's solved.

Then we get:

(the galaxy-galaxy plots are fixed). We still have the problem with d-m and m-m (that could be solved removing those factors 2 and 4). These two factors are convention factors (David mentioned it here).

I wanted to check if the bias was the cause of the problems because of how the theoretical prediction is computed. A galaxy and a lensing tracer is defined (apparently) using the same bias:

    tr_d = [ccl.NumberCountsTracer(cosmo, False, (z_nz, nz_tot[i]), bias=(z_nz, np.ones_like(z_nz)))
            for i in range(nbins)]
    tr_l = [ccl.WeakLensingTracer(cosmo, (z_nz, nz_tot[i])) for i in range(nbins)]

It seems here that we are assuming the same bias both for matter and galaxies.

I checked with a different CoLoRe box with a known bias of 2 and the result is okay:

the only apparent problem is d-m at high ell, but that is caused by a high smoothing value I used for that specific box.

Maybe whatever is happening now is happening in the CoLoRe box and not in the scripts. I'll take a look at it again and write a message to David if I can't find the problem.

[andreufont]

I decided to look at the scripts myself, to make sure I understand what you guys are doing. I'll send an email to both of you with some comments.