Change request #2054
MJD reference date in the output file of the ctbin task
| Status: | Closed | Start date: | 04/28/2017 | |
|---|---|---|---|---|
| Priority: | High | Due date: | ||
| Assigned To: |  Knödlseder Jürgen | % Done: | 100% | |
| Category: | - | |||
| Target version: | 1.6.0 | |||
| Duration: |
Description
During the analysis of some simulated DL3 events and IRFs produced with the ASTRI scientific analysis software (A-Scisoft) with CTOOLS, we have found that the ctbin task appends to the output fits file the CTA MJD reference date 51544.5.
We actually are using a different MJD reference date (which is correctly reported in the keywords of the initial DL3 event list) and we think the task should mantain the reference date read by the input file (ctselect, for example, does not change the MJDREF in the output fits).
Besides that, we have seen that ctbin also changes the time intervals in the GTI extension (perhaps because it changes the initial MJDREF), while again ctselect does not touch the initial GTI extension.
Is it possible to add some control in ctbin about the presence of an initial MJDREF value and continue to use that (and keeping the same GTI extension)? Thanks.
Recurrence
No recurrence.
Related issues
History
#1
Updated by Knödlseder Jürgen over 6 years ago
- Assigned To set to Knödlseder Jürgen
- Priority changed from Normal to High
- Target version set to 1.6.0
Dear Jurgen,
some time ago (last year, to be precise), I sent you the email below, concerning a problem that we are facing applying the CTOOLS tasks to the ASTRI DL3 event files, which are generate with a different MJDREF reference date (MJD=51910) with respect to the CTA MJDREF (55197). As you probably remember, we opened an issue on the CTOOLS redmine (#2054) concerning the ctbin task, but we found the same behaviour also with the ctselect task (as written in the email).
For this last one, we could avoid the problem setting tmin/tmax=0: in this way, our temporal keywords and the interval in the GTI extension (compliant with our event time interval) were mantained. This little trick does not work anymore with the last ctools version (v1.5.2), and we end with an empty file since the GTI time interval is re-calculated with respect to the CTA MJDREF and, as reported in the log, “There is no overlap between existing and requested time interval”.
I have seen that the issue on the ctbin task has not been worked yet. We did not opened a new issue concerning also the ctselect task, but we think the behaviour is the same. Do you plan in the near future to have a look at that? In our opinion, the tasks should mantain the reference date (and the GTI interval, if already present) read from the input files. What do you think?
Thanks in advance for your answer,
Fabrizio, Martina, and Saverio
#2
Updated by Knödlseder Jürgen over 6 years ago
- Status changed from New to In Progress
- % Done changed from 0 to 50
The init_members() methods of GCTAEventList and GCTAEventCube were setting the time references of the m_gti member, but the copy_members() methods did not copy that data member, hence any copy of GCTAEventList or GCTAEventCube had the standard CTA time reference as the reference.
This was changed now, and both classes now copy the m_gti member, preserving the original time reference.
I checked that when doing a ctselect on an event file with a time reference that is difference to the CTA time reference, the time reference is preserved.
Still, ctbin changes the time reference, hence I need to see what’s going on there. Probably also other tools, such as ctexpcube, etc., should be checked.
#3
Updated by Knödlseder Jürgen over 6 years ago
- % Done changed from 50 to 60
I added a mjdref parameter to ctobssim so that events can be simulated using a user defined reference MJD. I checked using the ASTRI reference MJD that the functionality works.
ctselect(apply reference of each observation)csobsselect(apply reference of each observation)ctbin(use reference of first observation)
mjdref parameter was added to the following tools to allow the specification of the reference time for times provided in MET:
ctobssimcslightcrvcspullcsviscubecsobsdef
The obsutils.set_obs() function now also has a mjdref optional parameter.
The ctools::time_reference constant was removed. The only place where the ctools depend explicitly on the CTA time reference is the GCTAObservation ctool::create_cta_obs() method for the case that no mjdref user parameter exists in the tool.
#4
Updated by Knödlseder Jürgen over 6 years ago
- % Done changed from 60 to 70
To forward the correct time reference for an exposure cube, and for compatibility with ctbin, the time reference of the first observation is now used when building an exposure cube. The GCTACubeExposure::fill_cube() method was adapted accordingly.
#5
Updated by Knödlseder Jürgen over 6 years ago
- Status changed from In Progress to Feedback
- % Done changed from 70 to 100
All changed were merged into devel.
Fabrizio, could you please check that everything is as you expected?
#6
Updated by Lucarelli Fabrizio over 6 years ago
Dear Jurgen, as you requested, I have downloaded and installed the last devel version (1.6.0.dev1) on my Mac and tested both ctselect and ctbin using in input one of the ASTRI DL3 input files with their own MJDREF (51910).
Everything is fine now: the output files are not empties and all the initial temporal keywords (MJDREF, TSTART/TSTOP) and GTI intervals are mantained.
Thanks a lot!
Fabrizio, Martina and Saverio
#7
Updated by Knödlseder Jürgen over 6 years ago
- Status changed from Feedback to Closed
Great, so I close the issue you.
#8
Updated by Knödlseder Jürgen almost 6 years ago
- Related to Bug #2776: event time bug from gammalib 1.4.0 to 1.5.2 added