Use custom DD4hep version in FCCDetectors

FCCSW
1

Hi

I’m working on implementing the IDEA vertex detector in key4hep fullsim. As a starting point, I use the CLD fullsim implementation. I now want to improve the description of the sensors so that there is not one sensor for a whole stave, but actually multiple sensors with some distance between them.

I looked at the underlying ZPlanarTracker class in DD4hep and modified it accordingly in my local DD4hep installation. How can I now use my local DD4hep installation instead of the one included in the key4hep stack (sourcing /cvmfs/fcc.cern.ch/sw/latest/setup.sh)?

I tried building DD4hep with the provided bootstrap.sh and with the key4hep stack. I’d then source thisdd4hep_only.sh from DD4hep. But in both cases, I don’t manage to cmake FCCDetectors and use geoDisplay to look at the detector.

TLDR: How do I use my local DD4hep installation instead of the one in key4hep?

Thank you already for the help! Also please let me know if this questions rather belongs somewhere else.

P.S: In DD4hep/DDDetectors, they use DD4hep_SiTrackerBarrel to build the vertex detector, which has the functionality to have individual modules/sensors, but it seems very old. Would that still be supported in FCCDetectors?

1 Like
2

Hi Armin,

Sorry for the late reply.

Valentin will probably reply with a more complete solution.
However, if you have not tried already, can you try to force using your local installation of DD4hep with
https://key4hep.github.io/key4hep-doc/developing-key4hep-software/Key4hepCMakeGuide.html#using-your-local-installation
In principle, repeating this for any package that you need to recompile, for example FCCDetectors should allow you to have a running local installation with your modifications.

This we need to check.

GG

3

Dear Gerardo

Thank you a lot for your response. Indeed, these tips helped me running FCCDetectors with my local DD4HEP installation. I however found out that ZPlanarTracker is not used from DD4HEP, but from lcgeo. I therefore also made a local installation of lcgeo, made the changes to ZPlanarTracker there and compiled all of it together like this, using the stable key4hep to build everything (for future reference):

# Compiling local DD4hep
source /cvmfs/fcc.cern.ch/sw/latest/setup.sh
cd DD4HEP_folder
source bootstrap.sh #(without sourcing the LCG_101 release)
logout

# Compiling local lcgeo
source /cvmfs/fcc.cern.ch/sw/latest/setup.sh
cd lcgeo_folder
mkdir build
cd build
source ~/DD4hep_folder/bin/thisdd4hep.sh
cmake -DBoost_NO_BOOST_CMAKE=ON ..
make -j4 install
logout

# Compiling FCCDetectors
source /cvmfs/fcc.cern.ch/sw/latest/setup.sh
mkdir build
source lcgeo_folder/bin/thislcgeo.sh
source DD4hep_folder/bin/thisdd4hep.sh
cmake -B build/

# Run geoDisplay
geoDisplay ~/FCCDetectors/Detector/DetFCCeeIDEA/compact/FCCee_DectMaster.xml

So overall it works, but it’s not clear to me how lcgeo, DD4hep and FCCDetectors are linked, with very similar code (e.g ZPlanarTracker) being in both DD4hep and lcgeo. What’s the relation between these?

Thank you again for the help,
Armin

4

Hi Armin,

So overall it works, but it’s not clear to me how lcgeo, DD4hep and FCCDetectors are linked, with very similar code (e.g ZPlanarTracker) being in both DD4hep and lcgeo. What’s the relation between these?

This can indeed be confusing. DD4hep is in principle just the toolkit that allows you to construct the geometry by writing “plugins”, functions that are declared with the macro

DECLARE_DETELEMENT(DD4hep_DiskTracker,create_detector)

and then loaded dynamically at runtime. Most of these will be specific to the user/experiment, but DD4hep does provide some (in DDDetectors and examples) that are either very generic or just used as examples. It can happen that these are duplicated in the downstream repositories (for us lcgeo and FCCDetectors) This is most likely just due to historical reasons - it would be good to upstream whatever can be upstreamed to dd4hep, but it has to be checked that this does not break anything and also that any changes in dd4hep won’t break anything.

For FCCDetectors and lcgeo, there is some duplication with the CLD detector, which is a bit unfortunate, and we’re trying to move everything to lcgeo.
Cheers,
Valentin