Should the GeoSvc implementation live in k4FWCore?

[tmadlener]

Currently the GeoSvc is implemented in k4SimGeant4:

• https://github.com/key4hep/k4SimGeant4/blob/main/Detector/DetComponents/src/GeoSvc.h
• https://github.com/key4hep/k4SimGeant4/blob/main/Detector/DetComponents/src/GeoSvc.cpp

However, the IGeoSvc interface is defined in k4FWCore: https://github.com/key4hep/k4FWCore/blob/main/k4Interface/include/k4Interface/IGeoSvc.h

Should we move the implementation to k4FWCore?

At least for me that was where I would have expected it to be when I first looked for it. A possible disadvantage would be that k4FWCore picks up DD4hep as a dependency, which it doesn't currently have.

[tmadlener]

Side note: This is partially motivated by key4hep/EDM4hep#462 and the wish to have an example on how to do that within the framework.

[jmcarcell]

The main reason and downside is having DD4hep as a dependency. For me it is nice to be able to build at least part of the stack without needing DD4hep, which I don't always have it installed. It's also possible that in the future there are more components that depend on DD4hep, for example, one algorithm to run simulation and maybe other pieces (TGeo or DD4hep-based visualization for algorithms?), then, should all that live in k4FWCore?

[tmadlener]

Yeah, the split across dependencies makes sense, and just pulling in DD4hep to simplify a test here is probably the wrong motivation.

one algorithm to run simulation and maybe other pieces (TGeo or DD4hep-based visualization for algorithms?), then, should all that live in k4FWCore?

I think this is a slightly different concern. Just because other components depend on DD4hep as well doesn't mean they need to live in k4FWCore, we can still have them somewhere else.

In the end my main question was: Should the implementation of an interface also live where it is defined? But we already have a lot of interfaces that are defined here and only implemented in other places (many of them in k4RecCalorimeter). Given that they are defined in k4Interface I think it is OK and they are "separate enough" from the other k4FWCore components.

I think this should be documented somewhere from at least two perspectives:

• For users that want to know where a service is actually implemented (gaudiComponentHelp.py)
• For developers that should know that interfaces go to k4Interface and implementations go wherever they are needed

[tmadlener]

Similar to the discussions / decisions that we had for other interfaces, should IGeoSvc go to k4SimGeant4 (where it is implemented)?

See, e.g.

• Delete the interfaces that are only used in k4RecCalorimeter #387
• Delete the ISimG4* interface files, present in k4SimGeant4 #386