[Rivet] Rivet 2.4.0 xsec/event counter

[Podskubka, Radek (ITP)]

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: line114:    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 some point ReaderYODA.cc tries to read numEntries 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":




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.hepforge.org/lists-archive/rivet/attachments/20151208/94bff1b8/attachment.html>