Skip to content
Snippets Groups Projects

provide tof v21a geometry

Closed Norbert Herrmann requested to merge n.herrmann/cbmroot:cbm_tof_geo_v21a into master
5 unresolved threads

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

Merge request pipeline #14653 passed

Merge request pipeline passed for dcb117eb

Approval is optional

Closed by Eoin ClerkinEoin Clerkin 3 years ago (Jan 24, 2022 10:23am UTC)

Merge details

  • The changes were not merged into master.

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
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);
  • Norbert Herrmann added 20 commits

    added 20 commits

    Compare with previous version

  • added 1 commit

    • dcb117eb - uncomment TofSimpClusterizer constructor

    Compare with previous version

  • Dear @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.

  • 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.

  • v21a_snap2

    It seems to me that there is two holes for the beampipe in the geometry. Perhaps one of the volumes has an misaligned placement.

  • the hole in the center is foreseen for the beam pipe, the bigger hole is a missing module. No idea how it happens in your case, in my case it is correct.TOF_v21a_geometry

  • 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?

  • 1 /* Copyright (C) 2021 GSI Helmholtzzentrum fuer Schwerionenforschung, Darmstadt
    2 SPDX-License-Identifier: GPL-3.0-only
    3 Authors: Norbert Herrmann [committer] */
    • 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.

    ModuleType0_v21a.dat

    ModuleType1_v21a.dat

    ModuleType2_v21a.dat

    ModuleType3_v21a.dat

    ModuleType4_v21a.dat

    ModuleType5_v21a.dat

    ModuleType6_v21a.dat

    ModuleType7_v21a.dat

    ModuleType8_v21a.dat

    ModuleType9_v21a.dat

    ModuleType10_v21a.dat

    ModuleType11_v21a.dat

    ModuleType12_v21a.dat

    ModuleType13_v21a.dat

    ModuleType14_v21a.dat

    Create_TOF_Geometry_v21a_FullWall.C

    ModulePosition_10m_v21a.dat

    tof_v21a.geo.root

    tof_v21a_geo.root

    tof_v21a.geo.info

    • The name of the corrected parameter file is "ModulePosition_10m_v21a.dat"

    • 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

      1.000000 0.000000 0.000000 Tx = 109.050003 v21a_snap4

    • Ok once I copied over the ModulePosition file then the module placement issue went away. It now seems to be correctly positioned.

      Many Thanks

      v21a_snap5

      Edited by Eoin Clerkin
    • This 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
    • Please register or sign in to reply
  • Please Ingo as author

  • Florian Uhlig changed milestone to %DEC21

    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.oldnewModulePosition_10m_v21a_new.dat

    • @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=5

      Looking 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 Clerkin
    • Hi Eoin, I think my binary is not 10 times the value. I checked that the radiation legnth of carbon is 1.87628. image

      By the way, the binaries were generated with fairsoft_apr21 and fairroot_v18.6.3_fs _apr21. The corresponding root version is ROOT 6.22/08.

    • Hi 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=6

      A 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 Clerkin
    • Hi Eoin,

      What's the unit of the radiation length? Do the two binaries have different units? Or is the difference caused by different root versions?

    • Hi 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

    • Please register or sign in to reply
  • Eoin Clerkin mentioned in merge request !667 (merged)

    mentioned in merge request !667 (merged)

  • closed

  • As discussed in SWM-20220120, datafiles in Ingo's comments above were copied into a new branch and this merge request is continued in

    !667 (merged)

  • reopened

  • closed

  • Florian Uhlig mentioned in commit bf827035

    mentioned in commit bf827035

  • Please register or sign in to reply
    Loading