Strange layering in ECal : Endcap VS Ring

[rete]

Hi !

I'm trying to compute the ratio of absorbser thicknesses between the ECalEndCap and the ECalRing for calibration. For that, I convert the compact file (i.e ILD_l4_v02) to gear and I parse the xml with a simple python library to get my ratio. During this process, I noticed that the ratio is not 1 as it should be. By comparing the result of the dumpdetector command with the ILD_l4_v02 model and the gear file, I noticed that the ECalEndCap and ECalRing (ECalPlug in GEAR) are not layered in the same way.

Dump of compact file : ILD_l4_v02_dumpdetector.txt Gear file : Gear file from ILDConfig

Any idea where it comes from ?

[shaojunlu]

@rete @danieljeans Please checkout the PR #160

[rete]

@shaojunlu Should we close this issue now ?

[shaojunlu]

@rete Yes, the fix in PR #160 has been approved and merged. You may close it.

[danieljeans]

If I understand correctly, PR #160 fixes the number of entries in the gear file (which was 2x too large for the plug).

There is an additional difference between ECAL endcap and plug in the dumpdetector: the "inner_thick" of the first layer. I'll check this.

I have a question: what is "absorberThickness" in the gear file meant to be? From the following snippet:

    <detector name="EcalBarrel" geartype="CalorimeterParameters">
        <layout type="Barrel" symmetry="8" phi0="0.000000000e+00" />
        <dimensions inner_r="1.804800000e+03" outer_z="2.350000000e+03" />
        <layer repeat="1" thickness="6.965000000e+00" absorberThickness="6.440000000e+00" cellSize0="5.088333333e+00" cellSize1="5.088333333e+00" />
        <layer repeat="1" thickness="3.325000000e+00" absorberThickness="2.800000000e+00" cellSize0="5.088333333e+00" cellSize1="5.088333333e+00" />

it looks like the layer "thickness" minus the thickness of the sensitive element (0.525 mm in this case). This is not the same as the thickness of e.g. tungsten absorber material between the sensitive layers. I think that's OK, as long as that is what's intended.

[danieljeans]

there is indeed a bug in filling the dd4hep::rec data in the ECPlug, the material in front of the first layer was not correctly accounted for.

Before I submit a fix, I would just like to confirm what should be put into "caloLayer.distance". For the endcap, I think it's the distance in z from the IP, but is it to the centre of the sensitive layer? or the beginning of the calolayer? This is not consistently filled in the ecal endcap and ECRing.

[gaede]

In DDMarlinPandora it is expected that this is the distance to the beginning of the layer, i.e. typically the front of the absorber surface: https://github.com/iLCSoft/DDMarlinPandora/blob/master/src/DDGeometryCreator.cc#L246 Also documented here: https://github.com/AIDASoft/DD4hep/blob/master/DDRec/include/DDRec/DetectorData.h#L410 But I am not sure if this is done consistently in all our drivers ...

[danieljeans]

This should all be fixed and made consistent by PR#165.