suggestion: "set parameters" commands

Hi Gauthier,

Thanks a lot for your suggestion.

> Have you ever considered the possibility of implementing something like a "set parameter" command?

Yes i do consider it, but never found an idea that I like about it.
I don't like to have this command in the MG5 interface, should rather be in the ME5 interface.
One solution is to allow such command when proposing to edit the card.
But not sure that this is 100% natural.

> Also, being able to have
>> display parameters MT
> working (as "display couplings GC_1" or "display particles g" already do) could also be fairly nice.

That's should be quite easy to do.

Cheers and Thanks,

Olivier

On Sep 14, 2012, at 4:05 AM, Gauthier Durieux <email address hidden> wrote:

> New question #208557 on MadGraph5:
> https://answers.launchpad.net/madgraph5/+question/208557
>
> Dear MG5 team,
>
> Have you ever considered the possibility of implementing something like a "set parameter" command?
>
> I often end up writing external scripts that edit the run_card.dat or param_card.dat.
> Instead, I would find it quite handy to have commands like:
>> set parameters MT=172, WT=1.52
>> set run_parameters ebeam1=3500, ebeam2=3500, nevents=50000
> available (equivalently before or after outputting).
>
> Also, being able to have
>> display parameters MT
> working (as "display couplings GC_1" or "display particles g" already do) could also be fairly nice.
>
> Many thanks,
>
> Gauthier
>
> --
> You received this question notification because you are a member of
> MadTeam, which is an answer contact for MadGraph5.

Hello Gauthier, Olivier,

Many thanks Gauthier for your suggestion.

Olivier, I think the main point is that this set command can be used before running (e.g.) generate_events, which can then be run using -f. So it should be possible to call at any time, and the run_card.dat or param_card.dat would then be modified correspondingly. A natural way to do it would be to read the actual param_card.dat and run_card.dat - in fact we are already doing this in v. 1.5.0, so it should be easy to use the same machinery.

Indeed this would simplify scripting quite a lot, and avoid having to use "!sed" statements or similar to edit the files.

All the best,
Johan

Hi Johan, Gauthier,

> Olivier, I think the main point is that this set command can be used
> before running (e.g.) generate_events, which can then be run using -f.

I see your point, but I'm not happy with that because
1) This should be part of the Madevent interface (and not MG).
This is a crucial point to me since we don't want the user to launch
mg5 all the time.

2) If you want to run it before generate_events the only way is to
pass by ./bin/madevent
(or launch -i) that's fine for me but maybe over complex. (In any case
having a command at that level is good idea but probably not enough)

Not sure what's the point to call with -f since for scripting you can
currently do like:
(write the following in a file)
generate_events
pythia
./Cards/param_card_0.dat
done
generate_events
parton
./Cards/param_card_1.dat
done
and do
./bin/madevent FILE

So if we add the set command as a possibility for the second question
you could do:
generate_events
pythia
./Cards/param_card_0.dat
set MH 130
set WH Auto
done
generate_events
parton
./Cards/param_card_0.dat
set MH 140
set WH Auto
done

> So it should be possible to call at any time, and the run_card.dat or
> param_card.dat would then be modified correspondingly.

When reading this, I'm not sure of what you have in mind. Could you
give an exact workflow.
For how you see this for the user point of view.

> A natural way to
> do it would be to read the actual param_card.dat and run_card.dat - in
> fact we are already doing this in v. 1.5.0, so it should be easy to
> use
> the same machinery.

Sure this is not very hard to do. But I never get the "perfect" idea
for this.
The problem is also that the basic idea is simple but you need to
cover all the case in a
consistent way.

> Indeed this would simplify scripting quite a lot, and avoid having to
> use "!sed" statements or similar to edit the files.

The advantages with that is that
1) The user knows what he is doing (i.e. not supposing that the width
are modified automatically --at least not all of them--)
2) The user has full control (can use analytical formula, numerical
formula,...).

Concerning the first point, they are a warning about that in the
question so this is fine if we do that at that level.
For the second point. I would say that I will stay at the level of
numerical value (and Auto for the width).

Some additional point that we need to think before starting:
1) How do we return to default value? (set MH default / set param
default / set run default)
2) what are the valid input?
set MH 120
is MH case sensitive, is MH is the UFO variable or the fortran
variable (not always the same...)?
Do we allow?
set mass 25 120
(here the idea is in fact BLOCK ID VALUE)
Do we allow?
set mass h 120
For the width do we allow? (They are no official block name for the
width so this is a special case)
set decay 25 0.1
set width 25 0.1
set width h 0.1
set decay h 0.1
3) How do we treat the decay table?
is this ok?
set decaytable 25 5 -5 0.1 (or set decaytable 25 > 5 -5 = 0.1)
or should we allow
set decaytable h b b~ 0.1
or simply not supported it (only usefull for pythia)?
4) Do we need check for consistent value?

I think in order to have functionality we need to have all those
points (+ autocompletion,...)
which starts to be a non trivial work, which might not be justified
enough by the number of people
which are going to use it (That's also a reason why I never
implemented it in fact).

Cheers,

Olivier

> All the best,
> Johan
>
> --
> You received this question notification because you are a member of
> MadTeam, which is an answer contact for MadGraph5.

Hi Olivier, Johan,

Many thanks for considering this suggestion so seriously.

− Olivier, I understand the reason why you'd like this to be part of ME instead of MG.
However, as it is quite handy to have a 'launch' command in the MG5 interface, I still believe it could be fairly convenient for a quick simple run to have some MG5 commands for setting parameters (potentially just keeping values in memory and editing cards when a 'launch' or 'output' is issued; note the fraction of people using the ME interface instead of 'launch <path>' is maybe also limited).
You have anyway default run and model parameters in MG that the user won't be aware of if he doesn't look at the cards or issue 'display parameters'.

Generally speaking, what I had in mind is indeed just a more convenient way to change parameters values than to edit cards (using a sed-like script, by hand or via the launch command). So I don't think this should have a lot of features like autocompletion etc. (also because, as Olivier wrote, these commands won't maybe interest many users... though, even the most basic user needs to change model and run parameters...).
Therefore:
− A single unique command for each parameter would, I believe, be enough (maybe just case insensitive?).
− Numerical values too.
− Just checking the correctness of the syntax too (like types and number of arguments, existence of the parameter and its external type of it).
− Using model external parameters identifiers that appear when issuing "display parameters" would maybe be the more sensible (while the bloc and pdg_code, that appear in param_cards could be OK too, for instance for decay table that are not displayed in "display parameters").
− Using run parameters identifiers that appear in the run_card too.

Using the existing 'set' and 'parameters' keywords and trying to have a syntax as close as possible to 'display parameters', 'param_card' and 'run_card', I would for instance write something like
$ set parameters MT = 172
$ set parameters WH = 0.006 or
$ set parameters DECAY 25 = 0.006 or maybe both, in this special case of decay widths
$ set parameters BR 25 5 -5 = 0.1
and like
$ set run_parameters ebeam1 = 3500
$ set run_parameters ptj = 30
$ set run_parameters etaj = 2.5
(or maybe "$ set parameters RUN ptj = 30"? But, in the absence of something like a corresponding 'MODEL' tag, this makes the distinction between run and model parameters unclear.)

Correspondingly, something like
$ set parameters MT = default
$ set parameters ALL = default
$ set run_parameters ebeam1 = default
$ set run_parameters ALL = default
for erasing the new value(s) put in memory, or fetching the ones in default cards, could indeed be very useful.

Cheers,
Gauthier

Hi Gauthier,

Let me be sure that you understand What I have in mind:

I was thinking of the following:

./bin/mg5
generate p p >e+ e-
output
launch

It ask:
Do you want to edit one cards (press enter to bypass editing)?
  1 / param : param_card.dat (be carefull about parameter consistency, especially widths)
  2 / run : run_card.dat
  9 / plot : plot_card.dat
  you can also enter
     a) a Path to a valid card.
     b) "set NAME VALUE" to change automatically the value of one parameter of run_card or param_card.
 [0, done, 1, param, 2, run, 9, plot, enter path, set][20s to answer]

Just to be clear this allow scripting since the following file is already supported:
generate p p >e+ e-
output
launch
./param_card.dat
done

This way this is accessible if you use:
launch
./bin/generate_events
launch -i
./bin/madevent
and the time when you have to enter the information is quite "natural" (i.e. when suggesting you to edit the cards)

What do you think?

Cheers,

olivier

Hi Olivier,

I see, this could indeed do the job in a nice way, from both our points of view!

Would also
$ generate p p > e+ e-
$ output
$ launch
$ set parameters MT = 171
$ set run_parameters nevents = 5000
$ done
be be allowed when scripting (through ./bin/mg5 myCommandsFile.txt)?

In interactive mode, would you then allow the use of the 'display' command after launch too? Like in:
$ launch <path>
$ display particles t
$ display parameters MT
$ set parameters MT = 171
...
$ display run_parameters ptj
$ set run_parameters ptj = 30
...
$ display parameters
$ set parameters ALL = default
...
$ display run_parameters
$ set run_parameters ALL = default
$ 0

Many thanks,
Gauthier

Hello Olivier, Gauthier,

> Some additional point that we need to think before starting:
> 1) How do we return to default value? (set MH default / set param
> default / set run default)
> 2) what are the valid input?
> set MH 120
> is MH case sensitive, is MH is the UFO variable or the fortran
> variable (not always the same...)?

I agree with Gauthier not to make them case sensitive. I think should be (in fact, has to be, since the values need to be written into the param_card, and should work also for v4 models) whatever variable is in the param_card comment # inside the block.

> Do we allow?
> set mass 25 120
> (here the idea is in fact BLOCK ID VALUE)

Absolutely!

> Do we allow?
> set mass h 120

Hmm... since it should be quite easy (the model knows the mapping) this could also be allowed.

> For the width do we allow? (They are no official block name for the
> width so this is a special case)
> set decay 25 0.1
> set width 25 0.1
> set width h 0.1
> set decay h 0.1

I would probably suggest to follow the param_card syntax, to reduce the number of possibilities and avoid confusion.

> 3) How do we treat the decay table?
> is this ok?
> set decaytable 25 5 -5 0.1 (or set decaytable 25 > 5 -5 = 0.1)
> or should we allow
> set decaytable h b b~ 0.1
> or simply not supported it (only usefull for pythia)?

I vote for the latter (since MadGraph doesn't know anything about BRs anyway anyway).

> 4) Do we need check for consistent value?

I'd say no.

Regarding run_card parameters, I think we could allow either
set run_parameter ptj 30
or just
set ptj 30
when there is no risk for confusion with mass parameters.

In fact I think a lot of people would be very happy to use this, so I don't think it would be wasted effort.

All the best,
Johan

Great to see that we converge on this point.

> I agree with Gauthier not to make them case sensitive. I think should be
> (in fact, has to be, since the values need to be written into the
> param_card, and should work also for v4 models) whatever variable is in
> the param_card comment # inside the block.

OK, I'm not sure about this one (but not have strong opinion on it)
Let me sum up the problem
FR/UFO are case sensitive so it is possible to (and It happen) to have two parameter define in the model
cw and Cw
(the second one being a dimension 6 operator coefficient).
In order to be a valid fortran model I change the name (don't ask me which one) to something like
cw__mod__2.
Let suppose that MG5 modifies the second one.
then if the user do
set Cw 0.1 either this will crash if cw is an internal parameter (like in the example that I have in mind)
or even worse it modifies the wrong parameter (if both are external)

whatever the choice we make we will have trouble for this with user surprized by the behavior.

>> 3) How do we treat the decay table?
>> is this ok?
>> set decaytable 25 5 -5 0.1 (or set decaytable 25 > 5 -5 = 0.1)
>> or should we allow
>> set decaytable h b b~ 0.1
>> or simply not supported it (only usefull for pythia)?
>
> I vote for the latter (since MadGraph doesn't know anything about BRs
> anyway anyway).

Ok Fine with me.

> Regarding run_card parameters, I think we could allow either
> set run_parameter ptj 30
> or just
> set ptj 30
> when there is no risk for confusion with mass parameters.

I agree on that, the run_parameters/param should be optional. (only mandatory if the variable is define in both card)

> Would also
> $ generate p p > e+ e-
> $ output
> $ launch
> $ set parameters MT = 171
> $ set run_parameters nevents = 5000
> $ done
> be be allowed when scripting (through ./bin/mg5 myCommandsFile.txt)?

Yes sure, that's an important point.

> In interactive mode, would you then allow the use of the 'display' command after launch too?

I would say that the display command that you need are simply opening the run_card/param_card.
And I see multiple potential problem with this (at the coding level). So I will not go for it, at least not in a first step.

Cheers,

Olivier

On Sep 21, 2012, at 3:05 AM, Johan Alwall <email address hidden> wrote:

> Question #208557 on MadGraph5 changed:
> https://answers.launchpad.net/madgraph5/+question/208557
>
> Johan Alwall proposed the following answer:
> Hello Olivier, Gauthier,
>
>> Some additional point that we need to think before starting:
>> 1) How do we return to default value? (set MH default / set param
>> default / set run default)
>> 2) what are the valid input?
>> set MH 120
>> is MH case sensitive, is MH is the UFO variable or the fortran
>> variable (not always the same...)?
>
> I agree with Gauthier not to make them case sensitive. I think should be
> (in fact, has to be, since the values need to be written into the
> param_card, and should work also for v4 models) whatever variable is in
> the param_card comment # inside the block.
>
>> Do we allow?
>> set mass 25 120
>> (here the idea is in fact BLOCK ID VALUE)
>
> Absolutely!
>
>> Do we allow?
>> set mass h 120
>
> Hmm... since it should be quite easy (the model knows the mapping) this
> could also be allowed.
>
>> For the width do we allow? (They are no official block name for the
>> width so this is a special case)
>> set decay 25 0.1
>> set width 25 0.1
>> set width h 0.1
>> set decay h 0.1
>
> I would probably suggest to follow the param_card syntax, to reduce the
> number of possibilities and avoid confusion.
>
>> 3) How do we treat the decay table?
>> is this ok?
>> set decaytable 25 5 -5 0.1 (or set decaytable 25 > 5 -5 = 0.1)
>> or should we allow
>> set decaytable h b b~ 0.1
>> or simply not supported it (only usefull for pythia)?
>
> I vote for the latter (since MadGraph doesn't know anything about BRs
> anyway anyway).
>
>> 4) Do we need check for consistent value?
>
> I'd say no.
>
> Regarding run_card parameters, I think we could allow either
> set run_parameter ptj 30
> or just
> set ptj 30
> when there is no risk for confusion with mass parameters.
>
> In fact I think a lot of people would be very happy to use this, so I
> don't think it would be wasted effort.
>
> All the best,
> Johan
>
> --
> You received this question notification because you are a member of
> MadTeam, which is an answer contact for MadGraph5.

hi,

I've started the implementation of the code:
lp:~maddevelopers/madgraph5/set_cmd_in_launch

For the moment, I've just modify the various class in order to allow to have a question which recognizes a command.
(So nothing serious for the moment).

Cheers,

Olivier

On Sep 21, 2012, at 9:56 AM, olivier mattelaer <email address hidden> wrote:

> Great to see that we converge on this point.
>
>> I agree with Gauthier not to make them case sensitive. I think should be
>> (in fact, has to be, since the values need to be written into the
>> param_card, and should work also for v4 models) whatever variable is in
>> the param_card comment # inside the block.
>
> OK, I'm not sure about this one (but not have strong opinion on it)
> Let me sum up the problem
> FR/UFO are case sensitive so it is possible to (and It happen) to have two parameter define in the model
> cw and Cw
> (the second one being a dimension 6 operator coefficient).
> In order to be a valid fortran model I change the name (don't ask me which one) to something like
> cw__mod__2.
> Let suppose that MG5 modifies the second one.
> then if the user do
> set Cw 0.1 either this will crash if cw is an internal parameter (like in the example that I have in mind)
> or even worse it modifies the wrong parameter (if both are external)
>
> whatever the choice we make we will have trouble for this with user surprized by the behavior.
>
>>> 3) How do we treat the decay table?
>>> is this ok?
>>> set decaytable 25 5 -5 0.1 (or set decaytable 25 > 5 -5 = 0.1)
>>> or should we allow
>>> set decaytable h b b~ 0.1
>>> or simply not supported it (only usefull for pythia)?
>>
>> I vote for the latter (since MadGraph doesn't know anything about BRs
>> anyway anyway).
>
> Ok Fine with me.
>
>> Regarding run_card parameters, I think we could allow either
>> set run_parameter ptj 30
>> or just
>> set ptj 30
>> when there is no risk for confusion with mass parameters.
>
>
> I agree on that, the run_parameters/param should be optional. (only mandatory if the variable is define in both card)
>
>> Would also
>> $ generate p p > e+ e-
>> $ output
>> $ launch
>> $ set parameters MT = 171
>> $ set run_parameters nevents = 5000
>> $ done
>> be be allowed when scripting (through ./bin/mg5 myCommandsFile.txt)?
>
> Yes sure, that's an important point.
>
>> In interactive mode, would you then allow the use of the 'display' command after launch too?
>
>
> I would say that the display command that you need are simply opening the run_card/param_card.
> And I see multiple potential problem with this (at the coding level). So I will not go for it, at least not in a first step.
>
>
> Cheers,
>
> Olivier
>
>
>
> On Sep 21, 2012, at 3:05 AM, Johan Alwall <email address hidden> wrote:
>
>> Question #208557 on MadGraph5 changed:
>> https://answers.launchpad.net/madgraph5/+question/208557
>>
>> Johan Alwall proposed the following answer:
>> Hello Olivier, Gauthier,
>>
>>> Some additional point that we need to think before starting:
>>> 1) How do we return to default value? (set MH default / set param
>>> default / set run default)
>>> 2) what are the valid input?
>>> set MH 120
>>> is MH case sensitive, is MH is the UFO variable or the fortran
>>> variable (not always the same...)?
>>
>> I agree with Gauthier not to make them case sensitive. I think should be
>> (in fact, has to be, since the values need to be written into the
>> param_card, and should work also for v4 models) whatever variable is in
>> the param_card comment # inside the block.
>>
>>> Do we allow?
>>> set mass 25 120
>>> (here the idea is in fact BLOCK ID VALUE)
>>
>> Absolutely!
>>
>>> Do we allow?
>>> set mass h 120
>>
>> Hmm... since it should be quite easy (the model knows the mapping) this
>> could also be allowed.
>>
>>> For the width do we allow? (They are no official block name for the
>>> width so this is a special case)
>>> set decay 25 0.1
>>> set width 25 0.1
>>> set width h 0.1
>>> set decay h 0.1
>>
>> I would probably suggest to follow the param_card syntax, to reduce the
>> number of possibilities and avoid confusion.
>>
>>> 3) How do we treat the decay table?
>>> is this ok?
>>> set decaytable 25 5 -5 0.1 (or set decaytable 25 > 5 -5 = 0.1)
>>> or should we allow
>>> set decaytable h b b~ 0.1
>>> or simply not supported it (only usefull for pythia)?
>>
>> I vote for the latter (since MadGraph doesn't know anything about BRs
>> anyway anyway).
>>
>>> 4) Do we need check for consistent value?
>>
>> I'd say no.
>>
>> Regarding run_card parameters, I think we could allow either
>> set run_parameter ptj 30
>> or just
>> set ptj 30
>> when there is no risk for confusion with mass parameters.
>>
>> In fact I think a lot of people would be very happy to use this, so I
>> don't think it would be wasted effort.
>>
>> All the best,
>> Johan
>>
>> --
>> You received this question notification because you are a member of
>> MadTeam, which is an answer contact for MadGraph5.
>