provide tof v21a geometry
Update CBM TOF geometry to version v21a for Online TDR with latest version of inner wall, The number of module types is increased to 15 requiring an update of CbmTofGeoHandler which is backward compatible. The merge request is accompanied with 2 others for the geometry and the parameter file.
Merge request reports
Activity
mentioned in merge request CbmSoft/cbmroot_geometry!117 (closed)
mentioned in merge request CbmSoft/cbmroot_parameter!65 (merged)
344 344 345 345 // ----- Local reconstruction in TOF ---------------------------------- 346 346 if (useTof) { 347 CbmTofSimpClusterizer* tofCluster = new CbmTofSimpClusterizer("TofSimpClusterizer", 0); 347 // CbmTofSimpClusterizer* tofCluster = new CbmTofSimpClusterizer("TOF Simple Clusterizer", 0); 348 348 tofCluster->SetOutputBranchPersistent("TofHit", kTRUE); 349 349 tofCluster->SetOutputBranchPersistent("TofDigiMatch", kTRUE); Maybe a different view: could it be that some files were added by mistake to the MR? Such as also the files in
macro/beamtime/mcbm2021
?cf !617 (diffs)
added 20 commits
Toggle commit listDear @n.herrmann, @i.deppner, @f.uhlig, @p.-a.loizeau,
you have been identified as code owner of at least one file which was changed with this merge request.
Please check the changes and approve them or request changes.
added CodeOwners label
assigned to @p.-a.loizeau
I think the geometry files are still missing as CbmSoft/cbmroot_geometry!117 (closed) was closed.
Do we want to include the update of the geometry and parameter hashes to this MR or do we merge it even if it bring a de-correlation between macros and binary files?
@f.uhlig Side question: if we go for the second one, should I set the MR to squash? And in case of the first one do a local squash/interactive rebase as we have commit right to the branch?
OK, I have ho idea, how to do it consistenly. The root files have to be generated consistenly by the macro that is part of this merge request. The last time the root files I generated were declared not to be needed/useful for the various positions that's why I cancelled the Merge request. If somebody would tell me which type of root file to submit, I'll try to do it.
Hi Ingo,
I checked out your code/branch again, a few moments ago. Unfortunately the module is still missing.
I notice in your image that you have a double green frame surrounding the sensor body, whilst I have only a single frame. This is not a perspective issue, I do have only a single frame, or two so close together so as to make them indistinguishable.
Attached is the binary I generated on my PC. tof_v21a_1h.geo.root
Could you send me the binary you have generated, and I will compare?
According to our CAD models, when the candidate beam pipe with bellows is included, the closest placement of the ToF is 688.2 cm (732.2cm from target) from the center of the magnet when a safety margin of 5cm between bellows, trd and tof is enforced.
May I suggest we choose a placement of 690cm for the most upstream point of the ToF?
Dear Eoin, I found the problem with the missing module, its a inconsistency in the parameter file (attached is the corrected one). Actually I uploaded all files involved with v21a. In addition I shifted the two center modules by 20 cm in order to take the beam deflection into account.
Hi Ingo,
I downloaded the files into tof geometry directory and rerun your macros. Unforunately there is still a missing module. See image.
Although, I now see that the double frame is there so this is now consistent.
I note that there is a difference between the generated binary and the one supplied for download in the positing of module_10_0
1.000000 0.000000 0.000000 Tx = 129.050003
Ok once I copied over the ModulePosition file then the module placement issue went away. It now seems to be correctly positioned.
Many Thanks
Edited by Eoin ClerkinThis MR is now fine with me to be merged once the positioning of the detector is moved to 6.9 m from center of magnet as requested above. I note the generated binaries have no translation matrix attached.
Also, the code sent in the comments above will need to be copied into the local branch attached to this merge request. A "git rebase" to master followed by a "git push -f" to update the MR.
Edited by Eoin Clerkin
changed milestone to %DEC21
assigned to @e.clerkin and unassigned @p.-a.loizeau
Below is the updated module position for CBM-TOF. With this update, the beam will not directly shoot on the counters.
ModulePosition_10m_v21a_new.dat
The corresponding geometry files are also attached.tof_v21a.geo.info
@zhangqn17_AT_mails.tsinghua.edu.cn
Hi Zhang,
Thanks for the binaries. Unfortunately I find errors in your binary.
The difference I see between your binary and that which was supplied as attachment above by Ingo was in relation to the material definitions
Material aluminium A=26.98 Z=13 rho=2.7 radlen=0.887509 intlen=3.88623 index=1
< Material aluminium A=26.98 Z=13 rho=2.7 radlen=8.8751 intlen=38.8622 index=1
< Material carbon A=12.011 Z=6 rho=2.265 radlen=18.7628 intlen=35.409 index=6
Material carbon A=12.011 Z=6 rho=2.265 radlen=1.87628 intlen=3.5409 index=6
Material tof_pole_aluminium A=26.98 Z=13 rho=2.7 radlen=0.887509 intlen=3.88623 index=2
< Material tof_pole_aluminium A=26.98 Z=13 rho=2.7 radlen=8.8751 intlen=38.8622 index=2
< Mixture air Aeff=14.6873 Zeff=7.32 rho=0.001205 radlen=30422.5 intlen=70886.8 index=0
Mixture air Aeff=14.6873 Zeff=7.32 rho=0.001205 radlen=3042.25 intlen=7088.69 index=0
Mixture RPCgas Aeff=17.4875 Zeff=8.38964 rho=0.00427 radlen=798.805 intlen=2052.02 index=3
< Mixture RPCgas Aeff=17.4875 Zeff=8.38964 rho=0.00427 radlen=7988.06 intlen=20520.2 index=3
Mixture RPCgas_noact Aeff=17.4875 Zeff=8.38964 rho=0.00427 radlen=798.805 intlen=2052.02 index=4
< Mixture RPCgas_noact Aeff=17.4875 Zeff=8.38964 rho=0.00427 radlen=7988.06 intlen=20520.2 index=4
< Mixture RPCglass Aeff=22.368 Zeff=11.1529 rho=2.5 radlen=10.5375 intlen=38.6223 index=5
Mixture RPCglass Aeff=22.368 Zeff=11.1529 rho=2.5 radlen=1.05375 intlen=3.86224 index=5Looking at the radiation length of carbon, it would appear to me that Ingo's binary is correct whilst yours seem to be 10 times the value. Is there another difference expected between the two binaries?
May I ask, which version of root are you using to generate the binary? Are you using the standard supplied for cbmroot? I've seen this before but would appreciate it if you share how this error occurred in your binary.
Edited by Eoin ClerkinHi Qiunan,
Yes, my mistake. I mixed up yours and Ingos binary. Your binary was correct, whilst Ingo's had the over calculation. I simply compared the two.
Material carbon A=12.011 Z=6 rho=2.265 radlen=1.87628 intlen=3.5409 index=6
Material carbon A=12.011 Z=6 rho=2.265 radlen=18.7628 intlen=35.409 index=6A default binary tof_v22a binary for the electron, muon, and hadron setups is available in MR CbmSoft/cbmroot_geometry!128 (merged) which will be merged if not objections come.
Edited by Eoin ClerkinHi Qiunan,
Yes it is suspected that there is a difference from going from cm to mm. Yes, different root seem to have different default behavior regarding this. Of course this can be overridden
TGeoManager::LockDefaultUnits(kFALSE); TGeoManager::SetDefaultUnits(TGeoManager::EDefaultUnits::kRootUnits);
The volume and not the manager is imported into cbmroot.
BR Eoin
mentioned in merge request !667 (merged)
mentioned in merge request CbmSoft/cbmroot_geometry!128 (merged)
As discussed in SWM-20220120, datafiles in Ingo's comments above were copied into a new branch and this merge request is continued in
mentioned in commit pwg-c2f/cbmroot@9f4792bb
mentioned in commit bf827035
mentioned in commit fweig/cbmroot@06201565