Make a decision about sacc2 data_type names

[joezuntz]

Should they be things like:

• ClEE, ClBB, with the tracers indicating exactly what kind of data is contained

or

• galaxy_shear_cl_ee, which is slightly more redundant but clearer. (This is currently implemented).

[damonge]

Alright, here's my pitch for the first option:

• It compartimentalizes information better: the tracers tell you about the physical properties of your observations. The data_type tells you what operation you carried out to summarize that information (Fourier/real, which spin combinations, is it counts, or just a scalar measurement of something).
• It requires a lot less code maintenance: data_types in this sense are very generic objects that we don't have to update as soon as we look at a new observables. In the case of 2-point functions, you only need to support ['ClEE', 'ClEB', 'ClBE', 'ClBB', 'Xi+real', 'Xi+imag', 'Xi-real', 'Xi-imag']. For the second option, and assuming we only have galaxy clustering (G) and cosmic shear (S), you need to support ['Cl_GG', 'Cl_SS_EE', 'CL_SS_EB', 'Cl_SS_BE', 'Cl_SS_BB', 'Cl_GS_E', 'Cl_GS_B', 'Xi_GG', 'Xi_GS_E', 'Xi_GS_B', 'Xi_SS_+', 'Xi_SS_-'] (plus the B-mode versions of Xi_SS, which I'm not sure have a standard notation). Now fast forward a bit and you're gonna want to cross correlate with CMB kappa. You now need to support ['Cl_Gk', 'Cl_Sk_E', 'Cl_Sk_B', 'Cl_kk', 'Xi_kG', 'Xi_kS_B', 'Xi_kS_E', 'Xi_kk']. And since there's interesting information in tSZ and kSZ you probably want to do that too, so add two more versions of that (and their cross-correlations). How about 21cm in the future. This gets silly very quickly, especially because all of these quantities are equivalent to each other (e.g. 'Cl_GG' and 'Cl_kG') in their storage and mathematical properties. With the first option, in this case you need to do next to nothing: either create a new tracer for each new kind of observable you want to include or nothing at all, if you're happy with having a string attached to each tracer that just defines what quantity on the sky it is (e.g. 'delta_g', 'gamma', 'tSZ' etc.).
• I think it will play better with other code, because other codes are also structured this way. E.g. in CCL we have different tracers for different sky quantities, but only one single angular_cl function (and not separate 'cl_gg', 'cl_gs', 'cl_ss' 'cl_kk', 'cl_kg', 'cl_ks' functions). Same thing for namaster Fields and power spectra.

I wonder if one option would be to support both the 'general' and 'specific' options, but I think @joezuntz would rather not give users too much freedom.

[joezuntz]

Dealt with this in the PR