GRIFFINCollaboration / detectorSimulations_v10

Geant4 version 10 of the simulation code for the GRIFFIN array and it's suite of ancillary detection systems.
MIT License
9 stars 14 forks source link

Naming scheme and decoding the detector and crystal number from it #57

Closed VinzenzBildstein closed 6 years ago

VinzenzBildstein commented 6 years ago

I've looked into the naming scheme we use for volumes placed in the simulation and how those names are used to get the detector and crystal number.

It seems that even though some ways to place detectors (e.g. placing each GRIFFIN detector on its own) give a name which has the detector and crystal number directly in it, most of the other ways (e.g. to place 20 sceptar detectors at once) can not do this as they use assembly imprints to place the same volume multiple times. In that case the only information left is the imprint number.

The imprint number is based on the copy number which can be provided to the MakeImprint function. If the number provided is zero, MakeImprint starts at the current number of daughter volumes. This means for the latter case our imprint number depends on the number of volumes placed before. I think this might have led to the wrong crystal numbers in #55 when creating SCEPTAR before GRIFFIN.

It seems that for GRIFFIN the functions that create Detectors w/o detector and crystal number (ConstructComplexDetectorBlock and ConstructComplexDetectorBlockWithDeadLayer) are not used anymore and only ConstructComplexDetectorBlockWithDetectorSpecificDeadLayer is being used. So for GRIFFIN it makes sense to get the numbers from the name ignoring the imprint number. For other detectors this will be different. For SCEPTAR e.g. the imprint number can be used (name of the form av_impr_).

I will do a quick check of the other detectors, but this might warrant a closer look for some of them to make sure that the detector numbers are parsed correctly.