| Multiple input files / trees [message #13244] |
Thu, 22 March 2012 10:59  |
Volker Friese
Messages: 365
Registered: April 2004
Location: GSI CBM
|
first-grade participant |
From: *zdv.uni-mainz.de
|
|
I would like to ask about the status of a topic that was discussed some time ago, concerning the possibility to have two (or more) input files of the same data level (the same branches) for a reconstruction run.
The concrete example is in our case to use two files with MC (transport) data and merge them before digitisation. A typical use case for us is to overlay background events (e.g. from UrQMD with some thousand tracks) with signal events (e.g. a J/psi decay with only two daughter tracks). Transporting UrQMD is very CPU and time expensive, while the transport of signals is not. So, one would like to re-use the same transported UrQMD events as background for different signals.
This demand can be generalised to using multiple files with the same branches at any stage of the reconstruction.
I recall that some years ago, Denis made some attempts to solve this, but I think there were major difficulties, and the issue was dropped eventually.
Are there plans to take this issue up again on the framework level? Or is the feature already solved without my being aware?
Best regards,
Volker
|
|
|
|
|
|
|
|
| Re: Multiple input files / trees [message #13247 is a reply to message #13246] |
Thu, 22 March 2012 12:44  |
Mohammad Al-Turany
Messages: 518
Registered: April 2004
Location: GSI, Germany
|
first-grade participant |
From: *gsi.de
|
|
Dear Volker,
First of all there are many features in FairRoot which where not communicated to CBM, even though they could be and they are needed by CBM. This has many reasons, the major one of them that in CBM there is not even a computing session (as in Panda or R3B) where we could go and report about our activities. Also the comunication between us (FairRoot core) and CBM developers is not ideal and mostly based on personal mails, but this we do not need to discuss here, and I think this Forum is a first step to correct that.
Now back to your original mail.
The merging we have in FairRoot for now was implimented on the level between Digi and MC and not directly on the digi level. i.e: after simulation of different generator output, the FairRunAna has following methods:
/**Set the input signal file
*@param name : signal file name
*@param identifier : Unsigned integer which identify the signal file
**/
void SetSignalFile(TString name, UInt_t identifier );
/**Set the input background file by name*/
void SetBackgroundFile(TString name);
/**Add input background file by name*/[/COLOR]
void AddBackgroundFile(TString name);
/**Add signal file to input
*@param name : signal file name
*@param identifier : Unsigned integer which identify the signal file to which this signal should be added
*/
void AddSignalFile(TString name, UInt_t identifier );
With this you can add several signals to a background file or chain, also signals can be chained, the mixing is controlled by:
| Quote: |
/**Set the signal to background ratio in event units
*@param background : Number of background Events for one signal
*@param Signalid : Signal file Id, used when adding (setting) the signal file
* here we just forward the call to the FairRootManager
*/
void BGWindowWidthNo(UInt_t background, UInt_t Signalid);
/**Set the signal to background rate in time units
*@param background : Time of background Events before one signal
*@param Signalid : Signal file Id, used when adding (setting) the signal file
* here we just forward the call to the FairRootManager
*/
void BGWindowWidthTime(Double_t background, UInt_t Signalid);
|
WIth these methods you can mix the signals and background but there is no direct pileup here. So do you need to pile up the events on MC level?
if yes then we have to add a merge after we read the signals and background depending on the ratio which one set for there mixing.
best regards,
Mohammad
|
|
|
|
GSI Forum
Search
Help
Members
Login
Home
