add DetectionEfficiencies (aka "normalisation")

[KrisThielemans]

No description provided.

[KrisThielemans]

We have a terminology problem. In ScannerGeometry we define detecting_elements as a list of ReplicatedBoxSolidVolumes (where each ReplicatedBoxSolidVolume could have a different material for instance).

PETSIRD/model/DetectorInformation.yml

Lines 20 to 25 in 0d543ad

	DetectorModule: !record
	fields:
	detectingElements: ReplicatedBoxSolidVolume*
	# list of unique ids for every replicated solid volume
	# constraint: size(detectingElements) == size(detectingElementsIds)
	detectingElementIds: uint*

However, in this PR, we currently use detecting_element as a single "crystal" (or "solid volume"), e.g.

PETSIRD/model/DetectionEfficiencies.yml

Lines 1 to 4 in 0d543ad

	# Detection efficiencies for every detecting element and energy window
	# If size along energyBinIdx is 1, the effiencies are assumed to be the same for every energy bin.
	# Constraint: size(DetElEfficiencies, "energyBinIdx") == scannerInformation.numberOfEnergyBins or 1
	DetElEfficiencies: float[detElIdx, energyBinIdx]

Note that we use detector_id in CoincidenceEvent, implying that a "detector" is a single "crystal"

PETSIRD/model/CoincidenceEvent.yml

Lines 3 to 6 in 0d543ad

	CoincidenceEvent: !record
	fields:
	# the pair of detector elements
	detectorIds: uint*2

I think that ScannerGeometry.detecting_elements is actually a pretty confusing name for what it is. Anyone any suggestions?

I also think that detector_id isn't great, as for many, a whole module could easily be the "detector". The name detecting_element (or det_el) seems to be more appropriate for the lowest level concept.

[KrisThielemans]

Also note that currently I'm not using the "detector ids" independent from the number. See #28 (comment)

[KrisThielemans]

I've now added (in Python) the facility to add multiple rings of blocks (while still using only rotations for symmetries), and updated the plotting to use boxes.

[KrisThielemans]

We have a terminology problem. In ScannerGeometry we define detecting_elements as a list of ReplicatedBoxSolidVolumes (where each ReplicatedBoxSolidVolume could have a different material for instance).
...
However, in this PR, we currently use detecting_element as a single "crystal" (or "solid volume")

On second thought, I now think there isn't really a problem. ScannerGeometry.detectingElements essentially is a list of a (replicated) list of what we call in the PR detEls. Aside from the "double list", the concept is fine. So, I'll leave this as-is for now.

I also think that detector_id isn't great, as for many, a whole module could easily be the "detector". The name detecting_element (or det_el) seems to be more appropriate for the lowest level concept.

I do think that this is a problem, but it should be addressed in a different PR.