Merge lp:~maddevelopers/mg5amcnlo/New_cmd_structure into lp:mg5amcnlo/lts

[Olivier Mattelaer]

Hi,

let's try to do this merge as soon as possible.

I just put below the content of the email that I just send to you.
(Only the pdf is missing here off course)

Cheers,

Olivier

Sended email:

Hi guys,

During the implementation,
I found useful to slightly change the class mapping for the class (nothing big off course)

So I attached the new class mapping:

The three first pages are the previous agreement.
The choice between 1 and 2, was supposed to be done at the extension class level.
the graph 3, was suppose to be activate if needed (so not at current stage).

The pages 4 and 5 corresponds to the pages 1/2 with the small modifications that I performed.
i.e.
1) I didn't display the Web part (that's done in pages 6)
2) MadGraphCmd inherits from Check, Help, ...

3) I add a class Switcher which contains all the
        def XXXX(self, *args, **opts)
      return self.cmd(self, *args, **opts°
    This allow
         - to easily move in the file (at least with Eclipse)
         - that the Web interface doesn't inherit from MasterCmd (which is forbidden since it can't have the shell inheritance)

The page 6 is the same but including the Web part.

The page 7 corresponds to page 3 (i.e. optional structure that we might be force to use at a point)

The page 8 is the same as 6. But with a multiple inheritance for MasterCmdWeb explicitely displayed.

Otherwise, I explicitly check -- in debug mode -- that all
do_xxx, check_xxx, ...
are present in the switcher, if this is not the case, an error is raised.
and the file containing the missing lines are written (so you just have to do a copy-paste).

In debug mode, I also check that each function/attribute is define only at a single place (but if they are present in the switcher or in one of the master).
If not an error is raised.
This should prevent a lot of problem in the future (at least I hope).

I will put the associated branch under review such that we can make the discussion on launchpad.

Cheers,

Olivier

[marco zaro (marco-zaro)]

Hi Olivier,
I am looking at it:

how do i scwitch from an interface to the other?

then
if i run tests/test_manager.py i get the following error...
does anybody get the same?

thanks for your efforts
Cheers
Marco

Traceback (most recent call last):
  File "./tests/test_manager.py", line 380, in <module>
    package=options.path)
  File "./tests/test_manager.py", line 70, in run
    re_opt=re_opt):
  File "./tests/test_manager.py", line 120, in __iter__
    self._check_if_obj_build()
  File "./tests/test_manager.py", line 116, in _check_if_obj_build
    self.collect_dir(self.package, checking=True)
  File "./tests/test_manager.py", line 152, in collect_dir
    self.collect_dir(directory + '/' + name, local_check)
  File "./tests/test_manager.py", line 150, in collect_dir
    self.collect_file(directory + '/' + name, local_check)
  File "./tests/test_manager.py", line 161, in collect_file
    __import__(pyname)
  File "/Users/marcozaro/PhD/mg5/new_cmd/New_cmd_structure/tests/unit_tests/interface/test_cmd.py", line 20, in <module>
    import madgraph.interface.cmd_interface as cmd
ImportError: No module named cmd_interface

On 15 Feb 2012, at 00:33, olivier mattelaer wrote:

> Olivier Mattelaer has proposed merging lp:~maddevelopers/madgraph5/New_cmd_structure into lp:madgraph5/2.0.
>
> Requested reviews:
> Rikkert Frederix (frederix)
> Johan Alwall (johan-alwall)
> Valentin Hirschi (valentin-hirschi)
> marco zaro (marco-zaro)
>
> For more details, see:
> https://code.launchpad.net/~maddevelopers/madgraph5/New_cmd_structure/+merge/93104
>
> Hi,
>
> let's try to do this merge as soon as possible.
>
> I just put below the content of the email that I just send to you.
> (Only the pdf is missing here off course)
>
> Cheers,
>
> Olivier
>
> Sended email:
>
>
> Hi guys,
>
> During the implementation,
> I found useful to slightly change the class mapping for the class (nothing big off course)
>
> So I attached the new class mapping:
>
>
>
> The three first pages are the previous agreement.
> The choice between 1 and 2, was supposed to be done at the extension class level.
> the graph 3, was suppose to be activate if needed (so not at current stage).
>
> The pages 4 and 5 corresponds to the pages 1/2 with the small modifications that I performed.
> i.e.
> 1) I didn't display the Web part (that's done in pages 6)
> 2) MadGraphCmd inherits from Check, Help, ...

> 3) I add a class Switcher which contains all the
> def XXXX(self, *args, **opts)
> return self.cmd(self, *args, **opts°
> This allow
> - to easily move in the file (at least with Eclipse)
> - that the Web interface doesn't inherit from MasterCmd (which is forbidden since it can't have the shell inheritance)
>
> The page 6 is the same but including the Web part.
>
> The page 7 corresponds to page 3 (i.e. optional structure that we might be force to use at a point)
>
> The page 8 is the same as 6. But with a multiple inheritance for MasterCmdWeb explicitely displayed.
>
> Otherwise, I explicitly check -- in debug mode -- that all
> do_xxx, check_xxx, ...
> are present in the switcher, if this is not the case, an error is raised.
> an...

[Olivier Mattelaer (olivier-mattelaer)]

Hi Marco,

For the moment, they are only one interface (I implement one Loop but
this is completely dummy and that's up to you and Valentin to create
it in practise.

In the file master_interface.py
you will see one command
change_principal_cmd(self, name)
where name defines which Interface will be the main one.

The Masterinterface takes also one argument in order to define it
directly.

> then
> if i run tests/test_manager.py i get the following error...
> does anybody get the same?

That's a quite critical error, just don't really understand why it was
working on my computer (maybe due to the remaining presence of
the .pyc?)

I'll fix that.

Cheers,

Olivier

On 15-févr.-12, at 03:07, marco zaro wrote:

> Hi Olivier,
> I am looking at it:
>
> how do i scwitch from an interface to the other?
>
> then
> if i run tests/test_manager.py i get the following error...
> does anybody get the same?
>
> thanks for your efforts
> Cheers
> Marco
>
>
> Traceback (most recent call last):
> File "./tests/test_manager.py", line 380, in <module>
> package=options.path)
> File "./tests/test_manager.py", line 70, in run
> re_opt=re_opt):
> File "./tests/test_manager.py", line 120, in __iter__
> self._check_if_obj_build()
> File "./tests/test_manager.py", line 116, in _check_if_obj_build
> self.collect_dir(self.package, checking=True)
> File "./tests/test_manager.py", line 152, in collect_dir
> self.collect_dir(directory + '/' + name, local_check)
> File "./tests/test_manager.py", line 150, in collect_dir
> self.collect_file(directory + '/' + name, local_check)
> File "./tests/test_manager.py", line 161, in collect_file
> __import__(pyname)
> File "/Users/marcozaro/PhD/mg5/new_cmd/New_cmd_structure/tests/
> unit_tests/interface/test_cmd.py", line 20, in <module>
> import madgraph.interface.cmd_interface as cmd
> ImportError: No module named cmd_interface
>
>
>
>
>
>
> On 15 Feb 2012, at 00:33, olivier mattelaer wrote:
>
>> Olivier Mattelaer has proposed merging lp:~maddevelopers/madgraph5/
>> New_cmd_structure into lp:madgraph5/2.0.
>>
>> Requested reviews:
>> Rikkert Frederix (frederix)
>> Johan Alwall (johan-alwall)
>> Valentin Hirschi (valentin-hirschi)
>> marco zaro (marco-zaro)
>>
>> For more details, see:
>> https://code.launchpad.net/~maddevelopers/madgraph5/
>> New_cmd_structure/+merge/93104
>>
>> Hi,
>>
>> let's try to do this merge as soon as possible.
>>
>> I just put below the content of the email that I just send to you.
>> (Only the pdf is missing here off course)
>>
>> Cheers,
>>
>> Olivier
>>
>> Sended email:
>>
>>
>> Hi guys,
>>
>> During the implementation,
>> I found useful to slightly change the class mapping for the class
>> (nothing big off course)
>>
>> So I attached the new class mapping:
>>
>>
>>
>> The three first pages are the previous agreement.
>> The choice between 1 and 2, was supposed to be done at the
>> extension class level.
>> the graph 3, was suppose to be activate if needed (so not at
>> current stage).
>>
>> The pages 4 and 5 corresponds to the pages 1/2 with the small
>> modifications that I performed.
>> i.e.
>> 1) I didn't display the Web part (that's done in pages ...

[Johan Alwall (johan-alwall)]

Hello Olivier,

I'm not sure I understand:

class MasterCmd(Switcher, NLOcmd.LoopInterface, cmd.CmdShell):
So when a command is called (using do_command), is it guaranteed that it will be the corresponding command in Switcher that is called? Also, I had expected that you simply create the referral command on-the-fly, in the same way that you now create the helping error text (but using "eval" or "exec"), rather than have a long list of defined commands in the Switcher?

Otherwise I think everything looks fine to me.

Johan

[Johan Alwall (johan-alwall)]

Oh, just one thing: Let's keep consistent between file names and command names, to avoid (a lot of) confusion: loop_interface.py is the appropriate module name since the class is called Loop...

Cheers,
Johan

[Johan Alwall (johan-alwall)]

Hi Marco, Olivier,

> For the moment, they are only one interface (I implement one Loop but
> this is completely dummy and that's up to you and Valentin to create
> it in practise.
>
> In the file master_interface.py
> you will see one command
> change_principal_cmd(self, name)
> where name defines which Interface will be the main one.
>
> The Masterinterface takes also one argument in order to define it
> directly.

At least my idea is that the implementor also defines how to switch between interfaces. In the case of the ColorOrdering, it's done when the color_ordered option is set > 0. For NLO, it might be by setting an option ("set Loop True"), when an NLO-prepared model is loaded ("import model sm-loop") or when a loop or real process is defined.

We had previously talked about defining a loop or real process by [QCD] and {QCD} respectively, but another possibility, which would be more friendly to this interface, would be to say, e.g.
set loop_order QCD
generate p p > ...
and
set real_order QCD QED
generate p p > ...
or something like that. This would make it very easy to switch between the interfaces appropriately. But I think it should be defined (in the MasterCmd class) by the person working on the interface that is being switched to.

Best,
Johan

[Valentin Hirschi (valentin-hirschi)]

> Hi Marco, Olivier,
>
> > For the moment, they are only one interface (I implement one Loop but
> > this is completely dummy and that's up to you and Valentin to create
> > it in practise.
> >
> > In the file master_interface.py
> > you will see one command
> > change_principal_cmd(self, name)
> > where name defines which Interface will be the main one.
> >
> > The Masterinterface takes also one argument in order to define it
> > directly.
>
> At least my idea is that the implementor also defines how to switch between
> interfaces. In the case of the ColorOrdering, it's done when the color_ordered
> option is set > 0. For NLO, it might be by setting an option ("set Loop
> True"), when an NLO-prepared model is loaded ("import model sm-loop") or when
> a loop or real process is defined.

I would say that it does so either by a 'set Loop True' as you suggest and/or whenever the user asks for a process while defining perturbation orders with the [].

> We had previously talked about defining a loop or real process by [QCD] and
> {QCD} respectively, but another possibility, which would be more friendly to
> this interface, would be to say, e.g.
> set loop_order QCD
> generate p p > ...
> and
> set real_order QCD QED
> generate p p > ...
> or something like that. This would make it very easy to switch between the
> interfaces appropriately. But I think it should be defined (in the MasterCmd
> class) by the person working on the interface that is being switched to.

I agree that the switching feature should by coded within each independent interface. However I am against defining an overall setting for the perturbation order to consider.
I believe that our philosophy is that the user specifies all the relevant information for the process along with the generate command, and I think it would be dangerous to have any perturbation order implicitly assumed because of an overall setting.
To me, this stands at the same level as 'forbidden particles' for example, that we specify for now at the time of the generating a process and not with an overall parameter setting.

Cheers,

> Best,
> Johan

[Olivier Mattelaer (olivier-mattelaer)]

Hi Johan,

> class MasterCmd(Switcher, NLOcmd.LoopInterface, cmd.CmdShell):
> So when a command is called (using do_command), is it guaranteed
> that it will be the corresponding command in Switcher that is called?

Let takes an example:
> class MasterCmd(Switcher, NLOcmd.LoopInterface,
> COLORcmd.ColorInterface, cmd.CmdShell):

The Rule is the following
1) it will search in MasterCmd if do_command is define
2) it will search in Switcher
3) in LoopInterface
4) in MadGraphInterface (the mother of Loop)
5) in ExtendedCmd
6) in all the mother of ExtendedCmd
7) in COLORcmd.ColorInterface
8) in CmdShell

So yes I'm sure.

> Also, I had expected that you simply create the referral command on-
> the-fly, in the same way that you now create the helping error text
> (but using "eval" or "exec"), rather than have a long list of
> defined commands in the Switcher?

I tried different things, and only one was mainly successful
(suggested by Valentin in fact).
But it looks like they are some sort of side effect which made me
nervous.
the hasattr function (as well as dir) is not working properly for
example.
So I'm worry to do something which is too border line, and therefore
which might be unstable depending of the python version/computer.

If you want, I can put this on a separate branch, such that you can
see yourself.

Cheers,

Olivier

On Feb 15, 2012, at 3:42 AM, Johan Alwall wrote:

> Hello Olivier,
>
> I'm not sure I understand:
>
> class MasterCmd(Switcher, NLOcmd.LoopInterface, cmd.CmdShell):
> So when a command is called (using do_command), is it guaranteed
> that it will be the corresponding command in Switcher that is
> called? Also, I had expected that you simply create the referral
> command on-the-fly, in the same way that you now create the helping
> error text (but using "eval" or "exec"), rather than have a long
> list of defined commands in the Switcher?
>
> Otherwise I think everything looks fine to me.
>
> Johan
> --
> https://code.launchpad.net/~maddevelopers/madgraph5/
> New_cmd_structure/+merge/93104
> Your team MadTeam is subscribed to branch lp:madgraph5/2.0.

[Olivier Mattelaer (olivier-mattelaer)]

In fact,

the definition on the flight loose the precedence, which is very very bad.
-> so I'm back to the point that we need to write those explicitely
(in good python: explicit is better than implicit ;-) )
Since I've some test to test if the definition are present this is not a too big problem.

[Olivier Mattelaer (olivier-mattelaer)]

Ok all the test are passing now (and I have remove the .pyc before ;-))
But let check it on another computer (always safer)

[Johan Alwall (johan-alwall)]

> the definition on the flight loose the precedence, which is very very bad.
> -> so I'm back to the point that we need to write those explicitely
> (in good python: explicit is better than implicit ;-) )
> Since I've some test to test if the definition are present this is not a too big problem.

Ok, sounds like good arguments to me.
Did you merge? (the status says "merged"). If not, I'm fine with this framework.

Cheers,
Johan

review: Approve

[Johan Alwall (johan-alwall)]

Hey Valentin,

> I agree that the switching feature should by coded within each independent interface. However I am against defining an overall setting for the perturbation order to consider.
> I believe that our philosophy is that the user specifies all the relevant information for the process along with the generate command, and I think it would be dangerous to have any perturbation order implicitly assumed because of an overall setting.
> To me, this stands at the same level as 'forbidden particles' for example, that we specify for now at the time of the generating a process and not with an overall parameter setting.

So probably the nicest is to always select an interface whenever do_generate is called rather than when a flag is set. So

- if color_ordering > 0 and no [] or {}, at do_generate the ColorOrdered interface selected
- if color_ordering == 0 and [] in the process def, select Loop interface
- if color_ordering == 0 and {} in the process def, select Real/FKS interface
- if color_ordering > 0 and [] in the process def, select ColorOrderedLoop interface
etc.

If the model doesn't support Loops, then the LoopInterface generate command returns an error, etc.
That way, the interface selection is always in the same place, and things are nice and clear.

Let me know what you think,
Johan

[Olivier Mattelaer (olivier-mattelaer)]

Hi Johan,

> Ok, sounds like good arguments to me.
> Did you merge? (the status says "merged"). If not, I'm fine with
> this framework.

It's not merged, but it was during ~30s due to a mistake that I
correct right away.

> I believe that our philosophy is that the user specifies all the
> relevant information for the process along with the generate
> command, and I think it would be dangerous to have any perturbation
> order implicitly assumed because of an overall setting.
> To me, this stands at the same level as 'forbidden particles' for
> example, that we specify for now at the time of the generating a
> process and not with an overall parameter setting.

To me this rather stands at the same level as 'regular' order. Where
if they are not define are assumed automaticaly.
So if the user launch the nlo_binary or explicitely launch the
LoopInterface (if this will be possible) then it will makes sense to
assume automatically [QCD]

Off course this require that the user should 'know' that he is in NLO
or standard interface and this should be reflected in the print
statement of the begin of the loop.
  (i.e. replace mg5> by mg5_nlo>)

> So probably the nicest is to always select an interface whenever
> do_generate is called rather than when a flag is set. So

I would say that we should switch as soon as we have the information.
Switching later force to re-do various command --mainly set and
import--,
which might be tricky (I don't like to have a function based on the
history).

Switching at the level of the generate command, is off course very
important.
But switching the interface before this command will help with
dedicated auto-suggestions, ...
And that this is very extension dependent. So I will simply not put a
rule on this.

> - if color_ordering > 0 and no [] or {}, at do_generate the
> ColorOrdered interface selected
> - if color_ordering == 0 and [] in the process def, select Loop
> interface
> - if color_ordering == 0 and {} in the process def, select Real/FKS
> interface
> - if color_ordering > 0 and [] in the process def, select
> ColorOrderedLoop interface
> etc.
>
> If the model doesn't support Loops, then the LoopInterface generate
> command returns an error, etc.

This should be present in any scenario, I think.

> That way, the interface selection is always in the same place, and
> things are nice and clear.

I see the points, but for MadWeight for example, I will probably need
to change the interface at the "set" level for sure.
So this nice features will be break at a point in the future for sure
to my point of view.

Cheers,

Olivier

On 15-févr.-12, at 20:58, Johan Alwall wrote:

> Review: Approve
>
>> the definition on the flight loose the precedence, which is very
>> very bad.
>> -> so I'm back to the point that we need to write those explicitely
>> (in good python: explicit is better than implicit ;-) )
>> Since I've some test to test if the definition are present this is
>> not a too big problem.
>
> Ok, sounds like good arguments to me.
> Did you merge? (the status says "merged"). If not, I'm fine with
> this framework.
>
> Cheers,
> Johan
> --
> https://...

[Johan Alwall (johan-alwall)]

Hello Olivier,

> To me this rather stands at the same level as 'regular' order. Where
> if they are not define are assumed automaticaly.
> So if the user launch the nlo_binary or explicitely launch the
> LoopInterface (if this will be possible) then it will makes sense to
> assume automatically [QCD]

But we are planning to allow also QED and mixed orders. Furthermore, how does the user specify between FKS and Loop? These would be natural to both have access to in your "NLO" binary.

> Off course this require that the user should 'know' that he is in NLO
> or standard interface and this should be reflected in the print
> statement of the begin of the loop.
> (i.e. replace mg5> by mg5_nlo>)

This is true in either case.

> > So probably the nicest is to always select an interface whenever
> > do_generate is called rather than when a flag is set. So
>
> I would say that we should switch as soon as we have the information.
> Switching later force to re-do various command --mainly set and
> import--,
> which might be tricky (I don't like to have a function based on the
> history).

I don't see this - in fact, thanks to your excellent organization, these variables don't even need to be modified since we never change command object!

> Switching at the level of the generate command, is off course very
> important.
> But switching the interface before this command will help with
> dedicated auto-suggestions, ...
> And that this is very extension dependent. So I will simply not put a
> rule on this.

This is true, but can probably be dealt with.

> > - if color_ordering > 0 and no [] or {}, at do_generate the
> > ColorOrdered interface selected
> > - if color_ordering == 0 and [] in the process def, select Loop
> > interface
> > - if color_ordering == 0 and {} in the process def, select Real/FKS
> > interface
> > - if color_ordering > 0 and [] in the process def, select
> > ColorOrderedLoop interface
> > etc.
> >
> > If the model doesn't support Loops, then the LoopInterface generate
> > command returns an error, etc.
>
> This should be present in any scenario, I think.

Of course.

> > That way, the interface selection is always in the same place, and
> > things are nice and clear.
>
> I see the points, but for MadWeight for example, I will probably need
> to change the interface at the "set" level for sure.
> So this nice features will be break at a point in the future for sure
> to my point of view.

That is not a problem. The idea is that each developer can choose when is the most natural point to do the change. It also doesn't have to be unique - a change to a certain interface can be triggered by several different things, although I would recommend to keep it as simple and unique as possible to simplify the interface for the user).

If we don't agree, I'd suggest to simply have a vote between the four of us, and go from there, so we can quickly move on to merge the NLO branch (and modify our branches appropriately).

Cheers,
Johan

[Valentin Hirschi (valentin-hirschi)]

Grr I really hate this LaunchPad interface to comment on the merges request.

Anyway, I agree we should be able to switch from one interface to another simply with a 'set' command and not only dynamically depending on the type of process generated.

So then for example we could have:

set perturbation_order [QCD]

Which would trigger the switch to the loop interface and setup the default perturbation order to QCD. So that now, a process like this:

generate g g > d d~

would implicitely be at one loop in QCD. The only problem is that one loses the separation between born_orders and squared_orders if on forgets about the [QCD] part in the synthax. Any idea?

And finally, one could always switch back to the regular interface with set perturbation_order [].

To make the switching more uniform, it would be enough to have for each interface a function "Is_valid()" which checks depending on the MadGraphCmd options if the interface is appropriate or not. And then everytime an option is modified, the MasterCMD would automatically check which interface is appropriate.

Cheers

review: Approve

[Olivier Mattelaer (olivier-mattelaer)]

Hi Johan,

> But we are planning to allow also QED and mixed orders.

Sure but that makes sense to not activate those by default (like now
we takes (sort of) QED=0 at tree level)

> Furthermore, how does the user specify between FKS and Loop? These
> would be natural to both have access to in your "NLO" binary.

Sure, in fact, I have no idea of the status of FKS, never seen any
branch for a while, and the previous status is quite old to me.
The same in fact for the aMCatNLO interface, what are the exact plan
for that?

>> I would say that we should switch as soon as we have the information.
>> Switching later force to re-do various command --mainly set and
>> import--,
>> which might be tricky (I don't like to have a function based on the
>> history).
>
> I don't see this - in fact, thanks to your excellent organization,
> these variables don't even need to be modified since we never change
> command object!

Not sure that you don't need to re-import the model, but in any case,
this is fine.

> That is not a problem. The idea is that each developer can choose
> when is the most natural point to do the change. It also doesn't
> have to be unique - a change to a certain interface can be triggered
> by several different things, although I would recommend to keep it
> as simple and unique as possible to simplify the interface for the
> user).

Fully aggree with that.

Cheers,

Olivier

On 16-févr.-12, at 05:07, Johan Alwall wrote:

> Hello Olivier,
>
>> To me this rather stands at the same level as 'regular' order. Where
>> if they are not define are assumed automaticaly.
>> So if the user launch the nlo_binary or explicitely launch the
>> LoopInterface (if this will be possible) then it will makes sense to
>> assume automatically [QCD]
>
> But we are planning to allow also QED and mixed orders. Furthermore,
> how does the user specify between FKS and Loop? These would be
> natural to both have access to in your "NLO" binary.
>
>> Off course this require that the user should 'know' that he is in NLO
>> or standard interface and this should be reflected in the print
>> statement of the begin of the loop.
>> (i.e. replace mg5> by mg5_nlo>)
>
> This is true in either case.
>
>>> So probably the nicest is to always select an interface whenever
>>> do_generate is called rather than when a flag is set. So
>>
>> I would say that we should switch as soon as we have the information.
>> Switching later force to re-do various command --mainly set and
>> import--,
>> which might be tricky (I don't like to have a function based on the
>> history).
>
> I don't see this - in fact, thanks to your excellent organization,
> these variables don't even need to be modified since we never change
> command object!
>
>> Switching at the level of the generate command, is off course very
>> important.
>> But switching the interface before this command will help with
>> dedicated auto-suggestions, ...
>> And that this is very extension dependent. So I will simply not put a
>> rule on this.
>
> This is true, but can probably be dealt with.
>
>>> - if color_ordering > 0 and no [] or {}, at do_generate the
>>> ColorOrdered interface selecte...

[marco zaro (marco-zaro)]

Hi,
for madfks, up to a (possible) bug in the fortran code, which we are searching, the python code + unit tests are ready, both from born and from real emission, and the two of them agree
i (still) need to think about possible parallel and acceptance tests, because the total cross-section computation are quite lenghty.
I will merge it with v 1.4 and pull on launchpad (beginning of next week), ok?
Cheers
Marco

On 16 Feb 2012, at 12:40, Olivier Mattelaer wrote:

> Hi Johan,
>
>> But we are planning to allow also QED and mixed orders.
>
> Sure but that makes sense to not activate those by default (like now
> we takes (sort of) QED=0 at tree level)
>
>> Furthermore, how does the user specify between FKS and Loop? These
>> would be natural to both have access to in your "NLO" binary.
>
> Sure, in fact, I have no idea of the status of FKS, never seen any
> branch for a while, and the previous status is quite old to me.
> The same in fact for the aMCatNLO interface, what are the exact plan
> for that?
>
>>> I would say that we should switch as soon as we have the information.
>>> Switching later force to re-do various command --mainly set and
>>> import--,
>>> which might be tricky (I don't like to have a function based on the
>>> history).
>>
>> I don't see this - in fact, thanks to your excellent organization,
>> these variables don't even need to be modified since we never change
>> command object!
>
>
> Not sure that you don't need to re-import the model, but in any case,
> this is fine.
>
>> That is not a problem. The idea is that each developer can choose
>> when is the most natural point to do the change. It also doesn't
>> have to be unique - a change to a certain interface can be triggered
>> by several different things, although I would recommend to keep it
>> as simple and unique as possible to simplify the interface for the
>> user).
>
> Fully aggree with that.
>
> Cheers,
>
> Olivier
>
>
> On 16-févr.-12, at 05:07, Johan Alwall wrote:
>
>> Hello Olivier,
>>
>>> To me this rather stands at the same level as 'regular' order. Where
>>> if they are not define are assumed automaticaly.
>>> So if the user launch the nlo_binary or explicitely launch the
>>> LoopInterface (if this will be possible) then it will makes sense to
>>> assume automatically [QCD]
>>
>> But we are planning to allow also QED and mixed orders. Furthermore,
>> how does the user specify between FKS and Loop? These would be
>> natural to both have access to in your "NLO" binary.
>>
>>> Off course this require that the user should 'know' that he is in NLO
>>> or standard interface and this should be reflected in the print
>>> statement of the begin of the loop.
>>> (i.e. replace mg5> by mg5_nlo>)
>>
>> This is true in either case.
>>
>>>> So probably the nicest is to always select an interface whenever
>>>> do_generate is called rather than when a flag is set. So
>>>
>>> I would say that we should switch as soon as we have the information.
>>> Switching later force to re-do various command --mainly set and
>>> import--,
>>> which might be tricky (I don't like to have a function based on the
>>> history).
>>
>> I don't see ...

[Olivier Mattelaer (olivier-mattelaer)]

> Hi,
> for madfks, up to a (possible) bug in the fortran code, which we are
> searching, the python code + unit tests are ready, both from born and from
> real emission, and the two of them agree
> i (still) need to think about possible parallel and acceptance tests, because
> the total cross-section computation are quite lenghty.
> I will merge it with v 1.4 and pull on launchpad (beginning of next week), ok?
> Cheers
> Marco

Perfect.

Could you finalize this review first?
Should we wait for Rik?

Cheers,

Olivier

[Olivier Mattelaer (olivier-mattelaer)]

review: Approve

[marco zaro (marco-zaro)]

ok, all tests passed now

review: Approve

=== modified file 'bin/mg5'
--- bin/mg5	2011-12-14 21:52:20 +0000
+++ bin/mg5	2012-02-14 23:32:18 +0000
@@ -112,7 +112,7 @@
     logging.getLogger('madgraph').setLevel(eval('logging.' + options.logging))
 except:
     pass
-import madgraph.interface.cmd_interface as cmd_interface
+import madgraph.interface.master_interface as interface
 
 # Call the cmd interface main loop
 try:
@@ -123,22 +123,21 @@
         else:
             input_file = options.file
         if options.web:
-            cmd_line = cmd_interface.MadGraphCmdWeb()
+            cmd_line = interface.MasterCmdWeb()
             cmd_line.debug_output = os.path.join(os.path.dirname(input_file),'generation.log')
             cmd_line.use_rawinput = False
             cmd_line.run_cmd('import command ' + input_file)
         else:
-            cmd_line = cmd_interface.MadGraphCmdShell(mgme_dir = options.mgme_dir)
+            cmd_line = interface.MasterCmd(mgme_dir = options.mgme_dir)
             cmd_line.use_rawinput = False
             cmd_line.run_cmd('import command ' + input_file)
-
     else:
         # Interactive mode
         if options.web:
-            cmd_line = cmd_interface.MadGraphCmdWeb()
+            cmd_line = interface.MasterCmdWeb()
             cmd_line.cmdloop()
         else:
-            cmd_line = cmd_interface.MadGraphCmdShell(mgme_dir = options.mgme_dir)
+            cmd_line = interface.MasterCmd(mgme_dir = options.mgme_dir)
             cmd_line.cmdloop()
 except KeyboardInterrupt:
     print 'writting history and quit on KeyboardInterrupt' 

=== added file 'madgraph/interface/NLO_interface.py'
--- madgraph/interface/NLO_interface.py	1970-01-01 00:00:00 +0000
+++ madgraph/interface/NLO_interface.py	2012-02-14 23:32:18 +0000
@@ -0,0 +1,45 @@
+################################################################################
+#
+# Copyright (c) 2009 The MadGraph Development team and Contributors
+#
+# This file is a part of the MadGraph 5 project, an application which 
+# automatically generates Feynman diagrams and matrix elements for arbitrary
+# high-energy processes in the Standard Model and beyond.
+#
+# It is subject to the MadGraph license which should accompany this 
+# distribution.
+#
+# For more information, please visit: http://madgraph.phys.ucl.ac.be
+#
+################################################################################
+"""A user friendly command line interface to access all MadGraph features.
+   Uses the cmd package for command interpretation and tab completion.
+"""
+
+import os
+
+import madgraph
+from madgraph import MG4DIR, MG5DIR, MadGraph5Error
+import madgraph.interface.madgraph_interface as mg_interface
+
+#usefull shortcut
+pjoin = os.path.join
+
+class CheckLoop(mg_interface.CheckValidForCmd):
+    pass
+
+class CheckLoopWeb(mg_interface.CheckValidForCmdWeb, CheckLoop):
+    pass
+
+class CompleteLoop(mg_interface.CompleteForCmd):
+    pass
+
+class HelpLoop(mg_interface.HelpToCmd):
+    pass
+
+class LoopInterface(CheckLoop, CompleteLoop, HelpLoop, mg_interface.MadGraphCmd):
+    pass
+
+class LoopInterfaceWeb(mg_interface.CheckValidForCmdWeb, LoopInterface):
+    pass
+

=== renamed file 'madgraph/interface/cmd_interface.py' => 'madgraph/interface/madgraph_interface.py'
--- madgraph/interface/cmd_interface.py	2012-02-03 22:14:20 +0000
+++ madgraph/interface/madgraph_interface.py	2012-02-14 23:32:18 +0000
@@ -12,7 +12,7 @@
 # For more information, please visit: http://madgraph.phys.ucl.ac.be
 #
 ################################################################################
-"""A user friendly command line interface to access MadGraph features.
+"""A user friendly command line interface to access MadGraph features at LO.
    Uses the cmd package for command interpretation and tab completion.
 """
 
@@ -1035,7 +1035,7 @@
 #===============================================================================
 # CompleteForCmd
 #===============================================================================
-class CompleteForCmd(CheckValidForCmd):
+class CompleteForCmd(object):
     """ The Series of help routine for the MadGraphCmd"""
     
  
@@ -1538,9 +1538,12 @@
 #===============================================================================
 # MadGraphCmd
 #===============================================================================
-class MadGraphCmd(CmdExtended, HelpToCmd):
+class MadGraphCmd(CmdExtended, HelpToCmd, CheckValidForCmd, CompleteForCmd):
     """The command line processor of MadGraph"""    
 
+    writing_dir = '.'
+    timeout = 0 # time authorize to answer question [0 is no time limit]
+  
     # Options and formats available
     _display_opts = ['particles', 'interactions', 'processes', 'diagrams', 
                      'diagrams_text', 'multiparticles', 'couplings', 'lorentz', 
@@ -1566,6 +1569,19 @@
     _curr_exporter = None
     _done_export = False
 
+    def preloop(self):
+        """Initializing before starting the main loop"""
+
+        self.prompt = 'mg5>'
+        
+        # By default, load the UFO Standard Model
+        logger.info("Loading default model: sm")
+        self.do_import('model sm')
+        self.history.append('import model sm')
+        
+        # preloop mother
+        CmdExtended.preloop(self)
+
     
     def __init__(self, mgme_dir = '', *completekey, **stdin):
         """ add a tracker of the history """
@@ -3430,87 +3446,6 @@
             else: 
                 last_action_2 = 'none'
         
-
-#===============================================================================
-# MadGraphCmd
-#===============================================================================
-class MadGraphCmdWeb(MadGraphCmd, CheckValidForCmdWeb):
-    """The command line processor of MadGraph"""
- 
-    timeout = 1 # time authorize to answer question [0 is no time limit]
-    
-    def __init__(self, *arg, **opt):
-    
-        if os.environ.has_key('_CONDOR_SCRATCH_DIR'):
-            self.writing_dir = pjoin(os.environ['_CONDOR_SCRATCH_DIR'], \
-                                                                 os.path.pardir)
-        else:
-            self.writing_dir = pjoin(os.environ['MADGRAPH_DATA'],
-                               os.environ['REMOTE_USER'])
-            
-        
-        #standard initialization
-        MadGraphCmd.__init__(self, mgme_dir = '', *arg, **opt)
-    
-    def finalize(self, nojpeg):
-        """Finalize web generation""" 
-        
-        MadGraphCmd.finalize(self, nojpeg, online = True)
-
-    # Generate a new amplitude
-    def do_generate(self, line):
-        """Generate an amplitude for a given process"""
-
-        try:
-           MadGraphCmd.do_generate(self, line)
-        except:
-            # put the stop logo on the web
-            files.cp(self._export_dir+'/HTML/stop.jpg',self._export_dir+'/HTML/card.jpg')
-            raise
-    
-    # Add a process to the existing multiprocess definition
-    def do_add(self, line):
-        """Generate an amplitude for a given process and add to
-        existing amplitudes
-        syntax:
-        """
-        try:
-           MadGraphCmd.do_add(self, line)
-        except:
-            # put the stop logo on the web
-            files.cp(self._export_dir+'/HTML/stop.jpg',self._export_dir+'/HTML/card.jpg')
-            raise
-        
-    # Use the cluster file for the configuration
-    def set_configuration(self, config_path=None):
-        
-        """Force to use the web configuration file only"""
-        config_path = pjoin(os.environ['MADGRAPH_BASE'], 'mg5_configuration.txt')
-        return MadGraphCmd.set_configuration(self, config_path=config_path)
-
-#===============================================================================
-# MadGraphCmd
-#===============================================================================
-class MadGraphCmdShell(MadGraphCmd, CompleteForCmd, CheckValidForCmd, cmd.CmdShell):
-    """The command line processor of MadGraph""" 
-    
-    writing_dir = '.'
-    timeout = 0 # time authorize to answer question [0 is no time limit]
-    
-    def preloop(self):
-        """Initializing before starting the main loop"""
-
-        self.prompt = 'mg5>'
-        
-        # By default, load the UFO Standard Model
-        logger.info("Loading default model: sm")
-        self.do_import('model sm')
-        self.history.append('import model sm')
-        
-        # preloop mother
-        cmd.CmdShell.preloop(self)
-
-
 #===============================================================================
 # Command Parser
 #=============================================================================== 

=== added file 'madgraph/interface/master_interface.py'
--- madgraph/interface/master_interface.py	1970-01-01 00:00:00 +0000
+++ madgraph/interface/master_interface.py	2012-02-14 23:32:18 +0000
@@ -0,0 +1,438 @@
+################################################################################
+#
+# Copyright (c) 2009 The MadGraph Development team and Contributors
+#
+# This file is a part of the MadGraph 5 project, an application which 
+# automatically generates Feynman diagrams and matrix elements for arbitrary
+# high-energy processes in the Standard Model and beyond.
+#
+# It is subject to the MadGraph license which should accompany this 
+# distribution.
+#
+# For more information, please visit: http://madgraph.phys.ucl.ac.be
+#
+################################################################################
+"""A user friendly command line interface to access all MadGraph features.
+   Uses the cmd package for command interpretation and tab completion.
+"""
+
+
+import atexit
+import logging
+import optparse
+import os
+import pydoc
+import re
+import subprocess
+import sys
+import traceback
+import time
+
+root_path = os.path.split(os.path.dirname(os.path.realpath( __file__ )))[0]
+root_path = os.path.split(root_path)[0]
+sys.path.insert(0, root_path)
+
+#usefull shortcut
+pjoin = os.path.join
+
+import madgraph
+import madgraph.interface.extended_cmd as cmd
+import madgraph.interface.madgraph_interface as MGcmd
+import madgraph.interface.NLO_interface as NLOcmd
+
+from madgraph import MG4DIR, MG5DIR, MadGraph5Error
+
+logger = logging.getLogger('cmdprint') # -> stdout
+
+
+class Switcher(object):
+    """ Helping class containing all the switching routine """
+        
+    def debug_link_to_command(self):
+        """redefine all the command to call directly the appropriate child"""
+        
+        correct = True
+        # function which should be self.cmd dependent but which doesn't start
+        # by do_xxxx, help_xxx, check_xxxx or complete_xxx 
+        overwritable = []        
+        # list of item overwritten by the MasterClass
+        self.to_preserve = [key for key,method in Switcher.__dict__.items() if
+                       hasattr(method, '__call__') ]
+        self.to_preserve += ['do_shell', 'help_shell', 'complete_shell']
+
+        ff = open(pjoin(MG5DIR, 'additional_command'), 'w')
+        
+        for key in dir(self):
+            # by pass all not over-writable command
+            if key in self.to_preserve:
+                continue
+            if not (key.startswith('do_') or key.startswith('complete_') or \
+               key.startswith('help_') or key.startswith('check_') or \
+               key in overwritable):
+                continue
+            text = """\
+    def %(key)s(self, *args, **opts):
+        return self.cmd.%(key)s(self, *args, **opts)
+        
+""" % {'key': key}
+            logger.warning("""Command %s not define in the Master. 
+            The line to add to the master_interface.py are written in 'additional_command' file""" % key)
+            ff.write(text)
+            correct = False
+               
+            
+        # Check that all function define in more than one subclass is define
+        # in the Switcher or in one of the MasterClass
+        define = {}
+        for mother in MasterCmd.__mro__:
+            if mother.__name__ in ['Cmd', 'BasicCmd', 'ExtendedCmd']:
+                continue
+            
+            
+            for data in mother.__dict__:
+                #check if  define in Switcher
+                if data in Switcher.__dict__ or data.startswith('__'):
+                    continue
+                if data in MasterCmd.__dict__:
+                    #always overwritten in the  main class
+                    continue 
+                if data not in define:
+                    define[data] = mother.__name__
+                else:
+                    logger.warning('%s define in %s and in %s but not in Switcher.' % (data, define[data], mother.__name__))
+                    correct = False
+                    
+        # Do the same for the WEb MasterClass
+        define = {}
+        for mother in MasterCmdWeb.__mro__:
+            if mother.__name__ in ['Cmd', 'BasicCmd', 'ExtendedCmd']:
+                continue
+            
+            for data in mother.__dict__:
+                #check if  define in Switcher
+                if data in Switcher.__dict__ or data.startswith('__'):
+                    continue
+                if data in MasterCmdWeb.__dict__:
+                    #always overwritten in the  main class
+                    continue                
+                if data not in define:
+                    define[data] = mother.__name__
+                else:
+                    logger.warning('%s define in %s and in %s but not in Switcher.' % (data, define[data], mother.__name__))
+                    correct = False                    
+                    
+        if not correct:
+            raise Exception, 'The Cmd interface has dangerous features. Please see previous warnings and correct those.' 
+        
+        
+    
+    
+    
+    def check_add(self, *args, **opts):
+        return self.cmd.check_add(self, *args, **opts)
+        
+    def check_answer_in_input_file(self, *args, **opts):
+        return self.cmd.check_answer_in_input_file(self, *args, **opts)
+        
+    def check_check(self, *args, **opts):
+        return self.cmd.check_check(self, *args, **opts)
+        
+    def check_define(self, *args, **opts):
+        return self.cmd.check_define(self, *args, **opts)
+        
+    def check_display(self, *args, **opts):
+        return self.cmd.check_display(self, *args, **opts)
+        
+    def check_draw(self, *args, **opts):
+        return self.cmd.check_draw(self, *args, **opts)
+        
+    def check_for_export_dir(self, *args, **opts):
+        return self.cmd.check_for_export_dir(self, *args, **opts)
+        
+    def check_generate(self, *args, **opts):
+        return self.cmd.check_generate(self, *args, **opts)
+        
+    def check_history(self, *args, **opts):
+        return self.cmd.check_history(self, *args, **opts)
+        
+    def check_import(self, *args, **opts):
+        return self.cmd.check_import(self, *args, **opts)
+        
+    def check_install(self, *args, **opts):
+        return self.cmd.check_install(self, *args, **opts)
+        
+    def check_launch(self, *args, **opts):
+        return self.cmd.check_launch(self, *args, **opts)
+        
+    def check_load(self, *args, **opts):
+        return self.cmd.check_load(self, *args, **opts)
+        
+    def check_open(self, *args, **opts):
+        return self.cmd.check_open(self, *args, **opts)
+        
+    def check_output(self, *args, **opts):
+        return self.cmd.check_output(self, *args, **opts)
+        
+    def check_process_format(self, *args, **opts):
+        return self.cmd.check_process_format(self, *args, **opts)
+        
+    def check_save(self, *args, **opts):
+        return self.cmd.check_save(self, *args, **opts)
+        
+    def check_set(self, *args, **opts):
+        return self.cmd.check_set(self, *args, **opts)
+        
+    def check_stored_line(self, *args, **opts):
+        return self.cmd.check_stored_line(self, *args, **opts)
+        
+    def complete_add(self, *args, **opts):
+        return self.cmd.complete_add(self, *args, **opts)
+        
+    def complete_check(self, *args, **opts):
+        return self.cmd.complete_check(self, *args, **opts)
+        
+    def complete_define(self, *args, **opts):
+        return self.cmd.complete_define(self, *args, **opts)
+        
+    def complete_display(self, *args, **opts):
+        return self.cmd.complete_display(self, *args, **opts)
+        
+    def complete_draw(self, *args, **opts):
+        return self.cmd.complete_draw(self, *args, **opts)
+        
+    def complete_generate(self, *args, **opts):
+        return self.cmd.complete_generate(self, *args, **opts)
+        
+    def complete_help(self, *args, **opts):
+        return self.cmd.complete_help(self, *args, **opts)
+        
+    def complete_history(self, *args, **opts):
+        return self.cmd.complete_history(self, *args, **opts)
+        
+    def complete_import(self, *args, **opts):
+        return self.cmd.complete_import(self, *args, **opts)
+        
+    def complete_install(self, *args, **opts):
+        return self.cmd.complete_install(self, *args, **opts)
+        
+    def complete_launch(self, *args, **opts):
+        return self.cmd.complete_launch(self, *args, **opts)
+        
+    def complete_load(self, *args, **opts):
+        return self.cmd.complete_load(self, *args, **opts)
+        
+    def complete_open(self, *args, **opts):
+        return self.cmd.complete_open(self, *args, **opts)
+        
+    def complete_output(self, *args, **opts):
+        return self.cmd.complete_output(self, *args, **opts)
+        
+    def complete_save(self, *args, **opts):
+        return self.cmd.complete_save(self, *args, **opts)
+        
+    def complete_set(self, *args, **opts):
+        return self.cmd.complete_set(self, *args, **opts)
+        
+    def complete_tutorial(self, *args, **opts):
+        return self.cmd.complete_tutorial(self, *args, **opts)
+        
+    def do_EOF(self, *args, **opts):
+        return self.cmd.do_EOF(self, *args, **opts)
+        
+    def do_add(self, *args, **opts):
+        return self.cmd.do_add(self, *args, **opts)
+        
+    def do_check(self, *args, **opts):
+        return self.cmd.do_check(self, *args, **opts)
+        
+    def do_define(self, *args, **opts):
+        return self.cmd.do_define(self, *args, **opts)
+        
+    def do_display(self, *args, **opts):
+        return self.cmd.do_display(self, *args, **opts)
+        
+    def do_exit(self, *args, **opts):
+        return self.cmd.do_exit(self, *args, **opts)
+        
+    def do_generate(self, *args, **opts):
+        return self.cmd.do_generate(self, *args, **opts)
+        
+    def do_help(self, *args, **opts):
+        return self.cmd.do_help(self, *args, **opts)
+        
+    def do_history(self, *args, **opts):
+        return self.cmd.do_history(self, *args, **opts)
+        
+    def do_import(self, *args, **opts):
+        return self.cmd.do_import(self, *args, **opts)
+        
+    def do_install(self, *args, **opts):
+        return self.cmd.do_install(self, *args, **opts)
+        
+    def do_launch(self, *args, **opts):
+        return self.cmd.do_launch(self, *args, **opts)
+        
+    def do_load(self, *args, **opts):
+        return self.cmd.do_load(self, *args, **opts)
+        
+    def do_open(self, *args, **opts):
+        return self.cmd.do_open(self, *args, **opts)
+        
+    def do_output(self, *args, **opts):
+        return self.cmd.do_output(self, *args, **opts)
+        
+    def do_quit(self, *args, **opts):
+        return self.cmd.do_quit(self, *args, **opts)
+        
+    def do_save(self, *args, **opts):
+        return self.cmd.do_save(self, *args, **opts)
+        
+    def do_set(self, *args, **opts):
+        return self.cmd.do_set(self, *args, **opts)
+        
+    def do_tutorial(self, *args, **opts):
+        return self.cmd.do_tutorial(self, *args, **opts)
+        
+    def help_EOF(self, *args, **opts):
+        return self.cmd.help_EOF(self, *args, **opts)
+        
+    def help_add(self, *args, **opts):
+        return self.cmd.help_add(self, *args, **opts)
+        
+    def help_check(self, *args, **opts):
+        return self.cmd.help_check(self, *args, **opts)
+        
+    def help_define(self, *args, **opts):
+        return self.cmd.help_define(self, *args, **opts)
+        
+    def help_display(self, *args, **opts):
+        return self.cmd.help_display(self, *args, **opts)
+        
+    def help_generate(self, *args, **opts):
+        return self.cmd.help_generate(self, *args, **opts)
+        
+    def help_help(self, *args, **opts):
+        return self.cmd.help_help(self, *args, **opts)
+        
+    def help_history(self, *args, **opts):
+        return self.cmd.help_history(self, *args, **opts)
+        
+    def help_import(self, *args, **opts):
+        return self.cmd.help_import(self, *args, **opts)
+        
+    def help_install(self, *args, **opts):
+        return self.cmd.help_install(self, *args, **opts)
+        
+    def help_launch(self, *args, **opts):
+        return self.cmd.help_launch(self, *args, **opts)
+        
+    def help_load(self, *args, **opts):
+        return self.cmd.help_load(self, *args, **opts)
+        
+    def help_open(self, *args, **opts):
+        return self.cmd.help_open(self, *args, **opts)
+        
+    def help_output(self, *args, **opts):
+        return self.cmd.help_output(self, *args, **opts)
+        
+    def help_quit(self, *args, **opts):
+        return self.cmd.help_quit(self, *args, **opts)
+        
+    def help_save(self, *args, **opts):
+        return self.cmd.help_save(self, *args, **opts)
+        
+    def help_set(self, *args, **opts):
+        return self.cmd.help_set(self, *args, **opts)
+        
+    def help_tutorial(self, *args, **opts):
+        return self.cmd.help_tutorial(self, *args, **opts)
+        
+    def test_interface(self, *args, **opts):
+        return self.cmd.test_interface(self, *args, **opts)
+
+
+
+class MasterCmd(Switcher, NLOcmd.LoopInterface, cmd.CmdShell):
+
+    def __init__(self, main='MadGraph', *args, **opt):
+            
+        # define the interface
+        self.change_principal_cmd(main)
+        self.cmd.__init__(self, *args, **opt)       
+        
+
+    def change_principal_cmd(self, name):
+        if name == 'MadGraph':
+            self.cmd = MGcmd.MadGraphCmd
+        elif name == 'Loop':
+            self.cmd = NLOcmd.LoopInterface
+        else:
+            raise MadGraph5Error, 'Type of interface not valid'  
+        
+        if __debug__:
+            self.debug_link_to_command()      
+        
+class MasterCmdWeb(Switcher, NLOcmd.LoopInterfaceWeb):
+ 
+    timeout = 1 # time authorize to answer question [0 is no time limit]
+    
+    def __init__(self, *arg, **opt):
+    
+        if os.environ.has_key('_CONDOR_SCRATCH_DIR'):
+            self.writing_dir = pjoin(os.environ['_CONDOR_SCRATCH_DIR'], \
+                                                                 os.path.pardir)
+        else:
+            self.writing_dir = pjoin(os.environ['MADGRAPH_DATA'],
+                               os.environ['REMOTE_USER'])
+            
+        
+        #standard initialization
+        MasterCmd.__init__(self, mgme_dir = '', *arg, **opt)
+        
+    def change_principal_cmd(self, name):
+        if name == 'MadGraph':
+            self.cmd = MGcmd.MadGraphCmdWeb
+        elif name == 'Loop':
+            self.cmd = NLOcmd.LoopInterfaceWeb
+        else:
+            raise MadGraph5Error, 'Type of interface not valid'  
+        
+        if __debug__:
+            self.debug_link_to_command() 
+    
+    def finalize(self, nojpeg):
+        """Finalize web generation""" 
+        
+        Switcher.finalize(self, nojpeg, online = True)
+
+    # Generate a new amplitude
+    def do_generate(self, line):
+        """Generate an amplitude for a given process"""
+
+        try:
+            Switcher.do_generate(self, line)
+        except:
+            # put the stop logo on the web
+            files.cp(self._export_dir+'/HTML/stop.jpg',self._export_dir+'/HTML/card.jpg')
+            raise
+    
+    # Add a process to the existing multiprocess definition
+    def do_add(self, line):
+        """Generate an amplitude for a given process and add to
+        existing amplitudes
+        syntax:
+        """
+        try:
+           Switcher.do_add(self, line)
+        except:
+            # put the stop logo on the web
+            files.cp(self._export_dir+'/HTML/stop.jpg',self._export_dir+'/HTML/card.jpg')
+            raise
+        
+    # Use the cluster file for the configuration
+    def set_configuration(self, config_path=None):
+        
+        """Force to use the web configuration file only"""
+        config_path = pjoin(os.environ['MADGRAPH_BASE'], 'mg5_configuration.txt')
+        return Switcher.set_configuration(self, config_path=config_path)
+    
\ No newline at end of file