Project

General

Profile

Actions

Bug #1278

closed

CbmUnigenGenerator: zero event plane

Added by Oleg Golosov about 3 years ago. Updated over 2 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Oleg Golosov
Target version:
Start date:
05/05/2019
Due date:
08/26/2019
% Done:

100%

Estimated time:
10.00 h
Spent time:

Description

In case you run transport simulation without random event plane generation event plane angle is always set to zero, even if it is non-zero in the model file.

Actions #1

Updated by Volker Friese about 3 years ago

  • Due date set to 05/31/2019
  • Status changed from New to Feedback
  • Assignee changed from Volker Friese to Oleg Golosov
  • Target version changed from APR19 to OCT19
  • Estimated time set to 10.00 h

Right.

We have to discuss how we handle things in this respect. UEvent has a member phi, which may be filled by the concrete event generator. In addition, the event can be rotated randomly by FairPrimaryGenerator. If the latter is the case, only the angle of the last rotation is stored in the event header.

Possible solution: If event rotation is activated, rotate the event and add the rotation angle to the one taken from the Unigen input file. Would that be correct in your opinion?

Actions #2

Updated by Oleg Golosov about 3 years ago

this solution sounds absolutely reasonable to me

Actions #3

Updated by Oleg Golosov about 3 years ago

  • Assignee changed from Oleg Golosov to Volker Friese
Actions #4

Updated by Volker Friese almost 3 years ago

  • Due date changed from 05/31/2019 to 08/26/2019
  • Assignee changed from Volker Friese to Oleg Golosov

Unfortunetaly, things are not so easy.

First, to get clear: if there is the variable UEvent.phi non-zero in the input file (from Unigen), it means that the event (the momentum vectors) are already rotated. They do not have to be rotated in CbmRoot (unless random event plane rotation is activated there. Is that correct?

Second: There may be different inputs (all from Unigen, or mixed with other types). In case they come with different event plane angles: which value should be stored in the MC event header?

By the way, which model type do you refer to? Neither UrQMD nor HSD set an event plane.

Actions #5

Updated by Oleg Golosov almost 3 years ago

The first is correct. This is the temporary solution I have been using in my private build of CbmRoot.
There is a bit safer (to my understanding) option though. There are two variables in URun: fPhiMin and fPhiMax that could be used for that purpose. Both of them are equal to zero in UrQMD output. In the DCM-QGSM model (answer for the third question) we set them to 0 and 2*Pi accordingly. So comparing these two variables could give you the answer.

As for the second question, I think the best decision would be to rotate all the inputs to a unified reaction plane angle if it is possible with FairRoot.

Actions #6

Updated by Oleg Golosov almost 3 years ago

  • Assignee changed from Oleg Golosov to Volker Friese
Actions #7

Updated by Volker Friese almost 3 years ago

  • Assignee changed from Volker Friese to Oleg Golosov
  • % Done changed from 0 to 50

When looking for a resilient solution, we should distinguish the generator level from the transport stage.

In the transport, the following modifications to the input tracks are performed globally (i.e., on all generator inputs) by FairPrimaryGenerator:

- shift the start point of the tracks to the common event vertex
- rotate the momenta according to the beam angle (around the x and y axes)
- rotate the momenta according to the event plane angle (around the z axis)

The vertex, the beam angle and the event plane angle are generated during transport, in FairPrimaryGenerator (now for us in CbmEventGenerator). They are not connected to any information found in any generator input. The corresponding information is stored in the event header (type FairMCEventHeader).

To be distinguished from that is the event information contained in the generator input, which tells something on how the event was generated inside the generator engine (e.g., UrQMD). Typical information here is the impact parameter. This information may vary from generator to generator: for instance, UrQMD does not generate a reaction plane angle, while SHIELD does. Other generators (e.g., the simple ones) do not have such information at all.

Up to now, we import the impact parameter to the MCEvent header. This is done in the CbmUnigenGenerator or CbmUrqmdGenerator. Other information from the generator level is lost.

The cleanest approach would be to define an generator-dependent event header, which is attached to the main event header. e.g., one could copy UEvent to the output. We would have to use a CBM-specific MC event header deriving from FairMCEventHeader, which is possible. Or they can be put in a different branch.

For the time being, I recommend not to rotate the event at the generator level, but do this at transport stage.

Actions #8

Updated by Oleg Golosov almost 3 years ago

We discussed the issue once more and concluded that indeed the easiest way would be to rotate the event to zero on the generator level for all the generators. After that common random rotation angle could be introduced at FairPrimaryGenerator level.

Actions #9

Updated by Oleg Golosov almost 3 years ago

  • Assignee changed from Oleg Golosov to Volker Friese
Actions #10

Updated by Volker Friese almost 3 years ago

After the discussion in the CBM Software Meeting of 5 September 2019 and some contemplemptation on my side, decision is:

  • Event plane rotation in FairPrimaryGenerator is de-activated for CBM (in CbmEventGenerator).
  • The possibility for a random event plane rotation is implemented in CbmUnigenGenerator.
  • In case of the use of CbmUnigenGenerator, FairMCEventHeader::fRotZ is set to the sum of UEvent->GetPhi() and the random angle generated in CbmUnigenGenerator.
  • Re-use of events in CbmUnigenGenerator (if more events are requested than present in the tree) is acivated if
    • the constructor was called with a respective flag, which is by default false;
    • random event plane rotation is activated.
Actions #11

Updated by Ilya Selyuzhenkov almost 3 years ago

Dear Volker, All,

1.
from your list of proposed changes I do not see how to realize a rotation of two (or more) events from different event generators (and different planes) to the common event plane angle, which was generated randomly.

Can you please clarify what would be the steps needed to achieve this?

2. I propose to create a separate ticket where the need and option to re-use the same Monte-Carlo events is discussed. I think this is a dangerous operation if somebody is doing a correlation analysis.

Can you please remind the reasons / examples when reusing events is a useful option?

Thank you.

Best regards,
Ilya

Actions #12

Updated by Volker Friese almost 3 years ago

1.
from your list of proposed changes I do not see how to realize a rotation of two (or more) events from different event generators (and different planes) to the common event plane angle, which was generated randomly.

Can you please clarify what would be the steps needed to achieve this?

This is indeed a feature not covered by the scheme above. In yesterday's discussion, the actual use case for that within CBM was considered not present. Actually, the opinion was rather that combining different generator inputs to the transport simulation is not needed at all (since MC events can be merged at digitisation level) and rather causes confusion, e.g. in the MCEventHeader.

Please inform if the feature is actually needed for CBM.

2. I propose to create a separate ticket where the need and option to re-use the same Monte-Carlo events is discussed. I think this is a dangerous operation if somebody is doing a correlation analysis.

Can you please remind the reasons / examples when reusing events is a useful option?

This feature allows to generate large transport statistics with a limited number of input events. The request was brought forward by N. Herrmann. It is obvious that this makes sense only when the input is considered as background and not for studying physics.

I should say that features 1. and 2. are hardly to be accommodated together in one class, unless the API will get rather obscure.

Actions #13

Updated by Volker Friese almost 3 years ago

  • Assignee changed from Volker Friese to Oleg Golosov
  • % Done changed from 50 to 100

I have committed a version of CbmUnigenGenerator which fixed the original issues and (hopefully) addresses all mentioned use cases. All current functionality is maintained.

The class can be instantiated with the following modes (second argument to the constructor):

  • CbmUnigenGenerator::kStandard (default): No rotation, no re-use, only Lorentz transformation into the lab system is applied.
  • CbmUnigenGenerator::kRotateRandom: Events are rotated by a random angle
  • CbmUnigenGenerator::kRotateFixed: All events are rotated by the same, fixed angle
  • CbmUnigenGenerator::kRotateToZero: Events are rotated back to zero angle, according to the angle found in the UEvent header, which was applied at generator level.
  • CbmUnigenGenerator::kReuseEvents: When more events are requested than present in the input tree, the events are reused - the tree is read around the corner. Random event plane rotation is applied.

Two angles phiMin and phiMax can be specified in the constructor, too. By default, they are 0 and 2pi. They specify the angular range in which the event plane angle is sampled (has effect only for kRotateRandom and kReuseEvents). In case of kRotateFixed, phiMin is used as fixed rotation angle.

Additional random rotation can be applied at the PrimaryGenerator level (CbmEventGenerator), on the responsibility of the user. It would make sense only if CbmUnigenGenerator is used together with another input generator.

The Unigen event ID (from UEvent) is forwarded to the MCEventHeader, also in the case of re-used events.

The event plane angle in the MCEventHeader (fRotZ) is set to the sum of the value found in UEvent, the angle applied in CbmUnigenGenerator, and the angle applied in CbmEventGenerator.

Please test this and report whether the features are ok for your use cases. If yes, I would like to port this back to RC OCT19.

This does not solve the principle issue that there is only one MCEventHeader. If several inputs to the transport are used, only the first can set this event header. Also, by now it is a matter of convention which members of the event header are set by the concrete generator and which by the EventGenerator. By now, the "work share" is
  • Generator sets event Id, impact parameter and event plane angle;
  • CbmEventGenerator sets event ID (if not set before), number of primaries, vertex, beam angle (fRotX and fRotY) and adds its event plane angle (if rotation is applied) to the one already present (fRotZ).
Not an optimal solution in my view. A better solution (for the future) would be
  • If we decide to restrict ourselves to just one input to the transport, the software can be simplified: no distinction between EventGenerator and generator; the latter can derive from the former instead of being registered to it.
  • If we decide to maintain the possibility of several inputs to transport, there should be several MCEventHeaders, one for each input, such that the entire information can be forwarded.
Actions #14

Updated by Volker Friese almost 3 years ago

  • Status changed from Feedback to Resolved

Slight changes as agreed in the Software Meeting of 12 September:

  • Mode kRotateRandom was removed.
  • Mode kRotateToZero is now kStandard and thus default; kStandard is renamed to kNoRotation.

These changes were implemented in trunk with r14995. The revision of the class was backported to OCT19 with r14996.

Actions #15

Updated by Oleg Golosov almost 3 years ago

Dear Volker,

could you, please, add random rotation to the default transport macro so that the user will not by chance run simulations with zero event plane.

Thank you!

Actions #16

Updated by Volker Friese over 2 years ago

I included this into run_transport.C in r15110 (trunk) and r15111 (OCT19).

I did not make this default in the CbmTransport class since I think that for many input sources other than full events, it may be unwanted behaviour, so the user should have to set it explicitly.

Please close the issue if you think appropriate.

Actions #17

Updated by Oleg Golosov over 2 years ago

  • Status changed from Resolved to Closed

Thank you, this is exactly what I meant.

Actions

Also available in: Atom PDF