Initial framework setup

[sethzenz]

Completely redid the repository structure. Have primitive objects and producers. Will send email to list.

[bendavid]

Hi Seth,
I just want to clarify a point about this.

The way I understand it, if CompositeCandidate is used, then the CompositeCandidate "owns" the photon daughters. Meaning they are stored INSIDE the composite candidate and NOT in a seperate collection.

This is probably fine, because the photons will always have specific properties modified (the four vector at least) such that they are only relevant with respect to a particular diphoton object. But it should be clearly understood that this is the case.

[bendavid]

(The alternative would be CompositeRefCandidate or CompositeRefCandidateT, where the photons get stored in a seperate collection and referenced by the diphoton object)

[sethzenz]

Hmm. I am not sure this is what we want, esp. since the vertex is not a daughter so the behavior would not be uniform. I think we can leave it for now and give it another think at the point when it starts to matter. Thanks for pointing this out.

[bendavid]

The vertex is different in the sense that two diphoton objects may point to the same vertex. But yes, I agree there may be another reason to do this differently, let's think about it a bit.

[bendavid]

I think the other implication of this is that if CompositeCandidate is used, then the photon collection should NOT be kept in the output, because it becomes only intermediate. (The "real" photons live inside the diphoton objects in the diphoton collection at that point)

[sethzenz]

That aspect of it is actually appealing, at least if any of the photon properties might be changed based on the diphoton+vertex interpretation. In fact, I think the answer to that question might determine whether we CompositeCandidate or CompositeRefCandidate.