Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using cylindrical surfaces for track reconstruction in iLCSoft #50

Open
armin-ilg opened this issue Aug 14, 2024 · 5 comments
Open

Using cylindrical surfaces for track reconstruction in iLCSoft #50

armin-ilg opened this issue Aug 14, 2024 · 5 comments

Comments

@armin-ilg
Copy link

  • OS version: lxplus/almalinux9
  • Compiler version: gcc 11.4.1 of the 2024-08-14 key4hep stack
  • Package version: My DD4hep branch (see DD4hep PR) with my k4geo branch (see k4geo MR) using CLDConfig (CLD reconstruction, just changing collection names, and list of ResolutionU and ResolutionV to have four barrel layers)
  • Reproduced by:

cloning DD4hep

source /cvmfs/sw.hsf.org/key4hep/setup.sh -r 2024-04-12 # latest nightly not working due to problem in lumical constructor
git clone -b try_cylinderSegmentSurface https://github.com/armin-ilg/DD4hep.git
cd DD4hep

compile DD4hep:

mkdir build; cd build
cmake .. -DCMAKE_INSTALL_PREFIX=../InstallArea -DDD4HEP_USE_GEANT4=ON \
        -DBoost_NO_BOOST_CMAKE=ON \
        -DDD4HEP_USE_LCIO=ON \
        -DDD4HEP_USE_EDM4HEP=ON \
        -DDD4HEP_USE_TBB=OFF \
        -DDD4HEP_USE_HEPMC3=ON \
        -DDD4HEP_BUILD_DEBUG=OFF \
        -DBUILD_TESTING=ON \
        -DDD4HEP_DEBUG_CMAKE=ON \
        -DDD4HEP_USE_XERCESC=ON \
        -DCMAKE_BUILD_TYPE=Release \
        -DCMAKE_CXX_FLAGS="-fdiagnostics-color=always"  \
        -DCMAKE_CXX_STANDARD=17
mkdir InstallArea
make -j4 install
cd ../InstallArea

source bin/thisdd4hep.sh

export CMAKE_PREFIX_PATH=$PWD/:$CMAKE_PREFIX_PATH
export PATH=$PWD/bin/:$PATH
export LD_LIBRARY_PATH=$PWD/lib:$PWD/lib64:$LD_LIBRARY_PATH
export PYTHONPATH=$PWD/python:$PYTHONPATH
export ROOT_INCLUDE_PATH=$PWD/include:$ROOT_INCLUDE_PATH
export DD4hep_DIR=$PWD

cd ../../

cloning and compiling k4geo:

git clone -b CLD_with_IDEAvertex_and_ultra-light https://github.com/armin-ilg/lcgeo.git
cd lcgeo

mkdir build                                                                                                                                                                                                                                                                                                                                                                                                               
cd build
source $DD4hep_DIR/bin/thisdd4hep.sh

cmake .. -DCMAKE_INSTALL_PREFIX=../InstallArea -DBoost_NO_BOOST_CMAKE=ON
make -j4 install
cd ../InstallArea
# source bin/thislcgeo.sh
source bin/thisk4geo.sh

export PYTHONPATH=${LCIO}/src/python:${ROOTSYS}/lib:$PYTHONPATH
cd ..
export k4geo_DIR=$(pwd)

export K4GEO=$(pwd)

Enabling the curved vertex by using this git patch:
use_ultra_light.patch

git apply use_ultra_light.patch

Cloning my CLDConfig repo:

cd ..
git clone https://github.com/armin-ilg/CLDConfig.git
cd CLDConfig/CLDConfig

Running SIM:

ddsim --compactFile $K4GEO/FCCee/CLD_IDEAvertex/compact/CLD_o2_v05_IDEAvertex/CLD_o2_v05_IDEAvertex.xml --outputFile sim.root --steeringFile cld_steer.py --random.seed 0123456789 --enableGun --gun.particle mu- --gun.energy 100*GeV --gun.distribution uniform --gun.thetaMin 89*deg --gun.thetaMax 89*deg --crossingAngleBoost 0 --numberOfEvents 1000

Running RECO:

k4run CLD_IDEAvertexCurvedReconstruction.py --inputFiles sim.root  --outputBasename reco.root --GeoSvc.detectors $K4GEO/FCCee/CLD_IDEAvertex/compact/CLD_o2_v05_IDEAvertex/CLD_o2_v05_IDEAvertex.xml --trackingOnly -n 1000
  • Input: No further input files needed

  • Output:
    dd4hep.log,
    k4geo.log,
    reco.log (reco.log is with TruthTracking - errors also persist with using the ConformalTracking chain)

  • Goal: I'm trying to use my ultra-light curved IDEA vertex in full simulation using CLD and replacing the IDEA vertex with this one. This has worked for the normal IDEA vertex detector (with ladders), but doesn't work yet with the curved variant, where the detector consists of curved silicon sensors, for which I adapted dd4hep::rec::VolSurface accordingly (see PR in DD4hep). I want to get d0 and z0 resolutions of particle gun tracks in the same way for the curved vertex as for the CLD/IDEA vertex detectors.

  • Problem: Using k4Marlin wrapper and the usual reco chain for the vertex (DDPlanarDigiProcessor + TruthTrackFinder/ConformalTracking+ClonesAndSplitTracksFinder) with adjusted ResolutionU und ResolutionV lets the reconstruction run, and the reco hits look reasonable (very close to the SIM hits as expected by the small resolution of 0.003 mm), but for every event I get the following error:

MyTruthTrackFinder DEBUG Retrieving LCIO Event for wrapped processor MyTruthTrackFinder
MyTruthTrackFinder DEBUG LCIO Event retrieved successfully
TDecompLU::Deco... ERROR matrix is singular
TDecompLU::Inve... ERROR matrix is singular, 0 diag elements < tolerance of 2.2251e-308
TDecompLU::Deco... ERROR matrix is singular
TDecompLU::Inve... ERROR matrix is singular, 0 diag elements < tolerance of 2.2251e-308
TDecompLU::Deco... ERROR matrix is singular
TDecompLU::Inve... ERROR matrix is singular, 0 diag elements < tolerance of 2.2251e-308
TDecompLU::Deco... ERROR matrix is singular
TDecompLU::Inve... ERROR matrix is singular, 0 diag elements < tolerance of 2.2251e-308
TDecompLU::Deco... ERROR matrix is singular
TDecompLU::Inve... ERROR matrix is singular, 0 diag elements < tolerance of 2.2251e-308

The resulting residuals of the tracks are way too large then in d0 and z0. The efficiencies and other track parameters look good however.

I think the problem arises from the MarlinTrk::createFinalisedLCIOTrack function, which is used both in the TruthTracking and the ConformalTracking.

Are cylindrical surfaces in general supported by iLCSoft reconstruction and are the changes I made in the DD4hep PR enough, what further needs to be changed to use a VolSurface instead of a plane surface? Since the reco hits look ok, I don't think the problem is in the DDPlanarDigitizer.

Thank you and kind regards,
Armin

@Zehvogel
Copy link
Collaborator

Just some first thoughts:

In principle the tracking can deal with cylindrical surfaces, the surface we use at the IP is a cylinder if I am not confusing things.
If that seamlessly works with cylinder segments was probably never tested.

Your VolCylinder volume surfaces will be used to build CylinderSurfaces (https://github.com/AIDASoft/DD4hep/blob/fcd5569044a4a5be8eae7cb201f02605dcdccfab/DDRec/src/DetectorSurfaces.cpp#L60-L67) and then turned into DDCylinderLayer (https://github.com/iLCSoft/DDKalTest/blob/9af3dfe9ee92799d78e09c68fda6991fede0af08/src/DDKalDetector.cc#L82-L85), so these places might also need some changes. In particular the later one and https://github.com/iLCSoft/KalTest/blob/master/src/geomlib/TCylinder.h I would guess as they would think that the hit is on the surface if it is anywhere on the full cylinder.

@andresailer
Copy link
Collaborator

andresailer commented Aug 14, 2024

Are cylindrical surfaces in general supported by iLCSoft reconstruction

Yes? https://github.com/iLCSoft/KalTest/blob/master/src/geomlib/TCylinder.cxx I think?
(we use cylindrical surfaces for the beampipe at least, but that doesn't have a measurement with it. I think the ILD TPC goes via cylindrical surfaces, but I could be mistaken there)

and are the changes I made in the DD4hep PR enough

No? Maybe? Depends on the rest of your code?

DDPlanarDigitizer

That cannot be used for cylindrical surfaces? Any smearing in "phi" would move the hit outside the surface?

Can you point to where you attach the surfaces to your cylindrical vertex detector layers?

PS: Thanks for the detailed reproducer! Almost perfect :)

Enabling the curved vertex by using this git patch:

but why not make this a git commit? Don't make me do manual things for the reproducer beyond copy pasting commands. Ideally one block of commands. Use shell comments # if you want

@andresailer
Copy link
Collaborator

This file CLD_o2_v05_IDEAvertex.xml doesn't exist here https://github.com/armin-ilg/lcgeo/tree/CLD_with_IDEAvertex_and_ultra-light/FCCee

But maybe I just got lost in your reproducer.

@armin-ilg
Copy link
Author

armin-ilg commented Aug 15, 2024

This file CLD_o2_v05_IDEAvertex.xml doesn't exist here https://github.com/armin-ilg/lcgeo/tree/CLD_with_IDEAvertex_and_ultra-light/FCCee

But maybe I just got lost in your reproducer.

Just fixed it, please fetch the k4geo/lcgeo branch again. (trouble with the k4geo parallel PR, for which I changed things as well). Also no more need to apply the git patch.

The output is the same as yesterday however (just tried).

I'm going through your comments, thank you both a lot already!

Yes? https://github.com/iLCSoft/KalTest/blob/master/src/geomlib/TCylinder.cxx I think?
(we use cylindrical surfaces for the beampipe at least, but that doesn't have a measurement with it. I think the ILD TPC goes via cylindrical surfaces, but I could be mistaken there)

Yes, I had seen the KalTest repo, but as you say the beampipe does not come with a measurement.

That cannot be used for cylindrical surfaces? Any smearing in "phi" would move the hit outside the surface?

Yes, I know. I also tried DDPlanarDigiProcessor without smearing (setting ResolutionU/V to 0) so that the hits stay where they are, but to no avail.

@armin-ilg
Copy link
Author

armin-ilg commented Aug 15, 2024

Can you point to where you attach the surfaces to your cylindrical vertex detector layers?

This is done here in VertexBarrel_detailed_o1_v02_geo.cpp

think the ILD TPC goes via cylindrical surfaces, but I could be mistaken there)

Yes, I had also found that: DDTPCDigiProcessor.

What approach do you think is best? Writing a DDCylindricalDigiProcessor based on the TPC one? (removing all TPC related things, only keeping Gaussian smearing in phi and z)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants