Number of generated events in NLO process does not match with nevent specified in run_card.dat

Hi,

I have done the following:

Import model DMsimp_UFO # model from http://feynrules.irmp.ucl.ac.be/raw-attachment/wiki/DMsimp/DMsimp_UFO.2.zip
generate p p > xd xd~ y0
output

# edit cuts.f and add the following cuts:
      ii=0 !need to be define on top
      ij=0 !need to be define on top
      do i=1,nexternal ! loop over all external particles
         if (istatus(i).eq.1 ! final state particle
     & .and. abs(ipdg(i)).eq.9000007) then ! top quark
C apply the pT cut (pT should be large than 200 GeV for the event to
c$$$C pass cuts)
            if (ii.eq.0) then
               ii = i
            else
               ij = i
            endif
         endif
      enddo
      if (( (p(1,ii)+p(1,ij))**2+(p(2,ii)+p(2,ij))**2 ).lt.150d0**2)then
         passcuts_user=.false.
         return
      endif

# run the code (NLO mode with Parton-shower activated--HW6)
./bin/generate_events
set nevents 6000
set mass my0 750
set mass mxd 1
set width all Auto

And I get:
   --------------------------------------------------------------
      Summary:
      Process p p > xd xd~ y0 [QCD]
      Run at p-p collider (6500.0 + 6500.0 GeV)
      Number of events generated: 6000
      Total cross section: 1.216e-03 +- 2.2e-06 pb
   --------------------------------------------------------------

If instead, I run (same mode):
./bin/generate_events
set nevents 6000
set mass my0 300
set mass mxd 1
set width all Auto

I get:
   --------------------------------------------------------------
      Summary:
      Process p p > xd xd~ y0 [QCD]
      Run at p-p collider (6500.0 + 6500.0 GeV)
      Number of events generated: 6000
      Total cross section: 4.345e-02 +- 8.3e-05 pb
   --------------------------------------------------------------

So clearly, I can not reproduce your problem with the information that you provide to me.

Cheers,

Olivier

On 7 Jul 2017, at 05:18, Siew Yan HOH <<email address hidden><mailto:<email address hidden>>> wrote:

New question #646788 on MadGraph5_aMC@NLO:
https://answers.launchpad.net/mg5amcnlo/+question/646788

Hi,

I am working on generating NLO processes in MG5_aMC_v2_5_1 using DMsimp spin0 model. The processes were p p > xd xd~ y0 with [QCD] flag. I have assigned a mediator pt cut at 150 GeV (only the mediator decay to pair of dark matter particles)

Here is my finding:

1.) With the event generation sat with parameter mass point M(y0) = 300 GeV, and M(xd) = 1 GeV, I am puzzled by the fact that out of 6000 event (requested in run card), I received 350 event (~ 6%) stated in the lhe file.

2.) To further on the investigation, i raise M(y0) = 750 GeV, and M(xd) = 1 GeV, i received 6500 events which is more then what i'd requested.

I have confirmed that the number of generated events are determined by the Integrated cross section x unit weight per event.

My question is, is this expected for generating NLO processes under MG5 or did i miss something?

Thanks

Siew Yan

--
You received this question notification because you are an answer
contact for MadGraph5_aMC@NLO.

Hi Oliver,

Thanks for running the test case, we are using this model http://feynrules.irmp.ucl.ac.be/attachment/wiki/DMsimp/DMsimp_s_spin0_UFO.zip for the generation.

We are generating p p > xd xd~ y0 DMS=4 [NLO]

Also, you may need to change the minimum DMS to 4 in coupling_order.py

Can you confirm with the changes and this model file its work fine for you?

Thanks,

Cheers,

Siew Yan

Hi,

Can you confirm that this is actually a loop-induced processes?
So that this is a LO process and not a NLO process as indicated in your last comment?

Therefore to reproduce your result, I'm running the following code:
> import model DMsimp_s_spin0_UFO
> generate p p > xd xd~ y0 DMS=4 [QCD]
> output
> launch
> set nevents 6000
> set ptheavy 150
> set my0 scan:[750, 300]
> set mxd 1
> set width all Auto

I'm running this now, but since it is loop-induced, it will take a (very) long time.

Cheers,

Olivier

> On 7 Jul 2017, at 05:18, Siew Yan HOH <email address hidden> wrote:
>
> New question #646788 on MadGraph5_aMC@NLO:
> https://answers.launchpad.net/mg5amcnlo/+question/646788
>
> Hi,
>
> I am working on generating NLO processes in MG5_aMC_v2_5_1 using DMsimp spin0 model. The processes were p p > xd xd~ y0 with [QCD] flag. I have assigned a mediator pt cut at 150 GeV (only the mediator decay to pair of dark matter particles)
>
> Here is my finding:
>
> 1.) With the event generation sat with parameter mass point M(y0) = 300 GeV, and M(xd) = 1 GeV, I am puzzled by the fact that out of 6000 event (requested in run card), I received 350 event (~ 6%) stated in the lhe file.
>
> 2.) To further on the investigation, i raise M(y0) = 750 GeV, and M(xd) = 1 GeV, i received 6500 events which is more then what i'd requested.
>
> I have confirmed that the number of generated events are determined by the Integrated cross section x unit weight per event.
>
> My question is, is this expected for generating NLO processes under MG5 or did i miss something?
>
> Thanks
>
> Siew Yan
>
>
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Hi Olivier,

The diagram we needed has a box diagram and the only way to generate them is proceeded with [QCD] flag. Therefore in my understanding, the process is NLO which produced via loop induced.

Let me know if you have the test case results. Thanks

Cheers,

Siew Yan

Hi,

> The diagram we needed has a box diagram and the only way to generate
> them is proceeded with [QCD] flag. Therefore in my understanding, the
> process is NLO which produced via loop induced.

Loop induced processes are LO and not NLO accurate. Such process requires the two loop-computation to be NLO accurate.
The dedicated syntax for such kind of processes is technically [noborn=QCD] but you can use the flag [QCD], the code will then try to generate a tree-level born.
In the case where such generation fails, then we automatically alter the syntax to [noborn=QCD].

> Let me know if you have the test case results.

Looks like that I face a bug in the development version of the code. This prevent me to have any result. I have to fix that bug first (will do that on Monday).

Now the fact that you have less event than expected is something possible which is linked to the difficulty of the integration that you perform.
We sometimes failed to generated enough events since we fail to correctly integrate such function.
One setup which can help you to integrate correctly would be run the following command before the generation of your diagram:
set max_npoint_for_channel 4
(You can see page 24 of the loop-induced paper for a description of that option: 1507.00020)

What really worry me actually is the fact that you can have more event than requested. This should never happens.

Cheers,

Olivier

> On 8 Jul 2017, at 22:33, Siew Yan HOH <email address hidden> wrote:
>
> Question #646788 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/646788
>
> Siew Yan HOH posted a new comment:
> Hi Olivier,
>
> The diagram we needed has a box diagram and the only way to generate
> them is proceeded with [QCD] flag. Therefore in my understanding, the
> process is NLO which produced via loop induced.
>
> Let me know if you have the test case results. Thanks
>
> Cheers,
>
> Siew Yan
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Hi,

The process finally ran trough and I have succesfully get my two sample at exactly 6000 events each.
If you still have less events than exxpected, I would suggest to follow my suggestions in the above post.

If you have more events than expected, please contact me again since this should never happen.

Cheers,

Olivier

Hi Olivier,

We have taken sometime to do the cross checking.

Thanks for the suggestion, I have ran with ''set max_npoint_for_channel 4", but the problem is still persisted (some produced with higher number of event and some lower from requested). Could you please check the model file here:

http://shoh.web.cern.ch/shoh/public/DMsimp_s_spin0_300_1_805.tar.gz

The model file is the benchmark used in DMF working group, i assume it was modified compare to the public available DMSimp. The default DM mass is set at 1 GeV, mediator mass at 300, and included 150 GeV cut. Also, the DM coupling set to 1 and quark coupling set to 0.25

Thanks.

Cheers,

Siew Yan

Note: The process is generated with 4 F.

Can you attach, the script file to run your code?
Such that I'm sure to reproduce exactly your run.

Cheers,

Olivier

PS: Note that I'm currently in holliday so I will run this only when i will be back.

Hi Olivier,

Sorry for the delay, and thanks for agreeing to cross check with me. Please download this version of MG5

http://shoh.web.cern.ch/shoh/public/MG5_aMC_v2_5_1.tar.gz

(This version of MG5 has included the model file, and tailored to run within CMSSW_7_1_20 )

please run with ./bin/mg5

generate p p > xd xd~ y0 DMS=4 [QCD]

and change the lhapdf set to 262000 (which is centrally prescribed to all Mono-X +MET signal process spin-0)

Please let me know if you have issue to run it.

Note: The customed MG5 is decoupled from a mega script prepared by MET+X convener, i have configured the "standalone" MG5 which could be run only in CMSSW_7_1_20 for its uses the release's libraries.

Cheers,

Siew Yan

Hi Olivier,

From our side, my college had carried out study on the two model , the publicly available model (UFO) and the hardcoded model from our convener. I have chosen benchmarks on the study, I am reporting the cross section here:

DMsimp_s_spin0 (taken from public ) :

Mphi-1000 Mchi 1 xsec = .00000083362
Mphi-300 Mchi-100 xsec = 0.0025425181
Mphi-10 Mchi-50 xsec = 0.00116086

From hardcoded:

Mphi-1000 Mchi 1 xsec = 6.946740047e-09
Mphi-300 Mchi-100 xsec = 9.809902e-06
Mphi-10 Mchi-50 xsec = 7.48405e-05

Also, during the generation i have come across this warning message

"WARNING: Channel has a very low efficiency of unweighting madgraph"

Looking forward to hear from you and thanks!

Cheers,

Siew Yan

This question was expired because it remained in the 'Open' state without activity for the last 15 days.