Normalization of yield data
From GOSIA
(corrected a typo in the DeltaOmega expression under "exceptions") |
(→Introduction: Added important note that this article assumes efficiency-corrected yields) |
||
Line 1: | Line 1: | ||
==Introduction== | ==Introduction== | ||
+ | |||
+ | ''In this "Normalization of yield data" article it is assumed that the user is passing efficiency-corrected gamma-ray yields to Gosia, but there are other ways that data can be used.'' | ||
Any arbitrary overall normalization of the gamma-ray yield data is acceptable, unless the user is trying to normalize to the collision partner's gamma-ray yields or to the elastic cross section. This is because Gosia fits one overall normalization constant to all yield data, representing the factors of beam current, beam time, etc. | Any arbitrary overall normalization of the gamma-ray yield data is acceptable, unless the user is trying to normalize to the collision partner's gamma-ray yields or to the elastic cross section. This is because Gosia fits one overall normalization constant to all yield data, representing the factors of beam current, beam time, etc. | ||
Line 5: | Line 7: | ||
==Ge detector solid-angle corrections== | ==Ge detector solid-angle corrections== | ||
- | If all of the Ge detectors span the same solid angle, then all of the data will be consistent if each count is efficiency-corrected by dividing by the relative efficiency <math>\epsilon (E_\gamma)</math> with an arbitrary overall normalization. However, if two data sets from different detector ''[[physical_germanium_type | types]]'' are included, then the following additional correction is necessary, since Gosia calculates (OP,INTI) yield per unit Ge solid angle | + | If all of the Ge detectors span the same solid angle, then all of the data will be consistent if each count is efficiency-corrected by dividing by the relative efficiency <math>\epsilon (E_\gamma)</math> with an arbitrary overall normalization. However, if two data sets from different detector ''[[physical_germanium_type | types]]'' are included, then the following additional correction is necessary, since Gosia calculates (OP,INTI) yield per unit Ge solid angle and expects the same yield per unit solid angle in fitting (OP,MINI). |
Gosia expects to read "corrected" yields of | Gosia expects to read "corrected" yields of | ||
Line 17: | Line 19: | ||
In cases where the overall normalization doesn't matter, the efficiency can absorb the solid angle and be taken on a scale of 0 < efficiency < 4pi, ''but the solid angle factor must not be included twice.'' | In cases where the overall normalization doesn't matter, the efficiency can absorb the solid angle and be taken on a scale of 0 < efficiency < 4pi, ''but the solid angle factor must not be included twice.'' | ||
- | ===Exceptions=== | + | ===Exceptions and warnings=== |
+ | |||
+ | If the data sets are from detector clusters (see OP,RAW in the user manual), all of the Ge crystals in the cluster should be of the same physical type. This is because Gosia gives output and expects data from the user representing the count per unit solid angle ''of the crystal type,'' not of the total cluster solid angle. | ||
- | + | It is not clear how to handle summed Ge clusters of ''different physical types'' in Gosia. | |
- | The OP,RAW command can be used to pass data to Gosia without an efficiency correction. The solid angle divisors are still required | + | The OP,RAW command can be used to pass data to Gosia without an efficiency correction and/or for summed clusters. The solid angle divisors are still required, and for each cluster should be taken as <math>\Delta\Omega_{crystal}</math>—the solid angle of a single Ge detector in the cluster! |