gtltcube no longer works without an input events file

[joeastro]

It used to be possible to run this tool without an input events file, which was useful for making exposure maps for future times. This behaviour is actually necessary for the mission planning software, since part of that routine creates all-sky exposure maps for the week being planned.

I believe this ability was present during the first one or two conda releases, and I'm certain it was in the last release before we switched to conda.

Command that produces the error:

$ gtltcube Event data file[] Spacecraft data file[FERMI_POINTING_PRELIM_562_2019066_2019073_00.fits] Output file[ltcube_MW562.fits] Step size in cos(theta) (0.:1.) [0.025] Pixel size (degrees)[1] Working on file FERMI_POINTING_PRELIM_562_2019066_2019073_00.fits WARNING: No intervals have been read in from the FT2 files that correspond to the FT1 data. All livetimes will be identically zero.

[jasercion]

Thanks @joeastro. I'll take a look at this.

[jasercion]

Interesting...the code that throws that warning hasn't been touched in quite some time. Latest commit is from jchiang back in August of 2013. It could be something happening several reference layers down though. The Fermitools-1.0.0 never threw that warning?

[joeastro]

No, it never did. I wrote an iPython notebook that used gtltcube without an events file, and it worked fine with the same commands as above.

[jasercion]

Could you diff two livetime cubes generated with the same input (1.0.0 vs 1.0.1) and post the output?

[donhorner]

If I run the command in the operations account here (which uses a very old version of the ScienceTools) using the same FT2 file, I get the same WARNING message, so I think that it's maybe always done this. Is the file it makes actually bad?

[jasercion]

I was thinking along the same lines. It may that iPython was previously suppressing the warning (unless you are now seeing the warning with the new version using the same notebook/script).

[joeastro]

OK, let me compare the output created with the old vs. new versions of the tools and report back.

[joeastro]

The output files are certainly different - I compared on that created today with FermiTools 1.0.3, and another that was created with the same commands using the old version of the ScienceTools that TAKO uses:

          ftdiff V1.38

ltCube/ltcube_MW562_pm50_b_p02.fits[0] < ltCube/ltcube_MW562_pm50_b_p02_test.fits[0] >

< card 14: DATE-END = 2019-03-13T22:10:25.9999

card 14: DATE-END = 2001-01-01T00:00:00.0000

< card 13: DATE-OBS = 2019-03-13T18:59:59.9999 card 13: DATE-OBS = 2001-01-01T00:00:00.0000

< card 23: FILENAME = ltcube_MW562_pm50_b_p02.fits card 23: FILENAME = ltcube_MW562_pm50_b_p02_test.fits

< card 15: TSTART = 574196405. card 15: TSTART = 0.

< card 16: TSTOP = 574207831. card 16: TSTOP = 0.

< calculated DATASUM=2867462615 calculated DATASUM=1365838511 --- These two data units are not identical.

[joeastro]

I'll install FermiTools 1.0.0 and test again.

[donhorner]

I used Fermitools 1.0.0 and got the same message. My questions was more about whether the file produced is actually valid. Have you tried using it to compute an exposure map? I don't suppose you have any older livetime cubes around to check against?

[joeastro]

We can chalk this one up to user error and close, I think. I copied the commands above from another script that I did develop using FermiTools 1.0.0, but I left off the parameters TMIN and TMAX, which are "hidden". It seems that they are not needed when providing gtltcube with an events file, but are needed when just supplying an FT2 file.

[donhorner]

OK. I'm closing the issue.