[Rivet] New CMS plugin: strangeness in UE (CMS-PAS-QCD-11-010) and UE at forward eta (CMS-PAS-FWD-11-003)

[Hendrik Hoeth]

Hi Hannes,

Thus spake Hannes Jung (hannes.jung at cern.ch):

> However, I do not understand your argumentation: for me and many
> others the important point is to have analyses available in Rivet, but
> I do not care whether they have 100 or 200 or only 10 lines of code.
> This might be important from an programmers point of view, but for me
> it is just irrelevant.

For us it's not irrelevant. There were already a couple of occasions
when Rivet internals changed such that we had to go through all analyses
and adopt things, and I'm sure this will occur again. I can even tell
you when: Rivet 2.0 will use a different histogramming backend (not
aida), and we need to touch every analysis. Not relevant to the user,
but relevant to us as maintainers.

> Of course, the code should run and produce correct results.

In this case, for example, the original code didn't run. My test job
crashed after about 1300 events with a double deletion memory violation
in the self-written sorting algorithm.

> If the code is changed by anyone other than the author, who is then
> responsible for validation?

About 10% of the analyses we get don't even compile cleanly out of the
box. Some with errors like missing/wrong brackets in if-statements. I
wonder how the authors validated those.

Anyway, back to this one. I also wonder how it was validated, given the
crash I experienced. But I can assure you that my code produces
identical results for the events before the crash of the original code,
and I don't feel like I introduced a bug by not having my code crash.

> BTW, for non-expert it is not always easy to find out which tools
> exist already ...

Firstly, that's why you have an expert in CMS who is supposed to check
the code, answer questions, etc.

Secondly, most of the things I've mentioned in my mail where simple C++
issues, not related to Rivet at all. Like having a function that returns
a vector, and then putting the output of that function into a vector by
looping over the output of the function and appending the individual
components to the new vector:

>> - This could be a "ParticleVector myTempParticles = sfsv.particles();".
>>  ------------------------------------
>>  ParticleVector myTempParticles;
>>  foreach (const Particle& p, sfsv.particles()) {
>>    myTempParticles.push_back(Particle(p));
>>  }
>>  ------------------------------------

It also doesn't take an expert to realise that
"pp-$>$$\text{jet}_{1}\text{jet}_{2}$" doesn't exactly produce a proper
arrow (taken from a different CMS analysis) or that there is a pair of
brackets missing in $p_T^{K}_{s}^{0}$ (from the CMS strangeness UE
analysis I added to svn yesterday). In fact, LaTeX even throws an error.
It's simple things like that which every particle physicist should be
able to get right. At least those issues should be caught by the expert
before sending us the code. Which is all I asked for yesterday.

I think it's an insult to us to send us something that doesn't even run
cleanly and call it "validated". Unfortunately, we are so used to that
kind of programming that we usually just nod, smile, reply that we added
the code to svn, fix the stuff quietly and go on with life (like the TeX
error above). But it takes me on average an hour per analysis to get it
into shape before committing it to the repository.

Cheers,

    Hendrik

-- 
If your dreams don't scare you, then you are not dreaming big enough.