Project

General

Profile

Actions

Development #297

closed

Development #295: STS NOV15

Consolidate STS digitizer

Added by Volker Friese about 7 years ago. Updated over 6 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
Start date:
06/18/2015
Due date:
11/27/2015
% Done:

100%

Estimated time:
100.00 h
Spent time:

Description

The realistic STS digitization is functional. The code should be worked on for improvement in speed. Possibly, the classes CbmStsSensorTypeDssdIdeal, -Simple and -Real can be united. Regular testing of the digitisation software should be extended (code coverage is now about 51%). QA should employ QA utilities like Histogrammanager and report creation and be intergrated in the regular tests.


Files

compare_ideal.C (3.39 KB) compare_ideal.C Macro for comparison with SensorTypeDssdIdeal Volker Friese, 09/09/2015 12:00 AM
compare_ideal.txt (5.09 KB) compare_ideal.txt Log for comparison with SensorTypeDssdIdeal Volker Friese, 09/09/2015 12:00 AM
compare_simple.C (3.4 KB) compare_simple.C Macro for comparison with SensorTypeDssd (old) Volker Friese, 09/09/2015 12:01 AM
compare_simple.txt (6.36 KB) compare_simple.txt Log for comparison with SensorTypeDssd (old) Volker Friese, 09/09/2015 12:01 AM

Related issues

Related to CbmRoot - Bug #809: Potential memory leakClosedFlorian Uhlig09/20/2016

Actions
Actions #1

Updated by Volker Friese about 7 years ago

  • Due date set to 10/31/2015
  • Status changed from New to Assigned
  • Assignee set to Volker Friese
  • Estimated time set to 20.00 h
Actions #2

Updated by Volker Friese almost 7 years ago

  • Status changed from Assigned to In Progress
  • % Done changed from 0 to 60
  • Estimated time changed from 20.00 h to 100.00 h

Code has been re-worked and improved. The classes CbmStsSensorTypeDssd, -DssdIdeal and -DssdReal are united into one. Physics processes can be choosen through the CbmStsPhysics singleton. Improvement in speed for realistic reponse (all processes) is about a factor of two.

Still to do: Change digitiser accordingly (proper instantiation of sensor types).

Actions #3

Updated by Volker Friese almost 7 years ago

The changes in the class CbmStsSensorTypeDssd are now effective. The digitiser task and run_reco.C were changed accordingly.

The new code was validated against CbmStsSensorTypeDssdIdeal and the old implementation of CbmStsSensorTypeDssd (see attached test macros and log outputs). The behaviour with corresponding settings was found identical for the ideal case. In the "simple case" (old implementation of Dssd, uniform energy loss, no other processes), there is a slight difference in the charge distribution of the fired strips, which can be understood since in the old code, a uniform charge distribution was analytically projected on the strips, while the new code explicitely produces about 100 discrete charge packets of about 300 e each. At the boundary of two active strips, one packet can fall into one or the other. The differences in the strip charges are well below the 300 e. So, this is a "charge discretisation error".

I tested with full UrQMD events using run_sim.C and run_reco.C (same settings: uniform energy loss, no other processes). The new code gives 1.2% more charge signals, 1.3% more digis, 0.6% more clusters and 0.9% more hits. The number of reconstructed tracks remains the same (+/- 1). This difference can also be understood since the new code allows partial trajectories in the active sensor volume, while the old one discarded a MCPoint if either the entry or the exit coordinates were not in the active area.

So, I consider the new code validated for ideal and uniform energy los without other processes (that is, against the old standard in run_reco.C).

The old behaviour of CbmStsSenorTypeDssd is still available (for testing) by choosing digiModel = 3 in CbmStsDigitize.

Validation against CbmStsSensorTypeDssdReal (energy loss fluctuations, Lorentz shift, diffusion, cross talk) is ongoing.

Actions #4

Updated by Volker Friese almost 7 years ago

  • % Done changed from 70 to 80

New functionality of SensorTypeDssd (Lorentz shift, diffusion, cross talk) was checked by comparing to SensorTypeDssdReal (using uniform energy loss for easier comparison).

Lorentz shift and cross talk is the same for both (after a bug fix in the new code). Diffusion in DssdReal was overestimated for holes (p side), which is now corrected in Dssd. The overall effect, however, is small, since diffusion does not play a vital role (diffusion widths are of the order of several mum only).

Actions #5

Updated by Volker Friese over 6 years ago

  • Due date changed from 10/31/2015 to 11/27/2015
  • Status changed from In Progress to Closed

Is considered done.

Actions #6

Updated by Volker Friese over 6 years ago

  • % Done changed from 80 to 100
Actions

Also available in: Atom PDF