Make TimeWinEventBuilder Algo more generic and compatible with simulated data

added 3 commits

507214c3 - 1 commit from branch computing:master
e9a63480 - Add interface to override the TS params with user values in TimeWinEvtBuild
aa64b357 - In TimeWinEvtBuilder, add flag to switch to CbmMuchDigi (instead of CbmMuchBeamtimeDigi)

Compare with previous version

added 1 commit

c09fb7c9 - Apply formatting

Compare with previous version

added 1 commit

8e3f8699 - Apply formatting

Compare with previous version

added 11 commits

8e3f8699...7a049115 - 7 commits from branch computing:master
2697b52b - Add interface to override the TS params with user values in TimeWinEvtBuild
759d7a1f - In TimeWinEvtBuilder, add flag to switch to CbmMuchDigi (instead of CbmMuchBeamtimeDigi)
e11aa06a - Apply formatting
9d6608b9 - Apply formatting

Compare with previous version

@p.-a.loizeau I just cloned this merge request and will start testing it.

Hi Pierre, Dominik, just the quick question, why you want to disable the TsMetaData array? I think to separate it from the Algo it should simply be possible to pass it to it from the task, shouldn't it? And I think it would be good for future developments to keep this far more flexible approach, instead of hardcoded values from the macro.

On a related note, @p.-a.loizeau @v.friese @f.uhlig @se.gorbunov , I am still a little bit confused about the terminology concerning "time-based" vs. "event-based".

The way I understand, if I run a simulation then I get "point" (i.e. "MuchPoint") and "MCTrack" objects in the output file. The point objects represent particles traversing a detector cell and carry a time-stamp, which is relative to the collision time, which is set to zero in MC.

The digitizer now can do one of two things:

Either it is run in "event-based" mode, in case of which each time-slice contains digis from exactly one collision and the variables "time-slice length" and "event rate" are set to -1 (no global information is stored). The digis will still contain time-stamps, but these will be relative to the collision time.

Or, the digitizer is run in "time-based" mode. In this case, the event rate and time-slice length need to be set. The digitizer then takes the MC events, which don't have well-defined time stamp, and distributes them in the time-slices with the chosen rate. If there are more events than what fits into one time-slice, then multiple time-slices are created.

So far so good. Now we have the reconstruction step, and here is where I get confused: We distinguish between "raw event-based" and "time-based" reconstruction. My task is to work on the former. As far as I understand, all four examples of event builders I showed in my talk (ideal, simple, 2018, 2019) fall into this category.

However the point of each of these event builders is precisely to read a time-slice, and then read the time-stamps of all digis contained in this time-slice and to disentangle the events (physical collisions) stored in that particular time-slice. So in other words, in order to get proper input data, I must run the digitizer in "time-based" mode rather than "event-based" mode. Otherwise I end up with a situation where there is only one event in the slice, which is trivial. The event builder should work in the more general case, right?

So ultimately my question is what exactly the definition of "event-based" and "time-based" is on the level of reconstruction. My guess is that "event-based" means something like "interaction rate is low such that overlap can be neglected" and "only digi time-stamps are used". Is this correct? So reconstruction can still be "event-based" even if there are more than one events in one time slice?

@p.-a.loizeau I was able to run the event builder on simulated data. For this purpose, I ran the following macros:

  root -l -q $CBMSRCDIR/macro/run/run_tra_file.C'("",25,"data  /sis100_muon_jpsi_test","sis100_muon_jpsi")'
  root -l -q $CBMSRCDIR/macro/run/run_digi.C'("data/sis100_muon_jpsi_test",25,"",1.e4,1.e7)'
  root -l -q $CBMSRCDIR/macro/run/run_reco.C'("data/sis100_muon_jpsi_test",- 1,0,"","Real","sis100_muon_jpsi")'

In run_reco.C I modified the following lines:

 if (eventBased) {
    if (evBuildRaw.EqualTo("Ideal", TString::ECaseCompare::kIgnoreCase)) {
      FairTask* evBuildRaw = new CbmBuildEventsIdeal();
      run->AddTask(evBuildRaw);
      std::cout << "-I- " << myName << ": Added task " << evBuildRaw->GetName()
                << std::endl;
      eventBased = kTRUE;
    }  //? Ideal raw event building 
    else if (evBuildRaw.EqualTo("Real", TString::ECaseCompare::kIgnoreCase))   {
      CbmMcbm2019TimeWinEventBuilderTask* evBuildRaw 
        = new CbmMcbm2019TimeWinEventBuilderTask();
      evBuildRaw->SetTsParameters(0.0,1.e7,0.0);

      run->AddTask(evBuildRaw);
      std::cout << "-I- " << myName << ": Added task " << evBuildRaw->GetName()
                << std::endl;
      eventBased = kTRUE;
    }  //? Real raw event building
    else {
      std::cerr << "-E- " << myName << ": Unknown option " << evBuildRaw
                << " for raw event building! Terminating macro execution."
                << std::endl;
      return;
    }
  }  //? event-based reco

The lower branch is new.

In order to run the event builder, I made the following changes to CbmMcbm2019TimeWinEventBuilderAlgo.h:

   /// Event building mode and detectors selection
  //EOverlapMode fOverMode {EOverlapMode::AllowOverlap};
  EOverlapMode fOverMode {EOverlapMode::MergeOverlap};

  EventBuilderDetector fRefDet =
    EventBuilderDetector(ECbmModuleId::kSts, ECbmDataType::kStsDigi, "kSts");
    //EventBuilderDetector(ECbmModuleId::kT0, ECbmDataType::kT0Digi, "T0");
  std::vector<EventBuilderDetector> fvDets = {
    //EventBuilderDetector(ECbmModuleId::kSts, ECbmDataType::kStsDigi, "kSts"),
    //EventBuilderDetector(ECbmModuleId::kMuch, ECbmDataType::kMuchDigi, "kMuch"),
    EventBuilderDetector(ECbmModuleId::kTrd, ECbmDataType::kTrdDigi, "kTrd"),
    EventBuilderDetector(ECbmModuleId::kTof, ECbmDataType::kTofDigi, "kTof")};
    //EventBuilderDetector(ECbmModuleId::kRich, ECbmDataType::kRichDigi, "kRich"),
    //EventBuilderDetector(ECbmModuleId::kPsd, ECbmDataType::kPsdDigi, "kPsd")};

This was necessary, as digis for the detectors which are commented out are not found.

A quick glance at the output tree tells me that 93 events were reconstructed, although I only produced 25 MC events. Probably I chose too small windows. I will try to understand this.

@f.uhlig Thanks, will check that out.

@p.-a.loizeau @f.uhlig Inserting this block in the run_reco.C macro works. The "kEventBuilder" types have to be used for the switches. The flags for the presence of detectors are set by reading from the CbmSetup object at the top of the macro.

The MuchBeamTimeDigiFlag must be set to kFALSE in my case. I haven't found out yet how to determine it automatically from the input. Probably it can be done.

Hardcoding the parameters in evBuildRaw->SetTsParameters(0.0,1.e7,0.0); is not ideal of course. Maybe this needs to be an additional parameter for the macro.

The current version now runs. I will now try to figure out whether the output makes sense.

else if (evBuildRaw.EqualTo("Real", TString::ECaseCompare::kIgnoreCase)) {

      //CbmMcbm2018EventBuilder* evBuildRaw 
        //= new CbmMcbm2018EventBuilder();

      if( !useSts ) {
         std::cerr << "-E- " << myName << ": Sts must be present for raw event "
                << "building using ``Real'' option. Terminating macro."
                << std::endl;
         return;
      }
      CbmMcbm2019TimeWinEventBuilderTask* evBuildRaw
        = new CbmMcbm2019TimeWinEventBuilderTask();
      evBuildRaw->SetTsParameters(0.0,1.e7,0.0);

      // Use CbmMuchDigi instead of CbmMuchBeamtimeDigi
      evBuildRaw->ChangeMuchBeamtimeDigiFlag(kFALSE);

      // Remove detectors where digis not found
      if( !useRich ) evBuildRaw->RemoveDetector(kEventBuilderDetRich);
      if( !useMuch ) evBuildRaw->RemoveDetector(kEventBuilderDetMuch);
      if( !usePsd ) evBuildRaw->RemoveDetector(kEventBuilderDetPsd);
      if( !useTof ) evBuildRaw->RemoveDetector(kEventBuilderDetTof);
      if( !useTrd ) evBuildRaw->RemoveDetector(kEventBuilderDetTrd);

      // Remove STS as it will be our reference
      evBuildRaw->RemoveDetector(kEventBuilderDetSts);

      // Set STS as reference detector
      evBuildRaw->SetReferenceDetector(kEventBuilderDetSts);

      run->AddTask(evBuildRaw);
      std::cout << "-I- " << myName << ": Added task " << evBuildRaw->GetName()
                << std::endl;
      eventBased = kTRUE;
    }  //? Real raw event building

@f.uhlig @p.-a.loizeau by the way: I understand that these forums are viewable by non-registered users. Will this be changed at some point?

With these additional lines I reconstruct exactly 25 events from 25 MC events. That doesn't mean they are the same ones, but this choice of window seems to be approximately right.

//Choose between NoOverlap, MergeOverlap, AllowOverlap
      evBuildRaw->SetEventOverlapMode(EOverlapMode::AllowOverlap);

      evBuildRaw->SetTriggerMinNumber(ECbmModuleId::kSts, 10);
      evBuildRaw->SetTriggerMaxNumber(ECbmModuleId::kSts, -1);
      evBuildRaw->SetTriggerWindow(ECbmModuleId::kSts, -5500, 5500);

Merging this is ok in my opinion. The changes are small and can't cause problems in my opinion.

added 1 commit

4398c9a9 - Add support for mCBM evt builders in sim reco macro

Compare with previous version

added 33 commits

4398c9a9...f1493312 - 28 commits from branch computing:master
ae82c4b3 - Add interface to override the TS params with user values in TimeWinEvtBuild
accf40fd - In TimeWinEvtBuilder, add flag to switch to CbmMuchDigi (instead of CbmMuchBeamtimeDigi)
d119902a - Apply formatting
7243148d - Apply formatting
dddd47f6 - Add support for mCBM evt builders in sim reco macro

Compare with previous version

added 1 commit

c0030e8e - Add tests for simu reco with real event builder + related fixes

Compare with previous version

resolved all threads

unmarked as a Work In Progress

changed the description

assigned to @v.friese

added 7 commits

6b9653a0 - 1 commit from branch computing:master
e0a2c09e - Add interface to override the TS params with user values in TimeWinEvtBuild
f11a99bd - In TimeWinEvtBuilder, add flag to switch to CbmMuchDigi (instead of CbmMuchBeamtimeDigi)
42270a8d - Apply formatting
8beba300 - Apply formatting
ae54bde1 - Add support for mCBM evt builders in sim reco macro
b0876e11 - Add tests for simu reco with real event builder + related fixes

Compare with previous version

Concerning your original post on the terminology: yes, one must distinguish between event-based / time-based simulation and event-based / time-based reconstruction.

You have correctly described the simulation case. In reconstruction, we mean with event-based that the respective algorithm operates on a set of data presumably representing one collision. While time-based means that the algorithm operates on the entire time-slice data without association of data to events.

Obviously, an event builder is always time-based in that sense. It performs the transition from time-slice to events by associating data to events (in your case data are the digis, but the statement also holds potentially for other data, e.g. event building from tracks). So, any algorithm running after the event builder can operate event-based (and it should, otherwise the event building does not make sense).

And yes, applying the event builder to simulated data makes only much sense for time-based simulations. As you correctly state, event-based simulations produce "time-slices" with data from exactly one MC event. It may, however, be interesting to check whether the event builder indeed makes one event of the one MC event (as it should), so for developing and debugging and benchmarking the event builder, this might be a viable tool.

approved this merge request

@p.-a.loizeau : Please rebase such merge is possible.

added 10 commits

b0876e11...6d929846 - 4 commits from branch computing:master
1bd2188b - Add interface to override the TS params with user values in TimeWinEvtBuild
a756e205 - In TimeWinEvtBuilder, add flag to switch to CbmMuchDigi (instead of CbmMuchBeamtimeDigi)
7e1bc2ed - Apply formatting
510e7d55 - Apply formatting
358500cd - Add support for mCBM evt builders in sim reco macro
fac1510e - Add tests for simu reco with real event builder + related fixes

Compare with previous version

merged

@p.-a.loizeau,

is the current version of the event builder general enough to be used with any of the setups? If so I would propose to rename the class and move it to the proper place in reco/eventbuilder.

@f.uhlig Probably, but I am also working on an updated version, which will be in reco/eventbuilder.

@d.smith,

Then we will wait for that version. What is the expected time line?

@f.uhlig Maybe we should discuss that now in the developer coffee

Make TimeWinEventBuilder Algo more generic and compatible with simulated data

Merge request reports

Activity