The relatively simple G4EllipticalTube class cannot be used with parameterized solids. It compiles and links successfully, but fails at runtime with the error that "ComputeDimensions() has not been defined for this class." I've tried working around this by using a G4Ellipsoid with extremely long Z axis, then clipping it to the Z height I need, but that (a) seems to make the visualization unhappy, and (b) doesn't seem like the "right" solution. Could G4EllipticalTube::ComputeDimensions() be implemented?
Hi Mike, as you know and discussed already in the past, not all shapes and notably specific ones, are enabled for parameterisations. Parameterisations have been thought originally to support only a set of the most common CSG shapes for which it could be possible to apply Cartesian and/or radial/phi-sections parameterisations. With time, this has been extended also to few other shapes (also to allow for divisions), forcing the original idea and complicating the adoption of this feature, as any new shape being added causes backwards compatibility to the existing user's code, due to an explicit dependency on the new shape being introduced in the kernel. That's the main reason why we refrain to introduce this feature to other (little used) shapes in the set. Can you please explain what exactly is your use case for this shape? Why can't you use placements of elliptical tubes instead?
I was surprised at how many "non-trivial" solids had their ComputeDimensions() defined, making them usable for parametrized/replicated volumes. I hadn't realized that each solid was "promoted" to being parameterized as needed, rather than all together. My specific use case is modelling the TES sensor pads applied to large crystal detectors via photolithography. The TES itself is a thin strip of tungsten (roughly 20 x 250 um) surrounded by aluminum QET collector fins. Phonons absorbed on the aluminum liberate quasiparticles which reach the tungsten and cause it to move through the superconducting transition zone. In our older crystals, the QET area is rectangular, but our latest crystal is a very close-packed array of ellipses, each 680 x 490 um, spaced 800 um apart. There are about 11,000 QET pads on each side of the crystal. In Geant4 (with G4CMP), we record the phonon hits onto the QET pads, and run those hits through a digitization stage to get readout pulses. We do not make the QET and TES separately, but just make the enclosing shape and use that with a G4LogicalBorderSurface to catch the hits. When I initially tried using simple placements, the memory usage was prohibitive (both the huge number of PVs and their associated surfaces), and the visualization couldn't handle it at all. Converting to G4PVParameterised solved both of those problems, and made the code much simpler as well. I can use G4Box for the pads instead of G4EllipticalTube, with the dimensions adjusted by sqrt(pi/4) to get equal area.
If using G4Box in place of G4EllipticalTube for the pads is a reasonable compromise for you, I would then strongly suggest you approach that solution, as it would be beneficial also for CPU performance in general!
