[Rivet] ZFinder problem report

[Andy Buckley]

Thanks, Elena! I've put my modified version of the analysis into the 
Rivet trunk now.

I think your existing version is probably fine for ATLAS use, although 
it would be better if the normalisation didn't have the overflow 
problem... here's what the modified version does in the finalize:

void finalize() {
   scale(_hist_zpt_el_dressed, 1/_sumw_el_dressed);
   scale(_hist_zpt_el_bare, 1/_sumw_el_bare);
   scale(_hist_zpt_mu_dressed, 1/_sumw_mu_dressed);
   scale(_hist_zpt_mu_bare, 1/_sumw_mu_bare);
}

Note that I've had to add sum(weight) counters in each ZFinder "if 
!empty()" block, and that the propagator-based histograms aren't in the 
version that will be bundled with Rivet.

Thanks again!
Andy


On 13/09/11 18:52, Yatsenko, Elena wrote:
> Hi Andy,
>
>>> Can you please update the file on AFS/SVN to have titles more like in
>>> other Rivet analyses e.g. "$Z$ $p_perp$ reconstructed from dressed/bare
>>> electrons/muons", "pT(ee) [GeV]", 1/\sigma \,
>>> \mathrm{d}\sigma/\mathrm{d}p_\perp [GeV^{-1}].
>
> I've updated ATLAS_7000_ZPT.plot file on /afs with new titles.
>
> Cheers,
> Elena
>
>
> 12 ???????? 2011, 21:13 ?? Andy Buckley<andy.buckley at ed.ac.uk>:
>> Just a couple of other points: if the data is normalised by
>> cross-section, then you shouldn't call the needsCrossSection() method;
>> and to do the normalising you should use scale(h, 1/sum_of_weights)
>> rather than normalize(h), because that doesn't account for any events
>> which fall into the overflow bins.
>>
>> We'll be addressing both of these points in Rivet 2.0, but for now I've
>> made the corrections to the version of the analysis that will go into
>> Rivet... just wanted to let you know about the possible issues. It's
>> also a good reason to get some outside scrutiny on the code before
>> running it in anger.
>>
>> Thanks again, and best wishes,
>> Andy
>>
>> On 12/09/11 17:51, Andy Buckley wrote:
>>> Hi again Elena/Judith,
>>>
>>> I started tidying up the analysis to include in the next Rivet release.
>>> It looks pretty good, but the main issue is that the .plot file needs to
>>> have comprehensible labels and titles rather than the unreadable things
>>> that come direct from HepData!
>>>
>>> Can you please update the file on AFS/SVN to have titles more like in
>>> other Rivet analyses e.g. "$Z$ $p_perp$ reconstructed from dressed/bare
>>> electrons/muons", "pT(ee) [GeV]", 1/\sigma \,
>>> \mathrm{d}\sigma/\mathrm{d}p_\perp [GeV^{-1}].
>>>
>>> Thanks :)
>>> Andy
>>>
>>>
>>> On 12/09/11 10:35, Andy Buckley wrote:
>>>> On 12/09/11 08:53, Judith Katzy wrote:
>>>>> Hi Andy,
>>>>>
>>>>> our understanding was that the ClusterPhoton flag only refers to the
>>>>> final state output, not the Zpt reconstruction. In order to avoid any
>>>>> interpretation issues it would be best to
>>>>> write 1-2 sentence documentation on what this is supposed to do.
>>>>
>>>> The main output of the projection is the reconstruction (of the whole Z
>>>> momentum, not just the pT), so that is what the cluster flag applies to.
>>>> I agree that the doc strings could be clearer: Frank S, you know best
>>>> how you intended the latest W/ZFinder interfaces to work... can you add
>>>> a bit more explicit Doxygen about the constructor arguments?
>>>>
>>>>> The analysis code is in the usual analysis area on lxplus since Elena
>>>>> didn't have submission rights to svn.
>>>>
>>>> Ok, I'll get it from there. I suggest that you request SVN access for
>>>> Elena, since much of the AFS area is in fact an SVN checkout and just
>>>> copying files in there could cause problems.
>>>>
>>>>> I strongly suggest that we should keep all the 3 types of corrections
>>>>> that ATLAS provides in hepdata and that are programmed in the current
>>>>> version.
>>>>
>>>> We will have to remove the pole mass observable -- not everything in
>>>> HepData is suitable for Rivet implementation and this kind of
>>>> "reconstruction" is exactly what Rivet is designed to avoid. But since
>>>> Gavin favours the "bare" observable for muons as being the least biased
>>>> (is there support in the paper for that interpretation, Gavin?), I guess
>>>> we'll keep that. It's not like we don't already have observables in
>>>> which a physics effect has been unfolded from the data!
>>>>
>>>> Cheers,
>>>> Andy
>>>>
>>>
>>>
>>
>> --
>> Dr Andy Buckley
>> SUPA Advanced Research Fellow
>> Particle Physics Experiment Group, University of Edinburgh
>>
>> The University of Edinburgh is a charitable body, registered in
>> Scotland, with registration number SC005336.
>>
>


-- 
Dr Andy Buckley
SUPA Advanced Research Fellow
Particle Physics Experiment Group, University of Edinburgh

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.