Project

General

Profile

Actions

Development #12

closed

generation of the reaction plane angle

Added by Selim Seddiki over 8 years ago. Updated over 6 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
Start date:
09/10/2015
Due date:
11/14/2015
% Done:

100%

Estimated time:
10.00 h
Spent time:

Description

Dear all,

I just want to ask for a few changes in the software concerning the generation of the reaction plane angle:

1) Now it is done in cbmgenerators/CbmUrqmdGenerator* & CbmUnigenGenerator*. I think this should be done in base/FairPrimaryGenerator* such that the event plane angle is defined in the same way (unit and range) whatever generator is used. This would off course imply that no event plane should be set at generation level (ex. phi_RP = 0 from UrQMD).

2) In the simulation software used my Marina and I, the event plane angle is defined in [-pi, pi]. This is the most natural choice since the function TMath::ATan2(), often used all over the code (including the rotation of particle momenta according to phi_RP in cbmgenerators/CbmUrqmdGenerator* & CbmUnigenGenerator*), gives an output in this unit and range. But in cbmgenerators/CbmUrqmdGenerator* & CbmUnigenGenerator*, unit and range are let to the user choice, which could be a source of errors. Maybe a message should be drawn to inform the user of the proper unit and range (at least the 'unit' in radian) for the event plane angle, whether he wants to use the event plane analysis later or not.

3) Also, without transition, it would be nice to include the SHIELD generator into the UniGen generator.

With my best regards, Selim


Related issues

Precedes CbmRoot - Development #366: Revise CbmMCEventHeaderClosedVolker Friese11/15/201511/16/2015

Actions
Actions #1

Updated by Volker Friese about 7 years ago

  • Tracker changed from Feature to Development
  • Due date set to 10/31/2015
  • Status changed from New to Scheduled
  • Assignee set to Volker Friese
  • Target version set to NOV15
  • Start date changed from 11/13/2013 to 10/01/2015
  • Estimated time set to 10.00 h
Actions #2

Updated by Volker Friese about 7 years ago

  • Due date changed from 10/31/2015 to 09/20/2015
  • Start date changed from 10/01/2015 to 09/10/2015
Actions #3

Updated by Volker Friese almost 7 years ago

  • Status changed from Scheduled to In Progress

To the requests:

  1. The event plane (as well as the impact parameter) are not considered on the FairRoot level; these are variables quite specific to heavy-ion reactions and thus to CBM. So, an implementation in FairPrimaryGenerator is possibly not desired. A solution could be to have a CbmPrimaryGenerator deriving from FairPrimaryGenerator, in which we could implement such CBM-specific functionality. I will have a look inhowfar that is possible.
  2. This addresses our system of units. We agreed to use cm for length, GeV for energy, mass and momentum, s for time. There is no regulation yet for angles. I think a convention that all angles have to be specified in radians would make sense. I will bring this to discussion in one of the next software meetings.
  3. I understand you want a converter from Shield format to unigen format, correct? I will have to find a person taking over this task.
Actions #4

Updated by Volker Friese almost 7 years ago

  • % Done changed from 0 to 50

To item 1:

I have to correct. The event plane functionality is meanwhile implemented in FairPrimary Generator, in the same way as we have it in CbmUrqmdGenerator. So, you can specify a range [phi1, phi2], out of which an event plane angle is (uniformly) sampled, and all input track momenta are rotated by this angle. The angle used for each event is available through in FairMCEventHeader::GetRotZ().

I notice that all variables we had implemented in CbmMCEventHeader are now also available in FairMCEventHeader. If that is true, we should use the Fair class.

I have created a new issue (#366) in this respect.

Actions #5

Updated by Volker Friese almost 7 years ago

To item 2:

I propose to add to our convention that angles must be specified in radians.

Which range is the proper one (0 to 2pi or -pi to pi) seems to depend on the specific problem. I, at the moment, do not see a possible error source here. Whether you rotate by 3/2pi or -1/2pi gives the same result.

Actions #6

Updated by Volker Friese almost 7 years ago

To item 3:

I think it is not a big deal to make a shield2u converter, taking CbmShieldGenerator as a basis. What I do not like is not to have any documentation about SHIELD in general and the shield output file format in particular. Does this exist?

Actions #7

Updated by Volker Friese over 6 years ago

  • Due date changed from 09/20/2015 to 11/14/2015
  • Status changed from In Progress to Closed
  • % Done changed from 50 to 100

Items 1 and are accounted for (see #366). A shield2u converter, strictly spoken, falls outside of cbmroot since it would be a Unigen issue. I will see to that, but close this issue for now.

Actions

Also available in: Atom PDF