Massive initial states in ISR lead to faulty kinematics

[Frank Siegert]

The following Run.dat contains massive c-quarks in the initial state:

(run){
  BEAM_1=2212; BEAM_ENERGY_1=3500;
  BEAM_2=2212; BEAM_ENERGY_2=3500;
  ME_SIGNAL_GENERATOR   = Comix
  MASSIVE[4]=1
}(run)

(selector){
  Mass 11 -11 60 7000
}(selector)

(processes){
  Process :  4  -4 -> 11  -11
  Order_EW : 2
  End process
}(processes)

During integration this gives errors of the type

SF::CalculateWeight : x out of bounds 4.21123e-08 at 8327.28, xrange = 1e-06 ... 1

which are caused by the fact that the s' passed to the ISR handler is larger than s. So it seems like the ISR channels are doing something wrong.

[Stefan Hoeche]

Tentatively fixed in r16357.

[Frank Siegert]

Patch attached, apply it with

  cd SHERPA-MC-1.2.3
  patch -p0 < heavy-isr.patch
  make install

[Frank Siegert]

One probably minor problem remains: A few % of events from processes of the kind

Process 5 93 -> 5 93;
Order_EW 0;
End process;

are rejected due to a slight violation of momentum conservation:

Blob_List::FourMomentumConservation(): (0x83dcacc) Four Momentum is not conserved.
   p_{in} = (1960,0,0,0) vs. p_{out} = (1959.85,-0.0431269,-0.00352041,-0.149026).

[Frank Siegert]

There is one more related problem that I have just encountered, namely with a setup as follows:

(run){
  BEAM_1=2212; BEAM_ENERGY_1=3500;
  BEAM_2=2212; BEAM_ENERGY_2=3500;
  ME_SIGNAL_GENERATOR   = Comix
  MASSIVE[5]=1
}(run)

(selector){
  ET 5 20.0 E_CMS
  ET -5 20.0 E_CMS
  Energy 5 20.0 E_CMS
  Energy -5 20.0 E_CMS
  PseudoRapidity 5 -5.0 5.0
  PseudoRapidity -5 -5.0 5.0
  DeltaR 5 93 0.4 20.0
  DeltaR -5 93 0.4 20.0

  METS sqr(30/E_CMS)
}(selector)

(processes){
  Process :  5 -5 -> 5 -5 93
  End process
}(processes)

During integration this produces floods of

Channel_Basics::SqLam argument nan <0 in Channel_Basics::sqlam()
s;s1;s2: nan;23.04;23.04
Phase_Space_Handler::Check4Momentum(): {
  p_0 = (3107.09913038,0,0,3107.09542274) (23.0399999999)
  p_1 = (6.14243279152,0,0,3.83268582046) (23.04)
  p_2 = (nan,nan,nan,nan) (nan)
  p_3 = (nan,nan,nan,nan) (nan)
  p_4 = (nan,nan,nan,nan) (nan)
  p_in  = (3113.24156317,0,0,3110.92810856) (14399.3340308)
  p_out = (nan,nan,nan,nan) (nan)
  diff  = (nan,nan,nan,nan) (nan)
}
Channel_Basics::SqLam argument nan <0 in Channel_Basics::sqlam()
s;s1;s2: nan;nan;nan
Channel_Basics::SqLam argument nan <0 in Channel_Basics::sqlam()
s;s1;s2: nan;nan;nan
Channel_Basics::SqLam argument nan <0 in Channel_Basics::sqlam()
s;s1;s2: nan;nan;nan
Channel_Basics::SqLam argument nan <0 in Channel_Basics::sqlam()
s;s1;s2: nan;nan;nan
Channel_Basics::SqLam argument nan <0 in Channel_Basics::sqlam()
s;s1;s2: nan;nan;nan
Channel_Basics::SqLam argument nan <0 in Channel_Basics::sqlam()
s;s1;s2: nan;nan;23.04
Channel_Basics::SqLam argument nan <0 in Channel_Basics::sqlam()
s;s1;s2: nan;nan;nan
TChannelWeight produces a nan!
  ...

They go away if I set MASS[5]=0.01.

[Stefan Hoeche]

This problem is related to the setup of the phase space recursion in Comix. It should be fixed on trunk r16667.

[Frank Siegert]

Sorry, have to reopen: Integration works fine now, thanks. But during event generation with the run card from 07/02 I get loads of warnings like this:

        CS_Cluster_Definitions::CoreScale(): Momentum not conserved.
        \sum p = (-0.00142853,0,0,0.000240675) in
        (0x82531b0): 2 -> 2 {
          \mu_r = 56.1525, \mu_f = 67.8773, \mu = 1122.68
          k_T = 1022.81, z = 0, phi = 0, kin = 0
          oew = 2, oqcd = 2, nlo = 0, new = (<no entry>)
                 (0,4)          bb (-1646.15,0,0,-1646.14) (0,5945) [0|0,0] <-> (1)
                   (1)           b (-2313.2,0,0,2313.2) (5945,0) [1|0,0]
                   (2)           b (1742.33,825.895,-1094.24,1075.27) (5946,0) [1|0,0]
                   (3)          bb (2217.03,-825.895,1094.24,-1742.33) (0,5946) [1|0,0]
        }

[Stefan Hoeche]

This problem is fixed on trunk r16785.

[Frank Siegert]

Sorry, have to reopen this one. Using the following run card,

(run){
  EVENTS=100
  FRAGMENTATION=Off

  MASSIVE[5] 1;
  BEAM_1 =  2212; BEAM_ENERGY_1 = 3500;
  BEAM_2 =  2212; BEAM_ENERGY_2 = 3500;
}(run)

(processes){
  Process 5 -5 -> 11 -11 93 93
  Order_EW 2; Max_N_Quarks 6
  End process;
}(processes)

(selector){
  Mass 11 -11 66 116
  METS sqr(20/E_CMS)
}(selector)

leads to the following error in Comix' PS although I would have expected that the METS cut should take care of all divergences (the cross section also doesn't look very divergent):

TChannelWeight: bad momenta!!!! -1 - 1 (1)
1: (121.556,0,0,121.461)
2: (121.556,0,0,-121.461)
3: (6.60519,0,0,6.60519)
4: (236.506,0,0,-6.60519)
0.679074 pb +- ( 0.3399 pb = 50.0535 % ) 5000 ( 10827 -> 46.1 % )
full optimization:  ( 2s elapsed / 2m 59s left )   
Sherpa: PS_Channel::GenerateChannel throws fatal error: 
   No vertex in z mode 0

[Stefan Hoeche]

A minor modification of the selector section should do the trick here:

  PT 93 1 E_CMS

The cross section itself is not divergent in this process (due to the massive b quarks), and the METS finder takes this into account. But the PS channels are divergent, leading to invalid results in the multi-channel. This is cured by the small p_T cut.

[Stefan Hoeche]

Milestone rel-1.3.0 deleted