Project

General

Profile

Actions

Bug #283

closed

Shape of STS v15a geometry depends on Root version used to run macro/sts/create_stsgeo_v15.C

Added by David Emschermann almost 7 years ago. Updated almost 7 years ago.

Status:
Closed
Priority:
Normal
Target version:
-
Start date:
06/15/2015
Due date:
% Done:

100%

Estimated time:
6.00 h
Spent time:

Description

The macro/sts/create_stsgeo_v15.C macro was availble between revisions 7551 and 7621.
The shape of the STS detector generated by this macro depends on the ROOT version
used to execute the macro:

With cbmroot_dec13p1 on Debian 6 and Root 5.34/13, the shape looks fine
(see attached 01_sts_v15a_with_root_5_34_13.png).

However with fairsoft mar15p2 on Debian 8 and Root 5.34/25 the STS v15a is compressed
in x and y (see attached 02_sts_v15a_with_root_5_34_25.png).

We have to find out why this is the case?!


Files

01_sts_v15a_with_root_5_34_13.png (17.9 KB) 01_sts_v15a_with_root_5_34_13.png STS v15a - Root 5.34/13 - normal shape David Emschermann, 06/15/2015 10:45 AM
02_sts_v15a_with_root_5_34_25.png (11.2 KB) 02_sts_v15a_with_root_5_34_25.png STS v15a - Root 5.34/25 - compressed David Emschermann, 06/15/2015 10:45 AM
03_sts_v15a_with_root_5_34_19.png (18.5 KB) 03_sts_v15a_with_root_5_34_19.png STS v15a - Root 5.34/19 - normal shape David Emschermann, 06/16/2015 09:50 AM
04_sts_v13y_with_root_5_34_25.png (11 KB) 04_sts_v13y_with_root_5_34_25.png STS v13y - Root 5.34/25 - compressed David Emschermann, 06/16/2015 09:54 AM
05_sts_v15a_with_root_5_34_22.png (11.9 KB) 05_sts_v15a_with_root_5_34_22.png STS v15a - Root 5.34/22 - compressed David Emschermann, 06/17/2015 04:01 PM
06_sts_v15a_with_root_5_34_21.png (9.84 KB) 06_sts_v15a_with_root_5_34_21.png STS v15a - Root 5.34/21 - compressed David Emschermann, 06/17/2015 04:43 PM
07_sts_v15a_with_root_5_34_20.png (12.1 KB) 07_sts_v15a_with_root_5_34_20.png STS v15a - Root 5.34/20 - compressed David Emschermann, 06/17/2015 09:13 PM
Actions #1

Updated by David Emschermann almost 7 years ago

  • Description updated (diff)
Actions #2

Updated by Volker Friese almost 7 years ago

  • Status changed from New to In Progress
  • Assignee set to David Emschermann

This is a very strange observation. Could you check whether the same holds for older STS geometries, i.e. the default v13y?

Actions #3

Updated by David Emschermann almost 7 years ago

The shape is still fine with Root 5.34/19 (see attached 03_sts_v15a_with_root_5_34_19.png).

Actions #4

Updated by David Emschermann almost 7 years ago

I just checked the question raised by Volker:
Yes, when created with Root 5.34/25 (AKA fairsoft_mar15p2) the STS v13y looks also compressed, (see attached 04_sts_v13y_with_root_5_34_25.png).

Actions #5

Updated by David Emschermann almost 7 years ago

The TRD v15a geometry is not affected by Root 5.34/25.

Actions #6

Updated by David Emschermann almost 7 years ago

With Root 5.34/22 the STS v15a is compressed in x and y (see attached 05_sts_v15a_with_root_5_34_22.png).

Actions #7

Updated by David Emschermann almost 7 years ago

With Root 5.34/21 the STS v15a is compressed in x and y (see attached 06_sts_v15a_with_root_5_34_21.png).

Actions #8

Updated by Volker Friese almost 7 years ago

Spannend! Ist 20 oder 21 der Bad Guy?

Actions #9

Updated by David Emschermann almost 7 years ago

With Root 5.34/20 the STS v15a is compressed in x and y (see attached 07_sts_v15a_with_root_5_34_20.png).

Will re-check with fairsoft_mar15p2 downgraded to Root 5.34/19, if the problem was really introduced in Root 5.34/20!?

Actions #10

Updated by David Emschermann almost 7 years ago

  • % Done changed from 20 to 50

The problem is caused by the following change to line 98 in
rootgeom/geom/src/TGeoShapeAssembly.cxx introduced
with git commit eeb676568becee8d5eb1de3e2a7c62bfa301bab8
on Jul 17 2014, 13:07 by agheata:

98 - fBBoxOK = kTRUE;
98 + if (fDX>0 && fDY>0 && fDZ>0) fBBoxOK = kTRUE;

As some of the Assemblies have size 0.,0.,0. their bounding box
is not properly respected with the new code (fBBoxOK = kFALSE).

Now the question is:
Do we patch Root versions > 5.34/19 or
do we modify the STS geometry macros?

Actions #11

Updated by David Emschermann almost 7 years ago

  • Assignee changed from David Emschermann to Florian Uhlig
Actions #12

Updated by Volker Friese almost 7 years ago

Question is what's behind the quoted change in ROOT. We should patch it only if it is clearly a bug, which it does not seem to be.

Why (and where) are there assemblies with zero extension created by the STS geo macro?

Actions #13

Updated by David Emschermann almost 7 years ago

Should we only patch future sts geometry macros or should we also make sure that create_stsgeo_v13?.C macros can be executed with Root versions later than 5.34/19? If we do not patch the old macros, they should also contain a warning section checking the root version upon execution!

Actions #14

Updated by Tomas Balog almost 7 years ago

I would propose just a simple note that ROOT 5.34/19 has to be used for the case of this geometry, since I believe that not so many people will play with changing the configuration of the positions of the sensors rather than just examine if the geometry fulfills the requirements. This means to look at output of the simulations using geo.root files aready created and provided.

Important thing is that more and more macros will have the troubles with new cbmroot releases. ROOT people seem to go new direction of code logic. I would say in a moment when change to ROOT 6 etc in FarRoot will happen there will be more and more things to repair...

Actions #15

Updated by David Emschermann almost 7 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 50 to 100

Applied in changeset cbmroot|r7744.

Actions #16

Updated by David Emschermann almost 7 years ago

  • Assignee changed from Florian Uhlig to David Emschermann

This bug has been reported to the JIRA Root bug tracker at CERN:

https://sft.its.cern.ch/jira/browse/ROOT-7420

Actions #17

Updated by David Emschermann almost 7 years ago

  • Status changed from Resolved to Closed

We received the following feedback from Andrei Gheata on our bug report:

This was indeed intended, due to large performance issues coming with the old implementation. The old policy was indeed to keep the bounding box of an assembly valid after adding any component, but in the case of very complex composed assemblies where any change deep in the hierarchy had to be propagated upwards to the containing assembly, this was extremely penalizing. Instead we changed this to a policy where the bounding box of assemblies is only computed during TGeoManager::CloseGeometry() which is indeed not as flexible but much faster...

In principle from now on one needs to force computation of a valid bounding box after each AddNode command:

    sts->AddNode(station, iStation, trans);
    sts->GetShape()->ComputeBBox();
Actions

Also available in: Atom PDF