Redesign handling two-point statistics

[vitenti]

Currently the two-point statistics are implemented by a class from where each instance describe a particular combination of two sources. We need a redesign to simplify its usage. This redesign must address the following closed issues:

• Additive shear bias #49
• PZ uncertainty parameterization + marginalization #50
• implement correlated multiplicative bias prior #54
• Complete IA and baryon modelling  #83
• Add PZ widths systematics model #84
• test min and max range keywords for correctness for ell or theta #114
• Incorporating CMB lensing into firecrown to do 5x2 #120
• Use sacc functionality for cutting data vectors #169
• Add a sacc-less utility "likelihood" #195

[tilmantroester]

Why were all these issues closed? As far as I can tell many have not been addressed yet.

[marcpaterno]

We opened this issue as a way to put all these issues together so that we can be sure that all are addressed in the ongoing design work in a coherent fashion, rather than dealing with them piecemeal.

[tilmantroester]

The closed issues cover a wide range of infrastructure and science work, at least some of which is already being worked on in the collaboration. Implementing all of them will take considerable effort from a significant number of people. Until there's a working implementation merged into master, I think closing these issues is premature, as it obfuscates what work needs to be done on firecrown, both for new and existing contributors.

[vitenti]

The idea is not to implement all the necessary features associated with those issues in a single PR. The point is that they were framed in the context of the old design. We intend to redesign the handling of the two point statistics, taking into account these issues. Then, in a next step, we (the whole team) solve them (recreating issues in the new framing when needed).

[tilmantroester]

On what time-scales will this new design be ready? I'm concerned that telling people not to work on firecrown because it's going through another redesign will kill what little momentum we have on getting people involved.

[vitenti]

We certainly do not intend to tell people not to contribute to Firecrown because we are concerned about the ongoing redesign. We are happy to help people update their code to adapt to changes in the design of the components they are using.

We want the development process to be as open and collaborative as possible. We are open to suggestions on how we can do development that both allows us to improve designs (e.g. for improved testability) and at the same time to break as little code that is not in Firecrown but uses Firecrown as possible. (We would of course modify anything that is in the release of Firecrown to work with any redesigns.)

This is a hard problem because we do not currently have anything in Firecrown that indicates what parts we expect people writing their "analysis code" (i.e. new likelihood factory functions) to use, and what we expect to be "internal details" to Firecrown. This is something we want to discuss with the community of Firecrown users and developers.

[tilmantroester]

What is the progress on this issue? As far as I can tell, many of the closed issues haven't been addressed yet. Could they be re-opened to make it easier to judge what work needs to be done?

[vitenti]

The redesign is in progress, but the issues here are not the main focus in a first phase. Nevertheless, issue #84 was recently addressed by PR #321. Please, feel free to reopen any issue you might want to work on and we can integrate your code afterwards if necessary.