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 Calibration/8818
Full headers

From: kuntz@milkyway.gsfc.nasa.gov
Subject: Selection inconsistencies
Compose reply
Download message
Move To:
2 replies: 1 2
1 followups: 1

Private message: yes  no

Notes:

Notification:


Date: Tue, 15 Jul 2003 18:24:48 GMT
From: kuntz@milkyway.gsfc.nasa.gov
To: xmmhelp@xmm.vilspa.esa.es
Subject: Selection inconsistencies
Name: K. D. Kuntz

Email_Address: kuntz@milkyway.gsfc.nasa.gov

Topic: tasks

Other_Topic: 

Usage_Mode: command line

SAS_Release: xmmsas_20030110_1802 - aka 5.4.1

Task_Version: 

Type: report a nuisance

Title: Selection inconsistencies

Description: This is not a bug per se, since I figured out that the program does
not work *the way I think that it should*,
rather than the program not working at all. These two nuisances require painful
work-arounds.

1.) Since I work with the diffuse background, I am usually interested in using
the entire FOV, minus a few of those
nuisances called point sources. So, if I use evselect or xmmselect to extract a
spectrum with no selection criterion other than 
  (PATTERN<=12)&&(FLAG==0)
the spectrum is extracted in an orderly fashion, but you can not get a backscal
parameter. (Instead you get an error message). This is most unuseful. Surely,
since the program is supposed to know about chip edges it supposed to know
about the FOV, it should be able to relay than information to the backscal
routine?
1b.) If you do a selection with 
  (PATTERN<=12)&&(FLAG==0)&&!(some region)
you will get a negative backscal parameter. There is, however, no obvious error
message to tell you that you've done something stupid.
1c.) If you extract a region that covers the entire FOV with
  (PATTERN<=12)&&(FLAG==0)&&(region larger than FOV)
when you increase the size of the region, the backscal parameter will also
increase, even though there is no more area of the FOV to be included. It
appears to me that the FLAG==0 criterion is ignored.

2.) Consider a region that covers multiple chips (for example, parts of chips 1
and 2) The selection
  (region)
and the selection
  (region)&&(CCDNR==1)
will produce the same backscal parameter. That is, the CCDNR selection criterion
is ignored. (Since the behavior of the instrumental background varies with the
CCD, being able to select on the basis of CCD is important for diffuse emission
sutdies!)

3.) Finally, soemthing that may be a bug, and if you haven't seen it before,
I'll try to be more careful and send you a more complete version of the problem.
If I use evselect to create a new events file based on spatial criteria in DET
coordinates, and then select from that file based on spatial criteria in sky
coordinates, the backscal is smoetimes obviously wrong. (I have not yet figured
out whether the rest of the time it is right, or merely not obviously wrong).

I'm not including observation numbers since I've seen the same problems with
multiple observations.


Operating_System: RedHat 7.x

Other_Operating_System: 

Instrument: 

Data_Type: 

Observation_Identifier: 

Exposure_Identifier: 

Private: 

Submitted_From: 128.183.17.174 (128.183.17.174)

Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.18-18.7.x i686)

Referer: http://xmm.vilspa.esa.es/sas/feedback/

Identify: 


Reply 1

Resend
From: Rosario Gonzalez Riestra <xmmhelp@xmm.vilspa.esa.es>
To: kuntz@milkyway.gsfc.nasa.gov
Subject: Re: Selection inconsistencies (PR#8818)
Date: Wed Jul 16 09:47:27 2003

Dear Dr. Kuntz,

Thanks for your very detailed message. Due to the peculiarities of your work, it
points out a number of inconsistencies that are usually hard to detect in the
usual analysis of point-source spectra.


This message deserves an extensive answer, and for this reason I am forwarding
it to our experts that will comment in detail all the points. I am sure they
will find it very interesting.


I'll let you know as soon as I get their answer.

Regards,

			Rosario Gonzalez-Riestra
			XMM-SOC User Support Group


Reply 2

Resend
From: Rosario Gonzalez Riestra <xmmhelp@xmm.vilspa.esa.es>
To: kuntz@milkyway.gsfc.nasa.gov
Subject: Re: Selection inconsistencies (PR#8818)
Date: Wed Jul 16 15:02:06 2003

Dear Dr. Kuntz

Please find below the comments on your e-mail form  our arf/backscal  expert.

Regards,


		Rosario

=================================================


backscale, via arfgen, works on the assumption that the
spatial selection is fully contained within the region information
given in the Datasubspace component of the input file.
Furthermore, it currently assumes that the given region is completely
contained within live areas of the CCD. As the user points out
the code does not:

1. Check whether part of the selected region lies outside the
field of view

2. Use any CCD selection to further subset the region.

3. Assume that the entire fov has been used if no selection
is present.

4. Handle the case of mixed coordinate regions, e.g. DETX and
X/Y. This is documented but I'm aware that it is a nasty limitation.


Point 1 is sort of covered by an outstanding SPR (2450) and should
be fixed for the next major release.

Point 2 would be hard work and since it can be solved by the user
making additional spatial selections I dont see it as a high priority.

I suppose that once the FOV is taken into account it would be
straightforward to calculate the BACKSCAL value assuming that the
whole field has been exposed in the case where the DSS contains no
spatial selection. Need to think this through though as it may have
negative effects elsewhere. I'll add this to SPR-2450 as a reminder.

A major code restructuring is needed to enable DET,POS and chip
coordinate selections to be handled simultaneously within arfgen.
This capability wont be added in the short term but I agree that
a warning should be output to say that such datasubspaces will
result in an incorrect BACKSCAL (raised SPR-2464).



Followup 1

Compose reply
Download message
Date: Wed, 16 Jul 2003 11:24:08 -0400
From: "K.D. Kuntz" <kuntz@milkyway.gsfc.nasa.gov>
To: Rosario Gonzalez Riestra <xmmhelp@xmm.vilspa.esa.es>
Subject: Re: Selection inconsistencies (PR#8818)
Thank you very much for your prompt and careful reply.
Please allow me to add my "two cents worth" in reply.
It seems to me that implementing the selection criterion
FOV and CCDNR could be done in a more straight-forward manner
than actually trying to implement those selections in backscal.
"All" that needs to be done is for backscale to recognize,
for example, the CCD selection, and then look up an equivalent
definition in terms of regions in detector or sky coordinates.
A similar method could be used for the FOV.

Thank you again. Now that I know how backscal works, I can
avoid doing all those things that will get me into trouble!

K.D.Kuntz
-- 
Dr. K.D.Kuntz (UMBC/LHEA)
NASA/GSFC, Code 662
Greenbelt, MD  20771
Phone: 301-286-1201
Fax:   301-286-1684
Home:  410-366-4236
E-mail: kuntz@milkyway.gsfc.nasa.gov
Web: http://lheawww.gsfc.nasa.gov/users/kuntz/


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