[Rivet] Rivet validation of higgs- > gamma/gamma plugin

[Michaela Queitsch-Maitland]

Hi Holger,

Thanks a lot, they look good to me!

Just to be sure — I take it that this is just gluon fusion production (which would explain why the last two bins of d29-x01-y01 are empty)?

Cheers,
Michaela

On 23 Mar 2015, at 02:06, Holger Schulz <holger.schulz at durham.ac.uk<mailto:holger.schulz at durham.ac.uk>> wrote:

Hi,

I ran the plugin through 100k Sherpa events in SM + higgs effective couplings (1st jet NLO, merged,
total xs=15.6 pb) disabling all BR weights and only allowing Higgs -> gamma gamma decays.
I scaled the output histo by a K-factor of 1.27 to get a total xs of 19.27 pb (just as Michaela quoted
powheg box) and a branching fraction of 0.00228 (again, see Michaela's mail).
The plots are here:
https://users.hepforge.org/~holsch/plots_higgs/ATLAS_2014_I1306615/index.html
Looks about right to me. Anything suspicious?

Holger


On 22/03/15 22:48, Andy Buckley wrote:

Hi Holger,

Reading the JO file, the LHE would have a name containing
"HJJ_MINLO_ggH_SM_M125". The rest of the fragment have to be very
generic given that we make so many samples through them -- betterthan
having thousands of huge JOs with lots of room for typos and other errors.

I'd guess the NLO/MINLO aspect is not super-crucial for validation (or
is it?) so LO should be good enough. So since Sherpa apparently won't
look quite right, do you have a copy of Pythia8 locally in which you
could enable the ggH process and set the H->2gamma decay mode exactly as
in the JO?

Andy


On 22/03/15 11:09, Holger Schulz wrote:


On 20/03/15 16:49, Michaela Queitsch-Maitland wrote:


Hi Holger,

The routine was validated using a gluon fusion MiNLO HJJ sample:

mc12_8TeV.181085.PowhegPythia8_AU2CT10_HJJ_MINLO_ggH125_gamgam.evgen.EVNT.e2005

scaled to XS*BR = 19.27*0.00228. No other production modes were included for the validation. The results from the routine were compared against the analysis code (used to derive the unfolding factors for the data) with very good agreement. The plots in the publication were also reproduced by Roman Lysak (ex ATLAS Rivet contact) using the routine. Unfortunately I don’t have the plots from the ‘final’ version of the routine — Roman would have those.

Let me know if you need anymore information.


Hi Michaela,

I was trying to find the generator setup bits for this sample looking
into AMI and the svn browser of MC job options.
It would seem as if powheg (==powhegbox???) parton level outputs (.LHEF)
were  simply showered with Pythia8
allowing only for H->gamma gamma decays handled by pythia8. What I am
unable to find are the processes
included when running powheg (box?).


These are the JOs:

 1. https://svnweb.cern.ch/trac/atlasoff/browser/Generators/MC12JobOptions/trunk/share/DSID181xxx/MC12.181085.PowhegPythia8_AU2CT10_HJJ_MINLO_ggH125_gamgam.py
 2. https://svnweb.cern.ch/trac/atlasoff/browser/Generators/MC12JobOptions/trunk/common/PowhegPythia8_AU2_CT10_Common.py
 3. https://svnweb.cern.ch/trac/atlasoff/browser/Generators/MC12JobOptions/trunk/common/Pythia8_Powheg.py
 4. https://svnweb.cern.ch/trac/atlasoff/browser/Generators/MC12JobOptions/trunk/common/Pythia8_LHEF.py
    ----> brick wall

As you can see, the latter just looks for files commonly named
"events.lhe" --- with no information whatsoever what these contain.

This is a bit dangerous. I would assume that the information on the
processes switched on when generating these files is
stored some other place. Maybe ami would be a good place to store this
kind of information globally.

So yeah, at this point I cannot consider your plugin validated as I
cannot reproduce your results.

Best,
Holger




Cheers,
Michaela

On 19 Mar 2015, at 20:07, Frank Siegert <Frank.Siegert at cern.ch><mailto:Frank.Siegert at cern.ch> wrote:



Hi Holger,

with a plain Sherpa H->gamma gamma setup the BRs will be screwed up,
so a factor of 10 can be expected.
There are new options for the upcoming Sherpa 2.2.0 which allow to fix this:
http://sherpa.hepforge.org/doc/SHERPA-MC-2.2.0.html#HDH_005fWIDTH

For Sherpa 2.1.1 you are best off running without BR weights
(HDH_BR_WEIGHTS=0) and multiplying with the correct H->gamma gamma BR
manually at the end.

Cheers,
Frank



On 19 March 2015 at 19:54, Holger Schulz <holger.schulz at durham.ac.uk><mailto:holger.schulz at durham.ac.uk> wrote:


Hi Michaela,

in preparation of tomorrows release of Rivet we are currently validating the
contrib plugins
and I am having trouble with yours.

Maybe you could tell me your validation procedure, i.e. which MC you ran
with what channels
and so forth.

I am seeing a factor of 10 discrapancy in a sherpa generic H->gamma gamma
setup.

Best,
Holger
_______________________________________________
Rivet mailing list
Rivet at projects.hepforge.org<mailto:Rivet at projects.hepforge.org>
https://www.hepforge.org/lists/listinfo/rivet


_______________________________________________
Rivet mailing list
Rivet at projects.hepforge.org<mailto:Rivet at projects.hepforge.org>
https://www.hepforge.org/lists/listinfo/rivet




_______________________________________________
Rivet mailing list
Rivet at projects.hepforge.org<mailto:Rivet at projects.hepforge.org>
https://www.hepforge.org/lists/listinfo/rivet







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.hepforge.org/lists-archive/rivet/attachments/20150323/3bf6370c/attachment.html>