Change request #1437
Switch order of BGD and BGD_RECO in GCTABackground3D
| Status: | Closed | Start date: | 03/09/2015 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assigned To: |  Knödlseder Jürgen | % Done: | 100% | |
| Category: | - | |||
| Target version: | 1.0.0 | |||
| Duration: |
Description
Currently, in GCTABackground3D::operator(), there is the flag etrue which is false on default. Accordingly, in the current format we only use the FITS column BGD_RECO (I also cannot really think about how we could derive the background as a function of true energy).
If we want to support bundling of events and IRFs (#1435), we could save a lot of disk space if the unused column was not stored, too.
Accordingly, my proposal is to allow GCTABackground3D to consist of only 7 columns instead of 8.
The code change would be marginal:
In GCTABackground3D::operator(), we could change int index = (etrue) ? 0 : 1; to int index = (etrue) ? 1 : 0;.
Just to give some numbers:
The background model file size depends on the binning. In my binning, currently a background file is 1MB which is 3x more than a usual event file. Reducing the size to 500kb by omitting the unused column would lead to significantly less storage, e.g. for all HESS data (~20000 runs).
Recurrence
No recurrence.
History
#1
Updated by Knödlseder Jürgen almost 10 years ago
I fully agree. The true energy is only possible in Monte Carlo simulations, that’s why this information is there.
I’m wondering whether we should drop support for this generally from GammaLib. As you say, it’s difficult to see how the information can be derived anyways, it does not make much sense. So I would be perfectly happy with dropping the true energy histogram from the background file and removing the etrue flag from the interface.
If a user really wants to play with that he can derive his own background model.
#2
Updated by Mayer Michael almost 10 years ago
Yes, the true energy comes only from MC. For the background, you would never plug in the energy response to unfold the true background (cosmic-ray or election energy). So let’s drop this column.
Actually, I wouldn’t drop this information e.g. in the effective area for now. If we take into account the energy resolution we should take the effective area as a function of true energy (which clearly comes from MC). To avoid the full energy resolution computation one could take the effective area as a function of reconstructed energy. In HESS both approaches exists in different analysis chains, so we might want to keep supporting this?
#3
Updated by Knödlseder Jürgen almost 10 years ago
Mayer Michael wrote:
Yes, the true energy comes only from MC. For the background, you would never plug in the energy response to unfold the true background (cosmic-ray or election energy). So let’s drop this column.
Actually, I wouldn’t drop this information e.g. in the effective area for now. If we take into account the energy resolution we should take the effective area as a function of true energy (which clearly comes from MC). To avoid the full energy resolution computation one could take the effective area as a function of reconstructed energy. In HESS both approaches exists in different analysis chains, so we might want to keep supporting this?
I won’t drop it in effective area, PSF or energy dispersion, just for the background (as it does not make much sense there).
#4
Updated by Mayer Michael almost 10 years ago
ok agreed. Do you merge in the changes and close the issue?
#5
Updated by Knödlseder Jürgen almost 10 years ago
Mayer Michael wrote:
ok agreed. Do you merge in the changes and close the issue?
You say “merge”, is there already a branch with the changes?
I can certainly make the changes.
#6
Updated by Mayer Michael almost 10 years ago
oups, I meant: “do you make the changes?”. There is no branch 
#7
Updated by Knödlseder Jürgen almost 10 years ago
- Status changed from New to In Progress
- Assigned To set to Knödlseder Jürgen
- Target version set to 1.0.0
- % Done changed from 0 to 10
Okay, I’m doing that (start with updating the CTA calibration database)
#8
Updated by Knödlseder Jürgen almost 10 years ago
- Status changed from In Progress to Closed
- % Done changed from 10 to 100
Merged into devel.