Up to top level
AO15   AO16   AO17   AO18   AO19   Backgrounds   Calibration   Conference   Data   Docs   EPICMOS   EPICpn   Feedback   Gallery   Misc   OM   Pending   PhD_Theses   Publications   RGS   RadMonitor   SAS_Hardware   SAS_WS   SASv16.0   SASv16.0_Installation   SASv16.1   SASv16.1_Installation   SASv17.0   SASv17.0_Installation   SASv18.0   SASv18.0_Installation   SciSim   Simulators_other   Suggestions   Trash   Visibility   XMM-bouncing   XMM-news   XRPS   XSA   esas   incoming  

Logged in as guest

Viewing OM/9061
Full headers

From: lucio@mi.iasf.cnr.it
Subject: OM "uvflux" recipe (which pixels ?)
Compose reply
Download message
Move To:
3 replies: 1 2 3
1 followups: 1

Private message: yes  no

Notes:

Notification:


Date: Tue, 26 Aug 2003 16:41:24 GMT
From: lucio@mi.iasf.cnr.it
To: xmmhelp@xmm.vilspa.esa.es
CC: lucio@mi.iasf.cnr.it
Subject: OM "uvflux" recipe (which pixels ?)
Full_Name: Lucio Chiappetti
Submission from: (NULL) (155.253.16.87)


With reference to the updated recipe at
http://xmm.vilspa.esa.es/sas/documentation/watchout/uvflux.shtml
which mentions source extraction radii of 12 and 30 pixels, to which kind of
images do these pixel refer ?  ODF or pipeprod ones, raw or sky images, big or
small (0000 or 1000) images ?

For the recipe to be applicable, should these count be extracted by a specific
SAS task, or can be extracted in any way (long ago I extracted count rates 
directly from FITS images using a very very simple IDL procedure, but used 
altogether different radii) ?


Reply 1

Resend
From: Michel G. Breitfellner <xmmhelp@xmm.vilspa.esa.es>
To: lucio@mi.iasf.cnr.it
Subject: Re: OM "uvflux" recipe (which pixels ?) (PR#9061)
Date: Wed Aug 27 10:10:24 2003
Dear Dr. Chiappetti,

The two values of source extraction radii mentioned are
refering to the two apertures used:
12 pixels without binning
 6 pixels with    binning
30 pixels without binning for the background
15 pixels with    binning for the background
These do not depend on neither ODF nor pipeprod nor raw
nor sky nor big nor small images.

In general we recommend to use the SAS omichain task
to process your data. This will give you count rates
in the end.

With best regards,
Michel G. Breitfellner
XMM-Newton User Support Group


Followup 1

Compose reply
Download message
Date: Wed, 27 Aug 2003 16:09:03 +0200 (MET DST)
From: Lucio Chiappetti <lucio@mi.iasf.cnr.it>
To: "Michel G. Breitfellner" <xmmhelp@xmm.vilspa.esa.es>
Subject: Re: OM "uvflux" recipe (which pixels ?) (PR#9061)
Thank you for your reply. I still have a couple of questions and a few
suggestions for the recipe page in
http://xmm.vilspa.esa.es/sas/documentation/watchout/uvflux.shtml

On Wed, 27 Aug 2003, Michel G. Breitfellner wrote:

> The two values of source extraction radii mentioned are
> refering to the two apertures used:
> [xxx] without binning
> [xxx] pixels with    binning
> These do not depend on neither ODF nor pipeprod nor raw
> nor sky nor big nor small images.

Well, actually the uvflux.shtml web page does not mention binning at all
nor the values "with binning". Perhaps it should.

Also what I meant by "big" and "small" images should refer just to
binning. The "small" images for me are those who carry 0000 in the
filename (e.g. *omsimage_0000.ftz), and the "big" ones those with 1000 in
the filename.

The 0000 have keywords BINAXn=0 (n=1,2) in the header which should mean
binning 1 (without binning), the 1000 have BINAXn=1, i.e. binning 2 (with
binning). Perhaps this should also be mentioned in the recipe.

Finally the recipe contains at point 4 of method 1 a reference to the UHB
which requires some searching. One should perhaps make a more explicit
reference to section 3.5.6 of UHB !


> In general we recommend to use the SAS omichain task to process your
> data. This will give you count rates in the end.

Well, what I'm after is just the flux of the central target. I do not have
any need or interest in running a detection algorithm on the entire field
(I just need to extract the counts from the 0000 images of any exposure,
be it a 0nn or a 4nn), so it looks simpler to just manipulate the image.

So my first question is :

  could I use directly the SWSRLI file included in the pipe product for
  the 0000 images (e.g. *oms006swsrli0000.ftz) ?

  It contains a RATE and a MAG column (and should contain just one for
  the central target). Can I trust that MAG has been derived from the
  canonical radii and with  coincidence loss and deadtime corrections
  so that I can take MAG and just use step 7 and 8 of the uvflux recipe ?

Side question :

  is RATE in SWSRLI files the net rate or the gross rate (before bkg
  subtraction and deadtime correction) ?

Second and last question :

  I have the impression that for a 10-12 cts/s source the 12-30 pixel
  annulus used to compute the background might include a fraction of
  the wing of the PSF.

  Is it a wrong impression, or is somehow catered for by the uvflux
  recipe ?

Thanks for your collaboration

----------------------------------------------------------------------------
Lucio Chiappetti - IASF/CNR - via Bassini 15 - I-20133 Milano (Italy)
For more info : http://www.mi.iasf.cnr.it/~lucio/personal.html
----------------------------------------------------------------------------





Reply 2

Resend
From: Michel G. Breitfellner <xmmhelp@xmm.vilspa.esa.es>
To: lucio@mi.iasf.cnr.it
Subject: Re: OM "uvflux" recipe (which pixels ?) (PR#9061)
Date: Thu Aug 28 16:52:12 2003
Dear Dr. Chiappetti,

Thank you very much for your suggestions!
Your questions were forwarded to our OM specialist.
We will come back to you as soon as possible.

With best regards,
Michel G. Breitfellner
XMM-Newton User Support Group


Reply 3

Resend
From: Michel G. Breitfellner <xmmhelp@xmm.vilspa.esa.es>
To: lucio@mi.iasf.cnr.it
Subject: Re: OM "uvflux" recipe (which pixels ?) (PR#9061)
Date: Fri Aug 29 17:06:51 2003
Dear Dr. Chiappetti,

Please, find enclosed the comments of our OM specialist.
_______________________________________________________________________________

>>In general we recommend to use the SAS omichain task to process your
>>> > data. This will give you count rates in the end.
>
>>
>> Well, what I'm after is just the flux of the central target. I do not
have
>> any need or interest in running a detection algorithm on the entire
field
>> (I just need to extract the counts from the 0000 images of any
exposure,
>> be it a 0nn or a 4nn), so it looks simpler to just manipulate the
image.
>>


One comment here:

OM, and in general XMM data, can be processed with any system. However the only
way the XMM project can guarantee the quality of the results is by using SAS.
In
particular for OM there are corrections, as the dead time fraction computation
and
the coincidence loss corrections which can hardly be done otherwise than with
SAS.
(Beware, I do not say that SAS is perfect!)

If a user just wants the flux of the target, and since the pipeline products
are
part of the data package, the easiest way is to take the count rate or the
magnitude as provided by the pipeline and then convert to flux. The user may
want
to check it, and then he can apply any other procedure to measure the count
rate
and he should not forget to apply all corrections made by SAS. (Let's mention
that
there is an interactive SAS task, omsource which allows to perform aperture
photometry interactively on any source in an OM image. Please refer to the SAS
User Guide)

Another fundamental reference with respect to OM calibration is the Calibration
Status report in

http://xmm.vilspa.esa.es/external/xmm_sw_cal/calib/index.shtml


>>
>> So my first question is :
>>
>>   could I use directly the SWSRLI file included in the pipe product
for
>>   the 0000 images (e.g. *oms006swsrli0000.ftz) ?
>>
>>   It contains a RATE and a MAG column (and should contain just one for
>>   the central target). Can I trust that MAG has been derived from the
>>   canonical radii and with  coincidence loss and deadtime corrections
>>   so that I can take MAG and just use step 7 and 8 of the uvflux recipe
?
>>
>> Side question :
>>
>>   is RATE in SWSRLI files the net rate or the gross rate (before bkg
>>   subtraction and deadtime correction) ?
>>
>>


We recommend the use of the latest SAS version, currently SAS 5.4.1.
If the data have been processed with this version, then the SWSRLI file
contains
magnitudes with all corrections (refer to OM Calibration status as already
mentioned) and also corrected count rates.

As for file naming convention, please note that the 0000 images may not be the
ones without binning, although usually they are.



>> Second and last question :
>>
>>   I have the impression that for a 10-12 cts/s source the 12-30 pixel
>>   annulus used to compute the background might include a fraction of
>>   the wing of the PSF.
>>
>>   Is it a wrong impression, or is somehow catered for by the uvflux
>>   recipe ?
>>


In fact, these sizes apply to the optical filters (U, B, V). In the UV, the
aperture size is twice as much due to a larger PSF. All this is accounted for
in
the SAS processing. The basic idea, as in any photometry reduction package, is
to
account for all photons received from the source. In the end the aperture size
does not matter, as far as all photons are counted. What is really important is
the corrections applied (all included in SAS): dead time fraction, coincidence
loss, count rate dependencies of the PSF, modulo_8.

We agree that the recipe in the SAS watch out page may be a bit confusing, but
remember that it was written for use within a SAS context. In any case we shall
make it more clear and general.
_______________________________________________________________________________

With best regards,
Michel G. Breitfellner
XMM-Newton User Support Group

Up to top level
AO15   AO16   AO17   AO18   AO19   Backgrounds   Calibration   Conference   Data   Docs   EPICMOS   EPICpn   Feedback   Gallery   Misc   OM   Pending   PhD_Theses   Publications   RGS   RadMonitor   SAS_Hardware   SAS_WS   SASv16.0   SASv16.0_Installation   SASv16.1   SASv16.1_Installation   SASv17.0   SASv17.0_Installation   SASv18.0   SASv18.0_Installation   SciSim   Simulators_other   Suggestions   Trash   Visibility   XMM-bouncing   XMM-news   XRPS   XSA   esas   incoming  

Logged in as guest


Please make your (short) question the subject of your request!


Web interface using JitterBug ... back to the XMM home page