Geometry descriptions for ECAL-E and ECAL-P

[shan-yamabuki]

Implementation of isolated ECAL-P (prototype by FCAL) and ECAL-E (prototype by CALICE/DRD-Calo).

Feature

• Adding new LUXEEcal detector type;
  • Based on CALICE testbeam prototype key4geo/detector/CaloTB;
  • Implementing a sub-slice element called module to describe transverse inhomogeneity within one slice;
• Detector description ECALe_luxe_2512.xml
  • Based on ECALe_luxe_v1.xml used in ECAL-NPOD study in 2024-25;
  • Ideas from ECALe_luxe_v2.xml are added, but the v1 geometry is kept;
  • (new) They are now pixelized in the module level; each pixel has its layer/(slice)/module/x/y cell ID; two readout schemes are available for selection;
• Detector description ECALp_luxe_2512.xml;
  • Based on ECALe_luxe_2512.xml with ECAL-P prototype geometrical design during TB2025;
  • Not fully consistent with current GEANT4 implementation of ECAL-P for TB2025;

To-do list

• Cell ID in readouts section;
  • Need help to understand how are the segments added (per module in our case? or per slice?)
  • Need help with digitization (but probably a digitizer processor is good enough?)
  • Alternatively, an additional processor can handle pixelization and digitization;
• Follow-up (naive) analyses on the new implementation;
  • Simple test simulation are done;
  • The latest analysis uses ECALe_luxe_v1.xml;
• Consistency check with other GEANT4 simulation, especially for ECAL-P;
• Clean out duplicated or unused definitions (e.g. description of materials);
  • Conflicting definitions of air in Materials_v1.xml and materials.xml;
  • Consistency with the tracker?
• Merge documents for ECAL to main README.md (?)

[tmadlener]

Thanks a lot for opening this. I had a brief look now only and in general this looks good, I think. There are a few more detailed questions / comments below.

Are the binary files necessary (i.e. the .png and .root files)? It looks like they are not used by the README and I would like to keep binary files out of git history if possible. If they are necessary, we can leave them in of course.

[tmadlener]

Some more comments to the top level TODO list items:

• Cell ID in readouts section;
  • Currently, we use an additional processor to do pixelization and digitization. They could have been implemented in the readouts section;
  • Need help to understand how are the segments added (per module in our case? or per slice?)
  • Need help with digitization (but probably a digitizer processor is good enough?)

I think for now this is perfectly fine to this downstream with some processor or algorithm. This should be fairly straight forward to change later (even if it is a bit of work). I think it would be more important to have a combined geometry with a tracker and a calorimeter in DD4hep for now.

• Follow-up (naive) analyses on the new implementation;
  • Only visualization and test simulation are done;
  • The latest analysis uses ECALe_luxe_v1.xml;

Could we have a test simulation as part of a test that we could run in CI? We would probably need some inputs, but we can also just run a particle gun for some very basic checks. We have some tests for the tracker already: https://github.com/LUXEsoftware/luxegeo/blob/main/tests/CMakeLists.txt

• Clean out duplicated or unused definitions (e.g. description of materials);
  • Conflicting definitions of air in Materials_v1.xml and materials.xml;
  • Consistency with the tracker?

Also here, I would be in favor of merging this in a way that standalone simulation with the individual calorimeters work. We can then do the homogenization and cleanup to make things consistent in a combined tracker + calorimeter geometry in a follow up PR.