[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

New XRT response software. [xrt_co:]

Dear XRT enthusiasts,

We are announcing the release of a calibration update and some new  
XRT software. While some testing has been done, it is realistic to  
expect that some of you may uncover new bugs. Please think of this as  
a "beta" release, and contact us with any problems you encounter. The  
new calibrations updates are available to you by using the new  
software, which is distributed in the normal manner through the XRT  
SolarSoft tree. (The update should percolate through SolarSoft  
sometime around Oct.7-9.)

Bug reports should be sent to xrt_manager@head.cfa.harvard.edu, but I  
encourage you to also have discussions on the majordomo community  
list at xrt_users@head.cfa.harvard.edu .

Before I give an overview of the changes, let me say that the XRT  
Analysis Guide will be updated to describe this new software, but is  
not yet ready. However, the program headers already include extensive  
documentation, and should be good enough for you to try the software.  
The XAG should be updated some time before the end of the month  

Why the changes? First, Narukage-san has completed a re-evaluation of  
the calibration ground-tests and has modified the instrument SXR  
response model. (He is finishing a paper on this.) Second, since the  
last major release, we have discovered a contaminant layer on the CCD  
that accumulates with time, and we bake it off every 3 to 4 weeks.  
The effect of this layer needs to be accounted for in the effective  
area, and is necessarily dependent on the specification of a data set  
or mission time. This required some re-arrangement of the program  
flow. Third, users are anxious to apply their own CHIANTI or APEC  
models to create temperature response curves. Although this  
functionality was present in the previous release, we have tried to  
make it a little easier for users.

Regarding the responses, what has not been accounted for in this  
release? (1) The XRT Team has begun to investigate a possible  
contamination layer on one or more of the filters. There are some  
inconsistencies in the current responses that we do not yet  
understand, which we are considering as an "on-orbit" calibration  
problem. Nevertheless, this current calibration update represents the  
Team's best current understanding of the instrument responses  
according to all of our ground tests (specifically, the filter  
thicknesses and aperture area). (2) The XRT Team will now be working  
on software for estimations of the measurement errors.


- To get the effective areas and spectral responses, it is now  
necessary to specify a thickness for the CCD contamination layer.  
This may be specified by a data set INDEX, by a mission time, or by a  
simple thickness. You use a single program called  
<make_xrt_wave_resp.pro>, which you may learn to use by reading the  
program header documentation. Here is a sample....

;       Basic usage #1 (for a datacube INDEX, DATA):
;       IDL> help, data, index
;       IDL> w_resp = make_xrt_wave_resp(index=index)
;       IDL> help, w_resp
;       IDL> help, w_resp, w_resp.effar, w_resp.sprsp, /st
;       Basic usage #2 (for all channels with single contamination
;                       thickness):
;       IDL> w_resp = make_xrt_wave_resp(contam_thick=500.)  ;;  
;       IDL> help, w_resp
;       IDL> help, w_resp, w_resp.effar, w_resp.sprsp, /st
;       Basic usage #3 (for all channels at single mission time):
;       IDL> ctime = '2007-May-25 10:00:00'
;       IDL> w_resp = make_xrt_wave_resp(contam_time=ctime)
;       IDL> help, w_resp
;       IDL> help, w_resp, w_resp.effar, w_resp.sprsp, /st
;       Plotting the effective area for the 3rd image:
;       IDL> ichn = 2
;       IDL> print, w_resp[ichn].effar.name
;       IDL> wlen = w_resp[ichn].effar.length
;       IDL> plot,  w_resp[ichn].effar.wave[0:wlen-1], $
;       IDL>        w_resp[ichn].effar.eff_area[0:wlen-1]
;       Check the x-ray channel ID and contamination thickness:
;       (This info should be in w_resp[ichn].name, too.)
;       IDL> print, w_resp[ichn].confg.name
;       IDL> print, w_resp[ichn].contam.thick, $
;       IDL>        w_resp[ichn].contam.thick_units

- To get the temperature responses, it is necessary to specify (a)  
the spectral response, which comes from <make_xrt_wave_resp.pro>; and  
(b) a spectral emission model, such as comes from APEC or CHIANTI.  
You use a single program called <make_xrt_temp_resp.pro>, which you  
may learn to use by reading the program header documentation. Here is  
a sample....

;       Basic usage:
;       IDL> t_resp = make_xrt_temp_resp(w_resp, emiss_model)
;       IDL> help, t_resp
;       IDL> help, t_resp, /st

There is a default APEC model available for your convenience:

         Basic usage:
         IDL> t_resp = make_xrt_temp_resp(w_resp, /apec)

We are preparing a more up-to-date APEC default model, and we are  
preparing an up-to-date CHIANTI option.

- What if you want to apply your own spectral emission model? You  
must use CHIANTI or APEC yourself to get the model. However, this  
information must be put into a particular format so that you may use  
it as an input to <make_xrt_temp_resp.pro>. You may use the program  
<make_xrt_emiss_model.pro> to assist you in transferring your model  
information into the correct format. (Hint: Use /VERBOSE so that it  
can tell you what your mistakes are, if it catches any.) You are  
strongly encouraged to read the program header in order to understand  
what information is expected. There are some "mandatory" details  
(such as the name of the ionization model) that do not directly  
affect the calculation of the temperature response curve, but which  
represent information that is crucial for describing the temperature  
responses. We STRONGLY encourage users to provide these details.

- Using the DEM solver. The previous solver <xrt_dem_iterative.pro>  
has been updated and named <xrt_dem_iterative2.pro>. The new program  
is compatible with the new format of the temperature response  
structures. It works almost identically, but now the temperature  
responses are mandatory, are provided explicitly by the user, and are  
a parameter input instead of a keyword.