gridpack production problem for light H+

Hi,

1) Looks like you have issue with the width of 37:
I see the following in your log:

> INFO: We need to recalculate the branching fractions for t~,h+,t
> INFO: using the FeynRules formula present in the model (arXiv:1402.1178)
> WARNING: The LO estimate for the width of particle 37 
> WARNING: differs from the one in the banner by 60154 percent 
> INFO:
> INFO: decay channels for t~ : ( width = 1.466899 GeV )
> INFO: BR d1 d2
> INFO: 1.000000e+00 b~ w-
> INFO:
> INFO:
> INFO: decay channels for h+ : ( width = 0.001659618 GeV )
> INFO: BR d1 d2
> INFO: 1.000000e+00 ta+ vt
> INFO:
> INFO:
> INFO: decay channels for t : ( width = 1.466899 GeV )
> INFO: BR d1 d2
> INFO: 1.000000e+00 b w+
> INFO:
> INFO:
> INFO: decay channels for h- : ( width = 0.001659618 GeV )
> INFO: BR d1 d2
> INFO: 1.000000e+00 ta- vt~
> INFO:
The second error is the following one:

> File "/afs/cern.ch/work/s/slehti/Production/MG5_aMCatNLO/mg265/genproductions/bin/MadGraph5_aMCatNLO/ChargedHiggs_taunu_light_NLO_M160/ChargedHiggs_taunu_light_NLO_M160_gridpack/work/MG5_aMC_v2_6_5/madgraph/core/helas_objects.py", line 5737, in generate_matrix_elements
> "No matrix elements generated, check overall coupling orders"
Which seems to indicate that your process fail to generate the matrix-element with the decay.
Which I guess is linked to the fact that your BR is evaluated to 0 according to the line above.

So in short, it seems that you have some issue with the evaluation of your width/BR

Cheers,

Olivier

> On 23 Aug 2019, at 11:38, S.Lehti <email address hidden> wrote:
>
> New question #683203 on MadGraph5_aMC@NLO:
> https://answers.launchpad.net/mg5amcnlo/+question/683203
>
> Dear experts,
> I'm trying to produce gridpacks with MG 5.2.6.5 for H+ production from top decays. I've managed to produce working gridpacks for low mass points (mH+ 80-100 GeV) only, heavier ones fail. The tarball is produced, but it doesnt work. Here are the datacards and log files.
>
> What am I doing wrong?
>
> Cheers,
> Sami
>
> /afs/cern.ch/user/s/slehti/public/html/ChargedHiggs_taunu_light_NLO_M160 or
>
> cmsdoc.cern.ch/~slehti/ChargedHiggs_taunu_light_NLO_M160/ChargedHiggs_taunu_light_NLO_M160_customizecards.dat
> cmsdoc.cern.ch/~slehti/ChargedHiggs_taunu_light_NLO_M160/ChargedHiggs_taunu_light_NLO_M160_proc_card.dat
> cmsdoc.cern.ch/~slehti/ChargedHiggs_taunu_light_NLO_M160/ChargedHiggs_taunu_light_NLO_M160_extramodels.dat
> cmsdoc.cern.ch/~slehti/ChargedHiggs_taunu_light_NLO_M160/ChargedHiggs_taunu_light_NLO_M160_madspin_card.dat
> cmsdoc.cern.ch/~slehti/ChargedHiggs_taunu_light_NLO_M160/ChargedHiggs_taunu_light_NLO_M160_run_card.dat
>
> cmsdoc.cern.ch/~slehti/ChargedHiggs_taunu_light_NLO_M160/ChargedHiggs_taunu_light_NLO_M160.log
> cmsdoc.cern.ch/~slehti/ChargedHiggs_taunu_light_NLO_M160/pilotrun_tag_1_debug.log
>
> cmsdoc.cern.ch/~slehti/ChargedHiggs_taunu_light_NLO_M160/gridpack_generation.out
> cmsdoc.cern.ch/~slehti/ChargedHiggs_taunu_light_NLO_M160/running.out
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Hi,
I've added a param_card in the card directory,
cmsdoc.cern.ch/~slehti/ChargedHiggs_taunu_light_NLO_M160/ChargedHiggs_taunu_light_NLO_M160_param_card.dat

took H+ width from HDECAY and tried with that. Retried with width*10 and width/10. Still no working gridpacks.
What do I need to change in the cards to get the gridpack production working?

Cheers,
Sami

Hi,
I will not be able to comment without the full log. But this being said your param_card is invalid:
DECAY 37 3.076E-01 # H+ width
# BR NDA ID1 ID2
     1.0 2 15 -16 # BR( H+ -> tau nu )
     1.0 2 -15 16 # BR( H- -> tau nu )
You should only have ONE of those two lines not both. I guess that you should remove the second one.

Cheers,

Olivier

> On 11 Sep 2019, at 14:37, S.Lehti <email address hidden> wrote:
>
> Question #683203 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/683203
>
> Status: Answered => Open
>
> S.Lehti is still having a problem:
> Hi,
> I've added a param_card in the card directory,
> cmsdoc.cern.ch/~slehti/ChargedHiggs_taunu_light_NLO_M160/ChargedHiggs_taunu_light_NLO_M160_param_card.dat
>
> took H+ width from HDECAY and tried with that. Retried with width*10 and width/10. Still no working gridpacks.
> What do I need to change in the cards to get the gridpack production working?
>
> Cheers,
> Sami
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Removed the last line from the param_card. Here are the log files:

cmsdoc.cern.ch/~slehti/ChargedHiggs_taunu_light_NLO_M160/ChargedHiggs_taunu_light_NLO_M160.log_withParamCard
cmsdoc.cern.ch/~slehti/ChargedHiggs_taunu_light_NLO_M160/pilotrun_tag_1_debug.log_withParamCard

cmsdoc.cern.ch/~slehti/ChargedHiggs_taunu_light_NLO_M160/gridpack_generation.out_withParamCard
cmsdoc.cern.ch/~slehti/ChargedHiggs_taunu_light_NLO_M160/running.out_withParamCard

Cheers,
Sami

Dear Sami,
If I understand correctly that you are doing the process
 p p > w- b~ h+ b [QCD]
please be aware of the following issues:
1) you need to enable the complex-mass scheme, and have the model support it
2) it is an extremely complicated process because of the phase space structure, which may not end up generating events. You need resonance aware FKS subtraction and matching to PS. These features are both still not public.

So, at the end, it may be extremely complicated to produce NLO events.

In order to simulate charged higgs production when m_H± ~ mt, back when I was charged Higgs convener, we provided the following recommendations: use the total cross sections available here
https://twiki.cern.ch/twiki/bin/view/LHCPhysics/LHCHXSWGMSSMCharged#Intermediate_mass_145_200_GeV_ch
(computed as described in arXiv:1607.05291) to normalise the sample.
For the events, generate them at LO as described here

https://cp3.irmp.ucl.ac.be/projects/madgraph/wiki/chargedHiggs

and normalise them according to the NLO cross section. To my knowledge, these recommendations were followed by both ATLAS and CMS in the searches in this region.

Please let me know if you need more information.

Best wishes,

Marco

Hi Marco,
We use extramodel 2HDMtypeII.tar.gz which I think was provided by you H+ theory experts some years ago.

For 2016 analysis, we (in CMS) used three overlapping mass regions for H+ -> taunu
-light (mass 80-160, NLO)
-intermediate (mass 145-200, LO)
-heavy (mass 180-3000, NLO)

For 2017 analysis the new gridpack production for the intermediate region (LO) works without a problem.
The heavy H+ production uses NLO, and there is a H+ width/MadSpin problem. Because of this problem we switch MadSpin off for the heaviest part of the heavy H+ production (and let Pythia to do the decay), while the mass points 180-~400/500 use MadSpin. The same needed to be done for the 2016 production.
The light H+ production cant switch MadSpin off, since we need to decay a top to H+, so the problem persists, and that's why I'm here asking for expert help.

Now, do I understand correctly, that we could extend the intermediate mass range to cover also the light H+ mass range, so having a mass 80-200 with the intermediate region model and not to have a separate light H+ gridpacks at all? I tested this and I was able to produce gripdpacks which are working, for all the mass points, all in less than an hour.

What comes to the recommendations, until now I've had an impression that we in CMS switched from Pythia to MG in order to get H+ production at NLO. The intermediate samples are LO only because the model doesnt support NLO. That's why we have an artificial kink in our limits around 160-180 GeV (published in July for the tau+nu final state), since NLO and LO distributions differ, which affects the event selection efficiency.

So my main question now is, is it ok to use intermediate H+ production model down to 80 GeV, or should we find a way to produce the light H+ from top decays (80-160GeV) with an NLO model; after all, it used to work for the 2016 samples.

Cheers,
Sami

Dear Sami,
thanks for your answer.
The answer to your question,
>
> So my main question now is, is it ok to use intermediate H+ production
> model down to 80 GeV, or should we find a way to produce the light H+
> from top decays (80-160GeV) with an NLO model; after all, it used to
> work for the 2016 samples.

is that it should be OK. In principle, the intermediate-mass recommendations include together non-resonant and resonant contributions, so they can be extended all over the mass range. In practice, having dedicated NLO+PS simulations for heavy and light range may be more convenient.
It would be nice to compare what you get in the two ways.

Just for me to know, what is the problem with madspin (I was just called for the last part of your question)?

Thanks,

Marco

> On 12 Sep 2019, at 11:27, S.Lehti <email address hidden> wrote:
>
> Question #683203 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/683203
>
> Status: Answered => Open
>
> S.Lehti is still having a problem:
> Hi Marco,
> We use extramodel 2HDMtypeII.tar.gz which I think was provided by you H+ theory experts some years ago.
>
> For 2016 analysis, we (in CMS) used three overlapping mass regions for H+ -> taunu
> -light (mass 80-160, NLO)
> -intermediate (mass 145-200, LO)
> -heavy (mass 180-3000, NLO)
>
> For 2017 analysis the new gridpack production for the intermediate region (LO) works without a problem.
> The heavy H+ production uses NLO, and there is a H+ width/MadSpin problem. Because of this problem we switch MadSpin off for the heaviest part of the heavy H+ production (and let Pythia to do the decay), while the mass points 180-~400/500 use MadSpin. The same needed to be done for the 2016 production.
> The light H+ production cant switch MadSpin off, since we need to decay a top to H+, so the problem persists, and that's why I'm here asking for expert help.
>
> Now, do I understand correctly, that we could extend the intermediate
> mass range to cover also the light H+ mass range, so having a mass
> 80-200 with the intermediate region model and not to have a separate
> light H+ gridpacks at all? I tested this and I was able to produce
> gripdpacks which are working, for all the mass points, all in less than
> an hour.
>
> What comes to the recommendations, until now I've had an impression that
> we in CMS switched from Pythia to MG in order to get H+ production at
> NLO. The intermediate samples are LO only because the model doesnt
> support NLO. That's why we have an artificial kink in our limits around
> 160-180 GeV (published in July for the tau+nu final state), since NLO
> and LO distributions differ, which affects the event selection
> efficiency.
>
> So my main question now is, is it ok to use intermediate H+ production
> model down to 80 GeV, or should we find a way to produce the light H+
> from top decays (80-160GeV) with an NLO model; after all, it used to
> work for the 2016 samples.
>
> Cheers,
> Sami
>
> --
> You received this question notification because you are subscribed to
> the question.

Hi Marco,
Thanks. We'll make the light H+ samples with the intermediate model then.

I would very much like to have the light NLO samples as well. If possible. What has changed from the 2016 production are the MG version (mg222 vs mg260, tested this also with mg265) and the pdf's. Added line ".true. = store_rwgt_info" in the run card. Compiler, but that should have no effect. I'm not aware of any other changes.

I know the problem is in MadSpin, since when I disable it, everything works. In my earlier posts above you can find links to all the log files which come from the gridpack production for 160 GeV mass point and test running the produced gridpack to get the lhe file. With these cards (also link above for mass 160), I was able to produce gridpacks with MadSpin for mass points 80 and 90, but failed for 100-160.

Cheers,
Sami

Hi,

Concerning MadSpin, I would need more details in order to help with it.
Now this remind me similar issue for that type of particle where the issue was with not madspin itself but the fact that narrow-width approximation was not valid for such benchmark. Could you check what is your width in your case?

If NWA is not valid
1) MadSpin can not be used
2) You should not produce sample from madgraph with that particle onshell (If you do it will not crash but I would not trust the result

Cheers,

Olivier

Hi,
Got Madgraph to generate me a param_card.dat with width

# PDG Width
DECAY 37 1.796702e-03
# BR NDA ID1 ID2 ...
   8.659711e-01 2 16 -15 # 0.00155589218079
   1.340289e-01 3 -5 5 24 # 0.00024081

Cheers,
Sami