GammaLib

We were just discussing this point also with Rolf. So do you think that a pointing table will be a standard CTA data product? Can you recall what the format should be? Would this also include deadtime as function of time?

Maybe we should start with writing a Python script that generates such a table. We could also have a ctool (something like ctpntsim) to simulate first a pointing table, and then use this as input to ctobssim for the simulations. ctpntsim would deal ultimately with observing constraints. Separating both steps is also useful for when we have real data. We can then use real pointing files to generate simulated data accordingly.

Kosack Karl wrote:

GCTAPointing should be able to read a table of START,STOP,ALT_PNT,AZ_PNT values, and store them internally in an interpolated list (a GNodesArray). Then, methods to get the pointing altitude (or zenith angle) and azumuth should be added that take a time as an input. They return the interpolated output.

Would the table contain START and STOP, or just a TIME (pointing at a given time stamp)? If you want to take provision for drift scans, for example, I would expect that the pointing table contains pointing information for a given time (kind of snapshots), and that the code the takes provision for interpolating between the time stamps.

I specified start+stop times only because these quantities are usually averages over a bin in time, and that makes the bin size explicit. One of the data products from the data reduction pipelines will be a housekeeping file, which is a set of tables in a similar format: START, START, <values>, that are “summarized” quantities from various instuments. The quantities are generally averaged in time between START and STOP, and thus can contain variances as well. Examples would be:

• array pointing summary: START, STOP, ALT, AZ (the pointing mode:track,fixed, slew is in the eventlist header). Deviations, etc, may also be stored in columns here
• trigger summary: START,STOP,RATE_AVG, RATE_VAR, DEADTIME_AVG, DEADTIME_VAR, etc.
• weather summary: START,STOP, TEMP_AVG, TEMP_VAR, PRES_AVG, PRES_VAR, etc.
• ...

All quantities can be used for making GTIs or for tracking the status of the array. The exact format has not been decided, but it will be something like what is shown above. The time bins for each table may be different, hence they are each in a separate HDU rather than one big table.

I also don’t quite think we need a GCTAPointings container, since this really still describes one pointing (e.g. a fixed point in RA/Dec), but when expressed in ALT/AZ coordinates you move in time. So I would say it’s still just a method of GCTAPointing, like GCTAPointing::altaz(time).

Generally, once should also ask for a time for the RA and dec coordinates. In the tracking-mode case, that just returns a fixed ra/dec for any given time. In the fixed-mode pointing, alt/az doesn’t change, but RA/Dec does. The only case where I could see a good use for a set of pointings would be a slew-mode.

1. add a class GHorizDir, similar to GSkyDir, but representing an Alt/Az (Horizontal) coordinate
2. change the interface of GCTAPointing to take:
   
pnt.dir( time ); // returns GSkyDir
pnt.dir_horiz( time ); //returns GHorizDir
pnt.rot( time ); // field-rotation matrix at time t

3. modify GCTAObservation to look for a housekeeping file in the XML definition
4. create pointing housekeeping table with START,STOP,ALT,AZ,RA,DEC (any maybe errors)
5. have GCTAPointing load the pointing housekeeping file and create an interpolation function for alt/az and ra/dec over time. The interpolation can be done assuming spherical coordinates with vector quantities (for best accuracy) or just as a simple linear interp (which is probably fine for looking up IRFs in alt/az)
6. use this interpolation function to get pnt.dir(t) or pnt.dir_horiz(t)

Another thing: conceptually, GCTAPointing is a single pointing, but now it contains an entire table of pointings. It would be better to introduce a pointing container class GCTAPointings to handle pointings as function of time. The GCTAPointings class would then deal with loading and saving of pointing tables, and interpolation, and could have an operator that returns a GCTAPointing object as function of time or index:

const GCTAPointing& operator[](const int& index) const;
GCTAPointing&       operator[](const int& index);
GCTAPointing        operator()(const GTime& time) const;

I created issue #1176 for this.

It’s somewhat of a philosophical question as to whether or not the pointing table refers to one pointing or multiple pointings: I would say it refers to a single pointing.

Do you call a pointing “a fixed position in RA/Dec”? In that case the pointing table is a table of Alt/Az values that corresponds to a single pointing.

If a pointing is called “a fixed position in AltAz”, then, each element in the table is a pointing (and then a Fixed RA/Dec is no longer a single pointing either)...

I thought it was a bit simpler thinking of a pointing as a fixed direction on the sky, and the table is just needed to translate that pointing into earth-based coordinates (therefore there is only one pointing).

If you want to be really general (and also allow the case of a drift scan where Alt/Az is fixed, or a slew scan where everything changes), than a concept of Pointings could be introduced, however you then need to differenciate between RA/Dec and Horizontal pointings.

actually, thinking about it more, I do like your GCTAPointings class, but I was confusing it with just a container of GCTAPointings (which it isnt: it’s more of a factory class that genreates a GCTAPointing given a time). It may give the same GCTAPointing over and over again, with only the horizontal coordinate changed, for example. That does work generally, and there is no longer a concept of tracking/drift/slew, etc.

It might be nice to give it a better name Than GCTAPointings though, which to me implies a container, not an interpolator. GCTAPointing is the return value, and is an instantaneous pointing direction. Maybe GCTAPointingEvolution or something like that for the class that describes the time-based pointing, rather than the instantaneous one? or you could use GCTATracking for the collection, and GCTAPointing for the instantaneous value (since tracking implies a change in time)

GCTATracking::get_pointing(time); // returns a GCTAPointing given a time
CCTATracking::get_mode();    // returns GCTATracking::FIXED_RADEC, ::FIXED_ALTAZ, ::SLEW? 

Yes, my idea was that GCTAPointing is an instantaneous pointing direction, while GCTAPointings is a collection of pointing directions. I guess it still could act as a container (so that it can also be used to simply create or concatenate point tables), while it will have interpolation methods that allow to derive interpolated instantaneous pointing directions. In this sense it would be more a factory, but is this conceptually bad that a container has factory-like methods?

Ok, I’m happy with it then. It was just a question of terminology: normally when we say there are multiple “pointings”, we mean multiple fixed-positions on the sky (e.g. the galactic center, the crab nebula, etc). During a pointing, the telescopes track in some way. So normally, for a single observation there is a single pointing, but during that pointing the tracking position may change in either alt/az, ra/dec, or both in the case of slewing. I think if it’s well documented what you mean by GCTAPointings, its ok, but just by reading the name of the class, I would expect it to be a list of fields of view, not the instantaneous position during an observation. Again, it’s another case where we need a good CTA dictionary to define terms...