Madspin uses different param_card than the one written by my UFO model 2HDMtII_NLO

The option ms_dir should either
1) not be used
2) point to an non-existing (or empty) directory
3) point to a valid directory which was used for THE exact same computation. (for madspin)

Looks like you try to point to an existing directory where another type of madspin (or other) computation was made and the code crash accordingly since this is very dangerous.

Solution is likely to remove the line
set ms_dir ./madspingrid
or to remove that directory first.

Cheers,

Olivier

Thanks Olivier for your fast reply !

I did remove the madspingrid dir as well I did re-generate the gridpack without set ms_dir ./madspingrid line and both give me the same error :

set max_weight_ps_point 400 # number of PS to estimate the maximum for each event
decay h3 > b b~
decay z > l+ l-
launch
^[[1;34mWARNING: set the mass of the b-quark to its value in the param_card.dat: 4.92 GeV ^[[0m
INFO:
INFO: decay channels for h2 : ( width = 138.4321 GeV )
INFO: BR d1 d2
INFO: 9.452454e-01 z h3
INFO: 4.709890e-02 b~ b
INFO: 5.993875e-03 ta+ ta-
INFO: 7.610615e-04 h1 h1
INFO: 5.598777e-04 t~ t
INFO: 2.281644e-04 w- w+
INFO: 1.127604e-04 z z
INFO: 9.972030e-25 a a
INFO:
INFO:
INFO: decay channels for h3 : ( width = 4.110495 GeV )
INFO: BR d1 d2
INFO: 8.855380e-01 b~ b
INFO: 1.008393e-01 ta+ ta-
INFO: 1.289610e-02 t~ t
INFO: 7.265975e-04 z h1
INFO:
INFO:
INFO: decay channels for z : ( width = 2.411753 GeV )
INFO: BR d1 d2
INFO: 1.520664e-01 s~ s
INFO: 1.520664e-01 d~ d
INFO: 1.502671e-01 b~ b
INFO: 1.178220e-01 c~ c
INFO: 1.178220e-01 u~ u
INFO: 6.878158e-02 vt~ vt
INFO: 6.878158e-02 vm~ vm
INFO: 6.878158e-02 ve~ ve
INFO: 3.453710e-02 ta+ ta-
INFO: 3.453710e-02 mu+ mu-
INFO: 3.453710e-02 e+ e-
INFO:
INFO: generating the production square matrix element
INFO: generate p p > h2 > h3 Z b b~ @0 --no_warning=duplicate;define pert_QCD = -4 -3 -2 -1 1 2 3 4 21;add process p p > h2 > h3 Z b b~ pert_QCD @0 --no_warning=duplicate;
Traceback (most recent call last):
  File "/scratch/kjaffel/25790206/tmp.4eV6UfOfno/lheevent/mgbasedir/MadSpin/madspin", line 137, in <module>
    cmd_line.import_command_file(input_file)
  File "/scratch/kjaffel/25790206/tmp.4eV6UfOfno/lheevent/mgbasedir/madgraph/interface/extended_cmd.py", line 1660, in import_command_file
    self.exec_cmd(line, precmd=True)
  File "/scratch/kjaffel/25790206/tmp.4eV6UfOfno/lheevent/mgbasedir/madgraph/interface/extended_cmd.py", line 1543, in exec_cmd
    stop = Cmd.onecmd_orig(current_interface, line, **opt)
  File "/scratch/kjaffel/25790206/tmp.4eV6UfOfno/lheevent/mgbasedir/madgraph/interface/extended_cmd.py", line 1463, in onecmd_orig
    return func(arg, **opt)
  File "/scratch/kjaffel/25790206/tmp.4eV6UfOfno/lheevent/mgbasedir/madgraph/various/misc.py", line 100, in f_with_no_logger
    out = f(self, *args, **opt)
  File "/scratch/kjaffel/25790206/tmp.4eV6UfOfno/lheevent/mgbasedir/MadSpin/interface_madspin.py", line 617, in do_launch
    self.options)
  File "/scratch/kjaffel/25790206/tmp.4eV6UfOfno/lheevent/mgbasedir/MadSpin/decay.py", line 2045, in __init__
    self.generate_all_matrix_element()
  File "/scratch/kjaffel/25790206/tmp.4eV6UfOfno/lheevent/mgbasedir/madgraph/various/misc.py", line 100, in f_with_no_logger
    out = f(self, *args, **opt)
  File "/scratch/kjaffel/25790206/tmp.4eV6UfOfno/lheevent/mgbasedir/madgraph/various/misc.py", line 1888, in deco_f_set
    out = f(*args, **opt)
  File "/scratch/kjaffel/25790206/tmp.4eV6UfOfno/lheevent/mgbasedir/MadSpin/decay.py", line 2704, in generate_all_matrix_element
    mgcmd.exec_cmd(commandline, precmd=True)
  File "/scratch/kjaffel/25790206/tmp.4eV6UfOfno/lheevent/mgbasedir/madgraph/interface/extended_cmd.py", line 1543, in exec_cmd
    stop = Cmd.onecmd_orig(current_interface, line, **opt)
  File "/scratch/kjaffel/25790206/tmp.4eV6UfOfno/lheevent/mgbasedir/madgraph/interface/extended_cmd.py", line 1463, in onecmd_orig
    return func(arg, **opt)
  File "/scratch/kjaffel/25790206/tmp.4eV6UfOfno/lheevent/mgbasedir/madgraph/interface/master_interface.py", line 292, in do_output
    self.cmd.do_output(self, line, *args, **opts)
  File "/scratch/kjaffel/25790206/tmp.4eV6UfOfno/lheevent/mgbasedir/madgraph/interface/madgraph_interface.py", line 7663, in do_output
    self.finalize(nojpeg, flaglist=flaglist)
  File "/scratch/kjaffel/25790206/tmp.4eV6UfOfno/lheevent/mgbasedir/madgraph/interface/madgraph_interface.py", line 7951, in finalize
    wanted_couplings)
  File "/scratch/kjaffel/25790206/tmp.4eV6UfOfno/lheevent/mgbasedir/madgraph/iolibs/export_v4.py", line 890, in convert_model
    model_builder.build(wanted_couplings)
  File "/scratch/kjaffel/25790206/tmp.4eV6UfOfno/lheevent/mgbasedir/madgraph/iolibs/export_v4.py", line 5601, in build
    self.write_all()
  File "/scratch/kjaffel/25790206/tmp.4eV6UfOfno/lheevent/mgbasedir/madgraph/iolibs/export_v4.py", line 5653, in write_all
    self.copy_standard_file()
  File "/scratch/kjaffel/25790206/tmp.4eV6UfOfno/lheevent/mgbasedir/madgraph/iolibs/export_v4.py", line 5668, in copy_standard_file
    self.dir_path)
  File "/scratch/kjaffel/25790206/tmp.4eV6UfOfno/lheevent/mgbasedir/madgraph/iolibs/files.py", line 144, in cp
    shutil.copytree(path1, path2)
  File "/cvmfs/cms.cern.ch/slc7_amd64_gcc700/external/python/2.7.14-pafccj/lib/python2.7/shutil.py", line 185, in copytree
    names = os.listdir(src)
OSError: [Errno 2] No such file or directory: '/scratch/kjaffel/25790206/tmp.4eV6UfOfno/lheevent/mgbasedir/models/template_files/fortran/printout.f'
gzip: events_decayed.lhe.gz: No such file or directory
mv: cannot stat '/scratch/kjaffel/25790206/tmp.4eV6UfOfno/lheevent/process/events_decayed.lhe': No such file or directory

more about the log here: https://cp3.irmp.ucl.ac.be/~kjaffel/forOlivier_different_param_card_issue/slurm-25790206_1.out

I think that line is needed so that all info is preserved and Madspin can decay the events in the generation, what it seems to me here that MG5 is trying to recompile the Fortran version which is removed from the gridpack, I don't know what I can do else!

Cheers,

Khawla

This seems to be an issue of the cms stack on which we can not comment since those issue are due to patch decided by CMS.
So I would suggest that you contact them.

I have a look at the param_card_default.dat in `process/madspingrid/ (decay_me or full_me )` dir :
https://cp3.irmp.ucl.ac.be/~kjaffel/forOlivier_different_param_card_issue/param_card_default.dat

It's different from the default one I get with the `write_param_card.py` script inside my `models/2HDMtII_NLO` : https://cp3.irmp.ucl.ac.be/~kjaffel/forOlivier_different_param_card_issue/param_card.dat

The first automatically generated by MG5 following the UFO model and the latest automatically generated by the UFO.
I don't see a reason why these default cards should be different!

Cheers,
Khawla

Hi,

I finally fixed the issue with 2.9.3 (and likely 3.1.0) for python3 and gridpack mode.
So I'm now finally able to go back to the original question of this thread.

I have run the following script and did not face any issue that the card are not matching.
So maybe you can try to use 2.9.3 (if you use python2.7) or better try with this version:
lp:~maddevelopers/mg5amcnlo/2.9.4

Cheers,

Olivier

PS: Here is the script that i use for my test

! rm -rf /tmp/ms
import model 2HDMtII_NLO
generate g g > t t~
output
launch
madspin=ON
edit madspin_card --after_line=banner set ms_dir /tmp/ms
set use_syst False
set nevents 1k
launch

Hello Olivier,

Thanks a lot for checking.
I did run your script with mg293 but I still see a difference in cards:

If you look at the /tmp/ms/param_card.dat of your test
and the param_card.dat that you have to generate with the write_param_card.py` script in your `mg_vxxx / models / 2HDMtII_NLO` you will see that they are not the same!

It's not a simple difference and it looks dangerous to me:
There is additional Block QNUMBERS 250 and 251 as well the number of spin states (2S+1) is not the same!

I just want to point that if someone needs to use param_card.dat instead of a customized card generating a default card with models/2HDMtII_NLO/write_param_card.py to work with will result in using the wrong card that may crash later in the generation step with the error I mentioned above ( that was my mistake )!

So instead, I did a similar test to yours and I uses the param_card I get from generating a random process after importing my model with madspin=ON.

Cheers,
Khawla

Could you remind me what a customised card is?
This is something specific to CMS framework that we do not have in mg5amc

cheers,

Olivier

> On 20 May 2021, at 15:11, Khawla Jaffel <email address hidden> wrote:
>
> Question #697008 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/697008
>
> Khawla Jaffel posted a new comment:
> Hello Olivier,
>
> Thanks a lot for checking.
> I did run your script with mg293 but I still see a difference in cards:
>
> If you look at the /tmp/ms/param_card.dat of your test
> and the param_card.dat that you have to generate with the write_param_card.py` script in your `mg_vxxx / models / 2HDMtII_NLO` you will see that they are not the same!
>
> It's not a simple difference and it looks dangerous to me:
> There is additional Block QNUMBERS 250 and 251 as well the number of spin states (2S+1) is not the same!
>
> I just want to point that if someone needs to use param_card.dat instead
> of a customized card generating a default card with
> models/2HDMtII_NLO/write_param_card.py to work with will result in using
> the wrong card that may crash later in the generation step with the
> error I mentioned above ( that was my mistake )!
>
> So instead, I did a similar test to yours and I uses the param_card I
> get from generating a random process after importing my model with
> madspin=ON.
>
> Cheers,
> Khawla
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Hello,

customized card look somthing like this :

# Settings for the Higgs potential
set param_card higgs 1 0.0655307646
set param_card higgs 2 0.0655307646
set param_card higgs 3 0.161002788
# Settings 2hdm parameters
set param_card frblock 1 1.0 # tanbeta
set param_card frblock 2 0.99 # sinbma
# Settings for the scalar bosons masses
set param_card mass 25 125.0 # h1: h
set param_card mass 35 200.0 # h2: H
set param_card mass 36 50.0 # h3: A
set param_card mass 37 200.0 # hc: Hc
# Settings for the scalar widths
set param_card width 36 Auto
set param_card width 35 0.96446288

 Commonly used by CMS true for gridpack production but sometimes we attempt to force Madspin to work, so we use the full param_card.dat with the needed decay table ( width and BR ) for the generated process.

Cheers,
Khawla

If i look at the difference between the Cards:

diff PROC_2HDMtII_NLO_21/Cards/param_card_default.dat /tmp/ms/production_me/Cards/param_card.dat
I do not see any difference between significant difference between the two cards. (only width related as expected since the _default card does not contains BR for madspin.

So I guess that your complain has nothing to do with madspin but the fact that the param_card_default.dat
(and/or the param_card.dat is not the same as the one of the file created within the UFO model).

This is in general True and they are plenty of reason why this can happens.
The most typical reason is that a file restrict_default.dat does exists in the UFO model which removes a lot of parameter (and vertex) from the model and therefore param_card. However, this is not your case

The second reason is that your model is a NLO model but you are doing LO computation in a unitary gauge.
Consequently some model information are not necessary and those are trimmed from the model (and in consequence from the param_card). This is in particular true for ghost and goldstone particle.
So the fact that particle are not defined anymore in the "QNUMBERS" block is actually directly related to that.

> as well the number of spin states (2S+1) is not the same!

This is a bug at the FR level, I have open a ticket for that : https://feynrules.irmp.ucl.ac.be/ticket/106#ticket <https://feynrules.irmp.ucl.ac.be/ticket/106#ticket>

Cheers,

Olivier

< DECAY 6 1.508336e+00 # WT
< DECAY 23 2.495200e+00 # WZ
< DECAY 24 2.085000e+00 # WW
< DECAY 25 1.000000e+00 # Wh1
< DECAY 35 1.000000e+00 # Wh2
< DECAY 36 1.000000e+00 # Wh3
< DECAY 37 1.000000e+00 # whc
< ## Dependent parameters, given by model restrictions.
< ## Those values should be edited following the
< ## analytical expression. MG5 ignores those values
< ## but they are important for interfacing the output of MG5
< ## to external program such as Pythia.
< DECAY 1 0.000000e+00 # d : 0.0
< DECAY 2 0.000000e+00 # u : 0.0
< DECAY 3 0.000000e+00 # s : 0.0
< DECAY 4 0.000000e+00 # c : 0.0
< DECAY 5 0.000000e+00 # b : 0.0
< DECAY 11 0.000000e+00 # e- : 0.0
< DECAY 12 0.000000e+00 # ve : 0.0
< DECAY 13 0.000000e+00 # mu- : 0.0
< DECAY 14 0.000000e+00 # vm : 0.0
< DECAY 15 0.000000e+00 # ta- : 0.0
< DECAY 16 0.000000e+00 # vt : 0.0
< DECAY 21 0.000000e+00 # g : 0.0
< DECAY 22 0.000000e+00 # a : 0.0
< #===========================================================
< # QUANTUM NUMBERS OF NEW STATE(S) (NON SM PDG CODE)
< #===========================================================
146a119,202
> #
> #*************************
> # Decay widths *
> #*************************
> #
> # PDG Width
> DECAY 1 0.000000e+00
> #
> # PDG Width
> DECAY 2 0.000000e+00
> #
> # PDG Width
> DECAY 3 0.000000e+00
> #
> # PDG Width
> DECAY 4 0.000000e+00
> #
> # PDG Width
> DECAY 5 0.000000e+00
> #
> # PDG Width
> DECAY 6 1.466899e+00
> # BR NDA ID1 ID2 ...
> 1.000000e+00 2 24 5 # 1.466899275807367
> #
> # PDG Width
> DECAY 11 0.000000e+00
> #
> # PDG Width
> DECAY 12 0.000000e+00
> #
> # PDG Width
> DECAY 13 0.000000e+00
> #
> # PDG Width
> DECAY 14 0.000000e+00
> #
> # PDG Width
> DECAY 15 0.000000e+00
> #
> # PDG Width
> DECAY 16 0.000000e+00
> #
> # PDG Width
> DECAY 21 0.000000e+00
> #
> # PDG Width
> DECAY 22 0.000000e+00
> #
> # PDG Width
> DECAY 23 2.412132e+00
> # BR NDA ID1 ID2 ...
> 1.520426e-01 2 3 -3 # 0.36674676344525575
> 1.520426e-01 2 1 -1 # 0.36674676344525575
> 1.504006e-01 2 5 -5 # 0.3627861343054578
> 1.178035e-01 2 4 -4 # 0.28415753968771834
> 1.178035e-01 2 2 -2 # 0.28415753968771834
> 6.877077e-02 2 16 -16 # 0.16588420184926503
> 6.877077e-02 2 14 -14 # 0.16588420184926503
> 6.877077e-02 2 12 -12 # 0.16588420184926503
> 3.453168e-02 2 15 -15 # 0.08329497809172756
> 3.453168e-02 2 13 -13 # 0.08329497809172756
> 3.453168e-02 2 11 -11 # 0.08329497809172756
> #
> # PDG Width
> DECAY 24 2.003002e+00
> # BR NDA ID1 ID2 ...
> 3.333333e-01 2 4 -3 # 0.6676673732925958
> 3.333333e-01 2 2 -1 # 0.6676673732925958
> 1.111111e-01 2 16 -15 # 0.22255579109753199
> 1.111111e-01 2 14 -13 # 0.22255579109753199
> 1.111111e-01 2 12 -11 # 0.22255579109753199
> #
> # PDG Width
> DECAY 25 1.000000e+00
> #
> # PDG Width
> DECAY 35 1.000000e+00
> #
> # PDG Width
> DECAY 36 1.000000e+00
> #
> # PDG Width
> DECAY 37 1.000000e+00

> On 20 May 2021, at 15:20, Olivier Mattelaer <email address hidden> wrote:
>
> Could you remind me what a customised card is?
> This is something specific to CMS framework that we do not have in mg5amc
>
> cheers,
>
> Olivier
>
>> On 20 May 2021, at 15:11, Khawla Jaffel <email address hidden> wrote:
>>
>> Question #697008 on MadGraph5_aMC@NLO changed:
>> https://answers.launchpad.net/mg5amcnlo/+question/697008
>>
>> Khawla Jaffel posted a new comment:
>> Hello Olivier,
>>
>> Thanks a lot for checking.
>> I did run your script with mg293 but I still see a difference in cards:
>>
>> If you look at the /tmp/ms/param_card.dat of your test
>> and the param_card.dat that you have to generate with the write_param_card.py` script in your `mg_vxxx / models / 2HDMtII_NLO` you will see that they are not the same!
>>
>> It's not a simple difference and it looks dangerous to me:
>> There is additional Block QNUMBERS 250 and 251 as well the number of spin states (2S+1) is not the same!
>>
>> I just want to point that if someone needs to use param_card.dat instead
>> of a customized card generating a default card with
>> models/2HDMtII_NLO/write_param_card.py to work with will result in using
>> the wrong card that may crash later in the generation step with the
>> error I mentioned above ( that was my mistake )!
>>
>> So instead, I did a similar test to yours and I uses the param_card I
>> get from generating a random process after importing my model with
>> madspin=ON.
>>
>> Cheers,
>> Khawla
>>
>> --
>> You received this question notification because you are an answer
>> contact for MadGraph5_aMC@NLO.
>

Hello Olivier,

> as well the number of spin states (2S+1) is not the same!

This is a bug at the FR level, I have open a ticket for that : https://feynrules.irmp.ucl.ac.be/ticket/106#ticket <https://feynrules.irmp.ucl.ac.be/ticket/106#ticket>

I don't have access to this link!

So which card has the right (2S+1): /tmp/ms/production_me/Cards/param_card.dat or the file created within the UFO 2HDMtII_NLO model ?

Should I be worried about this bug? Is this an easy/quick fix so the authors will download soon a newer version of the 2HDMtII_NLO model?

Cheers,
Khawla

> I don't have access to this link!

Maybe you need to create a feynrules account ;-)

> So which card has the right (2S+1):
> /tmp/ms/production_me/Cards/param_card.dat or the file created within
> the UFO 2HDMtII_NLO model ?

I do believe that the correct one is the one in /tmp/ms/production_me/Cards/param_card.dat.
But the FR author's might object to that. If so everyone will need to read the SLHA convention to see what is written
and potentially change the convention if some people even object to the convention.

> Should I be worried about this bug?

Well, since you should not use the param_card from 2HDMtII_NLO, I would say no.
Just use the cards param_card_default.dat within the Cards directory.

> Is this an easy/quick fix so the
> authors will download soon a newer version of the 2HDMtII_NLO model?

Well one should first wait for FR author to comment and if they agree fix the UFO model template and then
the model author can change the write_param_card.py (faster than rerun FR). None of those steps are under my control and i would say that you should not wait for them to occur.

Cheers,

Olivier

> On 20 May 2021, at 16:55, Khawla Jaffel <email address hidden> wrote:
>
> Question #697008 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/697008
>
> Khawla Jaffel posted a new comment:
>
> Hello Olivier,
>
>> as well the number of spin states (2S+1) is not the same!
>
> This is a bug at the FR level, I have open a ticket for that :
> https://feynrules.irmp.ucl.ac.be/ticket/106#ticket
> <https://feynrules.irmp.ucl.ac.be/ticket/106#ticket>
>
> I don't have access to this link!
>
> So which card has the right (2S+1):
> /tmp/ms/production_me/Cards/param_card.dat or the file created within
> the UFO 2HDMtII_NLO model ?
>
> Should I be worried about this bug? Is this an easy/quick fix so the
> authors will download soon a newer version of the 2HDMtII_NLO model?
>
> Cheers,
> Khawla
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.