Development #2274
openDevelopment #2256: Demonstrator for digi-based trigger, STS-only
Development #2269: Offline integration
Test of digi reconstruction
100%
Description
Test of offline reconstruction from digi level and verification against the current reconstruction scheme on the hand of simulated data and unpacked mCBM data.
Deliverable: Report
Related issues
Updated by Volker Friese 8 months ago
- Due date set to 11/15/2021
- Start date changed from 09/28/2021 to 11/15/2021
- Follows Development #2273: Reconstruction from digi level added
Updated by Volker Friese 8 months ago
- Due date changed from 11/15/2021 to 11/19/2021
- Assignee set to Shreya Roy
Updated by Florian Uhlig 8 months ago
- Assignee changed from Shreya Roy to Florian Uhlig
Updated by Florian Uhlig 8 months ago
- Assignee changed from Florian Uhlig to Shreya Roy
Updated by Volker Friese 6 months ago
- Status changed from Assigned to In Progress
- % Done changed from 0 to 10
Updated by Volker Friese 6 months ago
Here are some more detailed suggestions on how the test could be done.
The task is to verify the new implementation, which is run from macro/reco/reco_digi.C:
CbmTaskTriggerDigi, using the algo TimeClusterTrigger
CbmTaskBuildEvents, using the algo EventBuilder
against the current implementation run from macro/run/run_reco.C:
CbmTaskBuildRawEvents
The new software is expected to give identical results on the same input w.r.t. CbmTaskBuildRawEvents used with the SlidingWindowSeedFinder, provided the set of parameters is the same.
There are five parameters for the new software (see macro(reco/reco_digi.C):
CbmTaskTriggerDigi: trigger window size, minimum number of digis, dead time;
CbmTaskBuildEvents: event building window for STS (min, max)
I think the values currently in the macro are a good guess. The aim here is not so much optimising these parameters, but to verify that the new software does the same as the old. So, make sure that the equivalent settings are used in macro/run/run_reco.C. If you are unsure, Dominik can surely help.
I suggest to test this on four data samples:
- simulated data (full CBM), central events, event-by-event digitization;
- simulated data (full CBM), central events, time-based digitization, rate 1e5;
- simulated data (full CBM), central events, time-based digitization, rate 1e7
- real mCBM data (unpacked, one of the "golden" runs);
Since the new software can process STS data only, you can ease computation by ignoring all other detectors at digitization stage. For this, add run->DeactivateAllBut(ECbmModuleId::kSts)
in the run_digi.C macro.
The comparison of old and new software should look at the number of triggered events in the first place and the trigger times. Secondly, the number of digis in the events could be compared. You will not be able to use the event builder QA with the new data, since the match objects are not (yet) copied to the output, but for the event-by-event simulation, there should be no ambiguity, since all digis stem from one and the same event by construction. Of interest is further the execution time.