Much Unpacker in Algo namespace

changed the description

the compilation error on macosx is due to the fact that standard C++ doesn't have variable length arrays. The array size must be known at compile time. That it works with gcc is due to a gcc extension.

@v.singhal @v.friese @p.-a.loizeau

This MR contains a port of the STS Unpacker in the algo namespace to MUCH. The addressing maps were implemented to the best of my knowledge. MuchReadoutConfig was constructed by combining core/detectors/much/CbmMuchUnpackPar with macro/beamtime/mcbm2022/mMuchPar.par. These are both the most recent versions of MUCH parameter files that I could find.

There are many similarities with the STS unpacker. The entire logic pertaining to the treatment of time stamps is exactly the same. The main difference between the classes UnpackSts and UnpackMuch is the way digi addresses are assigned in the processHitInfo() function.

The address assignment is simpler for MUCH at the unpacker level, because MUCH addresses are stored channel-wise in the UnpackMuchElinkPar objects (for STS a module address and an Asic number is stored instead, and additional logic has to be applied to infer the "channel in module"). The MuchReadoutConfig class in turn is more complex than StsReadoutConfig, because it carries out the address computation.

For this purpose, the CreateMuchAddress() function of the old CbmMuchUnpackAlgo class was copied over to MuchReadoutConfig.

There are some aspects of the address mapping that I don't fully understand. Here is an excerpt from CbmMuchUnpackAlgo::processHitInfo():

  const uint16_t usElinkIdx = mess.GetLinkIndexHitBinning();
  uint32_t asicidx = fUnpackPar->ElinkIdxToFebIdx(usElinkIdx);
  uint32_t uAsicIdx = fuCurrDpbIdx * fUnpackPar->GetNbFebsPerDpb() + asicidx;
  int32_t uFebIdx = fUnpackPar->GetFebId(uAsicIdx);
  const uint16_t usChan     = mess.GetHitChannel();
  const uint16_t usRawAdc   = mess.GetHitAdc();
  const uint16_t usRawTs    = mess.GetHitTimeBinning();
  const uint32_t uChanInFeb = usChan + fNrChsPerAsic * (uAsicIdx % fNrAsicsPerFeb);
  ....
  const uint32_t address = CreateMuchAddress(fuCurrDpbIdx, uFebIdx, uChanInFeb);
  ....
  fOptOutAVec->emplace_back(CbmMuchDigi(address, usRawAdc, ulTimeInNs));

The variable name "uChanInFeb" is probably a misnomer, which originated from the copying of STS code. If uAsicIdx contains a global Asic index, then the expression (uAsicIdx % fNrAsicsPerFeb) should give a global Feb index. Then uChanInFeb is a global channel index? One should also note that fNrAsicsPerFeb = 1 in any case, and this is implicitly assumed in the lines above.

I translated this to:

 for (uint16_t comp = 0; comp < numComp; comp++) {
      uint16_t equipment = eqId[comp];
      fReadoutMap[equipment].resize(numElinksPerComp);
      for (uint16_t crob = 0; crob < numCrobPerComp; crob++) {
        for (uint16_t elink = 0; elink < numElinksPerCrob; elink++) {

          fReadoutMap[equipment][elink].resize(numChanPerAsic);
          uint16_t elinkId   = numElinksPerCrob * crob + elink;    // elink within component
          uint32_t febInCrob = elink2Feb[elinkId];                 // FEB within CROB
          uint32_t feb       = comp * numFebsPerComp + febInCrob;  // global FEB index
          int32_t febId      = GetFebId(feb);                      // FEB Id in MUCH addressing scheme

          for (uint16_t chanInAsic = 0; chanInAsic < numChanPerAsic; chanInAsic++) {
            uint32_t channel                       = chanInAsic + numChanPerAsic * (feb % numAsicsPerFeb);  //Fix this!
            fReadoutMap[equipment][elink][channel] = CreateMuchAddress(comp, febId, channel);
          } 
        }   
      }     
    }        
  }

I think this reproduces the old code, but can probably be cleaned up further.

I copied the 2022 "channel to pad" maps over by hand. We will need a way to automate this at some point.

What I would need now, is some data to test this new unpacker on. Since this is for the 2022 setup, I probably cannot use the .tsa files that I have.

@p.-a.loizeau Can you point me to a place where I can get such a file?

Also, to all others (mainly @v.singhal): I would appreciate any help in testing this new class.

added 1 commit

2d55edd0 - Integrated 2022 MUCH parameters into MuchReadoutConfig.

Compare with previous version

resolved all threads

@j.decuveland Could you take a look at CbmTaskUnpack.cxx please? I am not so familiar with the parallelization pragmas. I think I generalized correctly, but I'm not 100 percent sure.

added 1 commit

a99f4f94 - Unpack Much: Applied Epoch cycle fix. Fixed MacOS compilation (variable-sized array).

Compare with previous version

Dear @f.uhlig, @v.friese, @p.-a.loizeau,

you have been identified as code owner of at least one file which was changed with this merge request.

Please check the changes and approve them or request changes.

added CodeOwners label

added 1 commit

15149289 - Unpack Much: Applied Epoch cycle fix. Fixed MacOS compilation (variable-sized...

Compare with previous version

Dear @d.smith,

Apology for delayed reply as I was busy with my PhD thesis defense. A general query that what is the motivation and aim for generating new classes replacing earlier classes? (If you have presented or have any document kindly provide the same.)

1: in MuchReadoutConfig you have merged CbmMuchUnpackPar and mMuchPar.par, but whenever one changes any hardware configuration, the CbmRoot needs to be make again, as class will be modified. Earlier we used to modify mMuchPar.par without make.

2: There are different mMuchPar.par files according to run configuration, now how will we deal this?

3: We have not removed the variable fNrAsicsPerFeb , as in future MUCH FEE (version) will also comprise 2 SMX chip on one FEB, though, only 64 channels of one SMX will be used.

4: There are slight changes in the latest mMuchPar.par (total 7 CROBs and RPC FEB numbering is different) and correspondingly needs to change the numComp = 7 in CbmMuchUnpackPar.h

5: You may test with older runs (Not with latest GOLD 19-20 June data), I will generate a MR with above changes for GOLD runs.

Thanks and regards, Vikas

@p.-a.loizeau Perhaps you know what is going on here:

I am currently trying to compare the output of the old and the new unpackers using the input file 2391_node8_0_0008.tsa. It seems I am approaching correctness, but there still is a small discrepancy. On the first timeslice of the file, I get the following for the old version:

[INFO] Unpack: TS index 5496 components 26
[INFO] CbmRecoUnpack: Component 10, microslices 101, digis 3134171
[INFO] CbmRecoUnpack: Component 11, microslices 101, digis 824691
[INFO] CbmRecoUnpack: Component 12, microslices 101, digis 0

For the new version I get:

[INFO] SourceTs: Reading time slice 0 (index 5496) 
[INFO] Unpack: Component 10, microslices 101 , digis 3158659
[INFO] Unpack: Component 11, microslices 101 , digis 852013
[INFO] Unpack: Component 12, microslices 101 , digis 23684

So in each case, the new version finds around 20k more digis.

I suspected that these are pulser digis, so I filter them by discarding all digis with "febId = -7". This doesn't seem to help. I also disabled channel masking and duplicate hit rejection.

Is there an obvious answer here?

Edit: It might have to do with "not connected FEBs". I'm checking that now.

Throwing out the febId = -1 digis ("not connected") does seem to help some, but doesn't solve it entirely:

[INFO] Unpack: Component 10, microslices 101 input size 13020088 bytes, , digis 3158217, CPU time 400 ms
[INFO] Unpack: Component 11, microslices 101 input size 3908264 bytes, , digis 833548, CPU time 300 ms
[INFO] Unpack: Component 12, microslices 101 input size 323136 bytes, , digis 0, CPU time 40 ms

@p.-a.loizeau My latest insight here, is that the additional digis are found at the very end of the digi vector. I.e. the new version finds a few more digis at very late times for each component. Everything else seems to match, except the last digit of the time stamp, probably due to rounding.

I'm still investigating.

marked this merge request as ready

resolved all threads

Ready for merge.

@v.singhal @p.-a.loizeau @v.friese I just compared the run times of the old and the new version. They are almost the same. One possible explanation is that the reading of the data from the tsa file is the bottleneck and not the actual unpacker logic.

added 1 commit

f7875af1 - CbmTaskUnpack(): Added data format assert() statement for MUCH.

Compare with previous version

Much Unpacker in Algo namespace

Merge request reports

Activity