[CMS] Solids associated with divided volumes are incomplete

[cvuosalo]

The Volume::divide() method divides a volume and creates a new volume. Internally, the ROOT TGeoVolume::Divide() method is called to perform the division:

https://dd4hep.web.cern.ch/dd4hep/reference/Volumes_8cpp_source.html#l00600

ROOT creates a solid for the new volume, but this solid is not created with a DD4hep constructor, so it is lacking a title to identify its type.
It would be helpful if these solids from divided volumes had proper titles like all other DD4hep solids.

In my CMSSW code, I have a work-around where my code has to guess the type of the divided solid by repeatedly calling the dd4hep::isA<> method since the title for these solids is blank. If divided solids had titles like all other DD4hep solids, then I could remove this clumsy work-around in my code.

[cvuosalo]

@ianna FYI

[MarkusFrankATcernch]

@cvuosalo
Hi Carl,
could you please post some code snipped, which shows what you would like to do and what exactly does not work?
If the division is done in DD4hep I could add the corresponding shape titles, if this is all that is missing.
Thanks a lot!

Markus

[cvuosalo]

@MarkusFrankATcernch A minimal fix would be to ensure all these solids have valid titles. I found that calling dd4hep::Solid::title() for a solid created as a Division returns the empty string while all other solids have valid titles. I think this fix would be sufficient for CMS.
A more complete fix would be to ensure that a Division volume is always complete. I found that a bad-handle exception occurs when trying to examine the solid in a Division volume:

dd4hep::Volume parent = ns.volume(parentName); // parent is a complete, valid volume 
dd4hep::Volume child = parent.divide(childName, axis, numCopies, startInDeg, widthInDeg); 
dd4hep::Solid solid(child.solid()); 
std::cout << "Divided solid name = " << solid.name() << std::endl;

generates "Attempt to access invalid object of type TGeoShape [Invalid Handle]".
We don't actually need to perform this operation in our code, but it is troubling that a volume could contain an invalid solid. Maybe in the future we might need to access the solid in a divided volume in this way.

[MarkusFrankATcernch]

@cvuosalo
Actually the answer "Attempt to access invalid object of type TGeoShape [Invalid Handle]" means that the the shape
pointer you got from the volume is invalid.
In my test I stumbled over the same problem.
I then asked Andrei if this behavior is correct.
Here is his Andrei's answer:

• The TGeoVolumeMulti is intended as a helper utility for TGeoVolume::Divide operations. It represents the full subset of TGeoNode objects created by Divide, allowing to Divide again or to position other nodes inside. They won’t have a shape sice they are not real volumes and they will not appear in the geometry tree. The shape pointed by the intern nodes may be different for each node (in case of e.g dividing a tube along R) or point to the same “cell” shape (e.g. when dividing a box). A TGeoVolumeMulti is never placed in another volume, one always starts with a regular volume (placed somewhere) and creates daughter nodes via the Divide operation. TGeoVolumeMulti can be nested as in:
  TGeoVolumeMulti *divx = realvol->Divide(“X”,…); // has real nodes with shapes inside
  TGeoVolumeMulti *divy = divx->Divide(“Y”,…); // creates a TGeoVolumeMulti adding as nodes the result of Divide for each node of divx
  TGeoVolumeMulti *divz = divy->Divide(“Z”,…); // same for dividing all the nodes of divy
  So all nodes in divx, div, divz will have indeed a shape. It is not allowed to call Divide 2 times for the same volume.

If I interprete this correctly:
the TGeoVolumeMulti is sort of an artificial construct which is not a real volume, but uses a real volume and places regular shaped daughters in it. If you want to access the subshapes you have to ask:

  TGeoVolumeMulti *mvol = real_vol->Divide(...);
  for( int i=0, n=mvol->GetNvolumes(); i<n; ++i )   {
    Volume vv = mvol->GetVolume(i);
    printout(ALWAYS,"VolumeMultiTester","+++ Volume[%03d] %p %s [%s]",
	     i, vv.ptr(), vv.name(), vv.solid().type());
  }

In this sense your usage of the VolumeMulti was incorrect. However, I have to admit, I also did not know this upfront...

[MarkusFrankATcernch]

Fixed and tested in cmssw.