TTbar+Higgs cross section

[Stefan Hoeche]

Taken from previous email by Alistair:

I have been trying to do some Higgs simulations using Sherpa, predominantly ttH (often with your very useful help), however, my latest cross-sections still don't seem to tally with other results.

I've done a quick summary table of my results here: ​http://ppewww.physics.gla.ac.uk/~ahgemmell/xsections/CSC_Comparison

In short, the ttH cross-section for 14 TeV is given by the CSC note as 50fb (k-factor 1.2), whereas Sherpa suggests a value of 85.48fb. For WH at 14 TeV, an independent analysis using Pythia and Comphep returned cross-sections of 48.1fb and 49.6fb respectively, while Sherpa returns a value of 188.73.

[Stefan Hoeche]

This is the runcard we used for 1.2.0. I am somewhat puzzled by the big differences between the 1.2.0 and 1.2.1 results on Alistairs website, as nothing should have changed between the two versions concerning the matrix elements.

(run){
  FRAGMENTATION Off;
  SHOWER_GENERATOR None;
}(run)
(beam){
  BEAM_1          = 2212
  BEAM_ENERGY_1   = 7000.
  BEAM_2          = 2212 
  BEAM_ENERGY_2   = 7000.
}(beam)
(isr){
  PDF_LIBRARY     = CTEQ6Sherpa
  PDF_SET         = cteq6l1
}(isr)
(model){
  ACTIVE[15]	  = 0
  MASSIVE[5]      = 1
}(model)
(me){
  ME_SIGNAL_GENERATOR = Comix
  # geometric mean of m_T of the tops
  SCALES VAR{sqrt(MPerp2(p[4]+p[5]+p[6])*MPerp2(p[7]+p[8]+p[9]))}
  COUPLINGS VAR{sqr(Alpha_QCD(MU_F2)/Alpha_QCD(S_TOT))};
}(me)
(processes){
  # --- j-initiated processes ---
  Process 93 93 -> 25[a] 6[b] -6[c]
    Decay 25[a] -> 5 -5	
    DecayOS 6[b] -> 5 90 91
    DecayOS -6[c] -> -5 93 93
  # Order_QCD 2
  Max_Epsilon 1e-4
  End process
}(processes)

[Stefan Hoeche]

I made a comparison between 1.2.0, 1.2.1 and a recent trunk version using the runcard below (properly adapted for trunk, i.e. omitting the COUPLINGS tag). Results are as follows:

                  rel-1-2-0@r14682             rel-1-2-1@r14753             trunk@r15022

TTH @  7 TeV      0.0171729 +- 0.000141009     0.0171729 +- 0.000141009     0.0173277 +- 0.000115113
    @ 14 TeV      0.113694  +- 0.00112892      0.113694  +- 0.00112892      0.111115  +- 0.00107955

with cteq6l -> a_s(m_z) = 0.118

    @  7 TeV                                                                0.0146741 +- 0.000145653
    @ 14 TeV                                                                0.0969557 +- 0.000963227

It should be stressed that trunk is using an entirely different coupling reweighting, so the error is most likely not to stem from the COUPLINGS tag. All values agree within 2.5 x the estimated MC error (As expected, rel-1.2.0 and 1.2.1 give identical results.). Differences between the results from 1.2.0 and 1.2.1 as quoted on ​http://ppewww.physics.gla.ac.uk/~ahgemmell/xsections/CSC_Comparison will most probably arise from the fact that in the runcard above, the running coupling parameters were inconsistent with those required by the PDF and Sherpa 1.2.1 enforces the values used in the PDF automatically (me culpa, i 'checked' the input before). This problem is solved in the runcard below, however this doesn't make up for the large difference compared to the CSC note.

(run){
  FRAGMENTATION Off; SHOWER_GENERATOR None;
  EVENTS 0; ECMS:=7000;
}(run)
(beam){
  BEAM_1 2212; BEAM_ENERGY_1 ECMS/2;
  BEAM_2 2212; BEAM_ENERGY_2 ECMS/2;
}(beam)
(isr){
  PDF_LIBRARY CTEQ6Sherpa;
  PDF_GRID_PATH CTEQ6Grid;
  PDF_SET cteq6l1;
}(isr)
(model){
  ORDER_ALPHAS 0; ALPHAS(MZ) 0.129783;
  ACTIVE[15] 0;
}(model)
(me){
  ME_SIGNAL_GENERATOR Comix;
  SCALES VAR{max(MPerp2(p[4]+p[5]+p[6]),MPerp2(p[7]+p[8]+p[9]))};
  COUPLINGS VAR{sqr(Alpha_QCD(MU_F2)/Alpha_QCD(S_TOT))};
}(me)
(processes){
  Process 93 93 -> 25[a] 6[b] -6[c];
    Decay 25[a] -> 5 -5;
    DecayOS 6[b] -> 5 90 91;
    DecayOS -6[c] -> -5 93 93;
  End process;
}(processes)

[Generic User (don't modify these fields)]

For reference, the CSC cross-section is on p1336, table 1 of ​http://cdsweb.cern.ch/record/1125884/files/CERN-OPEN-2008-020.pdf

[Stefan Hoeche]

I found the culprit here: The default setting of the total width of the Higgs in Sherpa is taken from NLO calculations, giving 3.6 MeV. Now using LO and all possible decay channels gives 6.11 MeV instead. Therefore, when computing the decay with Sherpa (LO!), the h->bb channel alone has BR>1, which is obviously inconsistent. The proper solution is to override the Higgs width setting in the model section of the above runcard using

  WIDTH[25] 0.00611;

This gives a cross section of 68.7+-0.7 fb. Applying the lepton filter efficiency quoted in the CSC brings this down to 65.5 fb. It should also be stressed that the LO BR of h->bb is _not_ 67.5%, but rather 88.3%. Taking this into account, we arrive at 50.0 fb, which is the desired result.

Alistair, thanks a lot for pointing out this problem, we will discuss how to resolve the issue in general. For the time being, setting the width explicitly as shown above and applying a correction factor for the BRs should work without any problems.

[Jan Winter]

I ran into the same problem when I did crosschecks for Sherpa 1.1.3 to validate the LO production xsecs for gg->h @ Tevatron and needed to know the partial width of h->bbbar to extract these values. At that time I learned if I were to use this decay channel and want to be consistent that I would have to adjust the total higgs width input to what Sherpa would give me (@ LO of course) for a specified b quark mass. Otherwise I might end up with branching fractions that do not add up to 1. This confirms what Stefan wrote in his last comment. Here's an example to back it up a little: for a higgs mass of 120 GeV and mb=4.8 GeV, I found BF(h->bbar)=1.518 using Gamma_tot(h)=0.00356 GeV (from Higlu) which is 2.2356 times higher than the Higlu BF. Using the ratio of both BF values I find a b quark mass of 3.2 GeV for the Higlu BF (assuming that the partial width scales quadratically with mass). This corresponds approximately to a running b quark mass at the scale of the mass of the Higgs. That tells me that engineering the b quark mass in the setup (either directly or by changing the Yukawa mass setting for the bs) may be another possibility to get Sherpa's xsecs agree with the other predictions.

[Frank Siegert]

I agree with Jan that the simple and correct solution of this problem seems to be to enable the running of the b mass. This can be done with the switch

(me){
  YUKAWA_MASSES=Running
}(me)

This will have an influence on Interaction_Model_Base::ScalarFunction in the Running_Mass case and the only places where that's used are Interaction_Model_Higgs_SM::c_FFS and Interaction_Model_SM_Phantom_U1::c_FFS, i.e. exactly the ones where we want to be using the running mass of the b quark, right?

So the only thing needed to fix this bug, is to change the default setting of YUKAWA_MASSES from Fixed to Running and a documentation of that parameter in our manual where it seems to be missing. Right?

[Frank Siegert]

Sorry, one more remark: In Comix I couldn't find any usage of the running mass from the Interaction_Model. Where does it take the yukawa couplings from?

[Stefan Hoeche]

Enabling the running masses is not sufficient for Comix, as it is not yet using the interaction models. I will take care of this, but I have a question: As we have a development branch, where Comix _is_ using the interaction models and as this branch will hopefully soon be merged into trunk, I would like to avoid unnecessary doubling of all structures. What else (except for the running masses in the ffh-couplings) do we _really_ need from the interaction models for a 'consistent' SM setup?

[Stefan Hoeche]

Another remark: this will anyway not solve the problem that in our _default_ setup the higgs BR's do not add up to one, which is an extremely bad 'feature'. I would therefore strongly suggest to use the running masses for the definition of the yukawa couplings in the read-in routine of the Model_Base.

[Frank Siegert]

Replying to stefan:

Another remark: this will anyway not solve the problem that in our _default_ setup the higgs BR's do not add up to one, which is an extremely bad 'feature'. I would therefore strongly suggest to use the running masses for the definition of the yukawa couplings in the read-in routine of the Model_Base.

This seems to have been a misunderstanding, so just to make it clear: I proposed to set YUKAWA_MASSES=Running by default, then the BR's should add up to one.

[Stefan Hoeche]

All necessary coding is done (was done quite some time ago, actually) and a first test was successful. However, as this is quite a drastic change of our default settings, I would like the whole thing to be cross-checked before the release.

[Jan Winter]

Given the Run.dat card displayed in Stefan's comment on 19/05/10 (and after removing the "COUPLINGS ..." line in the (me) section), I finally tested the ttH cross sections with trunk version r15268. Defining the Yukawa masses as running in the read-in routine of the Model_Base (our new default) does the job: I obtain the following results ... @ 14 TeV: (56.21+/-0.55)fb (to compare with CERN-OPEN-2008-020 p1335 paragraph2 one needs to multiply with the lepton filter efficiency eps=0.953 to arrive at 53.6 fb, there is also a combinatorics factor of 2) [@ 14 TeV: enforcing YUKAWA_MASSES=Fixed will give (113.6+/-1.1)fb] @ 7 TeV: (8.539+/-0.058)fb I also checked what we get from the Run.dat that comes with our Examples/LHC_TTH: (87.65+/-0.50)fb which however includes also the tau decay channel; disabling the taus brings us back to (58.50+/-0.44)fb.

Also wanted to check the WH numbers, tried out a few cases but always get considerably larger xsecs but I guess I miss some information to do the comparison reliably. I couldn't get Alistair's link working.

[Stefan Hoeche]

Milestone old deleted