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

ddsim executes DDG4.kernel from a foreign installation #1407

Closed
ybedfer opened this issue Feb 27, 2025 · 3 comments
Closed

ddsim executes DDG4.kernel from a foreign installation #1407

ybedfer opened this issue Feb 27, 2025 · 3 comments
Labels

Comments

@ybedfer
Copy link
Contributor

ybedfer commented Feb 27, 2025

Hello, I installed my private DD4hep in an environment where another installation already exists (in some /opt/software link).
The DDG4 kernel that is executed is that from that /opt/software instead of mine. This, only recently: in the past, where as far as I can tell, I was proceeding exactly the same, everything was fine.

What I am doing (and was also doing in the past):

  • git clone from my fork, compile and source the thisdd4hep.sh script.
  • My private DD4hep installation is then linked into env. variables PATH, PYTHONPATH, LD_LIBRARY_PATH and DD4HEP_LIBRARY_PATH.
  • Execute ddsim. The program runs correctly and produces a valid output TTree. But it does not make use of my private DD4hep. I can tell that from the fact that I cannot see any of my printouts.
  • Also, when I execute ddsim w/in gdb, I can see that the DDG4 kernel that is executed is that from /opt/software. For example, I get the following trace:
#15 0x00007fffdb9c39c5 in dd4hep::sim::Geant4Exec::run(dd4hep::sim::Geant4Kernel&) ()
   from /opt/software/linux-debian12-x86_64_v2/gcc-12.2.0/dd4hep-1.30-cyaqyw2wpezcww3x5rxtqgzqpweevtx5/lib/libDDG4.so.1.30
#16 0x00007fffdb9f1cb9 in dd4hep::sim::Geant4Kernel::run() ()
   from /opt/software/linux-debian12-x86_64_v2/gcc-12.2.0/dd4hep-1.30-cyaqyw2wpezcww3x5rxtqgzqpweevtx5/lib/libDDG4.so.1.30

I also added a printout in DD4hepSimulation.py to output the path to the imported module (os.path.dirname(DDG4.__file__). => It's correct and does point to my own installation.

What can be the reason? What do I miss?

@andresailer
Copy link
Member

Either your environments are not completely updated with respect to the second installation of dd4hep, or you are using some software that is still linked to the first installation of DD4hep, or both.

@ybedfer
Copy link
Contributor Author

ybedfer commented Feb 28, 2025

Thanks for the suggestions.

There is indeed a complex web of software packages linked to my DD4hep installation. Which I was not aware of...

@andresailer
Copy link
Member

Ok, then I will assume that there is nothing else we can do on our side.

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

No branches or pull requests

2 participants