ctools

However, I am not sure it should be scaled by ontime or livetime.

Lu Chia-Chun wrote:

Tested. Now ctlike gives reasonable normalization.

Pull request
https://github.com/chiachun/ctools/tree/1297-ctbkgcube-scaling

You were too quick. I was just writing the following

Indeed, the expected units are probably counts/MeV/sr/s, but they actually are counts/bin. I guess the code in ctbkgcube.cpp from line 391 on should instead of

            // Compute model value for event bin
            double model = 
                   m_bkgmdl.eval(*(const_cast<const GCTAEventBin*>(bin)), *obs) *
                   bin->size();

            // Compute model value for event bin
            double model = 
                   m_bkgmdl.eval(*(const_cast<const GCTAEventBin*>(bin)), *obs);

Just saw you code. You just divided by time, which leaves the issue about the division by MeV and sr. Have you checked that you get the right spectral normalization of your background model?

I didn’t get the right norms so I planned to check my exporter. (I am not sure if my exporter gives output with right units...) So now I will try your scheme.

Knödlseder Jürgen wrote:

Just saw you code. You just divided by time, which leaves the issue about the division by MeV and sr. Have you checked that you get the right spectral normalization of your background model?

after romoving bin→size()
I get norm ~ 0.003 (1/rad/rad)...WHY?

0.003 = 1/deg2rad/deg2rad
Lu Chia-Chun wrote:

after romoving bin→size()
I get norm ~ 0.003 (1/rad/rad)...WHY?

Lu Chia-Chun wrote:

I get a cube filled with zero after updated because I used an obs.xml with eventlist not processed by ctselect (no roi). In this case, ctbkgcube should throw warning messages or exceptions.

2014-07-25T14:44:18: Bins within RoI ...........: 0
2014-07-25T14:44:18: Bins outside RoI ..........: 6000
2014-07-25T14:44:18: Background events in cube .: 0
2014-07-25T14:44:18: Cube livetime .............: 1604.94 sec

I agree. I created issue #1298.

I am not sure whether this is a good idea.
It can happen that people want to have frequent changes on ROI for testing. It doesn’t make sense to produce new cubes every time when people change ROI, especially for GCTAMeanPsf, which is computationally very expensive. We hope that we only have to calculate it once.

Besides, it happens also very frequently that one wants to change exclusion regions – there are always regions/sources which we don’t know how to do a good modelling. For HESS, whose PSF is at the order of 0.1 deg, we don’t have to model all sources in the fov. We can cut out some regions to have a clean map to do modelling on targets in interests.

Does ctbkgcube also exclude pixels in exclusion regions? I don’t understand why this is needed since ctlike ignores pixels with negative values in event cube.

I guess it’s about background modelling normalization? Then could we proceed as follows?

- make background cube with a fov larger than the ROI.
- ctlike tells GModel that some pixels are switched off.
- GModel re-normalize bkgcube.

Knödlseder Jürgen wrote:

Another piece that was missing was the cut of the background model beyond the RoI of a given run. This is important, otherwise you will get a predicted background rate in an area where there are no events due to an RoI cut. I also implemented this in ctbkgcube. I also implemented the same logic in ctbin, GCTAExposure and GCTAMeanPsf to be sure that all stacked cubes are compliant.

the size of GEventBin is solidangle() * ewidth().MeV() * ontime();
So, shouldn’t we weight the model value by ontime?

Knödlseder Jürgen wrote:

I did the change I indicated, and even more. In fact, as the background model is in rates (i.e. counts/MeV/s/sr), each observation (or run) has to be weighted by the livetime of each run. For two runs, for example, the background model is

Anyway, I modified my exporter to scale the background by ontime.
Now I get normalization 1. It doesn’t matter we use ontime of livetime. we just have to keep it consistent.

Lu Chia-Chun wrote:

I am not sure whether this is a good idea.
It can happen that people want to have frequent changes on ROI for testing. It doesn’t make sense to produce new cubes every time when people change ROI, especially for GCTAMeanPsf, which is computationally very expensive. We hope that we only have to calculate it once.

Does ctpsfcube take a long time for you? I can’t even see that it’s running, I get results basically immediately.

If you change the RoI, you have to reprocess the event list anyways (using ctselect). This takes more time than the response stuff ...

Besides, it happens also very frequently that one wants to change exclusion regions – there are always regions/sources which we don’t know how to do a good modelling. For HESS, whose PSF is at the order of 0.1 deg, we don’t have to model all sources in the fov. We can cut out some regions to have a clean map to do modelling on targets in interests.

Does ctbkgcube also exclude pixels in exclusion regions? I don’t understand why this is needed since ctlike ignores pixels with negative values in event cube.

You do not need exclusion regions for ctbkgcube.

I guess it’s about background modelling normalization? Then could we proceed as follows?

- make background cube with a fov larger than the ROI.
- ctlike tells GModel that some pixels are switched off.
- GModel re-normalize bkgcube.

No, it’s also (and mainly) about exposure computation. You should not have exposure added into an exposure cube from a region which has been excluded from the event selection. Exposure cube generation needs to know what your event selection region was for each run. The same is true for Psf cube, and also background estimates.

Lu Chia-Chun wrote:

the size of GEventBin is solidangle() * ewidth().MeV() * ontime();
So, shouldn’t we weight the model value by ontime?

It really depends how we define background rates. What is the H.E.S.S. definition? Number of events per livetime or per ontime?

Event bin size is defined per ontime, as the Irf includes the livetime correction.

We have never used absolute background rate in HESS. We can choose the one we like.

Knödlseder Jürgen wrote:

Lu Chia-Chun wrote:

the size of GEventBin is solidangle() * ewidth().MeV() * ontime();
So, shouldn’t we weight the model value by ontime?

It really depends how we define background rates. What is the H.E.S.S. definition? Number of events per livetime or per ontime?

Event bin size is defined per ontime, as the Irf includes the livetime correction.

About PSF cube calculation: It’s slow for an observation of several hundreds of runs. Probably I used too many spacial bins. I will check it again tomorrow.

About exposure computation: Now I am confused. We select events in an ROI in sky coordinate, not in instrument coordinate. The ROI is thus always the same for each run and the exposure cube, counts cube, every cube. It’s safe to just add all exposure up since the ROI never changes position, Isn’t it?

And, ctselect is a tool for unbinned analysis, why do we use it for cube analysis (always a binned analysis)? We should use ctcubemask, which sets pixels outside ROI -1. Then it doesn’t matter whether the exposure there is zero or not.

(Too tired, have to go to bed. I’ll come back tomorrow morning.)

Knödlseder Jürgen wrote:

No, it’s also (and mainly) about exposure computation. You should not have exposure added into an exposure cube from a region which has been excluded from the event selection. Exposure cube generation needs to know what your event selection region was for each run. The same is true for Psf cube, and also background estimates.

Lu Chia-Chun wrote:

About PSF cube calculation: It’s slow for an observation of several hundreds of runs. Probably I used too many spacial bins. I will check it again tomorrow.

About exposure computation: Now I am confused. We select events in an ROI in sky coordinate, not in instrument coordinate. The ROI is thus always the same for each run and the exposure cube, counts cube, every cube. It’s safe to just add all exposure up since the ROI never changes position, Isn’t it?

We probably call different things ROI. For GammaLib, ROI is a circular region around a pointing, typically a few degrees, from which events will be used. That’s just the zone of selected events. In a stacked cube analysis, you may want to define a cube that is larger than the ROI of an individual run. Hence for one run, there will be zones in the cube that will not be filled. It is then important that in these zones there is also no exposure and no background.

And, ctselect is a tool for unbinned analysis, why do we use it for cube analysis (always a binned analysis)? We should use ctcubemask, which sets pixels outside ROI -1. Then it doesn’t matter whether the exposure there is zero or not.

See above. It’s an issue when your cube is larger than the FoV of a single run. Making pixels does not help here.