MadGraph5_aMC@NLO

generation problem

Asked by dionysis skouras

Hello
I am using a spectrum file according to Les Houches Accord and I enter the path into MG5 but I get error messages. Pythia8 standalone has no problem using it
Here is the error

Error detected in "generate_events run_01"
write debug file ME5_debug
If you need help with this issue please contact us on https://answers.launchpad.net/mg5amcnlo
str : Invalid restriction card (not same block)
     {'te', 'rvsnvev', 'dsqmix', 'udlmix', 'higgslhc8', 'uulmix', 'uvmix', 'phases', 'hmix', 'flavorkitqfv', 'msoft', 'msq2', 'minpar', 'tu', 'yd', 'extpar', 'yu', 'udrmix', 'rvd', 'mse2', 'imfwcoef', 'fwcoef', 'effhiggscouplings', 'chargemix', 'sphenolowenergy', 'spheno', 'msu2', 'pseudoscalarmix', 'mass', 'usqmix', 'gaugegut', 'imuvmix', 'td', 'flavorkitlfv', 'msd2', 'ye', 'sminputs', 'uermix', 'uurmix', 'higgslhc7', 'decay', 'rvm2lh1', 'scalarmix', 'rvkappa', 'modsel', 'uelmix', 'gauge', 'msl2'} != {'te', 'vmix', 'hmix', 'snumix', 'umix', 'msoft', 'msq2', 'tu', 'yd', 'yu', 'mse2', 'upmns', 'msu2', 'usqmix', 'nmix', 'mass', 'selmix', 'td', 'msd2', 'vckm', 'ye', 'sminputs', 'decay', 'fralpha', 'dsqmix', 'msl2'}.
     Missing block: vckm,nmix,vmix,selmix,fralpha,upmns,snumix,umix
     Unknown block : rvsnvev,udlmix,higgslhc8,uulmix,uvmix,phases,flavorkitqfv,udrmix,minpar,extpar,rvd,imfwcoef,fwcoef,effhiggscouplings,chargemix,sphenolowenergy,spheno,pseudoscalarmix,gaugegut,imuvmix,flavorkitlfv,uermix,uurmix,higgslhc7,rvm2lh1,scalarmix,rvkappa,modsel,uelmix,gauge

Question information

Language:
English Edit question
Status:
Answered
For:
MadGraph5_aMC@NLO Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Olivier Mattelaer (olivier-mattelaer) said : 		#1

The real problem is that you are missing the following block for the model:
vckm,nmix,vmix,selmix,upmns,snumix,umix

you can use the "update missing" to fill those block to default value.
But they probably clash with the unknown block uvmix that is not known/handle by the model.

Now this seems that your input file does not follow SLHA2 (neither SLHA1) convention.
I'm not aware of an SLHA3 convention... (I know proposal but nothing more)
If your card follow one of those proposal, then you need to use a model that is also compatible with such proposal.

Cheers,

Olivier

Can you help with this problem?

Provide an answer of your own, or ask dionysis skouras for more information if necessary.

To post a message you must log in.