use rechit fractions in pos calculation

[argiro]

In order to calculate correctly cluster positions for PF clusters, rechit sharing fractions must be used

[ktf]

@slava77 @thspeer can you have a look at it and sign? @nclopezo can you start your tests?

[nclopezo]

Hi

I tested on CMSSW_7_0_X_2013-08-09-0200, all tests passed

[slava77]

@argiro
I have two issues/questions confusing me here:

• the change made now effectively uses frac^2 for weights (it was already using hit.energy()/cluster.energy() previously). Is this the intention, to weight by frac^2? I note that in the log(frac^2) - weighted positions (all use cases?) this change is just equivalent to W0-> W0/2 (weight = W0 + log(coeff) )
• (this is more surprising) I don't see any difference in DQM plots or in simple FWLite comparisons. In the FWLite comparisons I'm looking at
  multi5x5SuperClusters_multi5x5EndcapBasicClusters and hybridSuperClusters_hybridBarrelBasicClusters eta and phi.

So, while this looks like a basic function and has a change, I don't see any impact.
What did I miss?

Stefano, could you please clarify.
Thanks.

[argiro]

On 16 Aug 2013, at 08:37, slava77 notifications@github.com wrote:

@argiro
I have two issues/questions confusing me here:

• the change made now effectively uses frac^2 for weights (it was already using hit.energy()/cluster.energy() previously). Is this the intention, to weight by frac^2? I note that in the log(frac^2) - weighted positions (all use cases?) this change is just equivalent to W0-> W0/2 (weight = W0 + log(coeff) )

frac = fraction of the rechit used for that cluster, in case a rechit is shared among two (or more) clusters. If I am not mistaken, the change just uses (energy*frac) instead of (energy), therefore taking into account that not all the rechit energy belongs to the cluster under consideration

• (this is more surprising) I don't see any difference in DQM plots or in simple FWLite comparisons. In the FWLite comparisons I'm looking at multi5x5SuperClusters_multi5x5EndcapBasicClusters and hybridSuperClusters_hybridBarrelBasicClusters eta and phi.
So, while this looks like a basic function and has a change, I don't see any impact.
What did I miss?

in egamma clustering (hybrid and multi5x5) fractions are not used ( frac = 1 everywhere) , therefore no change is expected.
This addition was done for the benefit of the PF clustering, since PF developers would like to use PosCalc at least for reference.

cheers

Stefano

Stefano, could you please clarify.
Thanks.

—
Reply to this email directly or view it on GitHub.

[slava77]

Hi Stefano,

I missed the fact that frac is the fraction of the hit.
Thank you for the clarification.
It all makes sense now.

I'm going to sign this request once I manage to get on the topic
collector page.

Cheers

    --slava

On 8/19/13 10:33 AM, argiro wrote:

On 16 Aug 2013, at 08:37, slava77 notifications@github.com wrote:

@argiro
I have two issues/questions confusing me here:

• the change made now effectively uses frac^2 for weights (it was already using hit.energy()/cluster.energy() previously). Is this the intention, to weight by frac^2? I note that in the log(frac^2) - weighted positions (all use cases?) this change is just equivalent to W0-> W0/2 (weight = W0 + log(coeff) )

frac = fraction of the rechit used for that cluster, in case a rechit is
shared among two (or more) clusters. If I am not mistaken, the change
just uses (energy*frac) instead of (energy), therefore taking into
account that not all the rechit energy belongs to the cluster under
consideration

• (this is more surprising) I don't see any difference in DQM plots or in simple FWLite comparisons. In the FWLite comparisons I'm looking at multi5x5SuperClusters_multi5x5EndcapBasicClusters and hybridSuperClusters_hybridBarrelBasicClusters eta and phi.
So, while this looks like a basic function and has a change, I don't see any impact.
What did I miss?

in egamma clustering (hybrid and multi5x5) fractions are not used ( frac
= 1 everywhere) , therefore no change is expected.
This addition was done for the benefit of the PF clustering, since PF
developers would like to use PosCalc at least for reference.

cheers

Stefano

Stefano, could you please clarify.
Thanks.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#274 (comment).

---

Vyacheslav (Slava) Krutelyov
TAMU: Physics Dept Texas A&M MS4242, College Station, TX 77843-4242
CERN: 42-R-027
AIM/Skype: siava16 googleTalk: slava77@gmail.com
(630) 291-5128 Cell (US) +41 76 275 7116 Cell (CERN)

---

[cmsbuild]

The following categories have been signed by @slava77: Reconstruction

@cms-git-reconstruction