[Rivet] OPAL_2004_S6132243

Peter Skands peter.skands at cern.ch
Fri Nov 11 23:53:06 GMT 2011


Hi Andy,

Thanks for the speedy reaction. I'm afraid I have not much insight into how the 
original analysis was done. I could imagine that if the whole event hadronized 
into neutral energy, in the extreme case everything producing neutrons, the 
experimental systematics would be extremely hard to control. Correct me if I am 
wrong, but neutrons are basically invisible to you? Or do you see something in 
the EM/HAD calorimeters? Of course, it would be *extremely* rare for an entire Z 
decay to produce only two neutrons! But it could happen that no charged 
particles would be produced, and hence the event would consist of only neutral 
energy, say some K0L mesons (that live a long time) and maybe some photons from 
pi0 or eta0 decays. That might still be a situation not under extremely good 
control, and I really have no good feeling for how often it might happen, apart 
from the indication given by the charged-multiplicity distribution that says how 
often there are at least no charged tracks in the event. Still, they had pretty 
good EM calorimeters at LEP I guess, so should be able to detect an event 
reliably even if went to all pi0 -> photons, right? A small negative mass 
squared can be just the result of rounding errors. I agree that above the 
numerical precision, no spacelike quantities should be able to appear, but at or 
around numerical precision, rounding is always an issue, and the algorithm 
should be stable against small fluctuations induced by it.

Cheers,
Peter

On 11/11/11 6:36 PM, Andy Buckley wrote:
> Hi again Peter,
>
> I've put in some debug printout and found that the first of several problem
> events happens on event 53360. In this event, the hemispheres projection returns
> a negative mass^2_L value (~10^-9 GeV, so it's at the numerical precision
> level), and so the sqrt of that introduces the NaNs. I'm not yet sure why the
> "normal" histograms tolerate being filled with a NaN but the moments profiles
> die, but it's certainly not good because 4 vector calculations shouldn't be
> *able* to return negative mass2s! I'm looking into that now: will hopefully get
> it sorted this evening and be able to release the new version.
>
> On a more physics-oriented note, I wonder if there is an undeclared 4 jet (or at
> least 4 particle) cut on filling this distribution: it looks to me like there is
> an excess of entries in the zero bin of the main distribution. But I'm
> struggling to see how in a 4pi detector in the CoM frame it's even possible for
> a sphericity- or thrust-based hemispheres decomposition to ever have no
> particles in one of the hemispheres: the momentum has to be balanced somewhere.
>
> Andy
>
>
> On 11/11/11 07:16, Peter Skands wrote:
>> Hi Andy,
>>
>> I was just wondering. ML is normally a 4-jet quantity, i.e., it is
>> undefined (zero) for 3 particles or less. It may even be undefined for 4
>> partons, since it needs at least 2 of the partons to be on the "light"
>> hemisphere which is not always the case. I don't know exactly how you
>> compute the moments, but is it possible that something bad happens if
>> there is an event with too few particles in the light hemisphere? That
>> could conceivably happen only very rarely.
>>
>> Peter
>>
>> On 11/10/11 11:22 PM, Anton Karneyeu wrote:
>>> Hi Andy,
>>> I made a recheck with 1.7.0beta0 and still can see the problem - see
>>> attached
>>> pdf. Did you tried on lxplus?
>>>
>>> The full output which I see and script is here:
>>>
>>> /afs/cern.ch/user/a/akorneev/public/rivet
>>>
>>> Maybe something is wrong with my environment but I see the same issue in
>>> histograms coming from our BOINC cluster which are SLC5 i686 machines
>>> with
>>> minimal environment. Also, problem do not appear running small number
>>> of events,
>>> at least 100k events are necessary (probably it depends on random seed).
>>>
>>> Cheers,
>>> Anton
>>>
>>>
>>> On 10.11.2011 16:53, Andy Buckley wrote:
>>>> Hi Anton,
>>>>
>>>> Sorry about the delay, but with the trunk version of Rivet I don't see
>>>> any issue with these plots. I ran the PYTHIA default tune at 91 GeV and
>>>> your z2.params which specifies 133 GeV, and both worked fine. No NaNs in
>>>> any of the output files, and the plots look very reasonable (see
>>>> attached).
>>>>
>>>> Do you still see this issue with the 1.7.0beta0 version? We do now also
>>>> have a beta1 tarball available, but unless you found any problems in the
>>>> beta0 testing I think we are ready to make our proper 1.7.0 release
>>>> tomorrow.
>>>>
>>>> Cheers,
>>>> Andy
>>>>
>>>>
>>>> On 06/10/11 21:19, Anton Karneyeu wrote:
>>>>> Hi guys,
>>>>>
>>>>> could you have a look on OPAL_2004_S6132243 analysis there is a problem
>>>>> with HemiMassLMom (d25-x01-yYY) histogram. In some cases histogram bins
>>>>> contents NaNs.
>>>>>
>>>>> Please, find in attachment the script which reproduce the problem on
>>>>> lxplus:
>>>>>
>>>>> $ ssh lxplus
>>>>> $ ./bug.sh
>>>>>
>>>>> Problematic histogram is
>>>>>
>>>>> S6132243/OPAL_2004_S6132243/d25-x01-y02.{dat,pdf,png}
>>>>>
>>>>>
>>>>> Cheers,
>>>>> Anton
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Rivet mailing list
>>>>> Rivet at projects.hepforge.org
>>>>> http://www.hepforge.org/lists/listinfo/rivet
>>>>
>>>>
>>
>
>


More information about the Rivet mailing list