Public release of MadGraph5 v2.0 including aMC@NLO

List below the different points which necessarily need to be adressed before the public release of MadGraph5 v2.0.

When editing the above, please try to stick to the self-explanatory conventions (Syntax, fixed numbering and placement in the right section when fixed).

To fix before v2.0 beta release

aMC@NLO 5 | J.A. | When launching aMC@NLO some 'set' commands are not recognized and output their help.

This is because aMCatNLOLauncher uses exec_cmd from ExtendedCmd which in turn will call the do_set() of common_run_interface.py for which 'check_set()' does not recognize some options like complex_mass_scheme and loop_optimized_output. I am not sure how Marco wants this fixed, so please Marco do it.

mz:fixed after merge with mg5 1.5.2?

aMC@NLO 20 | O.M. | The tutorial aMCatNLO and the help of launch should explain the details of launch especially for running the shower

aMC@NLO 71| O.M. | aMCatNLO-Utilities should auto-detect the compiler/ the fact that we are in 64 bit/…

and also having a file make_opts used by all sub makefile present in this utilities.

DONE MZ r370 (and 16 for MCatNLO-utilities)

aMC@NLO ?? && ?? | O.M | Having all acceptance/parralel test working !! (not the case currently)

To fix before v2.0 release

no mail number|OM| Contextual help in aMCatNLO_run interfaces not valid (indicates multi_run for example)

4 | O.M. | Generate some html output for checking the generation of the fortran code and of the output.

22FKS | All | We need to discuss what functionality we want to release,

in particular the complex mass scheme. It is not correct as such right now but people could easily correct it and scoop us. Same for QED in principle. What feature do we want to lock and how? Please make your proposal below. R.F. | I wouldn't worry about this. The code is complex and before somebody figures out how to do this, we should have release it.

9 | V.H. | Fix RAMBO phase-space point generation for 3-body interactions

simply always generate the single configuration with the third particle at rest. It is good enough for the checks.

To be adressed (the fatest the better)

15FKS | O.M. | Generalize the function get_interaction_q_power

so that it uses aloha to retrieve this information (comment copied from FKS5 branch review) R.F. | Is this necessary before the release? We support only virtual corrections within the Standard Model.

28FKS | O.M. | Refactor helas_call_writers.py

by creating a loop version of this file to be put in the 'loop' directory and creating a LoopHelasCallWriter daughter class to build more elegant structures for the loop helas output. (comment copied from FKS5 branch review)

25FKS | V.H. | We should improve our handling of gauges in MG5

so to make it part of the UFO model which would now also specify the propagators of the particles included. This would allow for many gauges and the specification of any value for the chsi parameter. It could also possibly help for the exploration of the spin 3/2 landscape of propagators we have now.

32FKS | O.M. | Refactor process_checks.py by creating a loop_process_check.py

should be quick and very superficial anyway.

no mail number|OM| Having the shower to run in multi-core/cluster (This is very long and is easy to split)

aMC@NLO 44 | O.M. | Having the compilation/test on multi-core, and possibly also the generation/output

Fixed issues

aMC@NLO ?? && ?? |J.A && O.M | Change the tag before the > for the aMC@NLO run interface.

So to make it explicit where the user stand and avoid confusion.

[ Fixed ] V.H. | I changed it to aMC@NLO_run>.

2 | O.M | Commands help and auto-completion

Update the auto-completion and help for the loop functionalities.

[ Fixed ] V.H. | The auto-completion should now be ok, especially when entering loop processes definitions. The help has gained a color scheme and is now updated with the loop features except for the aMC@NLO launch section which Marco will fill in very soon. So let us know if anything suspicious is left in this department.

10 | M.Z. | Fix the STOP: momentum conservation errror from madloop

[ Fixed ] M.Z. | (r355), it was a stupid bug inside check_poles

1 | R.F | Default coupling orders at NLO

Change the default chosen coupling order configuration for processes which can have mixed order contributions at LO already. Typically, one wants p p > t t~ [QCD] to return only contributions with QED = 0. [ Fixed ] V.H. | Now in the case proposed above, it will inform the user that the configuration (QED=0,QCD=*) is chosen and warns that additional contributions of configuration (QED=2,QCD=*) are detected but discarded.

3 | V.H | Tracking of unstable points in MadFKS

For now simply from the IR cancellation test. At the end of a run, it should give their number versus the total number of calls to the virtual as well as writing out the first ten (with the renormalization scale used) in a log file like 'UPS.log' in the G* folder. [ Fixed ] M.Z. |

5 | O.M. | Have a nice error/treatment if fast jet is missing

[ Fixed ] M.Z. | (r341)

6 | O.M. | Explaining how to launch the shower (and the point for the counter-term in the tutorial

[ Fixed ] M.Z. | (r343)

7 | O.M. | add process crash in MC@NLO (if no generate are done before)

[ Fixed ] M.Z. | (r341)

8 | M.Z. | param_card updates do not affect results

[ Fixed ] M.Z. | (r352), was only related to tests

Development issues and strategies

The "end" of version 4, the early "beginning" of version 5

When do we freeze MG/ME v4? 1st October 2009, right after MG meeting

What do we include in the frozen v4?

1. lhapdf will be in.
2. proto CKKW matching. Only initial state are in. Final state will be there.
3. FR models + USRMOD2 will be in. Old models will be moved in a subdir of Models/ called Legacy/ + give the possibility to use old param_card.dat ? An email to the whole team to fix details.

What kind of modification will be allowed ?

1. Any new model (FR compatible)
2. Any other modification can be released as downloadable patches to "protect" the code.

MG@NLO stuff will be developed on top of the frozen in v4 and added to v5 when ready.

MG4Pythia: considered as a side project anyway, especially if the only public thing to release is a 2>2 process library, not the code to produce it (which is much more v5 in the philosophy). Johan will be in charge for the wrapping script, Tim will help for possible modifications to MG or HELAS required to produce off shell final state particles.

Yellow Sheet (OLD)

This is the official list of proposed improvements/developments. Some of them are prioritized.

• YellowSheet : This is the historical name of the todo list for Mad developers.

Comments and meeting minutes

• 2 Aug 2007 - GRID oriented developments
• 31 Jul 2007 - brain.pdf​: Slides of Brainstorming session held at UCL
• 31 Jul 2007- Comments & suggestions by Dorian Kcira

Sanity check for a modification of MadGraph

• TestProgram: This page present how to use (and also implement) the test of the different code of MadGraph

A long term project for MadGraph: version 5 ???

• v4tov5_plan.pdf​: v4 to v5 scattered thoughts
• MadGraph5: ideas/proposal for the v5 of MadGraph (full Python)
• MadEvent5: ideas/proposal for the v5 of MadEvent (Python + gfortran)
• MadGraph++ (old version, first thoughts)