| | 1 | |
| | 2 | |
| | 3 | === Dorian Comments on the status of MadGraph vs CMS === |
| | 4 | |
| | 5 | 1. since we introduced the interface in CMSSW, experimentalists are using MG/ME more than before. I was told that the organizers of the |
| | 6 | Les Houches workshop were surprized to see that a lot of people were using MadGraph |
| | 7 | 1. this summer we will simulate and reconstruct about 2M events (ttbar: dileptonic and semileptonic) privately in Louvain. They have been already generated |
| | 8 | but we could not yet start the simulation due to matching problem when using DECAY (see below). |
| | 9 | 1. starting from autumn, MG will be integrated in the official chain for generation/simulation/reconstruction that uses ProdAgent. This requires changes so that ProdAgent can read Les Houches files but this has been already approved and will be done by the groups that deal with it. |
| | 10 | 1. As you know, the physics validation has started already. We (Simon, myself) provided Roberto Chierici with the ttbar samples and with the plots (+scripts to produce them) that validate the matching. He has produced other plots, mainly comparisons with Alpgen, etc. which look in general good although there are small differences here an there. |
| | 11 | 1. Concerning the CMSSW interface, Johan has always provided a lot of help, council, and changes of code when needed. We bombard him continuously with questions so I would like to thank him a lot before I start describing technicalities and problems. For the interface I copy the fortran routine(s) that are used int he MG package and make small changes to them. |
| | 12 | These changes are not big but introduce the risk of bugs. |
| | 13 | 1. Ideally we should be in a state like this: |
| | 14 | - Each time a new MG relase comes out I also include the ME2Pythia from that release in CMSSW |
| | 15 | - It would be nice if the code can be changed such that I can include Me2Pythia directly in CMSSW without changes, this is technical, I have to discuss with Johan |
| | 16 | 1. The new code that Simon is writing for validating the matching should be also included in CMSSW but it relies on the StdHEP outptu file which we do not have by default in CMSSW |
| | 17 | 1. When using the new routines with matching in CMSSW we run into the two main following problems. |
| | 18 | i. If one produces the event-tree file for checking the matching, the status of the pythia particles is changed. In the routines that produce the event-tree this status is changed to select only the interesting particles in an elegant way. But this change is permanent and the particles one gets have no status-3 particles and some status 1 particles are status 2. This is a problem since the CMS software that runs on these generated particles often relies on this status number for selection too. I wonder if there is a way to do this without changing the status or reversing the changes. Anyway, if one choses not to produce the event-tree file, no status changes occur so everything works fine. |
| | 19 | i. Simon generated about 2M events ttbar and then we used the DECAY program from the MG package. We also wrote some small scripts to automatically run this program without having to type the choices at the command line interactively. This worked fine. Afterwards we tried to match these ttbar+N-partons samples in CMSSW but this did not work. After some investigation it became clear that at the point when these routines are run the mother-daughter relationships are not there (not always). This of course is a problem because you cannot exclude the daughters of the top-quark from the jetfinding and subsequent matching. The CMSSW we were using has pythia6.226 as default. Simon (and Johan, I believe) have run the matching routine from the MG package which has pythia 6.4X and it seems to work fine. I still have to test this when I come to Louvain. The new CMSSW versions use Pythia 6.409, we might need to generate with older releases but I can change the pythia version there too if needed. Concerning this point I have some suggestions/complaints. Please consider this as something we have to improve not personal against anyone. |
| | 20 | i. After we tried a couple of days with Simon, Pavel told us that he was aware of this problem and that we were loosing our time . . . |
| | 21 | i. also compareed the routine of CMSSW with the routine from the web site and they are different. I cannot say whether this is the problem or the pythia version is the problem. Here it becomes clear that we need synchronized and validated versions of the routines between MG and CMSSW. Theoreticians work mostly in small groups so I guess is usual that people do changes to routines and send them around. But in CMS the code has to be stable and validated in each release. If we commit some code and people generate-simulate-reconstruct millions and millions of events is a very big effort to redo this and anyway it takes months. |
| | 22 | i. Pavel also claims that, even if we fix pythia the matching will not work anyway. I could not completely understand the reason but I hope you will discuss this among yourselves now that Johan is there. |
| | 23 | i . In general, we need to improve the communication between us as this would save a lot of time. |
| | 24 | 1. Monica told me that some of the cards used for generation are not documented anywhere (VBF card? Simon knows about this one). Of course until know people that used MG were experts or in direct contact with experts but we might need to improve the documentation. |
| | 25 | |
| | 26 | The wiki page of MadGraph in CMSSW is: |
| | 27 | https://twiki.cern.ch/twiki/bin/view/CMS/SWGuideMadGraphInterface |
| | 28 | --------------------------- |
| | 29 | |
| | 30 | |
| | 31 | |
| | 32 | -- Main.FabioMaltoni - 31 Jul 2007 |
