Segmented Crystal ECAL (SCEPCal) addition

[wonyongc]

BEGINRELEASENOTES

• Added geometry, segmentation, sensitive action, and hit classes for the Segmented Crystal ECAL (SCEPCal).

ENDRELEASENOTES

Hi, I have been developing a full simulation for a segmented crystal ECAL (CalVision/MAXICC collaborations) and am now submitting PRs to get the simulation into key4hep.
I should note that I needed to make a new datatype to store the scintllation/cerenkov hit information for dual-readout. So far I have simply extended the edm4hep schema with a custom 'edm4dr' schema in the simulation repo, but to merge into k4geo, it seems like it would be a better option (or the only one) to have this new schema merged into the main edm4hep. I've opened a PR to do that here: key4hep/EDM4hep#380
Please let me know if I should take a different approach or if you have suggestions or changes I should make.
Thanks,
Wonyong

[BrieucF]

Hi Wonyong, thanks! Let's converge on the data model first. Can you answer the comments from key4hep/EDM4hep#380 ?

[atolosadelgado]

Hi @wonyongc

Thank you for this PR!

I tried to compile the project with the key4hep nightlies, and I found the following error:

In file included from /cvmfs/sw-nightlies.hsf.org/key4hep/releases/2024-11-26/x86_64-almalinux9-gcc14.2.0-opt/dd4hep/c9023f116f4f161f21d244fccdbc971753bd748f_develop-muro26/include/DDG4/Geant4StepHandler.h:17,
                from /tmp/k4geo_PR406/k4geo/detectorSegmentations/src/DRCrystalHit.cpp:8:
/cvmfs/sw-nightlies.hsf.org/key4hep/releases/2024-11-26/x86_64-almalinux9-gcc14.2.0-opt/dd4hep/c9023f116f4f161f21d244fccdbc971753bd748f_develop-muro26/include/DDG4/Geant4HitHandler.h:20:10: fatal error: G4EmSaturation.hh: No such file or directory
  20 | #include <G4EmSaturation.hh>
     |          ^~~~~~~~~~~~~~~~~~~
compilation terminated.

Do you have any hint about it?

In addition, I have few comments:

1. In general, removing the namespace is dangerous because you can create collisions, which may explode at runtime and they are difficult to spot. My advice here would be not using the using namespace xxx, e.g file DRCrystalHit.cpp

using namespace dd4hep::sim;
using namespace dd4hep;
using namespace std;
using namespace SCEPCal;

2. Are the ROOT macros needed at the end of the file DRCrystalHit.h?

Thank you for your time

Best,
Alvaro

[wonyongc]

Hi @BrieucF , @atolosadelgado ,
Thank you both for your comments. I've updated key4hep/EDM4hep#380 with a simpler data model. I've implemented the changes from Alvaro's comments as well, removing the namespace usages and the ROOT macros.
I also updated the segmentation class/file names with the "_k4geo" suffix to follow the convention.

The error regarding #include <G4EmSaturation.hh> was fixed by removing unnecessary includes from DRCrystalHit.h/cpp and putting them in the sensitive action instead (SCEPCalSDACtionDRCrystalHit.cpp).

I do however see a new error, which I believe is because the edm4hep changes are not merged in yet.

The cmake step runs fine, but the make step fails at the linker stage:

[ 15%] Built target detectorSegmentations
[ 90%] Built target k4geo
[ 90%] Generating libk4geo.components
ERROR: failed to load libk4geo.so: /home/wonyongc/src/hep/k4geo/build/lib/libdetectorSegmentations.so: undefined symbol: _ZTIN6dd4hep3sim13Geant4HitDataE
make[2]: *** [CMakeFiles/Components_k4geo.dir/build.make:73: libk4geo.components] Error 1
make[1]: *** [CMakeFiles/Makefile2:204: CMakeFiles/Components_k4geo.dir/all] Error 2
make: *** [Makefile:146: all] Error 2

I have sometimes seen this encoding error before with the linker (undefined symbol xxx with malformed strings, _ZTIN6dd4hep3sim13Geant4HitDataE), but as far as I know it is caused by different reasons in every case. Here my hunch is that it is because of the as-yet-undefined edm4hep schema but if you have any other ideas please let me know.

Thank you!

[andresailer]

# c++filt  _ZTIN6dd4hep3sim13Geant4HitDataE
typeinfo for dd4hep::sim::Geant4HitData

[wonyongc]

@lopezzot removed the edits made for local testing - lol

[wonyongc]

Tested all changes, this is ready to go from my end