Package Naming and location

[madbaron]

I believe the package grew beyond the scope of the name it was initially assigned.

I think (?):

• the Muon in the name refers to Muon Collider, but there's nothing specific of muon colliders in the actual algorithms
• the package can digitise also macropixels and strips(?) - so the VXD is somewhat restrictive

Perhaps it should be renamed to "RealisticSiliconTrackerDigitiser"? Or something like that?

I would also love to move this (more spefically, its gaudi port that should be merged here https://github.com/spg-berkeleylab/MuonCVXDDigitiser/tree/K4FWC) under the key4hep project as I think it deserves a wider exposure.

Tagging a few people to collect opinions @spagangriso @tmadlener @pandreetto

[spagangriso]

Hi Federico.
I completely agree on all points. Let me tag @angirar who has been mostly editing the repo lately in addition to @samf25 who did the migration to Gaudi.
Simone

[angirar]

Hi Federico and Simone,

Indeed I agree on the naming convention since this is quite a generic implementation for realistic digitization with planar geometry. And yes, it would be great if we can move the digitizer in the Key4Hep project so that it can be easily used with the mucol images! I also want to point out that this branch (https://github.com/spg-berkeleylab/MuonCVXDDigitiser/tree/K4FWC) needs to be synced with the current master branch of the parent repo (spg-berkeleylab/MuonCVXDDigitiser@K4FWC...MuonColliderSoft:MuonCVXDDigitiser:master), and also we should merge the changes on the multiple scattering implementation from Juliette which is pending in this PR - #16

Finally, Sam also prepared digi steering scripts which can switch between simplified vs realistic digitization and currently they are sitting here - https://github.com/samf25/mucoll-benchmarks/tree/real_digi/digitization
It would be great if we can also put them in the official mucoll-benchmarks repo.

I am currently working with a student using this Gaudi-implementation and would love to help in streamlining these tools. Let me know what your plan is!

[madbaron]

Hi @angirar,

Here's how I would propose to proceed:

1. it would be great if you could merge any outstanding PRs and make the main branch of this package the "ultimate" Marlin version.
2. we make a tag out of main - mostly for archival purposes
3. we port the package to gaudi (which likely means picking Sam's work + any missing features from the PRs at point 1 )
4. we rename the repository and do a little clean up of algorithm names to be consistent
5. we transfer the gaudified repository to key4hep

Since release 3.0, the digi/reco steering files have become detector concept-specific (mucoll-benchmarks could not fit all anymore with generic macros without major gymnastics).
It would be great if the digitisation updates / options could be put in PRs to https://github.com/MuonColliderSoft/MAIAConfig, https://github.com/MuonColliderSoft/MuCollConfig and https://github.com/MuonColliderSoft/MuSICConfig

• Made an initial PR to schedule the digitisers in Enable scheduling of realistic digi MAIAConfig#35

[tmadlener]

Sorry for being late to this one. I can't contribute many new things. I agree with the plan of @madbaron.

Regarding naming things, we had some discussion about this in the Key4hep meeting on Mar 31 (relevant notes). The relevant parts for this discussion are

• names should be descriptive of what they do, resp. the technology rather then tied to (sub)detector names
• overly generic names like default, detailed or realistic should be avoided as they are too open to interpretation
• If applicable algorithms can also be versioned (similar to the detector geometries) if breaking changes (physics or API wise) are considered unacceptable

(I don't have an immediate suggestion for a name here though)

For final placement we would probably like to put this into an existing repository unless there is a really compelling reason to have a new one. We can keep the relevant git history of things when lifting / moving things with some tools.

[madbaron]

Where would you move the algorithms to?

I know there's a paper coming out soon (?) about work done with this package, so it may be nice to make sure the pointers are in synch, rather than having this work disappear into a few classes in something else, but I think @spagangriso and @angirar should be the ones commenting here.

[tmadlener]

Currently most of the tracking digitizers either already live in https://github.com/key4hep/k4RecTracker or aim at being moved to there.

[angirar]

Hi @madbaron and @tmadlener It should be fine to move the package to the key4hep location pointed above. I think I need to iron out a few things left in the code which are hardcoded with certain mucol geometry assumptions so that it can be generically used by anyone.
I have pulled all other changes already (the Marlin version) and created a draft PR here - #18. Will clean up rest of the things shortly.