I can tell you what is happening in the XSPEC case and it looks as though
Sherpa copied XSPEC here. The assumption I made is that you create an arf
on energies supplied from an appropriate rmf file. The keyword in the arf
then tracks which rmf file was used for the energies. If this keyword differs
from the rmf read into XSPEC then there is a chance the user has made a
mistake hence the warning message.
What happens in psextract is that mkarf is run with the energies specified
by the input string 0.1:11.0:0.01 (ie start at 0.1 keV go up to 11.0 keV in
0.01 keV steps) hence this gets written into the keyword in the arf. Now,
psextract uses exactly the same energies to make the rmf so you are fine here.
While we are on the subject here is my latest pet peeve. If you do run mkarf
with the option to take the energies from the rmf you have to specify the
following string 'grid(source.rmf[matrix][cols energ_lo,energ_hi])'. When
I last checked this was wrong in the documentation. It also seems to be giant
leap backwards in user-friendliness. mkarf ought to know enough to look in
the correct columns in an rmf file.
On Fri, Jan 12, 2001 at 09:39:14AM -0500, Casey Law wrote:
> I've seen the second bug, regarding the arf file having 'RSPFILE' misset, in
> my own work. The header RSPFILE is equal to '0.1:11.0:0.01', just as in your
> data. In my case, I used Sherpa to work with the spectrum. After loading the
> data 'data source.pi', Sherpa automatically looks for associated files with the
> same base, 'source.rmf' and 'source.arf'. Although Sherpa give an error
> message similar to XSPEC (since it can't fine '0.1:11.0:0.01') it loads the
> 'source.rmf' file, and seems to use it properly.
> I don't know the source of these numbers, but I'll be sure the psextract
> developer gets this. Hopefully, we'll have another fix soon.
This archive was generated by hypermail 2b29 : Wed Jun 19 2013 - 01:00:03 EDT