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 RGS/75729
Full headers

From: Joel Bregman <jbregman@umich.edu>
Subject: RGS instrumental features
Compose reply
Download message
Move To:
2 replies: 1 2
1 followups: 1

Private message: yes  no

Notes:

Notification:


Date: Thu, 5 Feb 2015 13:44:54 -0500
Subject: RGS instrumental features
From: Joel Bregman <jbregman@umich.edu>
To: xmmhelp@sciops.esa.int
--089e013d18c0318cfa050e5bb399
Content-Type: text/plain; charset=UTF-8

Hello,

I was wondering if there is some solution to some of the instrumental
features in the RGS.  In particular, there are some strong features
adjacent to important atomic lines and the presence of the feature makes it
impossible to reliably measure the atomic lines. This occurred during the
analysis of Mrk 421, and other AGN, for which we used the most recent SAS.

In particular, the line of O VII He beta is at 18.627 A has an adjacent
instrumental feature at about 18.686 A and the O VIII Lya line at 18.969 A
has an instrumental feature at 18.893 A.  Less essential, but still
annoying is the instrumental feature at 21.81 A that is in the wings of the
important O VII He alpha line.

Is this a fundamental problem that one cannot avoid, or is a matter that
can be solved with further software processing?

Best Regards,

Joel Bregman

--089e013d18c0318cfa050e5bb399
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hello,<div><br></div><div>I was
wondering if there is some=
 solution to some of the instrumental features in the RGS.=C2=A0 In particu=
lar, there are some strong features adjacent to important atomic lines and =
the presence of the feature makes it impossible to reliably measure the ato=
mic lines. This occurred during the analysis of Mrk 421, and other AGN, for=
 which we used the most recent
SAS.</div><div><br></div><div>In particular,=
 the line of O VII He beta is at 18.627 A has an adjacent instrumental feat=
ure at about 18.686 A and the O VIII Lya line at 18.969 A has an instrument=
al feature at 18.893 A.=C2=A0 Less essential, but still annoying is the ins=
trumental feature at 21.81 A that is in the wings of the important O VII He=
 alpha line.</div><div><br></div><div>Is this a
fundamental problem that on=
e cannot avoid, or is a matter that can be solved with further software pro=
cessing?</div><div><br></div><div>Best
Regards,</div><div><br></div><div>Jo=
el Bregman</div></div>

--089e013d18c0318cfa050e5bb399--


Reply 1

Resend
From: Rosario Gonzalez Riestra <xmmhelp@sciops.esa.int>
To: jbregman@umich.edu
Subject: Re: RGS instrumental features (PR#75729)
Date: Fri Feb  6 11:26:41 2015

Dear Dr. Bregman

There are a number of known instrumental features affecting RGS data.
The list is given in the User Handbook at

http://xmm.esac.esa.int/external/xmm_user_support/documentation/uhb/rgsmultipoint.html

First, there are gaps between adjacent chips, or between the two 
readout nodes of RGS1 (and of RGS2 for data taken before the
change of readout mode in August 2007).

This is the case of the feature at 18.93 A, that corresponds to
the node gap in CCD 5 of RGS1 (but note that the RGS2 spectrum if
fine in this range).

These features cannot be suppressed during the processing as there
is a real lack of data. But one can always use the redundancy between
RGS1 and RGS2 when possible (even between first and second order
spectra for bright objects).

The two other features you mention (18.69, 21.81) are of the
type "cool pixels".
 These features sometimes appear in the spectra of bright
sources (as in the case of Mkn 421 you mention). Please refer to
the following document for a description of this effect:

http://xmm2.esac.esa.int/docs/documents/CAL-SRN-0218-1-0.ps.gz

The default processing does not filter out these pixels. Hence, it
they are "cool", it results in an absorption feature in the
spectrum.  They can be handled as normal bad/hot columns
[i.e. eliminated] setting the rgsproc parameter "keepcool"
to "no".

In addition to this, there is an a-priori solution: if one is interested in a 
particular spectral feature, the pointing can be slightly changed so 
that it does not coincide with any know instrumental feature:

http://xmm2.esac.esa.int/docs/documents/CAL-TN-0192-1-1.pdf

Please let me know if this answers your question

Regards

Rosario Gonzalez-Riestra
XMM-SOC 



Followup 1

Compose reply
Download message
Date: Mon, 9 Feb 2015 08:55:57 -0500
Subject: Re: RGS instrumental features (PR#75729)
From: Joel Bregman <jbregman@umich.edu>
To: Rosario Gonzalez Riestra <xmmhelp@sciops.esa.int>
--f46d043c07d230222f050ea821e4
Content-Type: text/plain; charset=UTF-8

Dear Dr. Gonzalez-Riestra,

We previously tried the setting "keepcool" to "no" and have tried again,
but the resulting spectrum still shows an artifact that is large enough to
prevent us from extracting useful scientific information.

I don't entirely understand why the problem cannot be solved, as the
spectrum is spread over many pixels in the cross-dispersion direction.  If
a few pixels are bad, I would have thought that they could be eliminated
and the others used, decreasing the S/N at a particular wavelength but
avoiding a strong "instrumental" feature.  I recall in the "early" days,
some members of the RGS group (Andy Peterson) had written software that
could recover a spectrum in the region of cool pixels (and published
papers),

I've read the documents about the RGS but am still confused by these
issues, so perhaps you can clarify them for me.

Best regards,

Joel Bregman

On Fri, Feb 6, 2015 at 6:26 AM, Rosario Gonzalez Riestra <
xmmhelp@sciops.esa.int> wrote:

>
>
> Dear Dr. Bregman
>
> There are a number of known instrumental features affecting RGS data.
> The list is given in the User Handbook at
>
>
> http://xmm.esac.esa.int/external/xmm_user_support/documentation/uhb/rgsmultipoint.html
>
> First, there are gaps between adjacent chips, or between the two
> readout nodes of RGS1 (and of RGS2 for data taken before the
> change of readout mode in August 2007).
>
> This is the case of the feature at 18.93 A, that corresponds to
> the node gap in CCD 5 of RGS1 (but note that the RGS2 spectrum if
> fine in this range).
>
> These features cannot be suppressed during the processing as there
> is a real lack of data. But one can always use the redundancy between
> RGS1 and RGS2 when possible (even between first and second order
> spectra for bright objects).
>
> The two other features you mention (18.69, 21.81) are of the
> type "cool pixels".
>  These features sometimes appear in the spectra of bright
> sources (as in the case of Mkn 421 you mention). Please refer to
> the following document for a description of this effect:
>
> http://xmm2.esac.esa.int/docs/documents/CAL-SRN-0218-1-0.ps.gz
>
> The default processing does not filter out these pixels. Hence, it
> they are "cool", it results in an absorption feature in the
> spectrum.  They can be handled as normal bad/hot columns
> [i.e. eliminated] setting the rgsproc parameter "keepcool"
> to "no".
>
> In addition to this, there is an a-priori solution: if one is interested
> in a
> particular spectral feature, the pointing can be slightly changed so
> that it does not coincide with any know instrumental feature:
>
> http://xmm2.esac.esa.int/docs/documents/CAL-TN-0192-1-1.pdf
>
> Please let me know if this answers your question
>
> Regards
>
> Rosario Gonzalez-Riestra
> XMM-SOC
>
>
>
> This message and any attachments are intended for the use of the addressee
> or addressees only.
> The unauthorised disclosure, use, dissemination or copying (either in
> whole or in part) of its
> content is not permitted.
> If you received this message in error, please notify the sender and delete
> it from your system.
> Emails can be altered and their integrity cannot be guaranteed by the
> sender.
>
> Please consider the environment before printing this email.
>
>

--f46d043c07d230222f050ea821e4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Dear Dr.
Gonzalez-Riestra,<div><br></div><div>We previousl=
y tried the setting &quot;keepcool&quot; to &quot;no&quot; and
have tried a=
gain, but the resulting spectrum still shows an artifact that is large enou=
gh to prevent us from extracting useful scientific
information.</div><div><=
br></div><div>I don&#39;t entirely understand why the problem
cannot be sol=
ved, as the spectrum is spread over many pixels in the cross-dispersion dir=
ection.=C2=A0 If a few pixels are bad, I would have thought that they could=
 be eliminated and the others used, decreasing the S/N at a particular wave=
length but avoiding a strong &quot;instrumental&quot; feature.=C2=A0 I
reca=
ll in the &quot;early&quot; days, some members of the RGS group (Andy
Peter=
son) had written software that could recover a spectrum in the region of co=
ol pixels (and published
papers),</div><div><br></div><div>I&#39;ve
read th=
e documents about the RGS but am still confused by these issues, so perhaps=
 you can clarify them for
me.</div><div><br></div><div>Best
regards,</div><=
div><br></div><div>Joel
Bregman</div></div><div class=3D"gm

Message of length 8780 truncated


Reply 2

Resend
From: Rosario Gonzalez Riestra <xmmhelp@sciops.esa.int>
To: jbregman@umich.edu
Subject: Re: RGS instrumental features (PR#75729)
Date: Tue Feb 10 09:29:35 2015
Dear Dr. Bregman,

Sorry if I was not clear enough in my previous message.

Let me first say that the expression "cool pixels" is rather misleading, it
should be "cool columns", as is the full column what is flagged in the SAS
processing.

RGS cool pixels were identified in a set of observations of Mkn421, and their
positions were collected in a calibration file.

In the current SAS implementation, RGS cool pixels are not identified in each
individual observation, but their positions are just taken from the calibration
file: if the parameter "keepcool" is set to "no" the columns defined in the file
are handled as any other bad/hot column, that is, they are filtered out.

(Note that this is different for "hot columns" that can come from the
calibration files and/or from identification during the processing).

Hence, within the SAS, there is no way to "reconstruct" the spectral bins
affected by cool pixels: They are either totally filtered ("keepcool"=no), or
may appear as spurious absorption features ("keepcool"=yes).

Please let me know if this answers your question. I'll be happy to provide 
more information if you need it.

Best regards

Rosario


 

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