SolidStateDetectors.jl
SolidStateDetectors.jl copied to clipboard
Type instability in Torus constructor
This came up in #285.
The construction of a Torus is not entirely type stable as some parametric types of Torus
depend on the values and not the types of the input arguments to the constructor:
@inferred CSG.Torus{Float64}(φ=π,θ=(π,2π)) # -> error
The parametric types which cause the issue are TT1
and TT2
of the Torus: https://github.com/SebastianRuffert/SolidStateDetectors.jl/blob/de2af27789cf8883f74ad0599acc60fc11aadd9a/src/ConstructiveSolidGeometry/VolumePrimitives/Torus.jl#L69.
These define the types of two surfaces of the Torus. If we just remove TT1
and TT2
from the Torus
we would shift the type instability into the function surfaces(t::Torus)
.
I think the best solution would be if we would came up with a way to remove the :inwards
and :outwards
parametric types of (all) surface primitives. Maybe by defining some field to those structs which only hold +1
or -1
in order to define the direction of surfaces like for the ConeMantle
or TorusMantle
.
However, we would still have the issue of the :flat
case for the Torus
.
Here, one (or two) of the surfaces of the Torus
become not a ConeMantle
but an
EllipticalSurface
: see TorusThetaSurface
.
We would need to come up with a way to define these "flat" surfaces still as ConeMantle
. In its current implementation of ConeMantle
, this is not possible as hZ
would be 0
.