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 Backgrounds/22859
Full headers

From: norad79@yahoo.com
Subject: new blank sky files
Compose reply
Download message
Move To:
6 replies: 1 2 3 4 5 6
5 followups: 1 2 3 4 5

Private message: yes  no

Notes:

Notification:


Date: Fri, 11 Aug 2006 07:39:17 GMT
From: norad79@yahoo.com
To: xmmhelp@sciops.esa.int
Cc: norad79@yahoo.com
Subject: new blank sky files
Full_Name: Norbert Nemes
Submission from: (NULL) (218.220.52.208)


Hello

I ran into some problems with the new blank sky files.

I downloaded the MOS1 and MOS2 medium filter and the PN medium filter full frame
mode anticenter blank sky files with the holes due to point sources refilled.
I am using SAS 7.0 (Suse 8.3 binaries) with the SAS_ODF and SAS_CCF environment
variables having their default values. My machine is a Pentium D class with Suse
10.1 64bit running on it and 1Gb of RAM.

From hereon I shall discuss the case of the PN file.

In the headder of extension #1 of the original file, the ONTIME(ccd_number)
keywords have all distinct values (~600000). Next I (pre)filter this file using
the command:

evselect table=pnmedrefila.fits.gz withfilteredset=Y filteredset=pnmedtemp.fits
updateexposure=N writedss=Y destruct=Y keepfilteroutput=T expression='#XMMEA_EP
&& ((FLAG & 0x10000)==0) && (PATTERN<=4) '

Using the resulting file and the double filtering method of Nevalainen et al. I
create 2 gti files, one for the hard band and one for the soft band. Then I
filter the pnmedtemp.fits file with the following command:

evselect table=pnmedtemp.fits withfilteredset=Y filteredset=pnmedback.fits
updateexposure=Y writedss=Y destruct=Y keepfilteroutput=T expression='#XMMEA_EP
&& !((FLAG & 0x10000)!=0) && (PATTERN<=4) &&
gti(pn.gti,TIME)&&gti(pn2.gti,TIME)'

Now when I check the values of the ONTIME(ccd_number) keywords in the filtered
file (pnmedback.fits) they all show the same value (1.53998349172324E+05) except
for ONTIME12 which shows a value almost two orders of magnitude shorter than the
above mentionned value (1.99990828736126E+03).

The same thing happens in the case of the MOS files. All ONTIME(ccd_number)
values in the filtered file are the same except for ONTIME7 which is an order of
magitude shorter than that for other CCDs. The same goes for the LIVETIME
values.

Initially I thought that it could be a problem related to the SAS version, but
repeating the procedure under SAS 6.5 gives the exact same results.

I would like to ask why the ONTIME value of the last CCD ( 7 in the case of the
MOS and 12 in the case of the PN) becomes so short after GTI filtering and why
do they become the same for the other CCDS when originally they were different?
Is it a software bug? What happens if I manually reset this discrepant value to
that of the other CCDs? Whill I have problems later on in the analysis process?

Thank you!

Norbert


Reply 1

Resend
From: Matthias Ehle <xmmhelp@sciops.esa.int>
To: norad79@yahoo.com
Subject: Re: new blank sky files (PR#22859)
Date: Fri Aug 11 08:23:37 2006
Dear Norbert,

I think you ran into the same problem that also we discovered only recently, 
namely that if you filter the blank sky fields, the exposure times
(visible e.g. in the ONTIME header keywords) are not correctly updated.

We are currently in the process of updating the event files on our
EPIC background web page. In the meantime, I suggest that you let me
know which blank-sky event lists you want to process and I could try
to make them available to you already now. 

Kind regards and sorry for any inconvenience,

   Matthias

--
   Dr Matthias Ehle 
   XMM-Newton User Support Group
   European Space Astronomy Centre


Followup 1

Compose reply
Download message
Date: Fri, 11 Aug 2006 03:38:26 -0700 (PDT)
From: Nemes Norbert <norad79@yahoo.com>
Subject: Re: new blank sky files (PR#22859)
To: Matthias Ehle <xmmhelp@sciops.esa.int>
Dear Dr. Ehle

Thank you for your quick response.
If you could provide me with the updated files, that would
really be great!

If possible I'd like to request the following event files:

MOS1 medium filter with holes refilled
MOS2 medium filter with holes refilled
PN medium filter full frame anticenter with holes refilled
PN thin filter full frame anticenter with holes refilled

Exposure maps are not required.

Thank you very much.

Best regards,

Norbert


--- Matthias Ehle <xmmhelp@sciops.esa.int> wrote:

> Dear Norbert,
> 
> I think you ran into the same problem that also we
> discovered only recently, 
> namely that if you filter the blank sky fields, the
> exposure times
> (visible e.g. in the ONTIME header keywords) are not
> correctly updated.
> 
> We are currently in the process of updating the event
> files on our
> EPIC background web page. In the meantime, I suggest that
> you let me
> know which blank-sky event lists you want to process and
> I could try
> to make them available to you already now. 
> 
> Kind regards and sorry for any inconvenience,
> 
>    Matthias
> 
> --
>    Dr Matthias Ehle 
>    XMM-Newton User Support Group
>    European Space Astronomy Centre
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 



Reply 2

Resend
From: Matthias Ehle <xmmhelp@sciops.esa.int>
To: norad79@yahoo.com
Subject: Re: new blank sky files (PR#22859)
Date: Fri Aug 11 12:08:49 2006
Hello Norbert,

you can download the (big) files now via ftp:

ftp xmm.esac.esa.int
user: ftpx, pw: xmmftpx
cd BGWG
bin
get M1.M.FF.EVLIRP.FIT
get M2.M.FF.EVLIRP.FIT
get PN.M.FF.EVLIRA.FIT
get PN.T.FF.EVLIRA.FIT
bye

I would appreciate very much if you could let us know if with
these files the problem that you reported before has been fixed.

Regards,
  Matthias


Followup 2

Compose reply
Download message
Date: Sat, 12 Aug 2006 06:29:02 -0700 (PDT)
From: Nemes Norbert <norad79@yahoo.com>
Subject: Re: new blank sky files (PR#22859)
To: Matthias Ehle <xmmhelp@sciops.esa.int>
Dear Matthias

Thank you for the files. I downloaded them and then
performed the filtering process described in my previous
mail. Everything seems to be OK now. The final ONTIME
values are different for each CCD and there are no large
dicrepancies between them. 

Thank you again.

Best regards,

Norbert

--- Matthias Ehle <xmmhelp@sciops.esa.int> wrote:

> Hello Norbert,
> 
> you can download the (big) files now via ftp:
> 
> ftp xmm.esac.esa.int
> user: ftpx, pw: xmmftpx
> cd BGWG
> bin
> get M1.M.FF.EVLIRP.FIT
> get M2.M.FF.EVLIRP.FIT
> get PN.M.FF.EVLIRA.FIT
> get PN.T.FF.EVLIRA.FIT
> bye
> 
> I would appreciate very much if you could let us know if
> with
> these files the problem that you reported before has been
> fixed.
> 
> Regards,
>   Matthias
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 



Followup 3

Compose reply
Download message
Date: Tue, 29 Aug 2006 23:40:10 -0700 (PDT)
From: Nemes Norbert <norad79@yahoo.com>
Subject: Re: new blank sky files (PR#22859) again
To: Matthias Ehle <xmmhelp@sciops.esa.int>
Dear Dr. Ehle

Sorry for not going through the regular helpdesk channels,
but I have hit a problem with the blank sky files you sent
me.
When I try to extract a spectrum from these files,
backscale fails with the following message:

**backscale::arfgen::error(attributableNotFound), Could not
find attribute with qualified name test1-back.pha%DATE-OBS
in attributable set test1-back.pha.

Other tasks also have a problem with the absence of the
DATE-OBS keyword like for instance evigweight.

Could you please tell me what values should I write into
the headder of the blank sky files for the DATE-OBS and
DATE-END keywords?


Another problem I found was that after I reprocessed my
ODFs with SAS 7.0 and  tried to run backscale on the
spectrum extracted from the source event files from a
certain region, backscale failed with the following error:

**backscale::arfgen: error (FITSIO), FITS error 207 while
accessing file 'mos11.pha': illegal character in keyword
Character 80 in this keyword is illegal. Hex Value =
FFFFFFF2
CONTINUE  '=12)&& (FLAG==0) && ((X,Y) IN
circle(27412.5,26577.5,17047.305))' /

The intersting thing is that in this keyword there are only
79 characters (spaces included).

Any ideas about what to do?
Since I'm extracting the source and the background spectrum
from the same region would it be OK if I omit running
backscale on my spectra?

Thank you,

Norbert



--- Matthias Ehle <xmmhelp@sciops.esa.int> wrote:

> Hello Norbert,
> 
> you can download the (big) files now via ftp:
> 
> ftp xmm.esac.esa.int
> user: ftpx, pw: xmmftpx
> cd BGWG
> bin
> get M1.M.FF.EVLIRP.FIT
> get M2.M.FF.EVLIRP.FIT
> get PN.M.FF.EVLIRA.FIT
> get PN.T.FF.EVLIRA.FIT
> bye
> 
> I would appreciate very much if you could let us know if
> with
> these files the problem that you reported before has been
> fixed.
> 
> Regards,
>   Matthias
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 



Reply 3

Resend
From: Matthias Ehle <xmmhelp@sciops.esa.int>
To: norad79@yahoo.com
Subject: Re: new blank sky files (PR#22859)
Date: Mon Sep 11 16:41:25 2006
Dear Norbert,

Sorry for my late reply but I have been on leave.

You wrote:
> Sorry for not going through the regular helpdesk channels,
> but I have hit a problem with the blank sky files you sent
> me.
> When I try to extract a spectrum from these files,
> backscale fails with the following message:
> 
> **backscale::arfgen::error(attributableNotFound), Could not
> find attribute with qualified name test1-back.pha%DATE-OBS
> in attributable set test1-back.pha.
> 
> Other tasks also have a problem with the absence of the
> DATE-OBS keyword like for instance evigweight.
> 
> Could you please tell me what values should I write into
> the headder of the blank sky files for the DATE-OBS and
> DATE-END keywords?

In the meantime my colleagues from Leicester have officially released
new/fixed blank sky files, see
http://xmm.esac.esa.int/external/xmm_sw_cal/background/blank_sky.shtml

These new files should now also be fixed for the DATE-OBS and DATE-END
keywords.

> 
> Another problem I found was that after I reprocessed my
> ODFs with SAS 7.0 and  tried to run backscale on the
> spectrum extracted from the source event files from a
> certain region, backscale failed with the following error:
> 
> **backscale::arfgen: error (FITSIO), FITS error 207 while
> accessing file 'mos11.pha': illegal character in keyword
> Character 80 in this keyword is illegal. Hex Value =
> FFFFFFF2
> CONTINUE  '=12)&& (FLAG==0) && ((X,Y) IN
> circle(27412.5,26577.5,17047.305))' /
> 
> The intersting thing is that in this keyword there are only
> 79 characters (spaces included).
> 
> Any ideas about what to do?

Could you let me know the ObsId of the data you are trying to process
together with all the steps you performed before the FITS error occured?

> Since I'm extracting the source and the background spectrum
> from the same region would it be OK if I omit running
> backscale on my spectra?

backscale needs to be run to compute and write the BACKSCAL keyword in 
EPIC spectra, a keyword used for example by XSPEC which I think is 
important e.g. when you want to compute model fluxes. 

Cheers,
  Matthias


Followup 4

Compose reply
Download message
Date: Mon, 11 Sep 2006 22:30:30 -0700 (PDT)
From: Nemes Norbert <norad79@yahoo.com>
Subject: Re: new blank sky files (PR#22859)
To: Matthias Ehle <xmmhelp@sciops.esa.int>
--0-918341104-1158039030=:71528
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Content-Id: 
Content-Disposition: inline

Dear Dr. Ehle

Thank you for your response. 
I dowloaded the refilled blank sky files for the mos1 and
mos2 medium filter and when recasting them to the position
of my observation, the attcalc warning about the missing
DATE-OBS/DATE-END came up again. So it seems that these
keywords are still not included in the headder(s) of the
files. In other words I'm still not able to run backscal on
the blank sky files.

Regarding the second matter about the failure of backscale
on my source files, this is what I did.


OBS_ID: 0082540201 (Cygnus Loop pos2)

1) I reprocessed the ODF using SAS 7.0.
2) I pre-filter the resulting files for bad data using the
command (example for MOS1)

evselect table=sourcefile.fits withfilteredset=Y
filteredset=sourcefilepreclean.fits updateexposure=N
writedss=Y destruct=Y keepfilteroutput=T
expression='#XMMEA_EM && PATTERN<=12)';


3) Using the method of Nevalainen et al. I create 2 gti
files for the soft and hard band respectively, then  filter
the cleaned file for gti with the following command:

evselect table=sourcefilepreclean.fits withfilteredset=Y
filteredset=sourcefileclean.fits updateexposure=Y
writedss=Y destruct=Y keepfilteroutput=T
expression='#XMMEA_EM &&(PATTERN<=12) &&
gti(gti1.gti,TIME)&&gti(gti2.gti,TIME)'

(attached gti files for the mos1)

4) Finally I correct for vignetting with

evigweight ineventset=sourcefileclean.fits newoutput=Y
outeventset=sourcefilecleanv.fits

then I extract the spectrum

evselect table=sourcecleanv.fits:EVENTS withspectrumset=yes
spectrumset=spectrum.pha writedss=true withspecranges=true
specchannelmin= 0 specchannelmax=11999 spectralbinsize=15
energycolumn=PI expression='!(CCDNR==1 && RAWX in
111,259,287,320,342,360,437,537) &&(PATTERN<=12)&&
(FLAG==0) && ((X,Y) IN circle(27412.5,26577.5,17047.305))'
withzcolumn=Y withzerrorcolumn=N

I backscale it,

backscale spectrumset=spectrum.pha withbadpixcorr=yes
badpixlocation=sourcecleanv.fits


And this is where it fails.

By the way, were the bad columns in the central mos CCDs
included in the bad pixel files in SAS 7.0 or do I still
have to use the selection expression above?

My OS is SUSE 10.1 and I am using the SUSE 8.something
binaries.

Thank you very much.

Best regards,

Norbert

 
--- Matthias Ehle <xmmhelp@sciops.esa.int> wrote:

> Dear Norbert,
> 
> Sorry for my late reply but I have been on leave.
> 
> You wrote:
> > Sorry for not going through the regular helpdesk
> channels,
> > but I have hit a problem with the blank sky files you
> sent
> > me.
> > When I try to extract a spectrum from these files,
> > backscale fails with the following message:
> > 
> > **backscale::arfgen::error(attributableNotFound), Could
> not
> > find attribute with qualified name
> test1-back.pha%DATE-OBS
> > in attributable set test1-back.pha.
> > 
> > Other tasks also have a problem with the absence of the
> > DATE-OBS keyword like for instance evigweight.
> > 
> > Could you please tell me what values should I write
> into
> > the headder of the blank sky files for the DATE-OBS and
> > DATE-END keywords?
> 
> In the meantime my colleagues from Leicester have
> officially released
> new/fixed blank sky files, see
>
http://xmm.esac.esa.int/external/xmm_sw_cal/background/blank_sky.shtml
> 
> These new files should now also be fixed for the DATE-OBS
> and DATE-END
> keywords.
> 
> > 
> > Another problem I found was that after I reprocessed my
> > ODFs with SAS 7.0 and  tried to run backscale on the
> > spectrum extracted from the source event files from a
> > certain region, backscale failed with the following
> error:
> > 
> > **backscale::arfgen: error (FITSIO), FITS error 207
> while
> > accessing file 'mos11.pha': illegal character in
> keyword
> > Character 80 in this keyword is illegal. Hex Value =
> > FFFFFFF2
> > CONTINUE  '=12)&& (FLAG==0) && ((X,Y) IN
> > circle(27412.5,26577.5,17047.305))' /
> > 
> > The intersting thing is that in this keyword there are
> only
> > 79 characters (spaces included).
> > 
> > Any ideas about what to do?
> 
> Could you let me know the ObsId of the data you are
> trying to process
> together with all the steps you performed before the FITS
> error occured?
> 
> > Since I'm extracting the source and the background
> spectrum
> > from the same region would it be OK if I omit running
> > backscale on my spectra?
> 
> backscale needs to be run to compute and write the
> BACKSCAL keyword in 
> EPIC spectra, a keyword 

Message of length 29205 truncated


Reply 4

Resend
From: Matthias Ehle <xmmhelp@sciops.esa.int>
To: norad79@yahoo.com
Subject: Re: new blank sky files (PR#22859)
Date: Thu Sep 14 17:25:40 2006
Dear Norbert

you wrote:
> I dowloaded the refilled blank sky files for the mos1 and
> mos2 medium filter and when recasting them to the position
> of my observation, the attcalc warning about the missing
> DATE-OBS/DATE-END came up again. So it seems that these
> keywords are still not included in the headder(s) of the
> files. In other words I'm still not able to run backscal on
> the blank sky files.

I forwarded your report to the colleagues who created the blank sky event
files. This is their reply:
The blank sky files are constructed from several different event lists, spanning
a large range in time over the mission. Date-related keywords, for example
DATE-OBS, have therefore been removed. A few SAS tasks require date and time
stamp keywords. It is recommended that these keywords be added by the user as
required. Missing date and time keywords could be e.g. set to that of the user's
source spectrum. This can be achieved for example using the FTOOLS viewer/editor
fv.
(see updated blank sky web page).

An easy work around for your problem could also be to run backscale 
on the source spectrum and - if the same area is extracted from the 
blank sky fields - to edit the background spectrum entering the same 
value there as well.

Regarding the second matter about the failure of backscale
on your source files: I still need to repeat your analysis 
here and will let you know if I can confirm your findings.

> 
> By the way, were the bad columns in the central mos CCDs
> included in the bad pixel files in SAS 7.0 or do I still
> have to use the selection expression above?
> 

Sorry, I do not quite understand what you mean: Bad events are stored in 
CCF files which have validation ranges such that they can be linked to 
a specific observation time.

Chers,
  Matthias


Followup 5

Compose reply
Download message
Date: Thu, 14 Sep 2006 21:17:45 -0700 (PDT)
From: Nemes Norbert <norad79@yahoo.com>
Subject: Re: new blank sky files (PR#22859)
To: Matthias Ehle <xmmhelp@sciops.esa.int>
Dear Dr. Ehle

> I forwarded your report to the colleagues who created the
> blank sky event
> files. This is their reply:
> The blank sky files are constructed from several
> different event lists, spanning
> a large range in time over the mission. Date-related
> keywords, for example
> DATE-OBS, have therefore been removed. A few SAS tasks
> require date and time
> stamp keywords. It is recommended that these keywords be
> added by the user as
> required. Missing date and time keywords could be e.g.
> set to that of the user's
> source spectrum. This can be achieved for example using
> the FTOOLS viewer/editor
> fv.
> (see updated blank sky web page).
> 
> An easy work around for your problem could also be to run
> backscale 
> on the source spectrum and - if the same area is
> extracted from the 
> blank sky fields - to edit the background spectrum
> entering the same 
> value there as well.


Oh, yes. I just saw the text on the updated blank sky page.
Sorry :).

> > By the way, were the bad columns in the central mos
> CCDs
> > included in the bad pixel files in SAS 7.0 or do I
> still
> > have to use the selection expression above?
> > 
> 
> Sorry, I do not quite understand what you mean: Bad
> events are stored in 
> CCF files which have validation ranges such that they can
> be linked to 
> a specific observation time.

I'm sorry. I didn't formulate my question correctly. I was
reffering to the columns in the MOS central ccds with
corrupted energies. In the EPIC calibration status
documentation (CAL-TN-0018.pdf) we are advised to manually
remove those columns and that this problem will be
addressed in the future. So what I wanted to ask was "Was
it addressed in sas 7.0"? Do we still need to manually
remove tose columns or they are taken care of by the
pipeline processing?

Thank you.

Best regards, 

Norbert

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 



Reply 5

Resend
From: Matthias Ehle <xmmhelp@sciops.esa.int>
To: norad79@yahoo.com
Subject: Re: new blank sky files (PR#22859)
Date: Fri Sep 15 10:14:25 2006
Dear Norbert,

you wrote:
> I'm sorry. I didn't formulate my question correctly. I was
> reffering to the columns in the MOS central ccds with
> corrupted energies. In the EPIC calibration status
> documentation (CAL-TN-0018.pdf) we are advised to manually
> remove those columns and that this problem will be
> addressed in the future. So what I wanted to ask was "Was
> it addressed in sas 7.0"? Do we still need to manually
> remove tose columns or they are taken care of by the
> pipeline processing?

The new SAS 7.0 can correct the unusual CTI in those columns BUT
only together with new to be released MOS CCF files. These CCF files
are still in preparation and under testing - unfortunately we do not 
yet have a firm date for the release. 

Cheers,
  Matthias



Reply 6

Resend
From: Matthias Ehle <xmmhelp@sciops.esa.int>
To: norad79@yahoo.com
Subject: Re: new blank sky files (PR#22859)
Date: Fri Sep 15 10:38:45 2006
Dear Norbert,

Now I also could repeat/check you analysis steps:

> OBS_ID: 0082540201 (Cygnus Loop pos2)
> 
> 1) I reprocessed the ODF using SAS 7.0.
> 2) I pre-filter the resulting files for bad data using the
> command (example for MOS1)
> 
> evselect table=sourcefile.fits withfilteredset=Y
> filteredset=sourcefilepreclean.fits updateexposure=N
> writedss=Y destruct=Y keepfilteroutput=T
> expression='#XMMEA_EM && PATTERN<=12)';
                                      ^ needs to be removed
Why do you set updateexposure=N?

> 
> 3) Using the method of Nevalainen et al. I create 2 gti
> files for the soft and hard band respectively, then  filter
> the cleaned file for gti with the following command:
> 
> evselect table=sourcefilepreclean.fits withfilteredset=Y
> filteredset=sourcefileclean.fits updateexposure=Y
> writedss=Y destruct=Y keepfilteroutput=T
> expression='#XMMEA_EM &&(PATTERN<=12) &&
> gti(gti1.gti,TIME)&&gti(gti2.gti,TIME)'

OK, I used the files mos1.gti and mos12.gti that you attached.

> 4) Finally I correct for vignetting with
> 
> evigweight ineventset=sourcefileclean.fits newoutput=Y
> outeventset=sourcefilecleanv.fits
> 
> then I extract the spectrum
> 
> evselect table=sourcecleanv.fits:EVENTS withspectrumset=yes
> spectrumset=spectrum.pha writedss=true withspecranges=true
> specchannelmin= 0 specchannelmax=11999 spectralbinsize=15
> energycolumn=PI expression='!(CCDNR==1 && RAWX in
> 111,259,287,320,342,360,437,537) &&(PATTERN<=12)&&
> (FLAG==0) && ((X,Y) IN circle(27412.5,26577.5,17047.305))'
> withzcolumn=Y withzerrorcolumn=N

you mean table=sourcefilecleanv.fits

> 
> I backscale it,
> 
> backscale spectrumset=spectrum.pha withbadpixcorr=yes
> badpixlocation=sourcecleanv.fits

again, I use table=sourcefilecleanv.fits
> 
> 
> And this is where it fails.
> 

It works fine for me:

backscale spectrumset=spectrum.pha withbadpixcorr=yes
badpixlocation=sourcefilecleanv.fits
backscale:- Executing (routine): backscale spectrumset=spectrum.pha
badpixlocation=sourcefilecleanv.fits withbadpixcorr=yes useodfatt=no
ignoreoutoffov=yes  -V 4
backscale:- backscale (backscale-1.3.2)  [xmmsas_20060628_1801-7.0.0] started:
2006-09-15T10:32:54.000
backscale:- Executing (routine): arfgen spectrumset=spectrum.pha withrmfset=no
rmfset=response.ds arfset=deletearf.ds detmaptype=flat
detmaparray=detmapfile.ds: withdetbounds=no detxoffset=1200 detxbins=1
detyoffset=1200 detybins=1 psfenergy=2 filterdss=yes withfilteredset=no
filteredset=filteredpixellist.ds withsourcepos=no sourcecoords=eqpos sourcex=0
sourcey=0 extendedsource=yes modeleffarea=no modelquantumeff=no
modelfiltertrans=no modelee=no modelootcorr=yes eegridfactor=100
withbadpixcorr=yes badpixlocation=sourcefilecleanv.fits setbackscale=yes
keeparfset=no useodfatt=no ignoreoutoffov=yes  -V 4
backscale:- arfgen (arfgen-1.70.4)  [xmmsas_20060628_1801-7.0.0] started: 
2006-09-15T10:32:54.000
backscale::arfgen:- Opening spectrumset spectrum.pha...
backscale::arfgen:- Closing spectrumset spectrum.pha.
backscale::arfgen:- Computing source position from region extent..
backscale::arfgen:- CCF constituents accessed by the calibration server:
CifEntry{EMOS1, FILTERTRANSX, 12, /ccf/pub/EMOS1_FILTERTRANSX_0012.CCF,
1998-01-01T00:00:00.000}
CifEntry{EMOS1, LINCOORD, 17, /ccf/pub/EMOS1_LINCOORD_0017.CCF,
1998-01-01T00:00:00.000}
CifEntry{EMOS1, MODEPARAM, 6, /ccf/pub/EMOS1_MODEPARAM_0006.CCF,
1998-01-01T00:00:00.000}
CifEntry{EMOS1, PATTERNLIB, 5, /ccf/pub/EMOS1_PATTERNLIB_0005.CCF,
1998-01-01T00:00:00.000}
CifEntry{EMOS1, QUANTUMEF, 16, /ccf/pub/EMOS1_QUANTUMEF_0016.CCF,
2000-01-01T00:00:00.000}
CifEntry{EMOS1, TIMECORR, 3, /ccf/pub/EMOS1_TIMECORR_0003.CCF,
1998-01-01T00:00:00.000}
CifEntry{RGS1, LINCOORD, 8, /ccf/pub/RGS1_LINCOORD_0008.CCF,
1998-01-01T00:00:00.000}
CifEntry{XMM, BORESIGHT, 19, /ccf/pub/XMM_BORESIGHT_0019.CCF,
2000-01-01T00:00:00.000}
CifEntry{XMM, MISCDATA, 21, /ccf/pub/XMM_MISCDATA_0021.CCF,
1999-01-01T00:00:00.000}
CifEntry{XRT1, XAREAEF, 8, /ccf/pub/XRT1_XAREAEF_0008.CCF,
2000-01-13T00:00:00.000}


backscale::arfgen:- Using a source position in DET coordinates of x=-121.594
y=-365.868
backscale::arfgen:-  The source position in focal plane coords is  theta=13.5351
phi=2.18837
backscale::arfgen:- detector map binning will be: xbins: 1 ybins: 1
backscale::arfgen:- Computing detector map bounds from the region selection
information stored in the spectrum ...
backscale::arfgen:- Constructing a FLAT detector map with  xmin=-23209.50145
xmax=22966.31261 xbins=1 ymin=-23453.77588 ymax=22722.04012 ybins=1
backscale::arfgen:- WCS info for the columns
temp_badcol_arfgen.del:BADPIX01:RAWX and temp_badcol_arfgen.del:BADPIX01:RAWX is
either non-existent or incomplete. A

Message of length 11406 truncated

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