here are the estimates for bulk KK-graviton:
https://github.com/acarvalh/Cross_sections_CMS/blob/master/WED/bulk_KKgrav_LHC13.txt
decay BR:
https://github.com/acarvalh/Cross_sections_CMS/blob/master/WED/bulk_KKgrav_decay.txt

with ktilde = k / \bar{M_{Pl}} = 0.1and kL = 35
(see this plot for recent public CMS results)

I suggest we take the same for radion and RS kk-graviton while waiting for the xsec estimates to arrive ?

See https://root.cern.ch/doc/master/classTLegend.html#a197ab3e749a6da0093538c4283750758

Ideally, for 2 columns, we should have something like:

The travis job for #101 failed with:
The command "wget http://sbrochet.web.cern.ch/sbrochet/public/ROOT-${ROOT_VERSION}_Python-2.7_Ubuntu-12.04_gcc4.9.tar.xz" failed and exited with 4 during.
I'll try to have a look at building a new package (this seems like a recipe, does anyone remember if @blinkseb used this or something else?), but any ideas/suggestions are welcome.

yes, I know... but recommendations:
https://twiki.cern.ch/twiki/bin/view/CMS/PoissonErrorBars

Needs to support horizontal and vertical lines (oblique lines needed?) in both plot units and NDC units

Hi!

I did a pull of all latest changes in plotIt, which include the change of formatting of the luminosity-label. Then in my python config file I use now

luminosity-label: '%1$.2f fb^{-1} (13 TeV)'

as discussed in the related PR. But for some reason this is not understood by the boost parser: see for instance http://cp3.irmp.ucl.ac.be/~simon/plottest_postbugfix_SF_withSig/lljj_M_llCRbb_logy.png

I checked that the code changes related to the luminosity-label are present, and of course recompiled plotIt. Any idea about what is going wrong?

Best,

Simon

• For plots in pdf, text in legend such as 'X2 \to HH (260)' are not displayed (but the legend entry is visible)
• Once we use groups some legends disapear. It seems that this problem appears from commit #14. We will try to provide more details on this issue soon.

There's a strange issue with the error bar on data when only one entry is in the bin:

On the other hand on other plots (produced at the same time as above) it seems fine:

Weird, right?

After setting up ROOT 6.14.08 with

source /cvmfs/sft.cern.ch/lcg/views/LCG_94a/x86_64-slc6-gcc8-opt/setup.sh

the tests do not pass.

It looks mostly like a y-axis range problem, but the error histogram doesn't move along, so that seems out of sync (to be investigated).

A few examples (always reference followed by generated and then the difference)

I've started a list of all the options that can be used in the configuration files, since with all the PRs it's becoming difficult to keep updated: https://github.com/cp3-llbb/plotIt/wiki/List-of-configuration-options

Do not hesitate to fill in what's missing! For some options I couldn't find immediately where they were used in the code (github's search in the code does not work for forked repos, and this repo is becoming quite different from Seb's original one)... Default values are defined in 3-4 different places, so I might have missed some. It's also not always quite clear whether a field is required or not.

Unfortunately the table does not render very well on the github wiki..

We need a more robust method for computing the uncertainties in the summary given by plotIt:

MC:
                                                                   N ±         ΔN            ε ±       Δε
(...)
TT_TuneCUETP8M1_13TeV-powheg-pythia8_MiniAODv2_v1…           1626.53 ±       5.54     0.08899% ± 0.00030%
DYJetsToLL_M-10to50_TuneCUETP8M1_13TeV-amcatnloFX…             -9.93 ±       -nan     -0.00002% ± -nan%
DYJetsToLL_M-50_TuneCUETP8M1_13TeV-amcatnloFXFX_M…             20.73 ±       0.02     0.00016% ± 0.00000%
------------------------------------------
Systematic uncertainties
                                        Luminosity                   ±      78.17
------------------------------------------
                                                             1699.29 ±       -nan

I don't really know how to compute an uncertainty on an efficiency when events with negative weights are in the game (if only positive weights, using https://root.cern.ch/doc/master/classTEfficiency.html#ae80c3189bac22b7ad15f57a1476ef75b will be the best choice).

On the other hand, we don't really need this uncertainty, do we? What's interesting is the uncertainty on the predicted yield, which is easier to compute (at the moment this is computed from the uncertainty on the efficiency)...

Any thoughts?

The use case is: suppose you want to make a 2016+2017+2018 plot. This is currently not possible in plotIt because the MC normalisation should then depend on the period, while the luminosity is a global configuration option (the situation may be different in case the plotter applies the normalisation, but that's not what I'm using or assuming).
Proposed solution: add an era key to each files entry (a string to identify the period), and an eras top-level configuration with the luminosity per era, entries of which can be of two formats:

2016:
    luminosity: XXX
    luminosity-error: YYY
    produce-plots: true

for a single period, and

Run2:
    eras: ["2016", "2017", "2018"] # individual eras

for a sum over eras (single-era plots are only produce if they have produce-plots set to true).
The current behaviour can be the fallback in case these are not specified.

Any feedback is more than welcome

path to the files, sum of event weights and cross-section for mc, integrated luminosity for data

A bit of context: I'd like to add bamboo to conda-forge, since it provides an easy way to get an environment to try it (e.g. a jupyterlab+binder with one of the examples on open data), see also https://gitlab.cern.ch/cp3-cms/bamboo/-/issues/65 - and to have plots it'd be nice to include plotIt :-)

The first attempt at a recipe is here. It builds and tests pass, but there are a few questions to ask / things to do first:

• what's the license of plotit? (we should also add a LICENSE file)
• make a release - i.e. push a tag (I guess we can follow https://semver.org - any preference what to call the current one?), and define a strategy for when to tag new releases
• maybe sort out the tests (I cheated by lowering the threshold from .995 to .99, the differences are in the fonts and the edges of the fit shaded region)
• any updates we may want to do to the documentation at http://cp3-llbb.github.io/plotit/

and anything else I didn't think of

The sooner the better. In order to avoid confusion each Friday morning about what color corresponds to what sample, it would be good to agree on a color code. Here is a list of palette : http://www.colourlovers.com/palettes/most-loved/all-time/meta with the "Thought Provoking" suggested by SB (I like it as well). The closer then we use to have would be something like TT --> ECD078 , DY --> 53777A, ZZ --> 542437 (two more left) but any suggestions are welcome :-) We will need more then one palette to fit the number of MC so do not hesitate to propose also other palette.

PlotIt uses Linux's built-in UUID definitions, which seem to have changed since Linux 3, so it works fine on ingrid's and lxplus CC7/SLC7, but for centres that are stuck in the middle ages there's no way to build it.

Since we link with boost anyway one solution would be to change to use boost::uuid.

Opinions?

What surprises me is that it worked fine in 2015/2016 when ingrid was still running SLC6...

Right now, systematics are only printed in the summary for MC. Extend it also to signal.

Making a data-data or MC-MC comparison plot requires some hacking of the config file (see #112), and signals are not stacked (nor combined for different eras, see #115).

Currently, the division is done by looking at the "type" of the sample/file:

• "data" is added to the data stack (as-is, no scaling or normalisation, unless the plot is normalised)
• "MC" is scaled to luminosity times cross-section divided by the sum of weights (times "scale"), unless "no-lumi-rescaling" is true, and added to the MC stack
• "signal" is scaled like MC, but not added to a stack.

How about allowing a "stack" property that is the type by default (for "data" and "MC", and the "pretty-name" by for signal), that can also be set per sample (per group?).
Possibly this could also allow for overlaying several ratio plots.

Maybe this is too complicated, and it would be better to have a simple python implementation that does not use eras or stacks for this (the typical use case is comparing a few MC samples with different settings, but there are also more analysis-like cases that could benefit from it)?