Problem 2074

Summary:	G4EllipticalTube cannot be used with parameterized solids, ComputeDimensions() undefined
Product:	Geant4	Reporter:	Michael Kelsey <kelsey>
Component:	geometry	Assignee:	Gabriele Cosmo <Gabriele.Cosmo>
Status:	RESOLVED WONTFIX
Severity:	enhancement
Priority:	P4
Version:	10.4
Hardware:	All
OS:	All

Description Michael Kelsey 2018-08-13 21:42:22 CEST

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?

Comment 1 Gabriele Cosmo 2018-08-14 08:54:14 CEST

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?

Comment 2 Michael Kelsey 2018-08-14 17:30:50 CEST

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.

Comment 3 Gabriele Cosmo 2018-08-15 09:09:16 CEST

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!