DCH v2 digitizer, which smears the position and adds cluster information

[atolosadelgado]

BEGINRELEASENOTES

• New digitizer for DCH v2 (based on twisted tubes). It calculates cluster information and smears the position along and perpendicular the wire separately. New custom EDM4hep data extension was added to include these data.

ENDRELEASENOTES

Hi,

Please find attached the drift chamber (DCH) digitizer, based on Walaa's code for the cluster number and size calculations. In addition, I added the position smearing based on analytical calculations (I was stuck here, but thanks to Andre we found the problem).

The algorithm works as expected, but I can imagine there is room for improvement regarding naming, coding style in general, so please let me know if I can improve it somehow.

I have been working on a stand alone repository, in case you want to try out: https://github.com/atolosadelgado/DCH_detector

Alvaro.

[BrieucF]

Hi Alvaro, excellent! Can you add a test and add a link between sim and digi hits? See e.g. https://github.com/key4hep/k4RecTracker/pull/28/files

[atolosadelgado]

Hi Alvaro, excellent! Can you add a test and add a link between sim and digi hits? See e.g. https://github.com/key4hep/k4RecTracker/pull/28/files

I have added the association and the test. I have inspected the output file and the associations seems to make sense.

Associations are now an additional output collection of the algorithm, but I am not sure if this is the proper way.

You can use the following script to inspect the output file of the test, everything seems consistent

import ROOT
from podio import root_io
import dd4hep as dd4hepModule
from ROOT import dd4hep
from ROOT import TVector3, TFile, TH1D

ofile = TFile("kk.root","update")
hDpw_calc = TH1D("hDpw_calc","",100,0,10)
hDpw_alg  = TH1D("hDpw_alg" ,"",100,0,10)
hDpw_diff = TH1D("hDpw_diff","",100,0,10)

input_file_path = "dch_proton_10GeV_digi.root"
podio_reader = root_io.Reader(input_file_path)

for event in podio_reader.get("events"):
  for dc_hit in event.get("DCH_DigiSimAssociationCollection"):
    digihit =  dc_hit.getDigi()
    simhit  =  dc_hit.getSim()
    digipos = TVector3( digihit.getPosition()[0],digihit.getPosition()[1],digihit.getPosition()[2] )
    simpos  = TVector3(  simhit.getPosition()[0], simhit.getPosition()[1], simhit.getPosition()[2] )
    hit_wire_vector = simpos - digipos
    distance_calculated = hit_wire_vector.Mag()
    distance_from_alg = digihit.getDistanceToWire()
    # print( distance_from_alg - distance_calculated )
    #print( f"{digihit.getEDep()}      {simhit.getEDep()}")
    hDpw_calc.Fill(distance_calculated)
    hDpw_alg.Fill(distance_from_alg)
    hDpw_diff.Fill(distance_calculated-distance_from_alg)
    
ofile.cd()
hDpw_calc.Write()
hDpw_alg.Write()
hDpw_diff.Write()
ofile.Close()

[atolosadelgado]

@BrieucF the code is ready for review :)

[BrieucF]

Thanks Alvaro!

[BrieucF]

Let's add the interface as well: https://github.com/BrieucF/k4RecTracker/blob/fix_for_Dolores/DCHdigi/dataFormatExtension/driftChamberHit.yaml#L66

[atolosadelgado]

Let's add the interface as well: https://github.com/BrieucF/k4RecTracker/blob/fix_for_Dolores/DCHdigi/dataFormatExtension/driftChamberHit.yaml#L66

does this do the trick? how can I test that it works?
47b0d5d

[BrieucF]

Let's add the interface as well: https://github.com/BrieucF/k4RecTracker/blob/fix_for_Dolores/DCHdigi/dataFormatExtension/driftChamberHit.yaml#L66

does this do the trick? how can I test that it works? 47b0d5d

I am surprised that it does not complain that the interfaces edm4hep::TrackerHit: is then defined twice in edm4hep. Let's ask @tmadlener what he thinks. Context: the goal is to avoid having to redefine extension::TrackerHit3D and extension::TrackerHitPlane in order to build an interface, as done here https://github.com/BrieucF/k4RecTracker/blob/fix_for_Dolores/DCHdigi/dataFormatExtension/driftChamberHit.yaml#L66. Last time I tried I could not mix extension objects and edm4hep object in an interface. The latter is indeed very annoying because, in order for subsequent algorithm to work, we have to cast e.g. edm4hep::TrackerHit3D coming from the SIM step into extension::TrackerHit3D and store this duplicated collection in the output rootfile.

[BrieucF]

All these parameters will be set at every call of the function, since many are hard coded, would'nt it be better to define them in the header once and for all?

[atolosadelgado]

Let's add the interface as well: https://github.com/BrieucF/k4RecTracker/blob/fix_for_Dolores/DCHdigi/dataFormatExtension/driftChamberHit.yaml#L66

does this do the trick? how can I test that it works? 47b0d5d

I am surprised that it does not complain that the interfaces edm4hep::TrackerHit: is then defined twice in edm4hep. Let's ask @tmadlener what he thinks. Context: the goal is to avoid having to redefine extension::TrackerHit3D and extension::TrackerHitPlane in order to build an interface, as done here https://github.com/BrieucF/k4RecTracker/blob/fix_for_Dolores/DCHdigi/dataFormatExtension/driftChamberHit.yaml#L66. Last time I tried I could not mix extension objects and edm4hep object in an interface. The latter is indeed very annoying because, in order for subsequent algorithm to work, we have to cast e.g. edm4hep::TrackerHit3D coming from the SIM step into extension::TrackerHit3D and store this duplicated collection in the output rootfile.

I changed the data extension as you proposed originally (by duplicating code), so the interface can work as expected.