Fix segmentation position calculation for Allegro ECal.

[scott-snyder]

Fix the calculation of cell position for
FCCSWGridModuleThetaMerged_k4geo.
Also add a layer() method to that class to extract the layer from a cell ID.

BEGINRELEASENOTES

• Fix cell position calculation for the Allegro ECal.
  ENDRELEASENOTES

[scott-snyder]

Depends on PR#1384 from DD4hep (AIDASoft/DD4hep#1384), and requires a corresponding change in k4RecCalorimeter.

[atolosadelgado]

Hi @scott-snyder

Thank you for your PR.

I think your approach is correct. However, I was wondering if it makes more sense that this extra information is stored as a data extension of the detector element, to be later retrieved by the segmentation itself and copied internally.

A data extension would be easier to retrieve later during the reconstruction steps. @BrieucF @giovannimarchiori do you have idea about some key information that you would like to attach to the ECAL? I am not sure it is the best reference, but for example this is the data extension for the drift chamber [link]

Nevertheless, I remember what you noticed that the initialization of the internal cache of the segmentation can not happen within the constructor, so it has to be done later. I think that step is unavoidable.

[atolosadelgado]

Hi,

The detector geometry appears to be accessible through the handle [link].

If you could store the geometry details as a data extension of the detector element, it could provide a more elegant solution. Please let me know if you require further support.

[giovannimarchiori]

Hi @atolosadelgado,

we have layer radial info stored as dd4hep::rec::LayeredCalorimeterData in the C++ builder of the detector

k4geo/detector/calorimeter/ECalBarrel_NobleLiquid_InclinedTrapezoids_o1_v04_geo.cpp

Line 769 in 915923d

dd4hep::rec::LayeredCalorimeterData::Layer caloLayer;

Is this the "data extension" you are proposing, or is it something different?
Cheers,
Giovanni

[atolosadelgado]

Hi @atolosadelgado,

we have layer radial info stored as dd4hep::rec::LayeredCalorimeterData in the C++ builder of the detector

k4geo/detector/calorimeter/ECalBarrel_NobleLiquid_InclinedTrapezoids_o1_v04_geo.cpp

Line 769 in 915923d

dd4hep::rec::LayeredCalorimeterData::Layer caloLayer;

Is this the "data extension" you are proposing, or is it something different? Cheers, Giovanni

Yes, that is. This subdetector has a data extension of type dd4hep::rec::LayeredCalorimeterData, attached few lines before [link]

My point is that the segmentation seems capable of retrieving the detector element and its data extension. Therefore, I’m wondering if the code in this PR, which creates an internal object of type std::vector<LayerInfo> and performs calculations within the segmentation, is truly necessary. Could the segmentation instead directly utilize the LayeredCalorimeterData provided by the geometry? This way, the code would become simpler and ensure consistency with the geometry.

[scott-snyder]

Thanks for the comments and suggestion. I'll take a look and see if that approach is workable.

[scott-snyder]

hi -

So here's a stab at storing the derived geometry information as DetElement
extensions rather than in the segmentation class.

The code is a bit nicer this way. The tradeoff is that it is very roughly
a factor of two slower than the previous version, due to the extra lookups.
It also now shorn of any pretence of thread-safety (as the dd4hep
extension mechanism is not thread-safe).

As far as LayeredCalorimeterData, it doesn't have the information we want
to cache (and we don't want to recompute it each time position is called).
And i don't think it should be added to the version in dd4hep.
So we use an additional extension.

An alternative would be to have the extension filled in createECalBarrelInclined
when the geometry is created, rather than lazily in the segmentation.
But the information needed is specific to the segmentation (it depends
for example on the phi ganging), so i don't think that really makes sense.

[atolosadelgado]

hi -

So here's a stab at storing the derived geometry information as DetElement extensions rather than in the segmentation class.

The code is a bit nicer this way. The tradeoff is that it is very roughly a factor of two slower than the previous version, due to the extra lookups. It also now shorn of any pretence of thread-safety (as the dd4hep extension mechanism is not thread-safe).

As far as LayeredCalorimeterData, it doesn't have the information we want to cache (and we don't want to recompute it each time position is called). And i don't think it should be added to the version in dd4hep. So we use an additional extension.

An alternative would be to have the extension filled in createECalBarrelInclined when the geometry is created, rather than lazily in the segmentation. But the information needed is specific to the segmentation (it depends for example on the phi ganging), so i don't think that really makes sense.

Hi,

You are right that the data extension is expected to be initialized together with the geometry builder. If it can not be used as read-only information by the segmentation, then it is not a good solution, I am sorry I misunderstood what the code was doing.

If you roll back to your original implementation, I can merge it.

Thank you for your time.

[scott-snyder]

Ok, done, thanks.

As a reminder, this change needs to be released together with this PR from k4RecCalorimeter: HEP-FCC/k4RecCalorimeter#135. (Is there any procedure for handling dependencies between packages in key4hep?)

[atolosadelgado]

Ok, done, thanks.

As a reminder, this change needs to be released together with this PR from k4RecCalorimeter: HEP-FCC/k4RecCalorimeter#135. (Is there any procedure for handling dependencies between packages in key4hep?)

As far as I know, there is no synchronous release procedure, as the repositories are independent.

[tmadlener]

(Is there any procedure for handling dependencies between packages in key4hep?)

We can put version requirements into the spack package (in this case make k4reccalorimeter depend on the correct minimal version of k4geo.

[atolosadelgado]

Ok, done, thanks.

As a reminder, this change needs to be released together with this PR from k4RecCalorimeter: HEP-FCC/k4RecCalorimeter#135. (Is there any procedure for handling dependencies between packages in key4hep?)

Hi @scott-snyder

Before I can merge, the CI tests need to pass for the release as well. It looks like the error message is related to a virtual function marked with override that doesn't actually override anything. Would you be able to take a look and update the test accordingly? Thanks!

[scott-snyder]

hi -

That's another interpackage dependency. As i said initially, this change depends on PR#1384 from DD4hep (AIDASoft/DD4hep#1384). This has been merged, but which i guess hasn't made it to a release.
Do we need to wait for another release to be made? (There probably needs to be a better way of handling this sort of thing...)

[jmcarcell]

Suggested change

	virtual bool cellsSpanVolumes() const override
	virtual bool cellsSpanVolumes() const

Does it work to maintain compatibility with the current release? I believe it would compile but I'm not sure if the results will be correct. Otherwise we should add the version of DD4hep that we require in the top level CMakeLists.txt.

[scott-snyder]

Yeah, i think that would compile. The results would be wrong... but maybe not more wrong than they already are.
That still feels like the the wrong way to go about it, though.