| Question | Answer |
|---|
| The link yesterday did not work, so I missed the entire data analysis session. Were
these recorded and will they be posted? | A link to the video has been posted to the
agenda page. Please copy the access password exactly. (There is a leading period included) |
| Why is the default refframe for barycorr still FK5? That really should be
changed. | It's mostly a compatibility thing for folks that don't change the
defaults |
| What happens first, telemetry saturation or pile up? | Almost always, the
problem is telemetry saturation. I think we have only seen mild pile-up effects in Sco
X-1. |
| In the NICER analysis guide there is no "ephem=". What is the ephemeris that is being
used if we use the following from the analysis guide? | Default is DE200, which was
released in 1980s, usually OK for slow pulsars. |
prompt> barycorr infile=orig.evt outfile=bary.evt
orbitfiles="$obs/auxil/ni${obsroot}.orb"
ra= dec=
refframe=ICRS | If you set reffreame=ICRS, then the default ephemeris is
DE405 |
| This example Tod is showing would only happen if you take a long FFT without
cconsidering the GTI, right? | Correct. |
| Once we have used the barycorr tool, do we calculate the MJD from the Time column in
the same way as before? (i.e. MJD(UTC) = MJDREFI + (TIME + TIMEZERO -
LEAPINIT)/86400.0) | Yes, same process |
| Could you say something about the effect of ISS vibration on timing? | This
question has been answered live |
| How high would be a typical modulation of the observed count rate if the source is not
on-axis? | The shape of the off-axis response profile is somewhat gaussian. The
half-max is at about 180" off axis |
| Are there any timing signatures that one should be aware of when comparing different
energy bands due to undershoot events for example? | For the most part, no. However, at
high undershoot levels the noise peak is greatly enhanced. That peak shows up at about 0.12
keV, but the tail of the peak can extend up to 0.35 keV. The noise peak is obviously
background-like counts that will interfere with your science and should be avoided |
| Can we expect to observe spurious dips in the light curves of faint X-ray sources? It
is mentioned in the GOF webpage that one has to be cautious about spurious dips in the case of
bright sources though! | The answer is that one should always be watchful regardless of
source brightness, but short dips will be most visible for bright sources. Spurious dips occur
only during orbit night and the unanticipated ISS obstructions that cause them are rare. |
| On one of the slides it was stated that the night library needs to be normalized by
ibg_i / ibg_lib, but for the daytime library it said nz_lib / nz_i. Why are they flipped
around? | I think this is a typo, and should be nz/nz_lib (that's what the tool
uses) |
| Does nibackgen3C50 will also provide the detector background file? Or does it return
only total background (detector + Sky x-ray background)? | It returns the total
sky+detector, since the background fields from which the library spectra are derived have
both. If your source is in a region of high sky background you ought to add an additional
component, accordingly, to account for that. |
| Could I use the gainepoch option 2021 also for observations that were performed before
2021? | The best option is to use nicerl2 to re-process such data with the latest gain,
and then use the 2021 gainepoch. That is, use gainepoch=2020 - the difference between the
latest gain and the 2020 gain is minimal. |
| Is it prefeble to use the total spectrum produced by 3c50 or the one extracted with
xselect? | The spectrum produced by 3C50 will throw out time intervals that lie outside
the library, and so in principle is more appropriate. But you can try both - esp. if there is
significant difference in exposure time. |
| Is it possible to calculate a background light curve using 3C50 model? | The
nibackgen3C50 tool does not calculate light curves, though a future version very well might.
Currently you would have to run it sequentially for each light curve bin, and derive the rates
from the spectra. |
| Is there any method one can extract detector background only? Because we are
interested in modeling the sky x-ray background. | Both background estimation tools use
blank sky fields that contain sky and detector components. |
| Do we need to update the KP.fits file everytime we run the background estimator using
the space weather model? | In principle, yes. There is more discussion of this here:
https://heasarc.gsfc.nasa.gov/docs/nicer/analysis_threads/geomag/ |
| How the low energy background is evaluated? For E< 1keV for example? | The
background methods are not energy specific. Basically both methods make a library of
background spectra, so the estimate is based on real data. |
| I know Craig talked about solar optical loading yesterday, but there also any evidence
for X-ray leakage from prompt solar events (flares, active regions, etc)? I guess that would
also be present in the day/night spectral differences, but these events have structure
(emission lines) in the NICER band. | NICER is pretty well buttoned up. There are few
surfaces where reflected solar X-rays would be visible by NICER. The background estimates do
show evidence of lines, which appear to be from the CXB. Also perhaps some Oxygen reflected
by diffuse atmosphere |
| Does the Kp background model allow us to remove certain FPMs? | it allows you to
scale for the number of fpms but not exclude individual ones. So if your observation has
N_fpm < 52, you can scale the background for the number of FPMs used. |
| For the nibackgen3C50 tool version6, the option gainepoch='2021' is not supported. Is
it reasonable to use gainepoch='2020' for observation carried out in 2021? | Yes, as Ron
mentioned in his talk, the difference between the latest gain and the 2020 gain is
minimal. |
| The lightcurve background generator methods was in development status in the source
code and undocumented in the earlier versions. Is it production ready now? Any caveats about
light curve background extraction with nicer_bkg_estimator? | This question has been
answered live |
| For the bkg lightcurve calculator, is it true that the background estimate will only
change as fast as KP or COR_SAX change (so it won't reproduce any short timescale background
flaring)? Also, how does it know what energy band to use? | Yes, the lightcurve
generator will not account for flares. Flares may be diagnosed by creating a lightcurve of
the "trumpet"-filtered events. There's a chanrange pararmeter that can be passed
(the default is to use channels 40-1500) |
| Do we have a good idea of the systematic uncertainties in either of the background
estimate models? And how do they compare to one another? | This question has been
answered live. There is additional discussion of this question in the Wednesday Q & A
session. |
| Are the 3C50 and "space-weather" models just the result of two different
"philosophies" or have they been designed to be used in specific (different) situations? In
case of the latter, which model is suggested to be used in which situation? | Mostly two
different philosophies. Since NICER is a non-imaging system, we need to model background
based on some other parameters. The two developers chose different parameters. |
| This is a comment but from some of the questions I think it is worth clarifying that
the gain epoch refers to the version of gain calibration to use (i.e. what year that gain
model was released), not when the observation was obtained. Observations from any date can (as
far as I know) be recalibrated to any gain model - ideally the latest version should be used
in all cases. Perhaps calling them gain epochs is confusing since RXTE PCA also had gain
epochs which were actual changes in the gain rather than our understanding of the
calibration. | Good point - although the parameter is defined in the help file and
parameter list. We can certainly consider renaming it. |
| Maybe I missed it, but why not use Kaastra's optimal binning that kind of deals with
this? | I think he's getting to it. But optimal binning also sometimes doesn't put
enough counts per bin. For the next release, "ftgrouppha" has an option to do Kaastra's
binning PLUS ensuring a minimum count per bin. |
| Those two spectra with different rebinning did not appear to be the same. The
rebinning issues are for making sure you are applying the right statistics, but cannot change
your data | Thanks for your input! |
| You suggested to fit spectra one-by-one, but you may want to consider fitting them all
at the same time in xspec linking some parameters (e.g., NH, black-hole spin, inclination
etc.) | This is a useful suggestion |
| Can we combine NICER spectra between each other in the case of observations close in
time? How can we do this? | You could read the event files into xselect and extract a
spectrum - the spectrum will be the combined spectrum from all the input event
files. |
| But in this case how can I extract the background spectrum for the combined
spectrum? | One method would be to estimate the background from the individual
observations then add the pha files together. You can also use the SW background method
directly on the combined pha file, but you'll need an mkf file which covers the entire
(combined) dataset |
| OK, I think Ron compared the effect of having the spectral bins resampled by a factor
3 with this AND "group min=25". I was wondering how having just "group min=25" does improve
(or not) the fit (I personally use to content myself with that)? | At some point it's a
scientific judgement question. There is a tool called ftgrouppha in HEASoft which can provide
Kaastra's "optimal" binning. In the next release you can also require a minimum number of
counts. |
| Once I extracted the background file for each observation, do you suggest to use
addspec/addascaspec in order to obtain the background, ARF and RMF files for the merged
spectrum? | Use addspec/addascaspec to combine the individual background
spectra. Assuming all the observations were obtained on-axis, you wouldn't need to combine
the arfs or rmfs when analyzing the combined (background-subtracted) spectra, since the only
difference in the combined spectrum would be the exposure time. |
