Dose Pineappl support SMEFTatNLO?

Hi,
in principle, it should.
Can you please tell me a bit more what you plan to do, so that I can help with more detailed informations?

Thanks!
cheers,

marco

Hi,

I meet errors when I use pineappl-0.5.0-beta.3 to produce ttbar in QCD at the NLO with the model SMEFTatNLO-NLO.

***the Card****
import model SMEFTatNLO-NLO
    #(I only care for ctu1, but other parameters give the same errors)
generate p p > t t~ NP=2 aEW=0 aS=2 [QCD] NP^2=4
output smeft
fixed_order = ON
set ctu1 1
set pdlabel lhapdf
set lhaid 14000
set pineappl True
done
*******

I get the below errors:
***the error****
Command "launch auto " interrupted with error:
Exception : program smeft/SubProcesses/P0_uxu_ttx/ajob1 1 all 0 1 launch ends with non zero status: 134. Stop all computation
Please report this bug on https://bugs.launchpad.net/mg5amcnlo
More information is found in 'smeft/run_01_tag_1_debug.log'.
Please attach this file to your report.
*******

I read the log.txt file in 'smeft/SubProcesses/P0_uux_ttx/all_G1'
*******
madevent_mintFO: pineappl_interface.cc:125: void appl_init_(): Assertion `(nlo_power == (lo_power + 2)) || (nlo_power == lo_power)' fai$

Program received signal SIGABRT: Process abort signal.
*******
Even I delete this line in smeft/SubProcesses/pineappl_interface.cc:125, It gives errors.

Hi,

I'm trying to reproduce your error, but when I type

  set ctu1 1

the generator complains about it being an unknown option. Is there maybe a typo?

In any case the problem is that the PineAPPL interface can't detect what's supposed to be LO and what should be NLO. Can you tell me what that should be?

Hi,

1). Sorry for the typo 'set ctu1 1', I just want to indicate that you only need this parameter. I have edited it.

2). It should be NLO.

I add some errors in '..../SubProcesses/P0_gg_ttx/all_G1/log.txt'
******
thread '<unnamed>' panicked at 'ndarray: index out of bounds', /home/gaomeisen/.cargo/registry/src/mirrors.ustc.edu.cn-61ef6e0cd06fb9b8/ndarray-0.15.3/src/arrayt$
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
fatal runtime error: failed to initiate panic, error 5

Program received signal SIGABRT: Process abort signal.

Backtrace for this error:
#0 0x7f8c8e594dfd in ???
******

Hi, thanks for the infomation, we can now reproduce the problem and are working on it!

Hi,
we are still investigating.
with this syntax
generate p p > t t~ NP=2 aEW=0 aS=2 [QCD] NP^2=4
you are including up to 4 EFT vertices in the amplitude, is this intended?

Cheers,

Marco

Hi,

The NP=2 means only 1 EFT vertex( ctu1 or ctd1) in each diagram, the NP^2=4 means the amplitude contains SM + interference + NP*NP=4 contributions.

I have set all EFT vertices to 0 except the 2 vertices: ctu1 ctd1, so up to 2 EFT vertices are included in the amplitude.

#( you can set EFT vertices in the 'MG5_aMC_v3_3_0/models/SMEFTatNLO' by copy the 'restrict_default.dat' to a new one, such as 'restrict_ctu1.dat' )

I have tested the syntax 'generate p p > t t~ NP=2 aEW=0 aS=2 [QCD] NP^2==4' which only contains EFT contributions, it can produce right results. So the problem is about the SM+interference terms, which can be produced by 'generate p p > t t~ NP=2 aEW=0 aS=2 [QCD] NP^2=2'.

Cheers,

Meisen

Hi Again,
thanks to Christopher's help, we have figured out where the problem is. It is related to the fact that one has the same coupling combination appearing at the Born and in NLO corrections.
Because of the internal structure of the code, if a coupling combination enters the born then it is not duplicated if it also enters the NLO part. And this creates issues, (un)fortunately only in the PineAPPL part.
(We never considered this possible, as we mostly focused on NLO QCD/EW corrections to SM processes)

We will try to have a look on how to solve this issue, but it may take quite some time

Cheers,

Marco

Thanks Marco and Christopher. Looking forward to your updates.

Hi Meisen,

there are two problems with the detection of whether an order is LO or NLO, which is complicated once you have an EFT:

1) the first one is in Madgraph5_aMC@NLO-PineAPPL interface, which you can fix using the following patch:

  https://gist.github.com/cschwan/99611c7f1c58a30627890bcfb1c72a51

Save the contents to a file called 'fix_nlo_detection.patch', and run `patch -p1 < fix_nlo_detection.patch` in the main folder of Madgraph5_aMC@NLO. This should enable you to run your calculation at LO for the time being (set `order = LO` after `fixed_order = ON`).

Note that the orders in PineAPPL appear as mg5_aMC puts them into the grid and are blind to the additional coupling, so you have look at the log files of the MC to figure out which orders are which. Have a look at the log files in the SubProcesses/P0*/all*/log*.txt, they should tell you this.

2) the second problem is a bit non-trivial to fix, I'm not sure what I can do.

Cheers,
Christopher

Hi Christopher,

Thanks for your patch, I can produce both LO and NLO results now. Are the NLO results physical?

Even without your patch, I can produce NLO EFT results with syntax 'generate p p > t t~ NP=2 aEW=0 aS=2 [QCD] NP^2==4' without errors. Is this result reliable?

Cheers,
Meisen

As far as I understand, NP=2 is shorthand for NP<=2 and selects the EFT coupling at amplitude level, so

- NP==0,
- NP==1 and
- NP==2;

NP^2==4 selects the coupling at *squared* amplitude level, so that means it'll select only the squared diagrams with the highest EFT coupling (because higher order corrections are QCD as per [QCD]).

In that case the detection which orders are LO and which are NLO seems to work, because they have unique couplings. But in terms of EFT you're selecting the least important ones, that's probably (?) not what you want.

@Marco: correct me if I'm wrong.

Hi Christopher,

Thanks again for your answer, the NP^2==4 terms is part of what I want.

As for the patch 'fix_nlo_detection.patch', you said "This should enable you to run your calculation at LO for the time being". But It also works at NLO for the process 'generate p p > t t~ NP=2 aEW=0 aS=2 [QCD] NP^2=4' , Is this a designed function?

Cheers,
Meisen

It should definitely work for LO, NLO might work (seems to be the case for you). In any case you should always compare the MC result against interpolated (PineAPPL) result and check that the differences do not exceed a few per mille at most.

Thanks Christopher, that solved my question!