Project

General

Profile

Actions

Development #1649

closed

Create box around STS v19r and commit STS geometries v19h and v19i to the trunk

Added by David Emschermann about 2 years ago. Updated 4 months ago.

Status:
Closed
Priority:
Normal
Target version:
Start date:
04/15/2020
Due date:
% Done:

100%

Estimated time:
30.00 h (Total: 33.00 h)
Spent time:
13.80 h (Total: 24.00 h)

Description

A STS geometry called v19h was derived from v19d and placed at the correct z position (40 mm upstream).
The v19h consists of units only (no box).

The surrounding box should be added by Evgeny in STS v19i.

This v19i can later be used for performance studies with the 105 mm pitch STS.

Since the trunk is still not writeable for normal users, Florian Uhlig should commit STS v19h and v19i upon completion.


Files

v19h_z0260.png (36.2 KB) v19h_z0260.png STS v19h position of 1st station David Emschermann, 03/26/2020 05:44 PM
v19h_z0995.png (36.2 KB) v19h_z0995.png STS v19h position of last station David Emschermann, 03/26/2020 05:44 PM
create_stsgeo_v19i.C (98.3 KB) create_stsgeo_v19i.C Evgeny Lavrik, 03/27/2020 03:08 PM
v19i_z0260.png (28.4 KB) v19i_z0260.png STS v19i position of 1st station David Emschermann, 03/27/2020 08:01 PM
v19i_z0995.png (28.4 KB) v19i_z0995.png STS v19i position of last station David Emschermann, 03/27/2020 08:01 PM
sts_v19a_targetbox_xz_plane.png (164 KB) sts_v19a_targetbox_xz_plane.png David Emschermann, 03/31/2020 04:39 PM
sts_v19i_targetbox_xz_plane.png (177 KB) sts_v19i_targetbox_xz_plane.png David Emschermann, 03/31/2020 04:39 PM
sts_v19a_targetbox_yz_plane.png (109 KB) sts_v19a_targetbox_yz_plane.png David Emschermann, 03/31/2020 04:39 PM
sts_v19i_targetbox_yz_plane.png (147 KB) sts_v19i_targetbox_yz_plane.png David Emschermann, 03/31/2020 04:39 PM
sts_v19a_beampipe_kink.png (68.2 KB) sts_v19a_beampipe_kink.png David Emschermann, 03/31/2020 04:39 PM
sts_v19i_beampipe_kink.png (69 KB) sts_v19i_beampipe_kink.png David Emschermann, 03/31/2020 04:39 PM
sts_inner_part.png (11.7 KB) sts_inner_part.png Carbon ladder parts removed from inner region David Emschermann, 03/31/2020 09:51 PM
sts_v19a_box_missing_cutout_front.png (49.7 KB) sts_v19a_box_missing_cutout_front.png David Emschermann, 03/31/2020 09:52 PM
sts_v19i_box_missing_cutout_front.png (48.2 KB) sts_v19i_box_missing_cutout_front.png David Emschermann, 03/31/2020 09:52 PM
sts_v19a_box_missing_cutout_back.png (29 KB) sts_v19a_box_missing_cutout_back.png David Emschermann, 03/31/2020 09:52 PM
sts_v19i_box_missing_cutout_back.png (30.1 KB) sts_v19i_box_missing_cutout_back.png David Emschermann, 03/31/2020 09:52 PM
sts_v19i_260.png (88.2 KB) sts_v19i_260.png David Emschermann, 03/31/2020 10:18 PM
sts_v19i_470.png (88.2 KB) sts_v19i_470.png David Emschermann, 03/31/2020 10:18 PM
sts_v19i_995.png (88.2 KB) sts_v19i_995.png David Emschermann, 03/31/2020 10:18 PM
sts_passive_v19i.gdml (132 KB) sts_passive_v19i.gdml Evgeny Lavrik, 04/01/2020 11:27 AM
sts_v19i_box_cutout_front.png (65.6 KB) sts_v19i_box_cutout_front.png David Emschermann, 04/02/2020 01:57 PM
sts_v19i_box_cutout_back.png (36.4 KB) sts_v19i_box_cutout_back.png David Emschermann, 04/02/2020 01:57 PM
sts_v19i_box_cutout_front_zoom.png (93.1 KB) sts_v19i_box_cutout_front_zoom.png David Emschermann, 04/02/2020 01:57 PM
sts_v19i_box_cutout_back_zoom.png (40.1 KB) sts_v19i_box_cutout_back_zoom.png David Emschermann, 04/02/2020 01:57 PM
sts_v19i_frontpanel_looking_upstream.png (21.7 KB) sts_v19i_frontpanel_looking_upstream.png David Emschermann, 04/02/2020 01:57 PM
StsThrough.png (23.2 KB) StsThrough.png Evgeny Lavrik, 04/03/2020 10:14 AM
StsThrough2.png (44.6 KB) StsThrough2.png Evgeny Lavrik, 04/03/2020 10:16 AM
z_p00_sts_v19a_target.png (59.9 KB) z_p00_sts_v19a_target.png Target position with STS v19a David Emschermann, 04/20/2020 04:04 PM
z_p08_sts_v19a_mvd_v17a_tr.png (59.9 KB) z_p08_sts_v19a_mvd_v17a_tr.png MVD station 1 position with STS v19a David Emschermann, 04/20/2020 04:04 PM
z_p20_sts_v19a_mvd_v17a_tr.png (59.9 KB) z_p20_sts_v19a_mvd_v17a_tr.png MVD station 4 position with STS v19a David Emschermann, 04/20/2020 04:04 PM
z_m04_sts_v19i_target.png (57.8 KB) z_m04_sts_v19i_target.png Target position with STS v19i David Emschermann, 04/20/2020 05:58 PM
z_p08_sts_v19i_mvd_v17a_tr.png (57.8 KB) z_p08_sts_v19i_mvd_v17a_tr.png MVD station 1 position with STS v19i David Emschermann, 04/20/2020 05:58 PM
STS_v19i_with_MVD_v17b_tr.png (93.9 KB) STS_v19i_with_MVD_v17b_tr.png STS v19i with MVD v17b tr David Emschermann, 04/22/2020 08:23 PM
sts_passive_v19i.gdml (132 KB) sts_passive_v19i.gdml Evgeny Lavrik, 05/29/2020 11:20 AM
sts_v19i_box_overlap.png (54.4 KB) sts_v19i_box_overlap.png David Emschermann, 05/29/2020 08:48 PM

Subtasks 1 (0 open1 closed)

Support #1681: Dump and check all sensor positions in STS geometry v19h / v19i / v19j / v19k / v19l / v19mClosedOleg Vasylyev04/15/2020

Actions

Related issues

Related to CbmRoot - Support #1600: Please commit geometry filesClosedDavid Emschermann03/11/2020

Actions
Related to CbmRoot - Support #1690: Create a MVD geometry which is shifted 40 mm upstreamClosedDavid Emschermann04/20/2020

Actions
Related to CbmRoot - Bug #1694: Fix positioning of exported beam pipes with a non-zero translationClosedFlorian Uhlig04/22/2020

Actions
Related to CbmRoot - Support #1698: Check exported STS v19j versus written STS v19a geometryClosedDavid Emschermann04/27/2020

Actions
Related to CbmRoot - Support #1737: Provide box for STS v19r geometry ClosedMehul Shiroya05/27/2020

Actions
Actions #1

Updated by David Emschermann about 2 years ago

Actions #3

Updated by David Emschermann about 2 years ago

As the CbmRoot trunk is not available for writing, I have placed the STS geometry creation macros here:
Actions #4

Updated by David Emschermann about 2 years ago

Evgeny, please get the create_stsgeo_v19i.C, place it in your local trunk/macro/sts/geometry and modify the xml file accordingly.

The STS station z-positions in v19i are z = 260; 365; 470; 575; 680; 785; 890; 995 mm.

Actions #5

Updated by David Emschermann about 2 years ago

  • % Done changed from 0 to 10
  • Estimated time changed from 0.50 h to 2.00 h
Actions #6

Updated by Evgeny Lavrik about 2 years ago

Done, see attachment

Actions #8

Updated by David Emschermann about 2 years ago

  • Assignee changed from David Emschermann to Florian Uhlig

Thank you Evgeny!

Florian, could you please commit the following 3 files:

  1. to macro/sts/geometry
    http://cbm.uni-muenster.de/cbmroot/more/sts_v19h_105mm/create_stsgeo_v19h.C
    http://cbm.uni-muenster.de/cbmroot/more/sts_v19h_105mm/create_stsgeo_v19i.C
  2. to geometry/sts/passive
    http://cbm.uni-muenster.de/cbmroot/more/sts_v19h_105mm/sts_passive_v19i.gdml

You can also generate a STS v19i geometry and commit it to the trunk. Thanks!

Actions #9

Updated by Florian Uhlig about 2 years ago

  • Assignee changed from Florian Uhlig to Evgeny Lavrik
  • % Done changed from 100 to 90

When trying to create the geometry I get the following warnings. Could you please let me know if this is expected or if these warninge have to be taken seriously.

===> Creating STS....
Info in <TGDMLParse::TGDMLParse>: Re-use existing material: STSBoxCarbonFibre
Info in <TGDMLParse::TGDMLParse>: Re-use existing material: STSBoxCarbonFoam
Info in <TGDMLParse::TGDMLParse>: Re-use existing material: air
Medium: aluminium, Not Yet Defined!
Medium: aluminium, Not Yet Defined!
Medium: aluminium, Not Yet Defined!
Medium: aluminium, Not Yet Defined!
Medium: aluminium, Not Yet Defined!
Medium: aluminium, Not Yet Defined!
Medium: aluminium, Not Yet Defined!
Medium: aluminium, Not Yet Defined!
Medium: aluminium, Not Yet Defined!
Medium: aluminium, Not Yet Defined!
Medium: aluminium, Not Yet Defined!
Medium: aluminium, Not Yet Defined!
Medium: aluminium, Not Yet Defined!
Medium: aluminium, Not Yet Defined!
Medium: aluminium, Not Yet Defined!
Medium: aluminium, Not Yet Defined!
Medium: aluminium, Not Yet Defined!

sts_v19i: size 94.8472 x 96.0000 x 81.5520, assembly
Daughters: 
      Unit00R_1, size 18.028 x 48.000 x  3.526, position (    0.000,    0.000,  -36.750 )
      Unit00L_2, size 18.028 x 48.000 x  3.526, position (    0.000,    0.000,  -36.750 )
      Unit01R_3, size 29.846 x 48.000 x  9.500, position (    0.000,    0.000,  -36.750 )
      Unit01L_4, size 29.846 x 48.000 x  9.500, position (    0.000,    0.000,  -36.750 )
      Unit02R_5, size 29.846 x 64.000 x  9.500, position (    0.000,    0.000,  -26.250 )
      Unit02L_6, size 29.846 x 64.000 x  9.500, position (    0.000,    0.000,  -26.250 )
      Unit03R_7, size 41.664 x 64.000 x  9.500, position (    0.000,    0.000,  -15.750 )
      Unit03L_8, size 29.846 x 64.000 x  9.500, position (    0.000,    0.000,  -15.750 )
      Unit04R_9, size 29.846 x 80.000 x  9.500, position (    0.000,    0.000,   -5.250 )
     Unit04L_10, size 41.664 x 80.000 x  9.500, position (    0.000,    0.000,   -5.250 )
     Unit05R_11, size 41.664 x 80.000 x  9.500, position (    0.000,    0.000,    5.250 )
     Unit05L_12, size 29.846 x 80.000 x  9.500, position (    0.000,    0.000,    5.250 )
     Unit06R_13, size 41.664 x 92.000 x  9.500, position (    0.000,    0.000,   15.750 )
     Unit06L_14, size 41.664 x 92.000 x  9.500, position (    0.000,    0.000,   15.750 )
     Unit07R_15, size 41.664 x 96.000 x  9.500, position (    0.000,    0.000,   26.250 )
     Unit07L_16, size 41.664 x 96.000 x  9.500, position (    0.000,    0.000,   26.250 )
     Unit08R_17, size 41.664 x 96.000 x  3.526, position (    0.000,    0.000,   36.750 )
     Unit08L_18, size 41.664 x 96.000 x  3.526, position (    0.000,    0.000,   36.750 )
sts_passive_v19i_18, size 234.000 x 142.500 x 103.800, position (    0.000,    0.000,    2.680 )

top: size 234.0000 x 142.5000 x 103.8000, assembly
Daughters: 
     sts_v19i_1, size 234.000 x 142.500 x 103.800, position (    0.000,    0.000,   62.750 )

Info in <TGeoManager::CheckGeometry>: Fixing runtime shapes...
Info in <TGeoManager::CheckGeometry>: ...Nothing to fix
Warning in <TGeoManager::CheckGeometry>: Volume "passive_unit0A_half_Top_Part1" has no medium: assigned dummy medium and material
Warning in <TGeoManager::CheckGeometry>: Volume "passive_unit0A_half_Top_Part2" has no medium: assigned dummy medium and material
Warning in <TGeoManager::CheckGeometry>: Volume "passive_unit0A_half_Top_Part3" has no medium: assigned dummy medium and material
Warning in <TGeoManager::CheckGeometry>: Volume "passive_unit0A_half_POB" has no medium: assigned dummy medium and material
Warning in <TGeoManager::CheckGeometry>: Volume "passive_unit0A_half_Center" has no medium: assigned dummy medium and material
Warning in <TGeoManager::CheckGeometry>: Volume "passive_unit2A_half_POB" has no medium: assigned dummy medium and material
Warning in <TGeoManager::CheckGeometry>: Volume "passive_unit2A_half_Center" has no medium: assigned dummy medium and material
Warning in <TGeoManager::CheckGeometry>: Volume "passive_unit3A_half_POB" has no medium: assigned dummy medium and material
Warning in <TGeoManager::CheckGeometry>: Volume "passive_unit3A_half_Top_Part1" has no medium: assigned dummy medium and material
Warning in <TGeoManager::CheckGeometry>: Volume "passive_unit3A_half_Top_Part2" has no medium: assigned dummy medium and material
Warning in <TGeoManager::CheckGeometry>: Volume "passive_unit3A_half_Top_Part3" has no medium: assigned dummy medium and material
Warning in <TGeoManager::CheckGeometry>: Volume "passive_unit3A_half_Center" has no medium: assigned dummy medium and material
Warning in <TGeoManager::CheckGeometry>: Volume "passive_unit3B_half_POB" has no medium: assigned dummy medium and material
Warning in <TGeoManager::CheckGeometry>: Volume "passive_unit3B_half_Top_Part1" has no medium: assigned dummy medium and material
Warning in <TGeoManager::CheckGeometry>: Volume "passive_unit3B_half_Top_Part2" has no medium: assigned dummy medium and material
Warning in <TGeoManager::CheckGeometry>: Volume "passive_unit3B_half_Top_Part3" has no medium: assigned dummy medium and material
Warning in <TGeoManager::CheckGeometry>: Volume "passive_unit3B_half_Center" has no medium: assigned dummy medium and material
Actions #10

Updated by David Emschermann about 2 years ago

Hi *,

when I try to run the STS v19i in macro/run$ root -l run_transport.C,
I get the following error:

[INFO] Constructing STSMC  geometry from ROOT  file /opt/cbm/cbmroot_trunk_latest_root6/geometry/sts/sts_v19i.geo.root
[INFO] Not exactly two keys in the file. File is not of new type.
[FATAL] Material STSPOBMaterialCarbon is not defined in ASCII file nor in Root file.
For later analysis we write a core dump to core_dump_26313

Could it be that we need an update of the media.geo file in trunk?

Actions #12

Updated by Evgeny Lavrik about 2 years ago

  • Assignee changed from Evgeny Lavrik to David Emschermann

I see in https://git.cbm.gsi.de/CbmSoft/cbmroot_geometry/blob/master/media.geo all required materials. I do not know where the error comes from.
Concerning overlaps I do not have input from mechanics to resolve it.

Actions #13

Updated by Evgeny Lavrik about 2 years ago

  • File sts_passive_v19i.gdml added

I was able to solve the materials issue. See attachment.
Overlap issue is still open.

Actions #14

Updated by David Emschermann about 2 years ago

Hi Florian,

I fixed a bug with the carbon ladders in the interior part of the STS.
This bus was introduced with STS v19b.
Please commit only fresh copies from my webpage (dated 2020-03-31):

  1. to macro/sts/geometry
    http://cbm.uni-muenster.de/cbmroot/more/sts_v19h_105mm/create_stsgeo_v19h.C
    http://cbm.uni-muenster.de/cbmroot/more/sts_v19h_105mm/create_stsgeo_v19i.C
Actions #15

Updated by David Emschermann about 2 years ago

These are the elements I removed in STS v19h and STS v19i from the inner part:

Carbon ladder parts removed from inner region

Actions #16

Updated by David Emschermann about 2 years ago

Hi Evgeny,

in your box for the STS v19i, from the gdml file,
I do not see the cutouts on the front and the backpanel,
see screenshots below - a comparison between STS v19a and v19i.

Could you please fix those cutouts?

STS box frontpanel

STS box backpanel

Actions #17

Updated by David Emschermann about 2 years ago

I finally got it:
new STS v19i with 105 mm station pitch and
new PIPE v16i with kink at the position of station 3.



Actions #18

Updated by Evgeny Lavrik about 2 years ago

Dear David, good job solving the overlap problem. As I understand, the target chamber and beam pipe were moved upstream. Does this break the integration with RICH and MUCH?
I've carefully redone the GDML. Now all cutouts should be in place. Please check.

Actions #19

Updated by Evgeny Lavrik about 2 years ago

  • Assignee changed from Evgeny Lavrik to David Emschermann
Actions #20

Updated by David Emschermann about 2 years ago

Dear Evgeny,

I have stretched the pipe design, the downstream end and diameter of the pipe remains unchanged.

I had to move the kink of the pipe (transition between cylindrical to conical part) by 10 mm,
so the diameter of the cone as function of z might slightly differ from the previous setup.

The interface to MUCH and RICH is compatible to what we had so far.

Actions #21

Updated by David Emschermann about 2 years ago

Hi Evgeny,

the STS box looks much better now.

However, if I look upstream through the hole in the backside, the front panel is not completely open (see last 2 screenshots below).
Could you please increase the length of the cutout volume a few mm upstream, to clear that opening?





Actions #22

Updated by Evgeny Lavrik about 2 years ago

Dear David, I do not quite understand the issue? Should the back hole for beampipe be enlarged since beampipe diameter at this Z will be larger?

Actions #23

Updated by Evgeny Lavrik about 2 years ago

Dear David, I can not confirm that the walls are closed.
Using the very last GDML I attached - I can see through the entire detector.

Actions #24

Updated by Evgeny Lavrik about 2 years ago

Front

Actions #25

Updated by Evgeny Lavrik about 2 years ago

  • Assignee changed from Evgeny Lavrik to David Emschermann

Dear David, I did not receive your feedback so far. Maybe due to my mistake not changing the assignee to you.

Actions #26

Updated by David Emschermann about 2 years ago

Hi Evgeny,

are you using Apple or Linux? I see the same effect in v19a and v19i with the backside of the front wall opening under Debian.

Actions #27

Updated by David Emschermann about 2 years ago

Hi Florian,

could you please commit the following 3 files, which I just checked:

Actions #28

Updated by Evgeny Lavrik about 2 years ago

Dear David, I am building the geo on kronos and visualizing on local mac, since OpenGL does not work for me over X forwarding.

Please be sure to take the gdml from this quoted message, there was a gravely mistake fixed
Evgeny Lavrik wrote:

Dear David, good job solving the overlap problem. As I understand, the target chamber and beam pipe were moved upstream. Does this break the integration with RICH and MUCH?
I've carefully redone the GDML. Now all cutouts should be in place. Please check.

Evgeny.

Actions #29

Updated by David Emschermann about 2 years ago

I have checked the target and MVD positions with STS v19a as reference:

z= 0, 8, 12, 16 and 20 cm

Target position with STS v19a
MVD station 1 position with STS v19a
MVD station 4 position with STS v19a

Actions #30

Updated by David Emschermann about 2 years ago

  • File deleted (sts_passive_v19i.gdml)
Actions #31

Updated by David Emschermann about 2 years ago

  • File deleted (sts_passive_v19i.gdml)
Actions #33

Updated by David Emschermann about 2 years ago

The MVD position does not change when displacing the pipevac1 volume, see below.
Here we do need a MVD with stations at z= 4, 8, 12 and 16 cm.

Target position with STS v19i
MVD station 1 position with STS v19i

Actions #34

Updated by David Emschermann about 2 years ago

  • Related to Support #1690: Create a MVD geometry which is shifted 40 mm upstream added
Actions #35

Updated by David Emschermann about 2 years ago

Hi Florian,

could you please commit the following 3 files:

The eventDisplay.C showing the MVD is only useful when looking at MVD + STS geometries.
It makes the overall setup DISPLAY very slow, if TOF is included, therefore I suggest not to commit it as default.

Actions #36

Updated by Anna Senger about 2 years ago

Hi.
Is there "matbudget" file for new STS geometry, or can user use old sts_matbudget_v19a.root?

Actions #37

Updated by Evgeny Lavrik about 2 years ago

Dear Anna, in his preliminary studies Iouri Vassiliev used some mat budget maps. Please consult with him.

Actions #38

Updated by David Emschermann about 2 years ago

Hi Anna,

the STS v19i files were not yet commited to the trunk by Florian
and a matching material budget file was not yet generated.

Actions #39

Updated by David Emschermann about 2 years ago

  • Related to Bug #1694: Fix positioning of exported beam pipes with a non-zero translation added
Actions #40

Updated by David Emschermann about 2 years ago

Finally, the STS v19i with a shifted MVD v17b TR in full glory and at the correct (!) positions:

STS v19i with MVD v17b tr

Actions #41

Updated by David Emschermann about 2 years ago

Which is fine also with an exported and re-imported STS geometry:

[INFO] Importing Pipe geometry from ROOT file /opt/cbm/cbmroot_trunk_latest_root6/geometry/pipe/pipe_v16d_1e.geo.root
[INFO] Constructing MVD  geometry from ROOT  file /opt/cbm/cbmroot_trunk_latest_root6/geometry/mvd/mvd_v17b_tr.geo.root
[INFO] Importing STS geometry from ROOT file /opt/cbm/cbmroot_trunk_latest_root6/geometry/sts/sts_v19i.geo.root
Actions #42

Updated by David Emschermann about 2 years ago

  • Related to Support #1698: Check exported STS v19j versus written STS v19a geometry added
Actions #43

Updated by David Emschermann about 2 years ago

Committed material budget file sts_matbudget_v19i.root for STS v19i to GIT.

Actions #44

Updated by Evgeny Lavrik about 2 years ago

Dear David, are you sure that the material budget should be calculated with passive materials in place? How would reconstruction software perform with such maps?
It was discussed a year ago, that 16g type of material budget with no passives should be used for this purpose.

Actions #45

Updated by David Emschermann about 2 years ago

Hi Evgeny,

it turned out that the material budget analysis macro makes some assumptions on the STS station position, which is not compatible with the long STS v19i geometry. Following a recommendation by Florian, the STS v19a and v19i now both use the same material budget file.

It was discussed a year ago, that 16g type of material budget with no passives should be used for this purpose.

I am not aware of such a discussion. Could you please point me to an issue or writeup?

Actions #46

Updated by David Emschermann about 2 years ago

Hello Anna, hello Ilya,

the hadron and electron setups with the long STS v19i are now ready for comparison to the default setups containing the STS v19a geometry. Florian has just pushed the relevant commits to the APR20 release branch.

You can run macro/run/run_transport_sts_long.C
to simulate setups with the long STS v19i.

Please start testing and report any issues.

For the muon Setups, we still need to adapt the beampipe to the new STS v19i.

Actions #47

Updated by David Emschermann about 2 years ago

  • Status changed from New to In Progress
  • Assignee changed from David Emschermann to Ilya Selyuzhenkov
  • Estimated time changed from 2.00 h to 30.00 h
Actions #48

Updated by David Emschermann about 2 years ago

Hi Florian,

please commit the following pipe to the SVN:

Once the GIT merge request #24 gets accepted, also the 2 muon setups with the long STS v19i are complete.

Testing can the begin using the following setups:

sis100_electron_sts_long
sis100_hadron_sts_long
sis100_muon_jpsi_sts_long
sis100_muon_lmvm_sts_long

in macro/run/run_transport_sts_long.C
Actions #49

Updated by Florian Uhlig about 2 years ago

I merged request #24 and add the file create_bpipe_geometry_v16d_1m.C. Both are now in the trunk and the release branch APR20.
I did not add the transport macro since the only change is in some commented lines with parameters. The parameter can be changed from the command line so I don't see a need to commit the file.

Actions #50

Updated by Anna Senger about 2 years ago

  • Assignee changed from Ilya Selyuzhenkov to David Emschermann

There are two overlaps

Unexpected Overlap: = Overlap ov00000: cave/pipe_v16d_1e_0/pipe1_0 overlapping cave/sts_v19i_0/sts_passive_v19i_18/passive_Box_Wall_Front_Wrong_1 ovlp=0.247

Unexpected Overlap: = Overlap ov00001: cave/pipe_v16d_1e_0/pipevac1_0 overlapping cave/sts_v19i_0/sts_passive_v19i_18/passive_Box_Wall_Front_Wrong_1 ovlp=0.247

Actions #51

Updated by David Emschermann about 2 years ago

  • Assignee changed from David Emschermann to Evgeny Lavrik

Hi Evgeny,

this seems to be an overlap between the MVD part of the beampipe and the STS box front wall.
I do not know how to edit the STS box gdml file, so I reassign this overlap issue to you.

Actions #52

Updated by Evgeny Lavrik about 2 years ago

  • Assignee changed from Evgeny Lavrik to David Emschermann

Hello David,
I've tried to move the pipe upstream by 0.25 cm and overlaps are gone. Please check the global Z positioning of the pipe.
The STS as a whole was moved exactly by 2 cm upstream to compensate for 4 cm extension, so there is no chance of a deltaZ of 0.247 appearing.

Actions #53

Updated by Volker Friese almost 2 years ago

Dear David,

this ticket is assigned to the target APR20, which we want to close as soon as possible. Could you comment? Can you finish it in short time?

Actions #54

Updated by David Emschermann almost 2 years ago

  • Assignee changed from David Emschermann to Evgeny Lavrik

Hello Volker,

the overlap is still present as of today when using STS v19i:

gGeoManager->CheckOverlaps(0.001);

[..]

root [3] gGeoManager->PrintOverlaps();
=== Overlaps for FAIRGeom ===
 = Overlap ov00000: cave/magnet_container_0 overlapping cave/rich_v17a_1e_0/rich_container_290 ovlp=11.5
 = Overlap ov00001: cave/pipe_v16d_1e_0/pipe1_0 overlapping cave/sts_v19i_0/sts_passive_v19i_18/passive_Box_Wall_Front_Wrong_1 ovlp=0.247
 = Overlap ov00002: cave/pipe_v16d_1e_0/pipevac1_0 overlapping cave/sts_v19i_0/sts_passive_v19i_18/passive_Box_Wall_Front_Wrong_1 ovlp=0.247

It is not present with STS v19h:

gGeoManager->CheckOverlaps(0.001);

[..]

root [3] gGeoManager->PrintOverlaps();
=== Overlaps for FAIRGeom ===
 = Overlap ov00000: cave/magnet_container_0 overlapping cave/rich_v17a_1e_0/rich_container_290 ovlp=11.5
root [4] 

STS v19i is a v19h with the adiidional STS box by Evgeny. So the overlap is between the pipe and Evgeny's STS box.
I do not know how to edit that box, so this problem should be resolved by Evgeny.

The STS as a whole was moved exactly by 2 cm upstream to compensate for 4 cm extension, so there is no chance of a deltaZ of 0.247 appearing.

It is not clear to me what is meant with this statement.

That bug prevents this long STS geometry to become the new default.

Actions #55

Updated by Evgeny Lavrik almost 2 years ago

  • Related to Support #1737: Provide box for STS v19r geometry added
Actions #56

Updated by Evgeny Lavrik almost 2 years ago

  • Assignee changed from Evgeny Lavrik to David Emschermann

Beampipe overlap issue solved in #1737

Actions #57

Updated by Evgeny Lavrik almost 2 years ago

I have backported the solution for the beampipe overlap issue for STS Box to v19i.

Actions #58

Updated by David Emschermann almost 2 years ago

This is the difference in the backport:

# diff sts_passive_v19i.gdml.orig sts_passive_v19i.gdml.update 
132c132
< <tube name="passive_Box_Wall_Front_Wrong_PartBody_op1" rmin="0.000000" rmax="400.800000" z="(30.000000)*2" startphi="0.000000" deltaphi="360.000000" aunit="deg" lunit="mm"/>
---
> <tube name="passive_Box_Wall_Front_Wrong_PartBody_op1" rmin="0.000000" rmax="400.800000" z="(32.500000)*2" startphi="0.000000" deltaphi="360.000000" aunit="deg" lunit="mm"/>
Actions #59

Updated by David Emschermann almost 2 years ago

Dear Evgeny,

I can confirm that the overlap with the pipe is gone. I have committed the gdml file and an updated STS v19i geometry to GIT.

Actions #60

Updated by David Emschermann almost 2 years ago

Hi,

I have discovered another overlap, which is not reported by the check:
It is an overlap between the downstream wall of the box intruding into the pipe v16d_1e.

Actions #61

Updated by Volker Friese almost 2 years ago

  • Target version changed from APR20 to APR21

As agreed per email of 29 June, not required for APR20. I thus shift to OCT20.

Actions #62

Updated by Florian Uhlig 11 months ago

What is the status of this ticket? An it be closed?

Actions #63

Updated by David Emschermann 11 months ago

  • Subject changed from Create box around STS v19i and commit STS geometries v19h and v19i to the trunk to Create box around STS v19r and commit STS geometries v19h and v19i to the trunk
  • Assignee changed from David Emschermann to Mehul Shiroya

Mehul is working on it ...

Actions #64

Updated by Florian Uhlig 11 months ago

  • Target version changed from APR21 to DEC21
Actions #65

Updated by David Emschermann 4 months ago

  • Related to deleted (Support #1737: Provide box for STS v19r geometry )
Actions #66

Updated by David Emschermann 4 months ago

  • Assignee changed from Mehul Shiroya to David Emschermann
Actions #67

Updated by David Emschermann 4 months ago

  • Status changed from In Progress to Resolved
Actions #68

Updated by David Emschermann 4 months ago

  • Related to Support #1737: Provide box for STS v19r geometry added
Actions #69

Updated by David Emschermann 4 months ago

  • Status changed from Resolved to Closed
Actions #70

Updated by Florian Uhlig 4 months ago

Test if the URL is correct now.

Actions

Also available in: Atom PDF