Change request #2054
MJD reference date in the output file of the ctbin task
|Assigned To:||Knödlseder Jürgen||% Done:|
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.
#1 Updated by Knödlseder Jürgen over 1 year ago
- Assigned To set to Knödlseder Jürgen
- Priority changed from Normal to High
- Target version set to 1.6.0
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 1 year ago
- Status changed from New to In Progress
- % Done changed from 0 to 50
init_members() methods of
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
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.
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 1 year 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)
mjdrefparameter was added to the following tools to allow the specification of the reference time for times provided in MET:
obsutils.set_obs() function now also has a
mjdref optional parameter.
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 1 year 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.
#6 Updated by Lucarelli Fabrizio over 1 year 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