[Rivet] ZFinder problem report

[Andy Buckley]

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.