Adiabatic initial conditions for interacting dark radiation component (fluid versus free-streaming case).

[flo1984]

Dear CLASS authors,

I had a closer look at the implementation of the interacting dark radiation (idr) component in CLASS.

I refer to line 5907 in the perturbations.c where the initial condition for theta_idr is set:

ppw->pv->y[ppw->pv->index_pt_theta_idr] = theta_ur;

where theta_ur has been defined in line 5611:

theta_ur = - k*ktau_three/36./(4.*fracnu+15.) * (4.*fracnu+11.+12.*s2_squared-3.*(8.*fracnu*fracnu+50.*fracnu+275.)/20./(2.*fracnu+15.)*tau*om) * ppr->curvature_ini * s2_squared;

and fracnu counts the contributions from collision-less relativistic components (i.e. _ur, _ncdm) and idr.

I agree, that this is the correct formula in the case of free-streaming dark radiation when shear is present (idr_nature=free-streaming). However, if I am not mistaken, I believe in the strongly interacting case without shear (idr_nature=fluid), the right adiabatic initial condition would read

ppw->pv->y[ppw->pv->index_pt_theta_idr] = theta_g;

(I checked this for om=0 and no spatial curvature, generalising the derivation in Ma&Bertschinger and working at order (tau k)^4; also note that in that case idr should not be added to fracnu).

Now, I don't think this is of great importance for practical applications and more of a pedantic comment (which is probably the reason for the current implementation). The reason is that the perturbations lock into the adiabatic attractor quickly (that is what I found when doing a few tests). I think it could only play a role for an exotic cosmology where idr dominates. I still thought, updating the initial conditions (or leaving a comment in the code) might be a worthwhile consideration for future versions to avoid confusion.

Best, Florian

[schoeneberg]

Dear @flo1984 , indeed this is something we are already aware of. The issue is that the problem is slightly more complicated than just using either theta_g or theta_ur. In the private github we do have an issue discussing this problem, but we haven't yet decided on the final approach.

[flo1984]

Thanks for the update!