[Rivet] Rivet 2.4.0 xsec/event counter

[Podskubka, Radek (ITP)]

Hi,

you are welcome :)

I have already finished the patch of Rivet and Yoda, that adds number of Monte Carlo event generator attempts to the yoda output file and ensures proper combination of parallel runs. Unfortunately the way that I have made it is quite complex and I am not sure if it is even possible to do it smarter and more efficient (for example I have had to modify some of the cython extensions and regenerate the yoda.cpp file with some functions that I have added...)

Anyway, tomorrow I can just write down what I have done in detail and send you modified parts of Rivet and Yoda, maybe it could be useful.

Best and good night,
Radek

________________________________________
From: Andy Buckley <andy.buckley at cern.ch>
Sent: Friday, December 11, 2015 12:22 AM
To: Podskubka, Radek (ITP); Rivet
Cc: daniel.rauch at desy.de; Gieseke, Stefan (ITP)
Subject: Re: Rivet 2.4.0 xsec/event counter

Hi Radek,

Thanks very much for finding the problem and tracking it all the way
back to the source -- I wish more of our users would do that!!

I have applied the trivial fix to our development trunk and (along with
a few other improvements that I'm working on right now) this will go
into the next patch release, hopefully very soon.

I'll check the yodamerge bug, too -- thanks again. Note that yodamerge
doesn't do anything special with the counter or xsec; we plan a
rivet-merge or similarly named script for that, since it's a
physics-specific concept. Any input on how it should work would be more
than welcome!!

Best wishes,
Andy


On 08/12/15 15:41, Podskubka, Radek (ITP) wrote:
> Hi all!
>
> Few weeks ago, there was a mailing discussion about adding the number of
> Monte Carlo event generator attempts as an output to yodafiles. In last
> days I have been working on the patch for Rivet 2.4.0 and YODA 1.5.5 to
> manage this. Anyway I think that I have bumped on something in the YODA
> code that could be considered as a bug...
>
>
> The function that returns number of entries in Counter.h is of the type
> of double
>
>
> *Counter.h: line**114:**double numEntries() const { return
> _dbn.numEntries(); }*
>
>
> which by itself is probably no big deal. The only thing that is
> affected is the format of the total number of entries in yodafile
> (section YODA_COUNTER), which is because of that printed out in
> scientific format (e.g. for 150 events generated, there is something
> like 1.500000e+05).
>
>
> The problem comes in the moment, when one wants to read generated
> yodafile by some of the tools that come with rivet - for example
> yodamerge. Lets stick to the yodamerge example and lets say that we want
> to merge outputs of two runs - run1.yoda, which contains information
> about 150 total entries and run2.yoda  which contains information about
> 300 total entries. yodamerge tries to read input files by
>
>
> *yodamerge: line129: **aos = yoda.read(filename)*
>
>
> Long story short, if I understand it well, this yoda.read(filename) function calls another
> chain of read functions and the file is at the end read by
> ReaderYODA.cc. At somepoint ReaderYODA.cctries to readnumEntries
> from YODA_COUNTER section (which  is in scientific format).
>
>
> *ReaderYODA.cc: line173:    iss >> sumw >> sumw2 >> n;*
>
>
> But here the numEntries (in the code denoted as n) is assumed to be
> unsigned long and is parsed to iss istringstream by >> operator. Now I
> don't understand it well, but I think that >> is just not awaiting
> anything else than a number in int format and can not parse int
> (resp. unsigned long) in a scientific format. Unfortunately what happens
> now is that just the part of the number before the decimal dot
> is parsed without throwing any error.
>
>
> If we get back to our example with two runs which are yodamerged, it
> leads to the final output with total number of entries 4 instead of 450
> in YODA_COUNTER, which is of course incorrect.
>
>
> The way how I have fixed it is very simple. I think that it is
> sufficient to change type of numEntries() in Couter.h from double to
> unsigned long. After this fixing I am getting numEntries as a ordinary
> int number (non-scientific format) in output file and thanks to that
> also correct results after merging.
>
>
> I am sorry that you had to read such a long story because of just one
> wrong type, but to me it was quite a puzzle to find out why yodamerge is
> giving incorrect numEntries. That is the reason why I felt that I also
> should explain why I think that it would be nice to fix it.
>
> Best,
>
> Radek
>
> PS: I am not sure, but to me it also seems that there is some
> another inconsistency in yodamerge itself. Shouldn't be there (line 204)
>
> *if opts.S1D_MODE == "assume_mean":*
>
>
> instead of
>
> *
> *
>
> *if opts.S2D_MODE == "assume_mean":*
>
>
>
>
>


--
Dr Andy Buckley, Lecturer / Royal Society University Research Fellow
Particle Physics Expt Group, University of Glasgow