[IDEA] Adding the detailed version of the muon system.

[mahmoudali2]

BEGINRELEASENOTES

• Define the first draft of the detailed muon system, which depend on mosaics of 50 * 50 cm^2 mRWELL chambers.
• Define a suitable XML for the new detailed version.
• Describe µRWELL materials.
• Add the parameters of the muon system into the full IDEA implementation.

ENDRELEASENOTES

[BrieucF]

Hi Mahmoud, thanks a lot for this! Here are already a few comments. Can you also try to run the overlap check?

create a geant4 macro named overlap.mac with this inside:
/geometry/test/run
exit

Then run the overlap checker with this: 
ddsim --compactFile ./compact/simple_detector.xml --runType run --part.userParticleHandler='' --macroFile overlap.mac >> overlapDump.txt

[BrieucF]

I propose to remove references to IDEA in this README, the detector builder is quite generic and could be used for other implementation. e.g. IDEA Muon System --> µRWELL Based Muon System

[mahmoudali2]

Hi Brieuc, I have edited the code after checking all the overlaps, and now it's clean.. I'm attaching the overlapDump file.
overlapDump-151.txt

[BrieucF]

Here and in other places: the "id" should be defined in DectDimensions_IDEA_o1_v01.xml and called here (see and modify

k4geo/FCCee/IDEA/compact/IDEA_o1_v02/DectDimensions_IDEA_o1_v01.xml

Line 43 in a02cbb4

<constant name="DetID_Yoke_Barrel" value=" 13"/>

)

[BrieucF]

I also suspect this should crash as it is now (did you try running it with ddsim?) because we have 4 bits for system in the readout which only allows to have "id's" from 0 to 15.

[mahmoudali2]

I added the 9 muon system layers IDs to the DectDimensions_IDEA_o1_v01.xml, and ddsim run without crashes even if the system has 4 bits. Isn't the 4 bits in that case only for the muon system, since for example I have here 9 detectors (layers)? since also every sub-detector has its own readout description?

[mahmoudali2]

New modification in the builder and the compact file to avoid all the overlap cases, I have introduced a new way to organize the different sides in the same layer, the following photo (X-Y plane) is an example for barrel sides overlapping and avoiding touching each others:

The same in encap, with creating unusual shapes by boolean operations UnionSolid (The only solution I got to solve the overlap with the mother volume):

...
And every layer (1 detector layer + 1 yoke layer "if present") has an independent mother volume in the shape of Polyhedra to avoid overlapping with each other:

....
Overall the complete muon system:

[BrieucF]

Hi Mahmoud, this is fantastic! Tahnks! Here is a first batch of comment.
Can you also update FCCee/IDEA/compact/README.md under IDEA_o1_v02 with something like:
"Based on o1_v01 but with a detailed description of the vertex detector, drift chamber and muon system, a place holder solenoid and the endplate absorber. Missing: SiWrapper, calorimeter."?

I am also a bit puzzled by the fact of having one detID per layer but I guess having one detID for the whole barrel and one for the whole endcap would imply a complete refactoring of the code?

[andresailer]

This /4.5 seems awfully fine-tuned? Or is this OK also for other thinknesses?

[mahmoudali2]

Hi @andresailer, I have changed the parameters, and now it is OK with other thicknesses to. Whatever the chamber dimensions the user will put in the compact file, It will work. I have made the variable detectorVolumeThickness is determined by the builder depending on the chamber dimensions and the overlap angle, instead before it was determined by the user.

[andresailer]

Maybe it makes sense to split this into a barrel and an endcap constructor?

[mahmoudali2]

Since the barrel last layer is enclosing all the endcap layers inside, we preferred to keep them in the same builder. Both Barrel and Endcap are sharing some common variables like numSides of the main polygon shape. and the length of the last layer of the barrel depending on the total thickness of the endcap detector. And to distinguish between the collection hits of barrel and endcap, a bit-field component has been defined. Maybe we might tend to separate them in the future if needed.

[andresailer]

Is this 1.5 factor always correct?

[mahmoudali2]

Yes, since the detector volume was centered in the 0.25 of the thickness of that volume. But I have also changed it in the new commits, and I centered it in the middle instead.

[andresailer]

What does the 2 signify?

[mahmoudali2]

It's coming from the formula to calculate the polygon side length Side Length a. a = 2r tan(π/n).

[mahmoudali2]

If you mean the number 2 in sideLength2 and other variable as well, that represents here the trapezoid's parallel sides lengths. just to distinguish between the two sides lengths.

[andresailer]

Sorry, yes I mean the 2 in sideLength2, can you please add what you wrote as a comment.

[mahmoudali2]

Done, I Have added the comments.

[mahmoudali2]

Thanks @BrieucF and @andresailer for your comments,
I have refactored all the builder, and here are the main updates:

• Looping over layers, which led to having all the muon-system layers represented by just one detector in the xml.
• Decreasing the number of parameters inserted by the user --> that made the code more automized and made the xml smaller and simpler.
• Refactoring the bit-field of the muon-system, and having all the muon hits in one collection called MuonSystemcollection, and you can distinguish between the barrel hits and the endcap hits by their different bit field section type if type = 0 --> Barrel Hits, if type = 1 --> Positive Endcap Hits, and type = -1 --> Negative Endcap Hits.
• The ability to make multiple layers and still the last barrel layer will enclose all the endcap layers inside.
  Let me know if you have any more comments.

[BrieucF]

Suggested change

	<id>system:5,type:2,layer:4,chamber:15,slice:1,y:-10,z:-10</id> <!-- The bit field is divided into 2^5 systems(IDEA sub-detectors), 2^2 types(Barrel Muon System, positive endcap, and negative endcap"), 2^4 layers(number of layers in barrel for example) ,2^15 chambers(the number of muRWELL chambers in every layer), 2^1 slice(number of sensitive layers inside every chambers), and 2^10 y&z strips in every sensitive layer-->
	<id>system:5,type:2,layer:4,chamber:15,slice:1,y:-10,z:-10</id> <!-- The bit field is divided into 2^5 systems(IDEA sub-detectors), 2^2 types(0 = Barrel Muon System, +1 = positive endcap and -1 = negative endcap"), 2^4 layers(number of layers in barrel for example) ,2^15 chambers(the number of muRWELL chambers in every layer), 2^1 slice(number of sensitive layers inside every chambers), and 2^10 y&z strips in every sensitive layer-->
	```?
	I'd also propose to change `type` to `side`, but it is not a strong request.

[mahmoudali2]

I'm afraid using side instead of type would cause confusion with the detector side variable that I use to determine the polygon shape sides.

[BrieucF]

Ok! But can you still say in the xml which value is given to barrel/endcap etc?

[mahmoudali2]

Yes, I just added it in the last commit

[atolosadelgado]

Are these materials still needed?

[mahmoudali2]

Yes, it's the material of the uRWELL.

[atolosadelgado]

maybe a cylinder would be more performant?

[mahmoudali2]

Cylinder will cause overlaps with different layers, and sub-detectors before the muon-system (in our case is DR-Calo).

[atolosadelgado]

maybe a cylinder would be more performant?

[atolosadelgado]

maybe a cylinder would be more performant?

[atolosadelgado]

to avoid confusion I would suggest to work on angle natural units of dd4hep. In addition, conversion of deg <-> rad can be done using ROOT factosTMath::DegToRad()

[atolosadelgado]

Overall it is good, here are minimal comments, @BrieucF can tell if they can be ignored :)

• typo: CarnonFiber :)

• Is there a real need of defining the following materials? G4_Fe, G4_Si0x56335d3d1480, Ca400x5633439c2580, ... G10_FR40x5633439ca570. These materials are introduced in this PR, lines 490-645 of the material XML file
  https://github.com/key4hep/k4geo/blob/931d8d1e96ac5f05e8239db4c2319207f11741f4/FCCee/IDEA/compact/IDEA_o1_v02/materials_o1_v01.xml

• would it be possible to the replace the union solids that make up the envelopes by cylinders for example?

[BrieucF]

I'd say the baseline is to implement them all :-P if some are causing problems or require significant change we de-discuss ;-)

[mahmoudali2]

Hi @atolosadelgado , Thanks very much for your comments, here are some clarifications;

• For the materials you mentioned in IDEA V02, it's now removed. I have removed all updates on muon-system from the V02, and just added it to V03. Also no more hex-names, but G4_Fe is needed for the yokes.
• Replacing union solids with cylinders will cause overlaps between the muon-system and other sub-detectors especially the DR-Calo. the idea of using union solid is to combine the different layers mother volumes together since there is no specific shapes that can describe the MS-barrel which is combination of two different polyhedra with different z-lengths(photo attached).

The same case for all the muon-system, which is 3 combinations of 3 different polyhedra:

[atolosadelgado]

Hi @atolosadelgado , Thanks very much for your comments, here are some clarifications;

* For the materials you mentioned in IDEA V02, it's now removed. I have removed all updates on muon-system from the V02, and just added it to V03. Also no more hex-names, but G4_Fe is needed for the yokes.

* Replacing union solids with cylinders will cause overlaps between the muon-system and other sub-detectors especially the DR-Calo. the idea of using union solid is to combine the different layers mother volumes together since there is no specific shapes that can describe the MS-barrel which is combination of two different polyhedra with different z-lengths(photo attached).

The same case for all the muon-system, which is 3 combinations of 3 different polyhedra:

I had a chat with Brieuc, and these are minor comments which can be ignored

[BrieucF]

Thanks a lot Mahmoud, and congratulations!
To be investigated for v02:

• use assembly instead of union
• understand if we need all the extra material definition (e.g. redefining the isotope content of Calcium)