I have been observing some issues with the data we get from the FSSC. This started taking place after the FSSC implemented the weekly boundaries in the ft1 files.
The aperture photometry light curve below is for Vela and it shows some really strange behavior in the last 3 weeks or so:
I use a python script I wrote to download and merge the data every night. I have used this script for more than a year and never so problems
and have not updated it recently so my first guess was that there is something wrong with the data I am getting from the FSSC. To exclude
this possibility I decided to generate a merged ft1 file using different methods. These methods are described in the table below and
the corresponding figures for Vela are attached. All of these were run form the command line to avoid any issues in the script.
As one can see every thing look normal using any of these methods. Method 2 in the table is what I do in the script except that in
the script I also run ftsort on the merged ft1 file to speed up the execution of gtbary which we tend to use a lot at NRL.
| Step 1 | Step 2 | Light Curve | Exposure |
|---|---|---|---|---|
1. | gtselect: time selection=YES, event selection=NO | fselect: event selection=YES | | |
2. | gtselect: time selection=NO, event selection=NO | fselect: event selection=YES | | |
3. | gtselect: time selection=YES, event selection=YES |
| | |
4. | gtselect: time selection=NO, event selection=YES |
| | |
5. | fselect: event selection=YES | ft1merge | | |
6. | fselect: event selection=YES | gtselect: time selection=YES, event selection=NO | | |
So I became suspicious of the sorting done with ftsort. So I modified my script to not run ftsort and it is now all clear that with the new way
the FSSC is processing the events ftsort seems to miss things up and I don't recommend running it until we figure out what is going on with the
reprocessing of the files in the FSSC.
No ftsort | ftsort |
|---|---|
| |
