Apply z = +7.0 cm shift to mSTS for survey of Juli 2021 run 1588, refs #2413
Merge request reports
Activity
- Resolved by David Emschermann
@f.uhlig For this MR we need the following 3 files in input/geometry_check:
sts_v22a_mcbm_geometrycheck.root sts_v22b_mcbm_geometrycheck.root sts_v22c_mcbm_geometrycheck.root I do not know how to generate these files. Could you please help?
enabled an automatic merge when the pipeline for ba5f2411 succeeds
enabled an automatic merge when the pipeline for b2be6876 succeeds
this time the test fails correctly. There is something strange with the media
Medium for /cave_1/sts_v22c_mcbm_0/Station01_1/Ladder09_1/HalfLadder09d_2/HalfLadder09d_Module03_1/Sensor03_1/ is wrong. Expected: silicon Found : vacuum Medium for /cave_1/sts_v22c_mcbm_0/Station01_1/Ladder09_1/HalfLadder09d_2/HalfLadder09d_Module03_2/Sensor03_1/ is wrong. Expected: silicon Found : vacuum Medium for /cave_1/sts_v22c_mcbm_0/Station01_1/Ladder09_2/HalfLadder09d_2/HalfLadder09d_Module03_1/Sensor03_1/ is wrong. Expected: silicon Found : vacuum Medium for /cave_1/sts_v22c_mcbm_0/Station01_1/Ladder09_2/HalfLadder09d_2/HalfLadder09d_Module03_2/Sensor03_1/ is wrong. Expected: silicon Found : vacuum Medium for /cave_1/sts_v22c_mcbm_0/Station02_2/Ladder10_1/HalfLadder10d_2/HalfLadder10d_Module03_1/Sensor03_1/ is wrong. Expected: silicon Found : vacuum Medium for /cave_1/sts_v22c_mcbm_0/Station02_2/Ladder10_2/HalfLadder10d_2/HalfLadder10d_Module03_1/Sensor03_1/ is wrong. Expected: silicon Found : vacuum Medium for /cave_1/sts_v22c_mcbm_0/Station02_2/Ladder11_3/HalfLadder11d_2/HalfLadder11d_Module03_1/Sensor03_1/ is wrong. Expected: silicon Found : vacuum Medium for /cave_1/sts_v22c_mcbm_0/Station02_2/Ladder11_3/HalfLadder11d_2/HalfLadder11d_Module03_2/Sensor03_1/ is wrong. Expected: silicon Found : vacuum Medium for /cave_1/sts_v22c_mcbm_0/Station02_2/Ladder11_3/HalfLadder11d_2/HalfLadder11d_Module03_3/Sensor03_1/ is wrong. Expected: silicon Found : vacuum
I have investigated on the media error reported by @f.uhlig : It occurs with all 3 STS v22[a,b,c] geometries, however not with v20e. The v22a adds a set of aluminum plates to v20e. For now I do not understand how this can impact on the sensor types. As workaround I might derive the v22c directly from v20e, which should not introduce that vacuum error.
It is even worse: I regenerated the binary for STS v20e with
root -l create_stsgeo_v20e.C
I copy the resulting binaries to geometry/sts.
Then I run a transport simulation:
root -l mcbm_transport.C
When I then run the media check, I get:
root -l ../geometry/check_media.C\(\"data/test\"\) ... Checking node pipe_v19f_0 Checked 16 sub nodes from pipe_v19f_0 and found 0 with wrongly assigned media Checking node sts_v20e_mcbm_0 Medium for /cave_1/sts_v20e_mcbm_0/Station01_1/Ladder09_1/HalfLadder09d_2/HalfLadder09d_Module03_1/Sensor03_1/ is wrong. Expected: silicon Found : vacuum Medium for /cave_1/sts_v20e_mcbm_0/Station01_1/Ladder09_1/HalfLadder09d_2/HalfLadder09d_Module03_2/Sensor03_1/ is wrong. Expected: silicon Found : vacuum Medium for /cave_1/sts_v20e_mcbm_0/Station01_1/Ladder09_2/HalfLadder09d_2/HalfLadder09d_Module03_1/Sensor03_1/ is wrong. Expected: silicon Found : vacuum Medium for /cave_1/sts_v20e_mcbm_0/Station01_1/Ladder09_2/HalfLadder09d_2/HalfLadder09d_Module03_2/Sensor03_1/ is wrong. Expected: silicon Found : vacuum Medium for /cave_1/sts_v20e_mcbm_0/Station02_2/Ladder10_1/HalfLadder10d_2/HalfLadder10d_Module03_1/Sensor03_1/ is wrong. Expected: silicon Found : vacuum Medium for /cave_1/sts_v20e_mcbm_0/Station02_2/Ladder10_2/HalfLadder10d_2/HalfLadder10d_Module03_1/Sensor03_1/ is wrong. Expected: silicon Found : vacuum Medium for /cave_1/sts_v20e_mcbm_0/Station02_2/Ladder11_3/HalfLadder11d_2/HalfLadder11d_Module03_1/Sensor03_1/ is wrong. Expected: silicon Found : vacuum Medium for /cave_1/sts_v20e_mcbm_0/Station02_2/Ladder11_3/HalfLadder11d_2/HalfLadder11d_Module03_2/Sensor03_1/ is wrong. Expected: silicon Found : vacuum Medium for /cave_1/sts_v20e_mcbm_0/Station02_2/Ladder11_3/HalfLadder11d_2/HalfLadder11d_Module03_3/Sensor03_1/ is wrong. Expected: silicon Found : vacuum Checked 306 sub nodes from sts_v20e_mcbm_0 and found 9 with wrongly assigned media Checking node rich_v21a_mcbm_0 ...
@f.uhlig @e.clerkin So the problem is not with the STS geometry macros. It is somewhere else.
My system is a:
$ echo $SIMPATH /opt/cbm/fairsoft_apr21p2_root6/installation $ echo $FAIRROOTPATH /opt/cbm/fairroot_v18.6.7-fairsoft_apr21p2_root6
The media in the original geometry file are always okay. The problem appears when we combine the cbm setup from several separate geometry files.
This is the same problem we had before and why we added the check. This check should ensure that we do not reintroduce the problem again. I have to check what the problem was and how we fixed it after we found it.
I looked into the issue and meanwhile found out what the problem is.
So the problem is not with the STS geometry macros. It is somewhere else.
This statement is only half true. The macro is okay but unfortunately creates three different files.
- sts_v22c_mcbm_geo.root which contains the full TGeoManager
- sts_v22c_mcbm.geo.root which contains the top volume written to the file using top->Write()
- sts_v22c_mcbm-geo.root which contains the sts volume exported to the file using the Export function plus the additional matrix to place the volume
In don't understand why all three versions are created and more important why the correct file is named sts_v22c_mcbm-geo.root but unfortunately you copied file 2. Not using the Export function to store the volume in a file results in the observed problems of changed materials.
You can see in the output of the simulation run if the volume is stored in the file correctly. In case the Write function was used the output is
Constructing STS geometry from ROOT file
In the correct case it is
Importing STS geometry from ROOT file
I will update the macro such that only one file is created, the proper unit system is used and the additional needed file for the media check is generated automatically.
The related MR is !709 (merged)
As it seems to lead to different printout in the simulation, can we do a test to check the existing geometry files and know if they have to be regenerated? or is this something which happened only for this geometry?
(I think I remember that at some point for TOF we also had to rename the files of 3. to the name of 2., then we made it so 3. was the default to avoid this step)
- Resolved by David Emschermann
I confirm the same problem.
In case there is some connection "check_overlaps.C" reports overlap in setup_mcbm_2021_07_surveyed between the pipe_v19f/vacu20 and tof_v21d_mcbmStand_1/module_5 ovlp 9.1455 I will make a redmine issue.
Nevertheless I comment out the tof, confirm there are now no overlaps in setup_mcbm_2021_07. I check the material in sts_v22c_mcbm, the sensor material is a vacuum still, so this is probably unrelated.
added 9 commits
Toggle commit listDear @f.uhlig,
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