Simplify parameterized single mu generator

[nburmaso]

Hi @lmassacr,
In this PR are the changes you have suggested.
Cheers,
Nazar

[github-actions]

REQUEST FOR PRODUCTION RELEASES:
To request your PR to be included in production software, please add the corresponding labels called "async-" to your PR. Add the labels directly (if you have the permissions) or add a comment of the form (note that labels are separated by a ",")

+async-label <label1>, <label2>, !<label3> ...

This will add <label1> and <label2> and removes <label3>.

The following labels are available
async-2023-pbpb-apass4
async-2023-pp-apass4
async-2024-pp-apass1
async-2022-pp-apass7
async-2024-pp-cpass0
async-2024-PbPb-apass1
async-2024-ppRef-apass1

[lmassacr]

Hi @nburmaso ,

I comment here as I am not sure you will see the comments otherwise. I am note sure the part related to the pdg is still correct. As you generate two muons per event that could be either positive or negative. I think you should pass a string like this: TString pdgs = "13;-13"; : (see example https://github.com/AliceO2Group/O2DPG/blob/247bd31c3444a1b4e375b314a7763d133e1a58ac/MC/config/PWGDQ/external/generator/GeneratorCocktailPromptCharmoniaToMuonEvtGen_pp13TeV.C)
But I think this is not that simple because this is a random number that is picking the pdg of the muon. So your event can have (+,+) or (-,-) or (+,-) or (-,+) muons, so you don't know a priori the order of the sign of muons.
Ie. the proper string could be TString pdgs = "13;13"; or TString pdgs = "-13;-13"; or TString pdgs = "13;-13"; or TString pdgs = "-13;13"; if I am correct about the logic of the code. You basically have to know what IpMuon has returned, to properly set the pdg code to your muon.
Do you see my point?

[nburmaso]

Hi @nburmaso ,

I comment here as I am not sure you will see the comments otherwise. I am note sure the part related to the pdg is still correct. As you generate two muons per event that could be either positive or negative. I think you should pass a string like this: TString pdgs = "13;-13"; : (see example https://github.com/AliceO2Group/O2DPG/blob/247bd31c3444a1b4e375b314a7763d133e1a58ac/MC/config/PWGDQ/external/generator/GeneratorCocktailPromptCharmoniaToMuonEvtGen_pp13TeV.C) But I think this is not that simple because this is a random number that is picking the pdg of the muon. So your event can have (+,+) or (-,-) or (+,-) or (-,+) muons, so you don't know a priori the order of the sign of muons. Ie. the proper string could be TString pdgs = "13;13"; or TString pdgs = "-13;-13"; or TString pdgs = "13;-13"; or TString pdgs = "-13;13"; if I am correct about the logic of the code. You basically have to know what IpMuon has returned, to properly set the pdg code to your muon. Do you see my point?

Hi @lmassacr,

From what I understand by looking at the GeneratorEvtGen.C code, in particular L109, this string of PDG codes is only used for filtering. The filtering is done by comparison of absolute value (L250). We don't need to perform decays, so I will also remove dependence on o2::eventgen::GeneratorEvtGen

[lmassacr]

Hi @nburmaso,
Indeed, looking at the code in GeneratorEvtGen.C it would probably not hurt if only the absolute value of the pdg of the particle is used.
I couldn't find the equivalent of GenParam.cxx in O2. But According to the AliRoot version of the class : https://github.com/alisw/AliRoot/blob/master/EVGEN/AliGenParam.cxx
with the constructor used, the pdg of the particle should be properly set for each muon in the array of particle (line 647, 654). So I think it is fine.

[nburmaso]

Hi @nburmaso, Indeed, looking at the code in GeneratorEvtGen.C it would probably not hurt if only the absolute value of the pdg of the particle is used. I couldn't find the equivalent of GenParam.cxx in O2. But According to the AliRoot version of the class : https://github.com/alisw/AliRoot/blob/master/EVGEN/AliGenParam.cxx with the constructor used, the pdg of the particle should be properly set for each muon in the array of particle (line 647, 654). So I think it is fine.

Hi @lmassacr,
The O2 equivalent is from the AEGIS repo -- https://github.com/AliceO2Group/AEGIS/blob/v1.5.4/GeneratorParam/GeneratorParam.cxx. The constructor that is used in the generator macro does not require a PDG code. In case if it is set using the other constructor, the PDG code is fixed and not randomized at all -- which we don't need. The actual PDG code is set in GenerateEvent() via fIpParaFunc constructed in our case from IpMuon(TRandom* ran), so I think we can avoid using o2::eventgen::GeneratorEvtGen at all and just do auto* gen = new o2::eventgen::O2_GeneratorParamMuon(); instead of auto gen = new o2::eventgen::GeneratorEvtGen<o2::eventgen::O2_GeneratorParamMuon>();

[nburmaso]

I actually found an error in my local tests causing a segfault. In GeneratorParam.cxx, L251, particle mass is set from random distribution depending on width. For muons for some reason TDatabasePDG returns

root [2] TDatabasePDG::Instance()->GetParticle(13)->Width()
(double) 2.9959840e-19

which leads to Error in <TF1::GetRandom>: Integral of function is zero causing a crash. I will implement a workaround for this generator and let you know, @lmassacr

[nburmaso]

Hi @lmassacr,

I have done some reworking on the generator, so it does not depend on GeneratorParam anymore. I have also added possibility to generate muons with a given charge via SetRandomCharge

Cheers,
Nazar

[lmassacr]

Hi @nburmaso,
Thanks for the work, I went through the code. I think it should work like this.
Two things to check in your test :

• phi definition. I think the reconstructed phi is defined between -Pi and Pi in the AO2D for the muon tracks (please check in some data AO2Ds, at least this is what I see in the QC plots for MCH, phi is plotted between -Pi() and Pi()). I see however in GeneratorParam that phi was also defined in [0;2Pi()] thought. I am not sure if there are some internal transformation of coordinate until the final AO2Ds.
• vertex set to (0,0,0) --> I am not sure this is ok for anchored MC if the ITS vertex is used for instance at the generation (?)
  Cheers,
  Laure

[nburmaso]

Hi @lmassacr,

phi definition

In the MC particles table, phi calculated as dynamic column from px and py so there should be no issues with it. (Also judging by other generators, e.g. GeneratorBoxFwd.C). Edit: just checked AnalysisDataModel.h -- for MC particles, phi is in [0, 2PI].

vertex set to (0,0,0) --> I am not sure this is ok for anchored MC if the ITS vertex is used for instance at the generation (?)

In this case we deal with tracks coming from the primary vertex. At least in my understanding, --vertexMode kCCDB in o2-sim is enough for the correct vertex smearing. I have done some tests (see e.g. /alice/cern.ch/user/n/nburmaso/mch_mc_tune/sim/test2/pbpb/544389/2/001/AO2D.root, the output of simulation with this parameterized generator anchored to 544389) and indeed distributions for the vertex position look healthy -- see attached.

[lmassacr]

Hi @nburmaso,

Thanks for checking. I guess for the phi the variable is then transformed later on, when filling the AO2Ds. It would be interesting to check the reconstructed muon phi distribution. I see indeed that what you have done is what is done in other DQ generators so far.

For the vertex, thanks for checking, I assume the track will be indeed smeared at extrapolation as I assume the reco code will take the reconstructed ITS vertex. So there should be a smearing of the track according to the vertex resolution.

Cheers,
Laure

ps: I am not in the list of DQ reviewers, so I think you should ping Ionut or Luca to review and approve.

[nburmaso]

Hi @iarsene, @lucamicheletti93,
Could you please check this PR?