Cross section growth with energy

First try to find one process which leads to increasing cross section.
It should be better if it will be processes 2->2.

The reason of increasing could be broken gauge invariance. I see the
following reasons for it

a) Your model is formulated in Unitary gauge.  So, there are large
cancellations between  diagrams if energy  become significantly larger
than masses of vector bosons.

You can  use quadruple precision to extend regions where precision is
not lost.

In  Feynman gauge increasing of cross sections is  not expected. Here
violation of gauge invariance appears  via negative cross sections.

b) May be indeed GI is lost in your model.

c) Particle widths can be  a   reason of lost of GI. Use Breit-Wigner
menu to  treat s- and t-channel  width in GI manner.

Best

    Alexander Pukhov

On 11/9/21 20:10, don_ch wrote:
> New question #699414 on CalcHEP:
> https://answers.launchpad.net/calchep/+question/699414
>
> Hi,
>
> I have this model containing hidden SU(2) gauge bosons (called X_1,2,3) and a dark Higgs (H_D). I generated my modelfiles and spectrum file with SARAH and SPheno, and there is no error/warning when compiled.
>
> In CalcHEP I ran a scan over initial momentum p_in the cross section for
>
> X1 X2 > X1 X2 X3
>
> with all subprocesses included. However it grows with p_in, hence with energy. I do not impose any kinematical cuts. Since I am including both hidden gauge bosons and dark Higgs in the amplitudes, I do not expect the characteristic cross section growth with energy from perturbative unitarity. Am I missing something?
>
>
>

Thanks Alexander, I will investigate each of these cases.

This may be related to my issue:

In the code I called (X1,X2,X3) as (Xp,X0,Xm) in notation similar to the triplet of W bosons in the SM, except that these are degenerate and stable. Indeed SPheno.spc does not have decay tables for them. I calculated the cross section

Xp X0 -> Xp X0

with all subprocesses in Feynman gauge decreases with energy (the 1D integration is fast too). However when I ask for

Xp Xm -> Xp Xm

there is a prompt 'Calculation of Constraints' and it seems that CHep starts computing the 4-body decays of X0

X0 -> d1 D1 d1 D1
...
etc

which takes forever. I think the code cares about this because there is a X0 in the s-channel in one of the diagrams.
It is strange that the code tries to compute decays for X0 because I already provided a SLHA file from SPheno.

Here there are two switches:

1) in numerical session   F5(Options)   contains item "SLHA width
On/Off". By default we  have On.  I guess you do not change it.

2)   slhaRead has paprameter "mode"

int slhaRead(char *fname, int mode)

   m1  0 overwrite all;  1 keep old data
   m2  0 ignore mistake  1: stop in case of mistake in input file.
   m4  0 read DECAY      1: don't read   Decay
   m8  0 read BLOCK      1: don't read   Blocks
   m16 0 read QNUMBERS   1: don't read   QNUMBERS

So, if mode==0, CalcHEP has to get width from SLHA file.

So, please check that SLHA file indeed contains X0 decay.

In principle one  X0 -> d1 D1 d1 D1  channel  has to be compiled fast
enough ( like 2->3 process). But if you have a lot of them, then it
indeed can take a large  time.

Best

     Alexander Pukhov

On 11/10/21 22:10, don_ch wrote:
> Question #699414 on CalcHEP changed:
> https://answers.launchpad.net/calchep/+question/699414
>
> Status: Answered => Open
>
> don_ch is still having a problem:
> This may be related to my issue:
>
> In the code I called (X1,X2,X3) as (Xp,X0,Xm) in notation similar to the
> triplet of W bosons in the SM, except that these are degenerate and
> stable. Indeed SPheno.spc does not have decay tables for them. I
> calculated the cross section
>
> Xp X0 -> Xp X0
>
> with all subprocesses in Feynman gauge decreases with energy (the 1D
> integration is fast too). However when I ask for
>
> Xp Xm -> Xp Xm
>
> there is a prompt 'Calculation of Constraints' and it seems that CHep
> starts computing the 4-body decays of X0
>
> X0 -> d1 D1 d1 D1
> ...
> etc
>
> which takes forever. I think the code cares about this because there is a X0 in the s-channel in one of the diagrams.
> It is strange that the code tries to compute decays for X0 because I already provided a SLHA file from SPheno.
>