Error while reading SLHA2 file in MG 2.5beta

Even if you do not import your model with the suffix '-<restricted dat name>', MG5aMC will load the model with the restrict card called 'restrict_default.dat' if present in the UFO model directory.

If you want to make sure that you don't load any restriction card, then use 'import <modelname>-full'.

Now, it seems that your SARAH model does not define it's parameters (see file parameters.py in the UFO model) in accordance with SLHA2 or you Spheno spectrum output does not comply to it.
Not being a SUSY expert, I cannot say.

In any case, from a technical point of view, what you must do is make sure that the param_card you obtained from SPHENO lines up with what is expected from the UFO model generated by SARAH.
You can see directly what kind of param_card is expected by this model by looking at the file param_card.dat produced by running 'python write_param_card.py' in that UFO model.

The problem is, very same card and model is perfectly working in MG 2.4 but it doesn't work for MG 2.5. I'm running everything exactly the same way, where I'm importing model by 'import model UMSSM --modelname'.

Hi jackaraz,

I'm worried that it was indeed going trough in 2.4 but that your entry was just discarded and only default value was used.
From what I see from your message, the most reasonable behavior is indeed to crash since 2.4 can produce kind of un-expected results.

Cheers,

Olivier

Dear Oliver

Yes exactly,for instance some imaginary mixing martices were taken as default since SPheno was not able to calculate them the phase difference were given to the other matrices:

From the same run in MG2.4: 'WARNING: information about "imuurmix [3, 3]" is missing (full block missing) using default value: 0.0.'

or some of the decays which does not exist and shouldn't exist in my SLHA file:

From MG2.4: 'WARNING: information about "decay [1000012]" is missing using default value: 0.0. '

And this is stated in SARAH/SPheno manual as well in the section for MG5. But now it doesn't read it at all, not just imaginary matrices but none of the blocks. Isn't there any way to make it run, a script that can transfer SLHA2 to SLHA1 maybe?

Thanks
Best regards

Jack

Hi,

This has nothing to do with SLHA1/2.
I think the best would be to ask the SARAH/SPHENO author to produce/expect consistent input.
I'm going to consider add an option to allow to avoid the problem. But I'm not yet sure in which format it would be.
(I'm thinking about a new functions "update missing")

Cheers,

Olivier

Hi,

> I think the best would be to ask the SARAH/SPHENO author
> to produce/expect consistent input.

I'm sorry to say but I don't think the problem is on SARAH/SPheno side, but the MG SLHA reader does not follow the official SLHA guidelines (see 0801.0045):

1) Unknown blocks shall just be ignored
2) The block containing the imaginary parts (IMXYZ) of parameters need just to be given if CP violation is turned on via MODSEL 5, otherwise they are taken to be zero.

Of course, it's not a big deal to add a flag to SARAH/SPheno to write out always the zeros for the imaginary parts even if the user has turned off CPV. However, this blows up the spectrum file unnecessarily and I think it would be better to follow the SLHA conventions since they are there...

Best,
Florian

Hi,

> However, this blows up the spectrum file unnecessarily

This is obviously a matter taste, I personally prefer explicit rather than implicit.

In any case, I think that the having a lot of warning is worst than having longer param_card.
(and not having warning for missing parameter is certainly not an option).

> 1) Unknown blocks shall just be ignored

This is the case. A single warning is raise in that case, such that the user is aware that those information are unexpected
not used in the computation.

> 2) The block containing the imaginary parts (IMXYZ) of parameters need just to be given if CP violation is turned on via MODSEL 5, otherwise they are taken to be zero.

Such type of functionality is not supported by the UFO format.
In that type of model, we are not allowed to have optional parameter and even less optional parameter if some other parameter are at some given value.
We can clearly propose such extension by having one additional entry in the parameters.py, something like:
optional=EXPR
as a new entry in the parameters.py
(for example)
optional=’True’
optional=‘False’
optional=‘modsel==5’
What do you think of that option?

I’ll implement today a work-around independently of this UFO proposal.
I will simply introduce a new command [to the card editor option]
“update missing“ which will simply automatically write all the missing parameter to their default value in the current param_card.

Cheers,

Olivier

> On Sep 29, 2016, at 17:27, Florian Staub <email address hidden> wrote:
>
> Question #402462 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/402462
>
> Florian Staub posted a new comment:
> Hi,
>
>> I think the best would be to ask the SARAH/SPHENO author
>> to produce/expect consistent input.
>
> I'm sorry to say but I don't think the problem is on SARAH/SPheno side,
> but the MG SLHA reader does not follow the official SLHA guidelines (see
> 0801.0045):
>
> 1) Unknown blocks shall just be ignored
> 2) The block containing the imaginary parts (IMXYZ) of parameters need just to be given if CP violation is turned on via MODSEL 5, otherwise they are taken to be zero.
>
> Of course, it's not a big deal to add a flag to SARAH/SPheno to write
> out always the zeros for the imaginary parts even if the user has turned
> off CPV. However, this blows up the spectrum file unnecessarily and I
> think it would be better to follow the SLHA conventions since they are
> there...
>
> Best,
> Florian
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Hi,

The command “update missing” has been pushed in the development version.
Running that command is (at least most of the time) suggested when running into that kind of problem.

Cheers,

Olivier

> On Sep 30, 2016, at 11:02, MATTELAER, OLIVIER P.C. <email address hidden> wrote:
>
> Hi,
>
>> However, this blows up the spectrum file unnecessarily
>
> This is obviously a matter taste, I personally prefer explicit rather than implicit.
>
> In any case, I think that the having a lot of warning is worst than having longer param_card.
> (and not having warning for missing parameter is certainly not an option).
>
>
>> 1) Unknown blocks shall just be ignored
>
> This is the case. A single warning is raise in that case, such that the user is aware that those information are unexpected
> not used in the computation.
>
>> 2) The block containing the imaginary parts (IMXYZ) of parameters need just to be given if CP violation is turned on via MODSEL 5, otherwise they are taken to be zero.
>
> Such type of functionality is not supported by the UFO format.
> In that type of model, we are not allowed to have optional parameter and even less optional parameter if some other parameter are at some given value.
> We can clearly propose such extension by having one additional entry in the parameters.py, something like:
> optional=EXPR
> as a new entry in the parameters.py
> (for example)
> optional=’True’
> optional=‘False’
> optional=‘modsel==5’
> What do you think of that option?
>
> I’ll implement today a work-around independently of this UFO proposal.
> I will simply introduce a new command [to the card editor option]
> “update missing“ which will simply automatically write all the missing parameter to their default value in the current param_card.
>
> Cheers,
>
> Olivier
>
>
>
>> On Sep 29, 2016, at 17:27, Florian Staub <email address hidden> wrote:
>>
>> Question #402462 on MadGraph5_aMC@NLO changed:
>> https://answers.launchpad.net/mg5amcnlo/+question/402462
>>
>> Florian Staub posted a new comment:
>> Hi,
>>
>>> I think the best would be to ask the SARAH/SPHENO author
>>> to produce/expect consistent input.
>>
>> I'm sorry to say but I don't think the problem is on SARAH/SPheno side,
>> but the MG SLHA reader does not follow the official SLHA guidelines (see
>> 0801.0045):
>>
>> 1) Unknown blocks shall just be ignored
>> 2) The block containing the imaginary parts (IMXYZ) of parameters need just to be given if CP violation is turned on via MODSEL 5, otherwise they are taken to be zero.
>>
>> Of course, it's not a big deal to add a flag to SARAH/SPheno to write
>> out always the zeros for the imaginary parts even if the user has turned
>> off CPV. However, this blows up the spectrum file unnecessarily and I
>> think it would be better to follow the SLHA conventions since they are
>> there...
>>
>> Best,
>> Florian
>>
>> --
>> You received this question notification because you are an answer
>> contact for MadGraph5_aMC@NLO.
>

Hi,

I need to come back to this topic because I recognised that there are new problems showing up with the SLHA interface:
MG is asking now for the Mass and Width of any particle in the model - even if is massless like the photon. Sorry, but that is quite annoying. MG ignores completely, if particles are defined in the UFO file with

(...
mass = Param.ZERO,
width = Param.ZERO,
...)

I made now a workaround on SARAH/SPheno side that this unnecessary information is written on demand to the SLHA file, but I want to encourage you to think again about this policy. You are losing for the MSSM/NMSSM any compatibility with the standard spectrum generators.

Hi,

That part was not done by design, it indeed does not make sense to require that.

This will be fixed in 2.5.3.

Cheers,

Olivier

Thanks,
Florian