Dipole subtraction and VBF+1 jet

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

I have tried generating dipole subtractions terms for the process 93 93 -> 93 93 93 25 with Order_EW=3. (This would be VBF Higgs boson production plus an additional jet in the final state.) However, SHERPA seems to sit for quite some time. In fact it doesn't seem to do anything. The color structures associated with this process are quite simple. I expect there to be on the order of 30 dipole factors that are subtracted. Is there someway to run SHERPA in debug mode?

[marek]

Hi Steffen,

I am afraid this is more your area of expertise. What happens is that it tries to calculate the colour structures for the colour-correlated Born processes underlying both the differential and integrated subtraction terms. In CFColor::BuildTChain in runs into an infinite loop as the last if-statement in l. 577 (if (tmp_list[0][4]==tmp_list[tmp_list.size()-1][6])) is never satisfied, and thus no break statement is hit. The output there tmp_list[0][4]=m vs. tmp_list[tmp_list.size()-1][6]=n. These indices then do not get modified further, thus the infinite loop. Any ideas?

Marek

[Frank Siegert]

The same infinite loop happens also in this simple setup:

(run){
  BEAM_1 = 2212; BEAM_ENERGY_1 = 4000;
  BEAM_2 = 2212; BEAM_ENERGY_2 = 4000;
  NLO_Mode 1
  ME_SIGNAL_GENERATOR=Amegic
}(run)

(processes){
  Process 1 1 -> 1 1
  NLO_QCD_Part I
  End process;
}(processes)

(selector){
  PT 1 20.0 E_CMS
}(selector)

Note that it only happens here if Order_EW is left unrestricted. For both Order_EW=0 and Order_EW=2 it does not happen.

[Steffen Schumann]

The problem seems resolved by the patch I sent around and attach here again.

Replying to fsiegert:

The same infinite loop happens also in this simple setup:

(run){
  BEAM_1 = 2212; BEAM_ENERGY_1 = 4000;
  BEAM_2 = 2212; BEAM_ENERGY_2 = 4000;
  NLO_Mode 1
  ME_SIGNAL_GENERATOR=Amegic
}(run)

(processes){
  Process 1 1 -> 1 1
  NLO_QCD_Part I
  End process;
}(processes)

(selector){
  PT 1 20.0 E_CMS
}(selector)

Note that it only happens here if Order_EW is left unrestricted. For both Order_EW=0 and Order_EW=2 it does not happen.

[Stefan Hoeche]

This fix breaks the RS integration in pp->tt~. The cross section for the setup below should be ~1500 pb (computed with r20291), but it comes out as ~3000 pb (computed with r20310). This finding is confirmed with current MC@NLO, which gives a mu_Q independent prediction as long as mu_Q<350GeV. As far as I can tell from checking the MC@NLO at mu_Q>350GeV the problem lies in the IF dipoles.

(run){
  EVENTS 10000;
  FRAGMENTATION Off;
}(run);

(beam){
  BEAM_1 2212; BEAM_ENERGY_1 4000;
  BEAM_2 2212; BEAM_ENERGY_2 4000;
}(beam);

(processes){
  Process 93 93 -> 6 -6;
  NLO_QCD_Part RS;
  Order_EW 0;
  End process;
}(processes);

(me){
  SCALES VAR{sqr(91.25)}{sqr(91.25)}
  ME_SIGNAL_GENERATOR Amegic;
  EVENT_GENERATION_MODE W;
}(me)

[Stefan Hoeche]

It turns out that the result depends on how the libraries are generated. NLO_Mode 1 and 3 generate different libs (mode 3 generates more / larger libs) and therefore integration results differ slightly. More important though, the initial integration performance is bad, and this leads to the discrepancy, depending on initial conditions. Moving this issue to http://sherpa.hepforge.org/privatetrac/ticket/28