[Rivet] Rivet 2.4.0 xsec/event counter

[Andy Buckley]

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