[Rivet] Bug in Rivet 2.4.0 histogram naming

[Andy Buckley]

Hi Alex,

Thanks for the report -- as you probably guessed, we developers don't 
use that feature very much, so the misbehaviour passed us by. We'll 
definitely fix it in the next release.

This is a good incentive to properly clear up the semantics of 
"underscore ignoring", and probably to encode those ignoring rules into 
a single function in the Rivet library. I suggest that rather than 
require either the first or last component of the histo path to have an 
underscore for the object to be ignored, that we ignore if *any* 
/-separated component starts with an underscore, i.e. if the underscore 
is not on the leaf node of the path, then it is as if one of the 
containing "directories" is being ignored instead. Does that sound sensible?

Cheers,
Andy


On 17/01/16 02:16, Alex Grecu wrote:
> Dear developers,
>
> I appreciate very much the features introduced by the YODA histogramming
> system in Rivet 2.x series.
> However, at least in Rivet 2.4.0, I noticed a bug in the way the name of
> an AnalysisHandler object is used to make the YODA histogram path (see
> Analysis::histoDir) and then in the way the same runName is used by the
> Rivet helper scripts to create the web page for the analysis results. In
> the first case runName is just another "branch" of the YODA path while
> the script rivet-cmphistos attaches the runName to the analysis name
> using underscore. This creates a problem when make-plots interprets the
> *.dat files as the plot meta data is no longer identified correctly in
> the corresponding *.plot/info file. The result is a web page that has
> neither analysis description nor plots with valid labels and titles
> (although the environment variables are set such as the meta data of the
> analyses should be found).
> I'm using the Rivet installation on lxplus at this path:
> /afs/cern.ch/sw/lcg/releases/MCGenerators/rivet/2.4.0-dd72f/x86_64-slc6-gcc48-opt.
> Could you please investigate and advise the maintainers to correct these
> issues if they are installation related. It is quite annoying to have a
> feature such as the runName if it is useless and it actually breaks
> things. I noticed however that if runName is set to an empty string
> everything works fine. So maybe it would be a good idea to explain, for
> developers, what is the purpose of this runName property. In the mean
> time I'll just instruct the LHCb users not to care about this feature
> when testing their analysis modules.
>
> Thank you in advance.
>
> Best regards,
>
> Alex Grecu
>
> --
> *LHCb* Experiment
> /Horia Hulubei/ National R&D Institute for Physics and Nuclear
> Engineering (IFIN-HH)
>
> @CERN
> ========================
> Office: 11/1-014
> Phone: +41 22 76 79058
> Postbox: F26500
>
> @IFIN-HH
> ========================
> Bucharest-Magurele, 408 Atomistilor, DFT bld, office 220 (2nd floor),
> Phone: +4(0) 21 404 62 48; ext. 3404
>
> Skype name: /alex.t.grecu/
>
>
> _______________________________________________
> Rivet mailing list
> Rivet at projects.hepforge.org
> https://www.hepforge.org/lists/listinfo/rivet
>


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