Chandra-MARX / marx

Chandra X-ray Observatory ray-trace simulator
http://space.mit.edu/cxc/marx/
5 stars 4 forks source link

New keywords in evt2 file #7

Closed hamogu closed 9 years ago

hamogu commented 9 years ago

Chandra repro-4 added new header keywords to evt2 files. Before, these parameters where read from the pbk and asol files, now access to these files is no longer required for some processing tools. On the downside, these tools will now break with an error if the header keywords are not present (even though I am not convinced that they actually need them in some cases). I noticed this in the scripts that make the grating responses (mkgarf, mktgresp, fullgarf). MARX should add those keywords with reasonable value to the fits files it generates.

Here is more info on those changes, pulled from the CIAO docs:

For ACIS and HRC, three new keywords were added to capture the mean SIM offsets during an observation: DY_AVG, DZ_AVG, and DTH_AVG. These numbers are needed by tools like dmcoords, mkacisrmf, and mkwarf to correctly map detector coordinates back to the location on the instruments. Previously each tool used the information in the asolfile parameter to compute the mean value, every time the tool was run. With the mean values now simply encoded as header keywords, the tools can run more efficiently.

For ACIS, the information in the Level 0 parameter block file, pbk0, needed to compute the dead area calibration was also added to the event file headers. The new keywords include: SUM_2X2, FEP_CCD, ORCMODE, and OCLKPAIR. This information together with some existing keywords, is used by ARF and Exposure map tools when creating response.

http://cxc.harvard.edu/ciao/watchout.html

http://cxc.harvard.edu/ciao/ahelp/r4_header_update.html

hamogu commented 9 years ago

To find out which values these keywords have when I add them to MARX simulated data, I contacted Cathrine Grant. Here is her response:

I'm not a CIAO expert in any sense, so I'm not sure where any of these parameters would get used, once you get past the initial level 0 processing. Glenn would probably know better than I. They all come out of the parameter block that gives ACIS the parameters for each science run. They are not user selectable parameters, thus they don't get mentioned in the POG.

As far as I am aware, we have never changed the values of OCLKPAIR, ORC_MODE, or SUM_2x2 since launch, except possibly in the checkout period before the doors were opened. The only reason we would change these would likely be associated with some kind of major instrument anomaly, so I would think leaving these at the defaults you have below should be fine.

The below is off the top of my head. I couldn't quickly find any useful documentation, although I'm sure there's something out there.

OCLKPAIR. Every time a row of data is read out of one of the four CCD amplifiers, additional "non-physical" pixels are read out after the real pixels. For OCLKPAIR=8, you get an additional sixteen "blank" pixels per row for each of the four output nodes. These "overclock" pixels have the same bias level and electronic noise as the imaging pixels and are used to track the variation of the bias level throughout a science run and to flag data frames that are anomalously noisy. I think the overclocks are only used during event finding and bias subtraction, both of which are done on-board and again on the ground in level 0 processing.

ORC_MODE. Each ACIS CCD has four output nodes. The standard readout direction has the outer nodes (node 0 and 3) clocked towards the edge of the CCD and the inner nodes (1 and 2) clocked toward the middle. You can, however, choose to change the direction of the clocking and read out different CCD regions from different amplifiers, i.e. clock the CCD such that all of nodes 0 and 1 gets read out in the middle, for example. This would be helpful if there was some kind of hardware problem with an amplifier or some other kind of physical damage that you would trying to avoid clocking through.

SUM_2x2. Pretty much what it sounds like. The pixels are clocked such that the charge in a 2x2 pixel region is combined into one summed "pixel". It's never been calibrated and isn't particularly useful for ACIS for a variety of reasons. I think Astro-H SXI will be run using summed pixels.

FEP_CCD. ACIS has six Front End Processors (FEP) that each can talk to one of the ten CCDs. The parameters blocks contain the assignments of which FEP will talk to which CCD during a science run. In the case below the assignments are: FEP 0 = CCD 4 (S0) FEP 1 = CCD 7 (S3) FEP 2 = CCD 5 (S1) FEP 3 = CCD 6 (S2) FEP 4 = CCD 8 (S4) FEP 5 = CCD 9 (S5) Royce Buehler has a ruleset he uses to determine the FEP/CCD pairing for each parameter block and the FEP/CCD mapping can change from observation to observation. The one here is a pretty standard one for 6-chip grating observations. I'm not sure if MARX or CIAO would ever care about what FEP was being used, since all the calibration is CCD-based.

Hopefully this makes sense and helps!

Catherine

hamogu commented 9 years ago

For the internal dither model dy, dz and dtheta are hardwired to 0 in https://github.com/Chandra-MARX/marx/blob/master/marx/src/marxasp.c#L864 so for DitherModel=INTERNAL I can just output 0.

Now I need to find a way to handle an externally supplied asol file. Alternatively, I could just ask the user to run r4_header_update.

hamogu commented 9 years ago

So, the only problem is FEP_CCD. Talking with Kenny, here is a solution that will make CIAO tools run: The FEP_CCD is used by the tools that include the "dead area" calibration -- so it will be all the tools that compute the effective area : mkarf, mkwarf, mkgarf, mkinstmap, eff2evt, and I'm probably missing couple.

The dead area calibration (at least right now, and for the foreseeable future) only depends on the number of CCDs that are "clocked" out -- not their order.

So yes, I think you can use standard values

DETNAM = 'ACIS-0123' -> FEP_CCD = '0123xx' DETNAM = 'ACIS-456789' -> FEP_CCD = '456789'

Kenny

However, if run like that, the effective area will be between 2.2 and 4% too high (depending on the chip position): http://cxc.harvard.edu/ciao/why/acisdeadarea.html

Not setting this parameter in marx2fits will require users to set pbk=None by hand, as explained in the MARX help (Section: Generating ARF and RMF with CIAO); on the other hand, in most situations we probably don't care about a 4% effect in the arf and life is just so much simpler if standard CIAO tools just work.

hamogu commented 9 years ago

Related, a user request per email: Hello Moritz, a science group here at CXC is interested in running some of the high level scripts (in particular reproject_obs, but could also be merge_obs and flux_obs) on MARX generated event files.

The scripts were not tested on simulated data but there is no reason why in principle they could not run on those. However currently keywords are missing from the header (for example reproject_obs need a non-zero OBS_ID, FP_TEMP and RAND_PI). Maybe they can be set in the obs.par (I don't know)?

When you have time it would be good to do some tests and see what is needed in the MARX files to run smoothly with the scripts. Then we could add notes on our threads.

Thanks, XXX

P.S. Recent email from Doug: The OBS_ID value is used to match up event files with asol/mask/badpix/... files, so they need to match (i.e. you can't just set OBS_ID to a non-zero value, it has to match the value in the relevant aspect file). If you want to use the same aspect file for multiple event files (not sure that you do), then you need to have separate copies of the event file, each with different OBS_ID values.