Why does R3BMCTrack not derived from FairMCTrack?

[YanzhaoW]

Recently I need the visualisation from the simulated tracks. In the R3B, we push the tracks to R3BStack, which is fine since there is no FairStack in its standard libraries. But we also have this R3BMCStack which is directly derived from TObject:

R3BRoot/r3bdata/R3BMCTrack.h

Lines 25 to 31 in de1bd47

	class R3BMCTrack : public TObject
	{
	public:
	/** Default constructor **/
	R3BMCTrack();

And there is also FairMCTrack in FairRoot, which has almost the same member functions and variables. The only difference is the detector lists (enum) used in R3BMCTrack is different than in FairMCTrack. And surprisingly unfortunately, the two detector lists have exactly the same name (DetectorId), which makes include "FairMCTrack" in R3BMCTrack.h not even possible. If someone knows the logic behind, please tell me.

So my proposal is whether we can make R3BMCTrack inherited from FairMCTrack and delete all those duplicated codes. And of course before this, we need to change enum name DetectorId to something else.

The advantage of this change is: if R3BMCTrack is inherited from FairMCTrack, we could also use FairMCTracksDraw in the event display.

[jose-luis-rs]

That class is 8 years old(or more!), so you could update it if you wish. Thanks in advance!

[klenze]

Trigger warning: R3BMCStack contains methods which take 19 parameters.

Have you tried:

#include "R3BDetectorList.h"
#define FAIRDETECTORLIST_H
#include <FairMCTrack.h>

This is of course a hack.

Also, if we want to attach detector Ids to the tracks in a persistent way, the enum (why are there two?) should have explicit values.

(Also, from grepping for kMUSIC and kCALIFA, these tags are write-only? Is all of this just for visualization?)

[YanzhaoW]

No, but it's a solution in a very desperate time ;D
IMO the enum is used to specify the number of tracks in a certain detector. In FairRoot, there are only six detector types:

enum DetectorId
{
    kREF,
    kFairRutherford,
    kTutDet,
    kSTOPHERE,
    kTutProp,
    kPixel
};

And in the R3BRoot, there are tons. I don't know which on comes first and for which reason they think six types of detector are enough for all cases.( giving that enum is hardly extensible in C++.)

The purpose of DetectorId in the FairMCTrack (not virtual function!) is also confusing:

Int_t FairMCTrack::GetNPoints(DetectorId detId) const
{
    // TODO: Where does this come from
    if (detId == kREF) {
        return (fNPoints & 1);
    } else if (detId == kTutDet) {
        return ((fNPoints & (7 << 1)) >> 1);
    } else if (detId == kFairRutherford) {
        return ((fNPoints & (31 << 4)) >> 4);
    } else {
        LOG(error) << "Unknown detector ID " << detId;
        return 0;
    }
}

while this function is totally different in R3BMCTrack.