MadGraph5_aMC@NLO

UFO Parameters mixed up with restriction card

Asked by Ilaria Brivio

Dear authors,

I have just stumbled upon something puzzling and I was wondering if you could give me any insight.

I have a UFO model that has different EFT couplings for leptons of different flavors. I am using it to generate

   mu+ mu- > t t~ SMHLOOP=0 NPprop=0 NP=1 NP^2==1 NPcHl1^2==1

to get the pure interference term of the cHl1 operator. cHl1 is not flavor specific, individual flavors are specified in the param card: cHl122 enters muon couplings, cHl133 tau couplings and cHl111 electron ones.

If I do this "normally", ie. importing the model in madgraph, and modifying the param card when I launch the generation, everything is fine and I get interference for cHl122 but not for cHl133, as expected.

If I do this importing the model with a restriction card (restrict_massless, also attached) that sets all the lepton masses to zero, I get the opposite. ie zero for cHl122 and nonzero for cHl133.
which cannot be, as one can check that the UFO does not contain any muon vertex with cHl133 and vice versa.

This happens for a number of operators, for some reason all those containing leptons. Operators with quarks are all fine.
And it happens consistently every time I import the model and generate processes with it, so it's not completely random.
I should also say that it does not depend on the process nor on the fact that I am generating a pure interference term.

Any clue why this comes about?!

Thanks a lot!
Ilaria

Question information

Language:
English Edit question
Status:
Solved
For:
MadGraph5_aMC@NLO Edit question
Assignee:
No assignee Edit question
Solved by:
Ilaria Brivio
Solved:
Last query:
Last reply:
Revision history for this message
Ilaria Brivio (ilariab) said : 		#1

The UFO is here https://heibox.uni-heidelberg.de/f/e4e4ff0c84914d2fb58d/?dl=1

and I noticed that the issue happens only if I use a restrictions where all the coefficients are set to the same value (9.999999e-01). While it goes away using different values for each parameter.

Revision history for this message
Olivier Mattelaer (olivier-mattelaer) said : 		#2

Hi,

Restriction file can be very sensitive since identical coupling will be merge into a single one.
This is based only on the evaluation of the coupling that you pass within the restriction_card.

The original idea of the restriction_card was to not allow the user to change the param_card.
Many people like the feature of restriction_card but found the constraint too strong and we therefore allowed to still edit the param_card (but setting a couple of restriction, like for identical entry in the restriction_card as well as 0 and 1 entry).

Looks like you have a case where the modification that you do inside your param_card is not compatible with the optimization done with your restriction_card. You can run in debug mode to see all the optimization done to your UFO model when the restriction is done. This is a crucial test that all model builder should do to check that restriction that they used do not have any side effects.

Cheers,

Olivier

Revision history for this message
Olivier Mattelaer (olivier-mattelaer) said : 		#3

Hi,

The value "9.999999e-01" is a special one telling the restriction_card that you can keep the parameter untouched (and to one) bypassing all the above security.

Clearly you can not do that. If you want to show to the user all value to "1" even if the restriction_card is based on other value, you can also include in the UFO model a file param_XXXX.dat in addition of the restrict_XXXX.dat, in that case the default param_card is not the restriction_card but that file.

Cheers,

Olivier

Revision history for this message
Ilaria Brivio (ilariab) said : 		#4

Hi Olivier,

thanks for the fast reply.

What I do is that I use the restriction you see in the UFO where all coefficients are 9.999999e-01 to import the model , but then in the param_card of the process I re-set everything to 0, apart from cHl122 or cHl133.

I understand that this might be pushing a little bit how the restriction works (especially cause I have a lot of parameters), but the behavior is awkward, cause everything goes fine but a subset of the parameters (and always the same ones) is swapped around. They are not even set to be equal, they are exchanged.

Of course I can just do things differently, this is not a real problem. It's just that it can get quite confusing..

Ilaria

Revision history for this message
Olivier Mattelaer (olivier-mattelaer) said : 		#5

Hi Ilaria,

I'm sorry that you are confused. But this is also why we did not include in any paper the special trick of using 9.999999e-01
and why we put all those restrictions. This is because we know that using such restrictions can lead to some surprise...

Remember that all the decisions are done on the NUMERICAL value of all the coupling evaluated from your restriction_card.
This is very powerful and allow huge flexibility but this is not a safe way to do it (you have FeynRules for that)

The reasons why we include such features is also because having a lot of zero coupling
1) slows down the code quite a lot (both at run time and the time to generate the code)
2) can lead to issue when you do the integration.

So if you only want to have two operators, you would need to need to create a specific restriction_card with only those two operators.
In your case with more than 100 coupling this is obviously not very practical.
The best way for EFT in general is to use the same method as the EWDim6 model (and sm model).
which has special support for the "customize_model" command.

Maybe I will take another look at that command to see how I can try to improve support of other model. Maybe by adding a mode
"customize_model --manual" allowing to edit the restrict_card via the standard "set" command.

Cheers,

Olivier

Revision history for this message
Ilaria Brivio (ilariab) said : 		#6

Hi Olivier,

sure, I completely agree with you that this is not the way the model should be used in general.
I was doing unusual stuff for a wider testing, but I agree indeed that a restriction that keeps a lot of parameters around is pointless for a realistic event generation.

Again, it's not a real problem. Now I know I just better avoid that kind of restriction, and it's perfectly fine.

I will look into the customize_model command to see if it can help, but it's not strictly necessary for now.

Thanks a lot again!
Ilaria