| 6 | | !MadGraph/MadEvent is highly optimized to run in parallel on computer clusters. The "single-diagrams-enhanched multichannel" integration technique makes it possible to split the phase space integration into small bits that can be evaluated independently. However, to get correct results it is mandatory that all these jobs are retrieved without errors. In principle such an architecture can also work efficiently over the LHC computing grid, which consist of many computer clusters around the world, apart from the fact that there is a larger overhead for sending jobs and, more importantly, the probability that some jobs might get "lost" cannot be neglected. Resending the lost jobs is an option, but not very efficient. We have therefore designed a special mode for !MadGraph/MadEvent that creates a self-contained package that can be sent over the grid. This package, "gridpack.tar.gz", is optimized for a specific process with ''fixed model and run parameters'' and is supposed to run on a single machine. The package needs to be compiled on a grid compatible machine after which it can be send over the grid with as only inputs the requested number of events for that run and the random number seed. The events generated by a gridpack with a given random number seed are independent of events generated with a different random number seed. The events from a single job are distributed in phase space according to their physical expectation, so any number of jobs can savely be added or removed. Gridpacks for "SM candle" processes at the LHC (both for 14 !TeV as well as 10 !TeV) can be found on the [:Library.MadGraphSamples:MadGraph Samples] wiki page. |
| | 6 | !MadGraph/MadEvent is highly optimized to run in parallel on computer clusters. The "single-diagrams-enhanched multichannel" integration technique makes it possible to split the phase space integration into small bits that can be evaluated independently. However, to get correct results it is mandatory that all these jobs are retrieved without errors. In principle such an architecture can also work efficiently over the LHC computing grid, which consist of many computer clusters around the world, apart from the fact that there is a larger overhead for sending jobs and, more importantly, the probability that some jobs might get "lost" cannot be neglected. Resending the lost jobs is an option, but not very efficient. We have therefore designed a special mode for !MadGraph/MadEvent that creates a self-contained package that can be sent over the grid. This package, "gridpack.tar.gz", is optimized for a specific process with ''fixed model and run parameters'' and is supposed to run on a single machine. The package needs to be compiled on a grid compatible machine after which it can be send over the grid with as only inputs the requested number of events for that run and the random number seed. The events generated by a gridpack with a given random number seed are independent of events generated with a different random number seed. The events from a single job are distributed in phase space according to their physical expectation, so any number of jobs can savely be added or removed. Gridpacks for "SM candle" processes at the LHC (both for 14 !TeV as well as 10 !TeV) can be found on the [wiki:Library.MadGraphSamples MadGraph Samples] wiki page. |
| 20 | | In specific cases the granularity could be increased, ''e.g.'', if you know beforehand that you will produce a lot of events. In this example, where the total number of events will be a million, the uncertainty will be sqrt(10^6){{{1000. Hence the granularity could have been set to 1000 as this will generate at least 1000 events for each channel. Hence you'll never be off by more than 1000 events. (The value for the granularity can be set by passing it as the 3rd argument when executing the }}}./run.sh= script). However, this should be used with great care, because in the case where not all the gridpack jobs can be retrieved, or if only a subset of the total number of events is analyzed, you are making an error. It is therefore '''highly recommended to not touch the default value for the granularity''' at leave the 3rd argument of the =./run.sh= script empty. |
| | 20 | In specific cases the granularity could be increased, ''e.g.'', if you know beforehand that you will produce a lot of events. In this example, where the total number of events will be a million, the uncertainty will be sqrt(10^6){{{ |
| | 21 | 1000. Hence the granularity could have been set to 1000 as this will generate at least 1000 events for each channel. Hence you'll never be off by more than 1000 events. (The value for the granularity can be set by passing it as the 3rd argument when executing the |
| | 22 | }}}./run.sh= script). However, this should be used with great care, because in the case where not all the gridpack jobs can be retrieved, or if only a subset of the total number of events is analyzed, you are making an error. It is therefore '''highly recommended to not touch the default value for the granularity''' at leave the 3rd argument of the =./run.sh= script empty. |
