FairMCEventHeader [message #13227] |
Fri, 16 March 2012 17:06 |
Volker Friese
Messages: 365 Registered: April 2004 Location: GSI CBM
|
first-grade participant |
From: *gsi.de
|
|
Hi,
from CBM, we would need to store the event plane angle (from the generator) as MC event variable. The proper place seems to be FairMCEventHeader. Is it possible to add a corresponding member to this class, with proper accessor and modifier?
More strategically thinking, it may happen again in the future that a particular application wants to store additional info in the MC event header (e.g., settings of the event generator). What would you propose as solution for this? I understand that FairMCEventHeader is used by the framework, e.g. for the run number and maybe other things. Of course, we can implement an additional class and branch in the tree, but then would have to change all generator classes to fill that one.
What do you think is the best solution? Some inheritance scheme?
|
|
|
Re: FairMCEventHeader [message #13231 is a reply to message #13227] |
Sun, 18 March 2012 20:01 |
Florian Uhlig
Messages: 424 Registered: May 2007
|
first-grade participant |
From: *pools.arcor-ip.net
|
|
Hi Volker,
Quote: |
from CBM, we would need to store the event plane angle (from the generator) as MC event variable. The proper place seems to be FairMCEventHeader. Is it possible to add a corresponding member to this class, with proper accessor and modifier?
|
in principle it would be possible to add the new data members, but I think it is not a good idea, as you already pointed out in your last posting about the FairMCPoint [message #13149].
Quote: |
More strategically thinking, it may happen again in the future that a particular application wants to store additional info in the MC event header (e.g., settings of the event generator). What would you propose as solution for this? I understand that FairMCEventHeader is used by the framework, e.g. for the run number and maybe other things. Of course, we can implement an additional class and branch in the tree, but then would have to change all generator classes to fill that one.
What do you think is the best solution? Some inheritance scheme?
|
Such as scheme is already implemented since more than a year. For CBM there is a CbmMCEvent and CbmMCEventHeader which can be used instead of the FairMCEvent or FairMCEventHeader. Both classes inherit from the base classes and add new data members. The CbmMCEventHeader for example add an additional data member for the reaction plane angle. To use the CbmMCEventHeader one has to add the following lines in the simulation macro
// Use the experiment specific MC Event header instead of the default one
// This one stores additional information about the reaction plane
CbmMCEventHeader* mcHeader = new CbmMCEventHeader();
fRun->SetMCEventHeader(mcHeader);
To have an example I changed the run_sim.C macro in CbmRoot. This macro now calculates an event by event reaction plane and stores the information in the CbmMCEventHeader for later usage.
Hope this info answers your question.
Ciao
Florian
|
|
|
Nice [message #13243 is a reply to message #13231] |
Thu, 22 March 2012 10:39 |
Volker Friese
Messages: 365 Registered: April 2004 Location: GSI CBM
|
first-grade participant |
From: *zdv.uni-mainz.de
|
|
Quote: | Such as scheme is already implemented since more than a year. For CBM there is a CbmMCEvent and CbmMCEventHeader which can be used instead of the FairMCEvent or FairMCEventHeader. Both classes inherit from the base classes and add new data members. The CbmMCEventHeader for example add an additional data member for the reaction plane angle. To use the CbmMCEventHeader one has to add the following lines in the simulation macro
|
Nice feature. I know that we discussed it some times ago, but was not aware that is has been implemented. Must be the age.
By the way: What happens if you do not specify the usage of CbmMCEventHeader in the macro? I suppose the CbmUrqmdGenerator crashes when doing the dynamic cast.
|
|
|