Direct Cross Section Calculation

[restrepo]

Dear Florian,
We have problems with the direct detection cross section calculation with micrOMEGAS in a model with the dark matter candidate is degenerate in mass with the other members of some multiplet. To illustrate the problem, we have done one implementation in SARAH of the Inert Doublet Model (attached as SimplifiedDM/IDM) based in the Scotogenic model implementation by Avelino, but following the same conventions that the official implementation of micrOMEGAS in micromegs/IDM folder, e.g., based on arXiv:1003.3125.

To illustrate the problem: we choose a benchmark point with all the inert scalars: H0, A0 and H+ degenerated to a mass of 600 GeV. Then we have

$ ./CalcOmega_with_DDetection_MOv4.2 SPheno.spc.SimplifiedDMIDM
[...]
CDM-nucleon cross sections[pb]:
proton SI 5.598E-05
[...]
In the attachment are also the corresponding LesHouches.in.SimplifiedDMIDM, and SPheno.spc.SimplifiedDMIDM.

This result have two main problems:

1) The DD cross section is independent of the value of the degenerate mass.
2) The DD cross section is orders of magnitude larger that the result obtained with:

2.A) The official micromegs/IDM: (mo.dat attached)

$ ./main mo.dat
[...]
CDM[antiCDM]-nucleon cross sections[pb]:
proton SI 9.597E-10
[...]

2.B) The SARAH implementation but with one small breaking of the degeneracy, for example, for m_H0=600 GeV and m_A0=m_H+=601 GeV:

$ ./CalcOmega_with_DDetection_MOv4.2 SPheno.spc.SimplifiedDMIDM
[...]
CDM-nucleon cross sections[pb]:
proton SI 5.324E-10
[...]

We try to change by hand the masses for m_A0 and m_H+ from 600 to 601 GeV in the original SPheno.spc.SimplifiedDMIDM with degenerate inert scalar masses, but the wrong DD cross section result does not change.

Both problems are illustrated in the attached plot.

A minor problem is that the right result in SARAH is still a factor of 1.5 smaller that the result from the official implementation in micrOMEGAS.

A virtual machine with the ready to compile tools for the model can be used to reproduce all the quoted results just by following the steps in the corresponding ipython notebooks:

http://mybinder.org/repo/restrepo/Simpl ... DM-Toolbox

P.D: In the near future I hope to have some automatic tests for the SARAH-toolbox releases based in this kind of docker images + Travis-CI

[FStaub]

Hi,

the difference is that for the default files, MO picks the neutral guy as DM while for the SARAH generated file it chooses the charged one as long as they are exactly degenerated. The difference seems to be the order in the prtcls1.mdl one file. The DM candidate is the particle which appears first in the case of degenerated masses. Thus, if I put in the SARAH file etp after etI it works even for degenerated masses. I was not aware of this before, and I'm not sure right now, if I can do anything to about that on SARAH. I would think that this should be solved on the MO side, for instance by asking the user in the case of exactly degenerated masses which one should be the DM particle. Of course, this is also not a real physical problem because the ew loop corrections will always give a small mass splitting.

I can't say much right now about the remaining difference. I was looking a bit at the MO implementation and think that here might be a problem

Code: Select all

mu2    |MHX^2-laL*(2*MW/EE*SW)^2
la3    |2*(MHC^2-mu2)/(2*MW/EE*SW)^2
la5    |(MHX^2-MH3^2)/(2*MW/EE*SW)^2
la4    |2*laL-la3-la5

If you use the same conventions in your SARAH file, la5 and la4 ar exchanged, if I'm correct. But, this doesn't change much numerically.


Cheers,
Florian

[restrepo]

Dear Florian,
Thanks for the suggested solution. Regarding the remaining difference, the MO implementation with the conventions that you showed, are just the ones in arXiv:1003.3125, which I implement in the previous attached SARAH model. I had a similar problem with another model and I will also fill a bug report to help to solve the issue.

Cheers,
Diego

[restrepo]

Dear Florian,

Regarding the still open question, I have found a systematic problem in SARAH in the calculation of the direct detection corss section calculation.

To summarize the problem for the IDM model files described before, besides the relic density calculation is the same than in the official IDM implementation of micromegas, as illustrated in the next plot:



The calculation of the direct detection cross section of SARAH is smaller:



by a factor:



We have an implementation in SARAH of the Singlet Doublet Fermion Dark Matter Model in the github repo with the SARAH-toolbox structure:

https://github.com/restrepo/SimplifiedDM-SDFDM-Toolbox

The SARAH model files are in:

SARAH/Models/SimplifiedDM/SDFDM

With a sample of input LHA file and Output file attached. The micromegas output is also attached

The Feynrules model files of the model (plus a decoupled singlet scalar) are in

micromegas/SDFDM/work/models

with a sample input file for the same SARAH point attached. The micromegas output is also attached.

The results presented below were obtained by evaluating all the cells and following the links of the notebook chain:

index.ipynb -> index_bash.ipynb ->tests/SimplifiedDM-SDFDM.ipynb

You can open those notebooks in an executable environment by following the link:

http://mybinder.org/repo/restrepo/Simpl ... DM-Toolbox

or view them directly in github directly as in https://github.com/restrepo/SimplifiedD ... DFDM.ipynb


The results for the SDFDM have the same features:

The relic density calculation is the same than in our SDFDM Feynrules implementation of micromegas, as illustrated in the next plot:



The calculation of the direct detection cross section of SARAH is smaller:



by a factor:



In addition the indirect detection cross section, is also the same in the two implementations:

io.tar.gz

input output for SDFDM in SARAH and FeynRules

(9.92 KiB) Downloaded 189 times

[FStaub]

Hi Diego,

sorry, but I have hardly time right now to do exhaustive checks what might go on. However, I have an educated guess:
Looking at the model files generated by SARAH I see:

Code: Select all

Mu1            |slhaVal("MASS",Q,1,2) 
Mu2            |slhaVal("MASS",Q,1,4) 
Mu3            |slhaVal("MASS",Q,1,6) 
...
Yu11           |(sqrt2*Mu1)/v 
Yu12           |0 
Yu13           |0 
Yu21           |0 
Yu22           |(sqrt2*McEff(Q)*one(QCDok))/v 
Yu23           |0 
Yu31           |0 
Yu32           |0 
Yu33           |(sqrt2*MtEff(Q)*one(QCDok))/v 

Thus, the masses are taken from the SLHA file, but for the Yukawas the QCD running is included. This causes an inconsistency because the direct detection is prop to ~Y/m, i.e. when taking m ~ Y, the DD cross section doesn't depend on the light quark masses respectively small Yukawa couplings. However, this won't be the case in the current setup. Thus, can you try to set

Code: Select all

...
Yu11           |(sqrt2*Mu1)/v 
Yu12           |0 
Yu13           |0 
Yu21           |0 
Yu22           |(sqrt2*Mu2)/v 
Yu23           |0 
Yu31           |0 
Yu32           |0 
Yu33           |(sqrt2*Mu3)/v 

if you find then better agreement?

Cheers,
Florian

[restrepo]

Yes Florian,
That change in func1.mdl SARAH generated file completely solve the problem:



How I could fix the problem in the original model SARAH files?

Thanks in advance,
Diego

[FStaub]

Hi Diego,

good, that this solves the problem. You need to run

Code: Select all

MakeCHep[UseRunningCoupling -> False];

when generating the code with the toolbox or write in your model file

Code: Select all

SetOptions[MakeCHep,UseRunningCoupling -> False]

Cheers,
Florian

[restrepo]

Dear Florian,
Unfortunately after introducing

Code: Select all

SetOptions[MakeCHep,UseRunningCoupling -> False] 

either in the end of the main SARAH model file or at the beginning of SPheno.m, the following kind of errors start to appear after the compilation of the model in micromegas/SimplifiedDMSDFDM:

Code: Select all

make main=CalcOmega.cpp

Code: Select all

VandP.c: In function ‘calcMainFunc’:
VandP.c:72:25: error: expected expression before ‘,’ token
    V[18]=slhaVal("MASS",,1,25);
                         ^

The full output of the micromegas compilation is attached

Any suggestion is welcome,

Cheers,
Diego

[FStaub]

Hi Diego,

I can't reproduce the problem here. Which version of SARAH and Mathematica do you use?
Can you please try for instance the model 'Inert' if you have the same problem there, or if it only shows up for your models.

Cheers,
Florian

[restrepo]

Dear Florian,
With the Simplified/IDM attached model files, and with

Code: Select all

SetOptions[MakeCHep,UseRunningCoupling -> False];

at the end of Simplified/IDM/Simplified-IDM.m

I download the last version of tooolbox:

Code: Select all

wget http://www.hepforge.org/archive/sarah/toolbox-2.0.1.tar.gz

With the mathematica version:

Code: Select all

9.0 for Linux x86 (64-bit) (November 20, 2012)

and the following configuration:

Code: Select all

../configure --disable-whizard --disable-higgsbounds --disable-higgssignals

I get exactly the same error as reported before.

After update toolbox-2.0.1. with SARAH-4.9.0 all the butler's get broken: for example:

Code: Select all

./butler SM

Code: Select all

In[7]:= 
SARAH run finished
./butler: 211: test: /home/restrepo/prog/toolbox/tmp/toolbox-2.0.1/toolbox/SSP/DefaultSettings.m.SM: unexpected operator

Building SPHENO for SM
===============================================================================

copying files...
cp: omitting directory ‘/home/restrepo/prog/toolbox/tmp/toolbox-2.0.1/toolbox/SARAH-4.9.0/Output/SM/EWSB/SPheno//3-Body-Decays’
cp: omitting directory ‘/home/restrepo/prog/toolbox/tmp/toolbox-2.0.1/toolbox/SARAH-4.9.0/Output/SM/EWSB/SPheno//Input_Files’
cp: omitting directory ‘/home/restrepo/prog/toolbox/tmp/toolbox-2.0.1/toolbox/SARAH-4.9.0/Output/SM/EWSB/SPheno//Observables’
cp: omitting directory ‘/home/restrepo/prog/toolbox/tmp/toolbox-2.0.1/toolbox/SARAH-4.9.0/Output/SM/EWSB/SPheno//SSP_Templates’

And the ./butler stops here!