Project

General

Profile

Actions

Sim-Development #1806

open

CbmMCTrack::GetMass() returns 0 for ions

Added by Viktor Klochkov almost 2 years ago. Updated almost 2 years ago.

Status:
In Progress
Priority:
Normal
Target version:
-
Start date:
09/11/2020
Due date:
09/16/2020 (about 23 months late)
% Done:

100%

Estimated time:
4.00 h
Spent time:

Description

Dear Volker

There are no ions in TDatabasePDG, so for all fragments return value will be 0.

I'm not sure what will be the best solution here, but maybe we can at least return A*u (u~0.9315). That should be enough for most of the cases (calculating rapidity the only real case I can think of).

Cheers,
Viktor

Actions #1

Updated by Volker Friese almost 2 years ago

  • Status changed from New to Assigned

Hm, not so easy. During transport, we add ions (FairIon) to the TDatabasePDG, but this is only transient during the run.

A possible solution would be to add this info to CbmMCTrack during transport, i.e. to extend this class by additional members. I'll discuss with Florian and Mohammad's group.

It also may be that the PDG code itself gives info on Z and A of the ion. Then, one could derive the mass from A as you suggested.

Actions #2

Updated by Viktor Klochkov almost 2 years ago

Yes, one can derive mass number from PDG code:

Nuclear codes are given as 10-digit numbers ±10LZZZAAAI
L - strangeness,
ZZZ - charge,
AAA - mass,
I - isomer level (0 for ground level)

https://pdg.lbl.gov/2006/reviews/pdf-files/montecarlo-web.pdf

Actions #3

Updated by Volker Friese almost 2 years ago

  • Tracker changed from Bug to Sim-Development
  • Project changed from CbmRoot to Simulation
  • Due date set to 09/16/2020
  • Status changed from Assigned to In Progress
  • Estimated time set to 4.00 h

Yes, that's true at least with TGeant3. I could not check with TGeant4, since I do not have and cannot easily find the source file.

Then it's easy, of course. I will take care.

Actions #4

Updated by Volker Friese almost 2 years ago

  • Assignee changed from Volker Friese to Viktor Klochkov
  • % Done changed from 0 to 50

I implemented that. In doing so, I noticed that CbmMCTrack::GetMass() returns 0 if the pdg code is not found in TDatabasePDG, without throwing any error. But 0 is a valid mass, so that does not appear a good choice. I thus introduced a LOG if the particle is not found (after catching the ion case with pdgCode > 100000000). But then I get an error in run_analysis_tree_maker.C:

[FATAL] CbmMCTrack: Unknown PDG code 50000050

Any idea how this odd PDG code comes about? I vaguely recall "private" PDG codes being defined in KFParticleFinder.

Actions #5

Updated by Oleg Golosov almost 2 years ago

These are Cherenkov photons.
They must be coming from Geant4 or VMC.

Actions #6

Updated by Viktor Klochkov almost 2 years ago

Yes, and during last PWG-COM meeting we disscussed that we probably don't need to store them into AnalysisTree. But I don't know how many more particles produced by GEANT which are not in TDatabasePDG.

Cheers,
Viktor

Actions #7

Updated by Volker Friese almost 2 years ago

I could return -1. for mass if the particle code is not found, leaving it to the user to catch this non-physical value. For the charge, however, this obviously does not work.

Actions #8

Updated by Viktor Klochkov almost 2 years ago

Maybe we could throw an exeption, std::runtime_error, for example? I've noticed that we don't do that in CBMROOT, is there a reason for that?

Actions #9

Updated by Volker Friese almost 2 years ago

Viktor Klochkov wrote:

Maybe we could throw an exeption, std::runtime_error, for example? I've noticed that we don't do that in CBMROOT, is there a reason for that?

Our current scheme is to use FairLogger for "exception handling".

Actions #10

Updated by Volker Friese almost 2 years ago

  • % Done changed from 50 to 100

I caught also the case of Cherenkov photons (PDG 50000050) in CbmMCTrack::GetMass() and GetCharge(). After that, all tests run through, meanung that at least in the tests, no other non-database PDGs occur.

Is in MR87.

Actions #11

Updated by Viktor Klochkov almost 2 years ago

Volker Friese wrote:

Viktor Klochkov wrote:

Maybe we could throw an exeption, std::runtime_error, for example? I've noticed that we don't do that in CBMROOT, is there a reason for that?

Our current scheme is to use FairLogger for "exception handling".

Ok, for me it's slightly different thing. I don't see how we can "catch" a warning with this scheme in a code. One will see this in console output, but I don't know how carefully log files are usually checked.

Actions #12

Updated by Florian Uhlig almost 2 years ago

This is very easy. It is one of the last line in the output after you execution was terminated. LOG means that there was an unrecoverable error and the execution is stopped after the log message.

Actions

Also available in: Atom PDF