This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
2013:groups:tools:eventformats [2013/06/19 11:54] eric.conte [Motivations] |
2013:groups:tools:eventformats [2013/06/20 12:05] eric.conte [Event Format : extended LHE] |
||
---|---|---|---|
Line 1: | Line 1: | ||
====== Event Format : extended LHE ====== | ====== Event Format : extended LHE ====== | ||
- | People involved: | + | People involved: Eric & Benj |
===== Present state ===== | ===== Present state ===== | ||
Line 26: | Line 26: | ||
===== Some ideas to discuss ===== | ===== Some ideas to discuss ===== | ||
- | * Using text format (theorist-friendly format :-D). ROOT is rejected. | + | * Using text format. ROOT is rejected ; STDHEP seems to be old. |
- | * Keeping the structure of the existing LHE Format (arXiv:hep-ph/0609017) and its XML tags. Name of the format extension: eLHE (e for 'extended') ? Reminder: | + | * Prefering extending an existing format to defining a totally new one (avoiding developers from coding writer and reader functions from scratch). Our choice is to extend the LHE Format (arXiv:hep-ph/0609017) and its structure based on XML tags. Reminder about the LHE structure: |
<LesHouchesEvents version="X"> | <LesHouchesEvents version="X"> | ||
Line 58: | Line 58: | ||
</LesHouchesEvents> | </LesHouchesEvents> | ||
- | * Possibility to store hard-process states and reco objects in a same file. | + | * Extending the LHE format in order to store partons, hadrons and jets (reco objects) in a same file. The generation step (hard-process, shower, reco) will be specified by the status-code. Some details: |
- | * The generation step (hard-process, shower, reco) will be specified by the status code. | + | ---- |
- | * Optional substructure in <event> block: defining a XML tag for each collection of objects. Several collections of a same object kind (jets in the example) can be defined and used. | + | * parton level: same conventions than the existing LHE. Example: |
- | <hardprocess> | + | 6 2 1 2 501 0 -0.14952840473E+03 0.23999735524E+02 -0.25720865153E+03 0.34516945021E+03 0.17335203433E+03 0. 0. |
+ | |||
+ | * hadron level: the conventions can be applied without too much change (maybe the meaning of the two ICOLUP variables could be discussed). | ||
+ | |||
+ | 2212 2 1 2 501 0 -0.14952840473E+03 0.23999735524E+02 -0.25720865153E+03 0.34516945021E+03 0.17335203433E+03 0. 0. | ||
+ | |||
+ | * reco level: the conventions have to be adapted. We can keep: | ||
+ | * one line per physics object. | ||
+ | * ISTUP variable with specific PDG-id for reco objects. Example: 11/-11 for electrons, 13/-13 for muons, 15/-15 for hadronically-decaying taus, 22 for photons, 21 for jets, 12 for MET, -12 for MHT | ||
+ | * MOTHUP variables linked the reconstructed object to the originated partons (only for some objects). Example: a electron coming from hard-process. | ||
+ | * PUP variables without change. | ||
+ | Other relevant variables, specific to the nature of the reconstructed objects, must be added. | ||
+ | |||
+ | |||
+ | ---- | ||
+ | |||
+ | * Optional substructure in <event> block: defining a XML tag for each collection of reconstructed objects. When detector fast-simulation is applied, several configurations can be applied (for instance for lepton isolation) and several collection of the same object kind can be produced. The <event>-block substructure is designed to handle several collections of a same object kind. Example: | ||
+ | |||
+ | <event> | ||
... | ... | ||
- | </hardprocess> | + | |
<jets> | <jets> | ||
... | ... | ||
Line 79: | Line 97: | ||
... | ... | ||
</muons> | </muons> | ||
- | ... | + | </event> |
- | + | ||