Storing MCtracks which produced a hit

[ThomasRuf]

In run_simSND exists the option MCTracksWithHitsOnly. It should store the MCTrack history of any particle producing a hit. This is not working, because of

shipdata/ShipStack.cxx line 250, loop to associate points to track for (Int_t iDet=kVETO; iDet<kEndOfList; iDet++) { and line 12 shipdata/shipDetectorList.h enum DetectorId {kEmulsionDet,kLHCScifi,kMuFilter, kVETO, ...

with the result that no points in a SND@LHC detector is associate to a MCTrack.

There are two ways to fix this: 1) move kVETO to the start of the enum (I tested it and works 2) or modfiy the loops (two loops!) in ShipStack.cxx

[siilieva]

Where else does one use this enum DetectorId? Changing the enumerator order might affect other code.

[ThomasRuf]

the header file is included in all detector classes, plus Floor.cxx, where it is used in the constructor, example: Scifi::Scifi(const char name, Bool_t Active, const char Title) : FairDetector(name, true, kLHCScifi),

changing the enum might make old geofiles not matching anymore with the code? Maybe changing the two loops to start from kEmulsionDet is more save.

[siilieva]

I agree, changing the loops will be safer. Then, I am confused with the comment // kSTOPHERE is needed for iteration over the enum. All detectors have to be put before. here since there is no such entry in the DetectorId enum. Is that an outdated piece of advice?

[ThomasRuf]

probably, kSTOPHERE only exists inside sndsw in the comment. In FairRoot, they are using FairStack.cxx: for (Int_t iDet = kREF; iDet < kSTOPHERE; iDet++) {
and defined it in the detector list: MyProjData/MyProjDetectorList.h: kSTOPHERE

[ThomasRuf]

in sndsw, kEndOfList is used instead of kSTOPHERE

[olantwin]

in sndsw, kEndOfList is used instead of kSTOPHERE

The important thing is that the same enum type is used in the loop as in the enum. What we call it doesn't matter.

We can probably just iterate from kEmulsionDet (inclusive) to kVETO (exclusive), right?

Not overly enthusiastic about iterating over enums (especially because we rely on a specific ordering), but we don't have to fix FairRoot's design decisions here right now.

[olantwin]

Moving enum values around could have strange consequences, as these are not typed enums, so could be implicitly converted to ints, ROOT kColors, converted to (u?)ints for storage etc. What happens when reading old geometry files is not something I'd want to predict...

[siilieva]

I believe we all agree to 1. change the 2 loops in ShipStack.cxx 2. remove the outdated comment about kSTOPHERE

We can probably just iterate from kEmulsionDet (inclusive) to kVETO (exclusive), right?

Why not on all members in the DetectorList - this way the code will work out of the box for AdvSND or in any case we add a detector?

[olantwin]

Why not on all members in the DetectorList - this way the code will work out of the box for AdvSND or in any case we add a detector?

Sure, why not!