MadGraph++

Some scattered thoughts about a very long term project: a complete rewriting of the whole HELAS/MG/ME software in modern language(s) emphasizing the "development framework" aspect and opening new physics opportunities.

Disclaimer: For the moment it's more an abstract idea, even a dream than a real proposal. But time is flying and obviously we are sometimes facing limitations of Fortran and its static structure. A complete rewriting would probably take a few years, but this is precisely because of this that we should maybe start thinking about it. Also the pre-thinking step is the most important and the longest one for an object-oriented software. Since it is not extremely time consuming (a lot of brain storming, not a lot of real coding work), I personally think this can be started right now, even if we are moving slowly. At some point, when ideas will become more clear, I also think we could make a (quiet) announcement about it to show to the community we are aware of current limitations and we are ready to think about future. -- Michel

New things we want…

• deep reusability
• faster than fortran version (it should be a real progress)
• keep successful algo (madgraph main algos, single-channel integration, ...)
• conceptually model independent (including non-renormalizable interactions, ...)

Old things we maybe not want anymore…

• .inc files between MG and ME (hard to maintain)
• hard coding of process independant part of ME in MG (matrix.f heading, ...)
• several copies of I/O routines (cards, LHE, ...)

Language proposal

Proposal 1 (Michel, first try)

C++: probably the only reasonable choice for the numerical stuff (HELAS and MadEvent). It is fast, object oriented and highly portable thanks to gcc. Drawback: need a very serious tree project before starting (using mind mapping/ML tools ?)

Python: could be an interesting choice for MadGraph. It is a scripting language, rather fast, highly portable on all OS, object-oriented and very easy to maintain/update. It is often used for code-writing codes a la MadGraph. It can also be used as a replacement for perl (which is hard to maintain and not very readable) and csh (which is deprecated on most OS). Drawbacks: nobody knows it very well except Olivier ;)

Proposal 2 (Michel & Pavel, second try)

Full Python! It may seems a crazy choice but it's not. In fact MG/ME is the archetype of a large scientific application, and it should not be a big monolithic application, almost freezed once for all (where C++ is really good). It should be evolving, modular, easy to script, debug, test and modify. In one word, living. And for the numerical aspects, Python is very efficient to interface C and C++ (or even Fortran), so we can write the very few critical numerical part in a fast language (Pavel was proposing to stick to C which is simple and the fastest) and keep the main trunk in Python. What I like about the idea:

• no more distinction between a hard core and scripts around, everything is made of easy to maintain scripts calling a few very fast numerical routines (HELAS, SCI, ...)
• it looks like the future for programing large scale applications, so in some sense we can switch from the past (F77) to the future (Python like) without stopping at an intermediate step (C++, like Sherpa, Pythia, Herwig, ...). It can give a big advantage to MG in the future.
• C++ is heavy (look at ROOT, Sherpa, ...) and even if well coded, the associated libraries are easily huge (e.g. 300Mb for W3j in Sherpa!)
• Python is very evolutive, so we can start the project quickly, even with bad ideas, and build the whole application in steps. It looks like Python is done for Physicists (who change their mind every three days) while C++ is more for computer scientists (who are able to design a 60k line app in advance).
• Great for the web, imagine you can improve the numerical integration routine for a specific complicated process by tuning ME directly online... Or that you can implement new HELAS structures from FeynRules...
• Python is the real way to go to open source. Open should not only means available, but also easy to modify and share. We can even think about using open source projects like SciPy to take care of plotting, diagram drawing, MC basic routines, ...
• More time for physics!

To convince yourself, look at ​this and ​this.

-- Main.MichelHerquet - 10 Dec 2007