ctools

I got your tree. Just one comment (I’ve seen the same yesterday with ctpsfcube): don’t put the binary under version control of git. The binary will be produce from the source code, but should not be part of the repo (as it is platform dependent).

sorry. It’s a mistake.

Knödlseder Jürgen wrote:

I got your tree. Just one comment (I’ve seen the same yesterday with ctpsfcube): don’t put the binary under version control of git. The binary will be produce from the source code, but should not be part of the repo (as it is platform dependent).

Chia-Chun: ctbkgcube gives skymap as output and ctmodel > gives eventcube.
Juergen: What do you mean here? ctbkgcube will give a 2D > skymap, or a 3D map (skymap as function of energy)?

Chia-Chun: My understanding is that EventCubes have more information such as GTI. It doesn’t make sense to have this for a model cube. Combing ctmodel and ctbkgcube together is possible, but we have to add several condition loops, which make the code hard to read.

• replicate the code ctbin::init_cube to initialise a GSkymap object
• use code like that found in ctbin::cube() to create a GCTAEventCube object from the GSkymap object
• now loop over the event bins, like in ctmodel::model_map to evaluate the model and set the model value
• then save the GCTAEventCube (you may simply call the GCTAEventCube.save() method)

Does this sound reasonable?

Lu Chia-Chun wrote:

My understanding is that EventCubes have more information such as GTI. It doesn’t make sense to have this for a model cube. Combing ctmodel and ctbkgcube together is possible, but we have to add several condition loops, which make the code hard to read.

Indeed, they have GTIs, but does it harm to have this information in a FITS file? Construction would be very similar compared to ctbin::fill_cube (you use m_gti.extend(events->gti()); to append the GTIs of a specific observation to the list. That just costs you a single line of code.

You would then need to update the GTIs in the event cube at the end (as you won’t have this information upon the initial construction, unless you want a separate loop over all observations to get this information).

Indeed, they have GTIs, but does it harm to have this information in a FITS file? Construction

I don’t object, but if we really want to have GTI in background cube, we’d better make the files consistent. It’s strange that background cubes without ctmodel processing don’t have GTI while those after ctmodel processing do.

Lu Chia-Chun wrote:

Indeed, they have GTIs, but does it harm to have this information in a FITS file? Construction

I don’t object, but if we really want to have GTI in background cube, we’d better make the files consistent. It’s strange that background cubes without ctmodel processing don’t have GTI while those after ctmodel processing do.

Now I’m lost. I though we won’t use ctmodel anymore for background cube processing, and that you create ctbkgmodel specifically for writing background cubes.

In any case, it won’t be difficult either to just save the GSkymap object, and not the entire GCTAEventCube object. The logic would still be the same. You would create a GCTAEventCube first, loop over it’s bins, but then just save the sky map (either the one in the cube, or another one that you create outside; but the latter would double the memory requirements, hence you’d like to use the GCTAEventCube skymap ...)

- I vote for using ctbackcube because I don’t like multi-condition loops.
- The steps I take in ctbackcube is

1. create a skymap with user-defined bins
2. go to each pixel and calculate the model value for that position.

The difficulty I have is:
GModels takes GCTAEventBin as an argument.
skymap is in the sky coordinate but GCTAEventBin has to be in instrument coordinate.
I want to use GCTAPointing to transform skymap sky direction to instrument direction and then create a GCTAEventBin by the instrument coordinate, but I don’t know how to do it. GCTAEventBin doesn’t allow setting directions.

Another possibility is to write a new GCTAEventCube constructor,
GCTAEventCube::GCTAEventCube(skymap, ebound, gti, pointing) and do coordinate transformation in GCTAEventCube.

• replicate the code ctbin::init_cube to initialise a GSkymap object
• use code like that found in ctbin::cube() to create a GCTAEventCube object from the GSkymap object
• now loop over the event bins, like in ctmodel::model_map to evaluate the model and set the model value
• then save the GCTAEventCube (you may simply call the GCTAEventCube.save() method)

So you create a GCTAEventCube object which then allows you looping over the events, without any need to pass through pointings, etc. If you’re stuck with that, just commit the latest code and I can take over implementing this part.

I’ve used GCTAEventCube to do the loop similar to model_map(). Now the loop seems to do model evaluation right, but the saved event cube or skymap is still empty. Don’t know what’s wrong...
My newest code is here:

https://github.com/chiachun/ctools/tree/ctbkgcube-2

Thanks!

I’ll give it a look later ...

Thank you !
I am checking the code to find out what I did wrong...
Knödlseder Jürgen wrote:

Here you are. Your tool is in devel and working.

It looks like I missed this line....
m_bkgcube.gti(obs→events()→gti());

Is this the reason why my code didn’t work?
And I am surprised to find that GCTAEventCube doesn’t have to be a member of a specific observation!

Lu Chia-Chun wrote:

It looks like I missed this line....
m_bkgcube.gti(obs→events()→gti());

Is this the reason why my code didn’t work?

Possibly, but not sure. I don’t think that the times are used at the end.

And I am surprised to find that GCTAEventCube doesn’t have to be a member of a specific observation!

In principle, every GammaLib class can live alone. Even GCTAEventBin!