I was wondering the following thing: I am trying to make a Geometry of a bunch of 2S Modules (see: Prototyping and qualification of 2S modules for the CMS Outer Tracker upgrade at the HL-LHC - CERN Document Server) in series. The point is: that the 2S Module is comprised of two so-called “hybrids”, each of which is comprised of a seed sensor and a correlated sensor, with some separation between them. Thus, a single 2S module has 4 sensors that define it. Needless to say, it is a bit cumbersome to define a geometry:
How can I define a “Module” in Allpix; that is comprised of a specific arrangement of sensors? has something like this been implemented yet? The configuration file above is not an issue when the Euler Angles are all zero; it becomes an issue when they are not … I have created a script that does all of the rotations with Eigen, but was wondering if anything existed already in Allpix.
I think the short answer is that these functionalities are not implemented or foreseen in Allpix Squared so far. Each detector is treated completely agnostic of all others. We’ve heard of a small number of people struggling with this issue (e.g. @drastorg , @mcaspar ), see also this presentation, Slide 16. I think that for the moment scripting the geometry is the best option from a user perspective.
Alternatively it could be implemented in the framework, and we would have to wrap the detector descriptions with a DetectorModule description and define multiple detectors per DetectorModule. This is possible, but requires quite some implementation work and at this point in time there’s no effort into that direction. We would be happy for any contribution or suggestion, though!
one thing we could think about is to re-use the role parameter we introduced. For now it is only used to mark geometry objects as passive, but in principle we could also add new keywords, e.g. tracking to follow another detector in orientation et cetera? @pschutze how do you liekt he idea? It would then mean we interpret the provided coordinates relative to the tracked model instance in the geometry:
[my_first_sensor]
orientation = 0 0 -20urad
position = 3mm 2mm 10cm
[my_second_sensor]
role = "tracking"
tracked_detector = my_first_sensor
orientation = 0 0 +40urad
position = 0 0 3mm
could then mean that the second sensor is rotated with respect to the first bu 40urad and offset in z by 3mm. The biggest difficulty here I see from an “understanding the geometry when reading the file” is that we are mixing local and global coordinates in the same parameters.
Apart from that, @Andrew at elast for the different hybrids I would model them as one detector - the sensor volume about which we care most is the same as far as I understand your detector correctly. The splitting in hybrids in only a result of the electrical schematics and the actual readout chips - so it affects the “channel id” but not the local coordinates of the sensor.
this would be one approach that would be working and fairly easy to implement, but in my eyes is a bit counter intuitive. a) it’s the mixing of local and global parameters in one config file and b) the origin of a detector module would always be one sensor.
Another option, probably more tricky to implement, would be having a role module in the main config file:
[2S_00001]
role = "module"
type = "2S"
position = 0 0 150mm
orientation = 0 2deg 0
and then another file 2S.conf, similar to the detector models, describing the module:
[bottom]
type = "2S_strips"
position = 0 0 200um
orientation = 0 0 0
[top]
type = "2S_strips"
position = 0 0 4200um
orientation = 0 0 40urad
from which you could then generate the sensitive volumes 2S_00001_bottom and 2S_00001_top.
I consider this to be more elegant, also for the reason that you can have several module of the same type by just defining them once.
indeed, my suggestion has severe shortcomings in terms of usability. I oike your suggestion but it would essentially mean yet another layer of config files:
main → geometry → module → model
Then to me that would immediately pose the questions
If we’re at it, why not make it recursive, such that we can have a module built of modules?
Is there a better way than calling it a “module”? That’s already taken in the framework lingo.
Do we rework histogram generation such that detectors of the same “module” get put into a common subfolder for easier grouping? How to do this in the ROOT output files and the contained configuration copy?
You would still have some config files with local and some with global coordinates I guess?
but it would essentially mean yet another layer of config files:
main → geometry → module → model
Indeed, but the third one would be optional and only kick in in case there is a role = "module".
Otherwise, delicious food for thought, thank you
Recursion? You’d like to create a module of modules of modules of modules? Not sure whether this is actually needed, it sounds a bit overkill to me. Although, you could build a full tracker with a lot less configurations indeed… Would you expect it be a lot of overhead in terms of implementation?
There is none, but we need to find one, module indeed is taken. I will think about it. assembly could be one option…
Huh.
3.1. I would say that grouping histograms is not a requirement, but of course grouping these and on second-order also generating module-internal plots in the DetectorHistogrammer (e.g. hits per module per event) could be helpful.
3.2. Mmh good question. The configuration copy could hold the information on individual sensors instead of modules if that would be easier. I don’t think that this necessarily needs to be folded back into the module->model hierarchy.
Yep, but that’s not a new situation: the model file is local, the geometry file is global.
Not possible for DetectorHIstogrammer unless we completely rework how modules are instantiated. They are either global or attached to a single detector.
Right, then we would be back to one global geometry with all-global coords, right? Should be compatible though.
I’d highly support a single overhead level over recursion, it seems much cleaner at least from the user side.
DetectorGroup? It’s a bit too generic, but still reflects the essence and does not create ambiguity.
What if instead of introducing another internal level of abstraction in the architecture we make it work only on the configuration stage? (like it works for misalignment). Thus, the Detector class just gets an additional field, could even just be std::string group. This will lead to ambiguity in detector names, as then we need a pair (group, name) as detector’s UID (alternatively just override its name to "groupname_detectorname"). Then the whole concept of DetectorGroup boils down to two things: recalculating/assigning coordinates on configuration and then setting proper paths in the output files if group for a given detector is non-zero.
I like this:
and then another file 2S.conf , similar to the detector models, describing the module:
Thank you for all of your responses. I am a first year PhD student and my work is not urgent at the moment, so I would love to chip in and get involved with this. I am acquainted with the allpix hierarchy and I have compiled versions of mine in the past, but I will definitely need some guidance. Would it be a good idea to organize a bit for this?
I oike your suggestion but it would essentially mean yet another layer of config files: