Logged in as guest
Viewing RGS/4842 Full headers
Private message: yes no
Notes: Notification:
Date: Thu, 21 Mar 2002 15:58:44 GMT From: ilaria.cagnoni@uninsubria.it To: xmmhelp@xvsoc01.vilspa.esa.es CC: ilaria.cagnoni@uninsubria.it Subject: RGS extraction region offset
Full_Name: Ilaria Cagnoni Submission from: (NULL) (193.206.163.9) Hello, I run rgsproc on ObsId0080940101 within sas5.2.0 and after producing the dispersion images (dispersed spectrum BETA vs XDSP and bananaplot BETA vs PI) I run rgsimplot to see the extraction regions. While the region on the BETA-XDSP looks good, the ones in the banana plot are offset with repect to the spectral maxima. How can I choose the appropriate regions for the spectrum to be extracted? Is there a direct way? (e.g. draw a region onto ds9 and use that??) thanks a lot ilaria
From: Maria Santos-Lleo <xmmhelp@xmm.vilspa.esa.es> To: ilaria.cagnoni@uninsubria.it Subject: Re: RGS extraction region offset (PR#4842) Date: Fri Mar 22 20:36:20 2002
Dear Ilaria, To choose the appropriate regions for the spectrum to be extracted from RGS data, you can use the SAS task rgssources. It is designed exactly for that purpose. Hope this helps With best regards Maria Santos-Lleo, XMM-Newton SOC User Support Group
Date: Mon, 25 Mar 2002 13:51:26 +0100 From: Ilaria Cagnoni <ilaria.cagnoni@uninsubria.it> To: Maria Santos-Lleo <xmmhelp@xvsoc01.vilspa.esa.es> CC: fabrizio@brera.mi.astro.it, ilaria@uninsubria.it Subject: Re: RGS extraction region offset (PR#4842)
Thanks, I tried that. If I run rgssources with default values, the result is the same and the spectrum in the banana plot is missed. I tried to create a new source list from the EPIC PN image, and I already had troubles with a faked source found even increasing the likelihood of the detection at the highest limit (see details below). I solved this editing the fits file the row containing the faked source. And the I passed this epic pn source list to rgssources, but the source is not considered because "None of the epic sources have met all the conditions for inclusion". What are these selection criteria? Is this the correct way to proceed? I am writing next: 1)- a dump of the pn source list I passed to rgssources 2)- all the details of what I did so far. Thanks for your help ilaria ---- 1)- DUMP OF THE PN SOURCE LIST I PASSED TO RGSSOURCES BOX_ID_SRC ID_INST ID_BAND SCTS SCTS_ERR J J J E E counts counts 1 1 1 4.427446E+06 2.574151E+03 BOX_CTS X_IMA X_IMA_ERR Y_IMA Y_IMA_ERR E E E E E counts image pixels image pixels image pixels image pixels 2.960187E+06 2.757868E+02 2.101127E-05 2.720170E+02 2.147937E-05 SIGMA BG_MAP BG_RAW EXP_MAP FLUX E E E E E counts/pixel counts/pixel seconds cgs 2.083400E+07 3.825000E+01 3.825000E+01 5.703070E+04 7.763268E-10 FLUX_ERR RATE RATE_ERR RA E E E D cgs counts/pixel counts/pixel deg 4.513624E-13 7.763268E+01 4.513624E-02 3.297160644376E+02 DEC RADEC_ERR LII BII D E D D deg arcsec deg deg -3.022584230327E+01 1.502362E-04 1.772994473092E+01 -5.224508053981E+01 HR1 HR1_ERR HR2 HR2_ERR HR3 E E E E E NULL NULL NULL NULL NULL HR3_ERR BOX_SIZE EEF DIST_NN E E E E pixels arcsec NULL 5.000000E+00 6.683832E-01 2.039908E+02 ----------------------- 2)- DETAILS OF WHAT I DID: ---- evselect table='../../pipeprod/P0080940101PNS003PIEVLI0000.FIT' \ withimageset=yes imageset='pn_bin100.img' imagebinning='binSize'\ xcolumn='X' ycolumn='Y' ximagebinsize=100 yimagebinsize=100 eboxdetect withdetmask=no withexpimage=no imagesets='pn_bin100.img' \ boxsize=5 likemin=50 boxlistset='pn_sources.ds' usemap=no pn_sources.ds has a long list of faked sources we need a map background not a local background let's try to use esplinemap esplinemap bkgimageset='pn_bkg.fits' boxlistset='pn_sources.ds' \ imageset='pn_bin100.img' now run eboxdetect with the created background map mv pn_sources.ds pn_sources_local.ds eboxdetect withdetmask=no withexpimage=no imagesets='pn_bin100.img' \ boxsize=5 likemin=50 boxlistset='pn_sources.ds' usemap=yes \ bkgimagesets='pn_bkg.fits' fv pn_sources.ds & (view thw table) a faked source is detected at the border with the detector and PSF brightest line I use fv table delete rows to delete that false entry and to bring the source into row 1 rgssources rgsset='0174_0080940101_R1S00400_sources.ds' filemode='modify' \ clobberonlabel=yes withepicset=yes epicset='../EPIC/PN/pn_sources.ds' ** rgssources: warning (noValidEpicSources), None of the epic sources have met all the conditions for inclusion. ** rgssources: warning (primeAtDefault), Just a reminder that you may want to specify the new prime source index - it is still set to its default setting of 1. ** rgssources: warning (badPrimeRate), The prime source (index 1) has a RATE value of <= zero. Confusion values cannot be calculated. nothing changed!!! the source from the epic list was not accepted!!! Maria Santos-Lleo wrote: > > Dear Ilaria, > > To choose the appropriate regions for the spectrum to be > extracted from RGS data, you can use the SAS task > rgssources. It is designed exactly for that purpose. > > Hope this helps > > With best regards > > Maria Santos-Lleo, > XMM-Newton SOC > User Support Group -- Ilaria Cagnoni Dipartimento
Date: Tue, 26 Mar 2002 12:15:41 +0100 From: Ilaria Cagnoni <ilaria.cagnoni@uninsubria.it> To: Maria Santos-Lleo <xmmhelp@xvsoc01.vilspa.esa.es> CC: ilaria@uninsubria.it, fabrizio@brera.mi.astro.it Subject: Re: RGS extraction region offset (PR#4842)
Dear Maria, while waiting for your reply I tryed another way: I tried to use rgssources with user defined source. I took the source position from NED and calculate the count rate with pimms. But I was not able to create the output file. A detailed list of the things I did are below. Thanks for your help cheers, ilaria --- ATTEMPT WITH USER DEFINED SOURCE rgssources positionstyle='radec' ra=329.7169375 dec=-30.2255883 \ filemode='create' addusersource=yes \ atthkset='0174_0080940101_SCX00000_attitude.ds' \ instrument='rgs1' label='pks2155-304' \ rgsset='rgs1_usersourceslist.fits' rate=10. ** rgssources: warning (defaultExposure), Creation of a new file has been requested, but no value was assigned to the --exposure parameter. This prevents exposure-specific keywords from being written to the source list header. ** rgssources: error (noValidExposureId), Rgssources needs the exposure number in order to calculate the attitude, but you did not supply this via the --exposure parameter, and the task was unable to deduce a value. WE USED AS EXPOSURE TIME THE MAXIMUM VALUE IN THE EXPOSURE MAP FILE CREATED BY RGSPROC (I.E. 60378s) BVUT THIS DID NOT WORK APPARENTLY IT IS EXPECTING AN INTEGER < 999 ???? LET'S TRY TO SAY NOT TO USE THE EXPOSURE AND SKIP THE KEYWORDS rgssources positionstyle='radec' ra=329.7169375 dec=-30.2255883 \ filemode='create' addusersource=yes \ atthkset='0174_0080940101_SCX00000_attitude.ds' \ instrument='rgs1' label='pks2155-304' \ rgsset='rgs1_usersourceslist.fits' rate=10. writeexpkwds=no ** rgssources: warning (defaultExposure), Creation of a new file has been requested, but no value was assigned to the --exposure parameter. This prevents exposure-specific keywords from being written to the source list header. ** rgssources: error (noValidExposureId), Rgssources needs the exposure number in order to calculate the attitude, but you did not supply this via the --exposure parameter, and the task was unable to deduce a value. IT STILL WANTS THE EXPOSURE! RGSSOURCE HELP SAYS: "This is the exposure number. (...) Therefore, for example, if filemode=`create' but both writeexpkwds and exposure are left at default values, the task will fail with an error." BUT THE DEFAULT FOR writeexpkwds IS YES AND I CHANGED IT INTO NO!! WHY IS IT STILL FAILING? -----
From: Maria Santos-Lleo <xmmhelp@xmm.vilspa.esa.es> To: ilaria.cagnoni@uninsubria.it Subject: Re: RGS extraction region offset (PR#4842) Date: Tue Mar 26 17:47:58 2002
Dear Ilaria, Your problem with 'exposure' comes from a confusion between the 'exposure' keyword in the fits files headers, and the exposure ID number of your RGS 'exposures'. In the particular case of the observation you are using (I took the number from your email) , I can see in our log files that RGS1 is exposure number 4 and RGS2 is exposure number 5 > ATTEMPT WITH USER DEFINED SOURCE > > rgssources positionstyle='radec' ra=329.7169375 dec=-30.2255883 \ > filemode='create' addusersource=yes \ > atthkset='0174_0080940101_SCX00000_attitude.ds' \ > instrument='rgs1' label='pks2155-304' \ > rgsset='rgs1_usersourceslist.fits' rate=10. > > if you add another parameter, i.e. instrument='rgs1' exposure=4 or instrument='rgs2' exposure=5 the rgssources task should work I hope this helps and you can finally extract your rgs spectrum. Do not hesitate to contact us again in case of problems. (But please note that Thursday, Friday and Monday are public holidays here) With best regards Maria
Date: Thu, 11 Apr 2002 14:58:01 +0200 From: Ilaria Cagnoni <ilaria.cagnoni@uninsubria.it> To: Maria Santos-Lleo <xmmhelp@xvsoc01.vilspa.esa.es> CC: ilaria@uninsubria.it Subject: Re: RGS extraction region offset (PR#4842)
This is a multi-part message in MIME format. --------------E646B58107CC8D9806F9999B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Maria, thanks for your help. I run rgssources and reextracted a spectrum for the source as you suggested. But I have the same problem of the pipeline products (i.e. the extraction region in PI vs BETA does not center the spectrum, see attached ps figure) What can I do next? I am reporting at the end of this e-mail all the tasks I run thanks ilaria ************ TASKS RUN ******************************************** rgssources positionstyle='radec' ra=329.7169375 dec=-30.2255883 \ filemode='create' addusersource=yes \ atthkset='0174_0080940101_SCX00000_attitude.ds' \ instrument='rgs1' label='pks2155-304' \ rgsset='rgs1_usersourceslist.fits' rate=10. exposure=4 rgssources positionstyle='radec' ra=329.7169375 dec=-30.2255883 \ filemode='create' addusersource=yes \ atthkset='0174_0080940101_SCX00000_attitude.ds' \ instrument='rgs2' label='pks2155-304' \ rgsset='rgs2_usersourceslist.fits' rate=10. exposure=5 cp rgs1_usersourceslist.fits 0174_0080940101_R1S00400_sources.ds cp rgs2_usersourceslist.fits 0174_0080940101_R2S00500_sources.ds rgsangles set="0174_0080940101_R1S00400_merged.ds"\ sourceset="0174_0080940101_R1S00400_sources.ds" it changes something in the 0174_0080940101_R1S00400_merged.ds which is already filtered for the GTI rgsfilter set='0174_0080940101_R1S00400_merged.ds' \ expimageset='0174_0080940101_R1S00400_expmap.ds' \ filteredset='0174_0080940101_R1S00400_filtered.ds'\ withcombmap=yes withexpmaps=yes creates an exposure map and a filtered event list rgsregions set='0174_0080940101_R1S00400_sources.ds' \ eventset='0174_0080940101_R1S00400_filtered.ds' it modifies the 0174_0080940101_R1S00400_sources.ds file now check if the extraction region is ok evselect table='0174_0080940101_R1S00400_filtered.ds' imagebinning='imageSize'\ withimageset=yes imageset='rgs1.img' xcolumn='BETA' ycolumn='XDSP' \ ximagesize=600 yimagesize=600 evselect table='0174_0080940101_R1S00400_filtered.ds' imagebinning='imageSize'\ withimageset=yes imageset='rgs1_banana.img' xcolumn='BETA' ycolumn='PI' \ ximagesize=600 yimagesize=600 rgsimplot device=/VCPS srclistset='0174_0080940101_R1S00400_sources.ds'\ endispset='rgs1_banana.img' spatialset='rgs1.img' withspatialregionsets=yes\ --plotfile='rgs1_overlay.ps' gv rgs1_overlay.ps & ********* -- Ilaria Cagnoni Dipartimento di Scienze Universita' dell'Insubria/Como Via Valleggio 11, 22100 Como, Italy tel: +39-031-2386311 fax: +39-031-2386119 e-mail: ilaria.cagnoni@uninsubria.it ...or simply ilaria@uninsubria.it --------------E646B58107CC8D9806F9999B Content-Type: application/postscript; name="rgs1_overlay.ps" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="rgs1_overlay.ps" %!PS-Adobe-3.0 EPSF-3.0 %%For: ilaria %%Title: PGPLOT PostScript plot %%Creator: PGPLOT %%CreationDate: 11-Apr-2002 14:50 %%BoundingBox: (atend) %%DocumentFonts: (atend) %%LanguageLevel: 1 %%Orientation: Portrait %%Pages: (atend) %%EndComments %%BeginProlog /L {moveto rlineto currentpoint stroke moveto} bind def /C {rlineto currentpoint stroke moveto} bind def /D {moveto 0 0 rlineto currentpoint stroke moveto} bind def /SLW {5 mul setlinewidth} bind def /SCF /pop load def /BP {newpath moveto} bind def /LP /rlineto load def /EP {rlineto closepath eofill} bind def /MB {gsave translate MFAC dup scale 1 setlinewidth 2 setlinecap 0 setlinejoin newpath} bind def /ME /grestore load def /CC {0 360 arc stroke} bind def /FC {0 360 arc fill} bind def %%EndProlog 0.000 1.000 1.000 setrgbcolor %%Page: 1 1 %%BeginPageSetup /PGPLOT save def 0.072 0.072 scale 350 250 translate 1 setlinejoin 1 setlinecap 1 SLW 1 SCF %%EndPageSetup %%PageBoundingBox: (atend) 0.000 1.000 1.000 setrgbcolor 1 SLW gsave newpath 779 6036 moveto 6161 0 rlineto 0 3674 rlineto -6161 0 rlineto closepath clip /picstr 600 string def 600 600 8 [ 9.738E-02 0.000E+00 0.000E+00 1.633E-01 -7.595E+01 -9.857E+02 ] {currentfile picstr readhexstring pop} false 3 colorimage 00004D00004D00004D00004D00004D00004D00004D00004D00009B00004D00004D00004D00004D00004D00004D00004D00004D00004D00004D00004D 00004D00004D00004D00004D00004D00009B00004D00004D00004D00009B00004D00004D00009B00004D00004D00004D00004D00004D00004D00004D 00004D00004D00004D00004D00004D00004D00004D00004D00004D00004D00004D00004D00004D00004D00004D00004D00004D00004D00004D00004D 00004D00004D00004D00004D00004D00004D00004D00004D00004D00004D00004D00004D00004D00004D00004D00004D00004D00004D00004D00004D 00004D00004D00004D00004D00004D00004D00004D00004D00004D00004D00004D00004D00004D00004D00004D00004D00004D00004D00004D00004D 00004D00004D00004D00004D00004D00004D00004D00004D00004D00004D00004D00004D00004D00004D00004D00004D00004D00004D00004D00004D 00004D00004D00004D00004D00004D00004D00004D00004D00004D00004D00004D00004D00004D00004D00004D00004D00004D00004D00004D00004D 00004D00004D00004D0000
From: Maria Santos-Lleo <xmmhelp@xmm.vilspa.esa.es> To: ilaria.cagnoni@uninsubria.it Subject: Re: RGS extraction region offset (PR#4842) Date: Fri Apr 12 19:38:26 2002
Dear Ilaria, After having look to your plot, I must apologize I did not understood your question intially. Your initial question was clear enough, so it was my fault, I am very sorry for that. In principle, you could use the rgsregions to define new energy masks. However, there might be something special with your observations. Does this happen to all the rgs exposures in the revolution, or only to the one you are talking about ?. Sorry again for my misunderstanding. I will forward your question to RGS experts for advice. With best regards Maria
Date: Mon, 15 Apr 2002 15:47:25 +0200 From: Ilaria Cagnoni <ilaria.cagnoni@uninsubria.it> To: Maria Santos-Lleo <xmmhelp@xvsoc01.vilspa.esa.es> Subject: Re: RGS extraction region offset (PR#4842)
Hi Maria, > However, there might be something special > with your observations. Does this happen to all the rgs > exposures in the revolution, or only to the one you are > talking about ?. It happens also to ObsId0080940301. I have not checked ObsId0080940401 and ObsId008094501 yet. thanks ilaria -- Ilaria Cagnoni Dipartimento di Scienze Universita' dell'Insubria/Como Via Valleggio 11, 22100 Como, Italy tel: +39-031-2386311 fax: +39-031-2386119 e-mail: ilaria.cagnoni@uninsubria.it ...or simply ilaria@uninsubria.it
From: Maria Santos-Lleo <xmmhelp@xmm.vilspa.esa.es> To: ilaria.cagnoni@uninsubria.it Subject: Re: RGS extraction region offset (PR#4842) Date: Tue Apr 16 16:40:30 2002
Dear Ilaria, After consultation to our SAS experts, we realised that the problem you encountered is a problem of rgsimplot, but not a problem on the extraction regions themselves. This can be verified by making an overlay of your image of BETA_CORR versus PI with the command: imgdisplay withregiontable=true regiontable=your_source_list:RGS1_SRC1_ORDER_1 withimagefile=true imagefile=your_image.ds this command should show the correct regions. In any case, the problem with rgsimplot has been solved in the recently released SAS version 5.3. It was released yesterday. As you are currently reprocessing your data, and further improvements have been performed in the new rgs tasks, you may want to reprocess the data with sas 5.3 Therefore, I would strongly recommend you, in case it is possible for you, to change to sas 5.3 and forget about your previous problems. Please note that the syntax of the main rgs reduction (meta)task, rgsproc, has been changed in sas 5.3. However, after you have defined your SAS environment variables and run odfingest and cifbuilt, you only need to type 'rgsproc' to have standard outputs with default settings. Hope this solves all your problems. I apologize again for the delay my first misunderstanding may have caused to your analysis. Please do not hesitate to contact us again for further questions. With best regards Maria
Date: Mon, 22 Apr 2002 15:42:04 +0200 From: Ilaria Cagnoni <ilaria.cagnoni@uninsubria.it> To: Maria Santos-Lleo <xmmhelp@xvsoc01.vilspa.esa.es> CC: fabrizio@brera.mi.astro.it, ilaria@uninsubria.it Subject: Re: RGS extraction region offset (PR#4842)
This is a multi-part message in MIME format. --------------BE55316C7EE87CC1FE71D6D2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Thanks Maria, I installed sas5.3 and re-extracted the spectrum. The display problem is not solevd yet, though (see attached ps files). And I am puzzled by the funny shape of the extraction region in the BETA vs XDISP image (see attached ps files) Also, I was trying today to extract the spectrum of another obsid, but I run into odfingest troubles. As a check I tried to reproduce the RGS spectrum I extracted on Friday using the same SAS version (5.3) and the same commands and I am not able to do it since I incurr in the same odfingest problem. I have no idea on what is going on and why this happensa despite the same version of the sas software, the same ccf files and the same commends. Here are a list of commands I gave + the cifbuild and odfingest logs. thanks for your help ilaria ---------------------- COMMANDS: ---------------------- setsas setenv SAS_ODF /data/ilaria/pks2155/XMM/ObsId0080940101/odf setenv SAS_CCF /data/ilaria/pks2155/XMM/ObsId0080940101/odf setenv SAS_CCFPATH /calibrations/xmm/ccf setenv SAS_VERBOSITY 3 cd $SAS_ODF cifbuild > & cifbuild.log odfingest > & odfingest.log -------------------- cifbuild.log -------------------- cifbuild:- Executing (routine): cifbuild calindexset='ccf.cif' withccfpath=no us ecanonicalname=no ccfpath='.' recurse=no fileglob='*.ccf|*.CCF' fullpath=no with observationdate=no observationdate='now' analysisdate='now' category='XMMCCF' ig norecategory=no masterindex=no withmasterindexset=no masterindexset='ccf.mif' ap pend=no -V 3 cifbuild:- Will ask the analysis date to the OAL. cifbuild:- Using the ODF 0174_0080940101 found in /data/ilaria/pks2155/XMM/ObsId 0080940101/odf cifbuild:- Observation date: 2000-11-19T18:33:03.000 cifbuild:- Analysis date: 2002-04-22T13:12:43.000 -------------- odfingest.log -------------- odfingest:- Executing (routine): odfingest odfdir='.' withodfdir=no outdir='.' s ummaryfile='0000_0000000000_SCX000SUM.SAS' usecanonicalname=yes writepath=yes fi ndinstrumentmodes=yes usehousekeeping=yes oalcheck=no -V 3 odfingest:- Identified the following ODF Revolution: 0174 Observation: 0080940101 Proposal: 0080940101 odfingest:- Detected a data set with data mode 5 [Diagnostic]. This is know to c ontain the wrong DATE-END. I'm assigning to it an arbitrary duration of 1 second . odfingest:- Detected a data set with data mode 5 [Diagnostic]. This is know to c ontain the wrong DATE-END. I'm assigning to it an arbitrary duration of 1 second . odfingest:- Detected a data set with data mode 5 [Diagnostic]. This is know to c ontain the wrong DATE-END. I'm assigning to it an arbitrary duration of 1 second . odfingest:- Detected a data set with data mode 5 [Diagnostic]. This is know to c ontain the wrong DATE-END. I'm assigning to it an arbitrary duration of 1 second . (...) . odfingest:- Detected a data set with data mode 5 [Diagnostic]. This is know to c ontain the wrong DATE-END. I'm assigning to it an arbitrary duration of 1 second .odfingest:- Detected a data set with data mode 5 [Diagnostic]. This is know to c ontain the wrong DATE-END. I'm assigning to it an arbitrary duration of 1 second . odfingest:- Detected a data set with data mode 5 [Diagnostic]. This is know to c ontain the wrong DATE-END. I'm assigning to it an arbitrary duration of 1 second . ** odfingest: warning (MissingData), No CONFIGURATION record found. Maria Santos-Lleo wrote: > > Dear Ilaria, > > After consultation to our SAS experts, we realised that the problem you > encountered is a problem of rgsimplot, but not a problem on > the extraction regions themselves. > > This can be verified by making an overlay of your image of BETA_CORR > versus PI with the command: > > imgdisplay withregiontable=true > regiontable=your_source_list:RGS1_SRC1_ORDER_1 > withimagefile=true imagefile=your_image.ds > > this command should show the correct regions. > > In any case, the problem with rgsimplot has been solved in the > recently released SAS version 5.3. It was released yesterday. > As you are currently reprocessing your data, and further > improvements have been performed in the new rgs tasks, you > may want to reprocess the data with sas 5.3 > > Therefore, I would strongly recommend you, in case it is > possible for you, to change to sas 5.3 and forget about your > previous problems. > > Please note that the syntax of the main rgs reduction (meta)task, > rgsproc, has been changed in sas 5.3. However, after you have > defined your SAS environment variables and run odfingest and > cifbuilt, you only need to type 'rgsproc' to have standard > outputs with default settings. > > Hope this solves all your problems. I apologize again for the > delay my first misunderstanding may have caused to yo
From: Maria Santos-Lleo <xmmhelp@xmm.vilspa.esa.es> To: ilaria.cagnoni@uninsubria.it Subject: Re: RGS extraction region offset (PR#4842) Date: Mon Apr 22 16:29:48 2002 CC: fabrizio@brera.mi.astro.it
Dear Ilaria, I have got your new question, let me go step by step to try to answer - rgsimplot: > I installed sas5.3 and re-extracted the spectrum. > The display problem is not solevd yet, though (see attached ps files). can you please check which rgsimplot version are you using ?, please type: rgsimplot -v if you have sas 5.3 you should get rgsimplot-1.11.7 which should produce the right overlay we believe you may be still using an old version of rgsimplot as we get different results than you using sas 5.3 - 'funny shape' of extraction region: > And I am puzzled by the funny shape of the extraction region in the > BETA vs XDISP image (see attached ps files) we know the shape looks 'funny' but this is the correct one as implemented in sas 5.3 (via the ccf files). It comes from the fits to the spatial profiles of real sources It might be wise anyhow to change the default value of the fraction of the cross dispersion point spread function (PSF) for the source extraction region (e.g use 95 percent instead of the 90 per cent as default). This is because your target is very bright and you are probably excluding too many photons (see also the next point in this email regarding target coordinates). To do this you can use the following: rgsproc xpsfincl=95 xpsfexcl=98 pdistincl=95 in this way you will also change the percentage of the pulse-heigh distribution and the percentage of the cross-dispersion PSF exclusion region for background extraction (from the default of 95 to 98) - target coordinates: though the coordinates used in the proposal are quite similar to those reported in NED for your target, they do differ. It might be better to run rgsproc with the updated coordinates rgsproc withsrc=yes srclabel=my_source srcstyle=radec srcra= scrdec= - odfingest problems: > Also, > I was trying today to extract the spectrum of another obsid, > but I run into odfingest troubles. > As a check I tried to reproduce the RGS spectrum I extracted on Friday > using the same SAS version (5.3) and the same commands and > I am not able to do it since I incurr in the same odfingest problem. > I have no idea on what is going on and why this happensa despite > the same version of the sas software, the same ccf files and the same > commends. the problems that are mentioned, from your log are of two types (correct me if I missed something): > odfingest:- Detected a data set with data mode 5 [Diagnostic]. This is > know to contain the wrong DATE-END. I'm assigning to it an arbitrary > duration of 1 second you can disregard this message as it is only related to the 'diagnostic' files, which are not used in the normal processing. Please look into rgsproc or rgsoffsetcalc documentation if you want to see what they could be used for. this warning should not stop odfingest, nor prevent a right output to be created >> ** odfingest: warning (MissingData), No CONFIGURATION record found. this is again a harmless problem. You can proceed as odfingest should finish successfully . (Last, in case you want to run rgsproc with the parameters shown here, you can of course, combine the different parameters I suggested in one go) Hope this helps you to solve your problems. With best regards Maria
Date: Tue, 23 Apr 2002 10:51:24 +0200 From: Ilaria Cagnoni <ilaria.cagnoni@uninsubria.it> To: Maria Santos-Lleo <xmmhelp@xvsoc01.vilspa.esa.es> Subject: Re: RGS extraction region offset (PR#4842)
Hi Maria, yes, I did something wrong and I was still using sas v5.2. Now I run with v5.3 following your suggestions. rgsproc xpsfincl=95 xpsfexcl=98 pdistincl=95 \ withsrc=yes srclabel='pks2155' srcstyle=radec srcra=329.7169375 \ srcdec=-30.2255883 > & rgsproc.log and everything works fine BUT the rgsrmfgen part of rgsproc. When I look into the spectrum created by rgsproc the sourcesid keyword is properly set to 3 (the source I added to the list using ned coordinates) but when I look into the rmf the sourceid is 0 (proposal coordinates). PROC0 = 'rgsrmfgen evlist=''P0080940101R1S004EVENLI0000.FIT'' file=''P008094&' CONTINUE '0101R1S004matrix1003.FIT'' srclist=''P0080940101R1S004SRCLI_0000.F&' CONTINUE 'IT'' source=0 order=1 emax=2.8 emin=0.3 ebins=4000 withbackground=n&' CONTINUE 'o withspectrum=yes spectrumset=''P0080940101R1S004SRSPEC1003.FIT'' &' CONTINUE 'fftdim=3 # (rgsrmfgen-0.50.2) [xmmsas_20020413_2031-5.3.0]' Is there a way to ask rgsproc to calculate the rmf of source 3 or do I always need to rerun rgsrmfgen afterwards? Also... I suspect I need to re-run also rgsfluxer because it would use the wrong rmf. Thanks a lot. ilaria PS= I am having troubles with SAS but I appreciate the SAS-HELPDESK Thanks! -- Ilaria Cagnoni Dipartimento di Scienze Universita' dell'Insubria/Como Via Valleggio 11, 22100 Como, Italy tel: +39-031-2386311 fax: +39-031-2386119 e-mail: ilaria.cagnoni@uninsubria.it ...or simply ilaria@uninsubria.it
From: Maria Santos-Lleo <xmmhelp@xmm.vilspa.esa.es> To: ilaria.cagnoni@uninsubria.it Subject: Re: RGS extraction region offset (PR#4842) Date: Tue Apr 23 13:35:31 2002
Dear Ilaria, I am happy to hear that everything looks finally fine !. It seems that we are converging. With regard to your last problem, you do not need to worry (fortunately!) everything was done correctly: looking into the header you sent: > and everything works fine BUT the rgsrmfgen part of rgsproc. > When I look into the spectrum created by rgsproc the sourcesid keyword > is > properly set to 3 (the source I added to the list using ned coordinates) > but when I look into the rmf the sourceid is 0 (proposal coordinates). > > PROC0 = 'rgsrmfgen evlist=''P0080940101R1S004EVENLI0000.FIT'' > file=''P008094&' > CONTINUE '0101R1S004matrix1003.FIT'' > srclist=''P0080940101R1S004SRCLI_0000.F&' > CONTINUE 'IT'' source=0 order=1 emax=2.8 emin=0.3 ebins=4000 > withbackground=n&' > CONTINUE 'o withspectrum=yes > spectrumset=''P0080940101R1S004SRSPEC1003.FIT'' &' > CONTINUE 'fftdim=3 # (rgsrmfgen-0.50.2) [xmmsas_20020413_2031-5.3.0]' > You can see that rgsrmfgen is run with "withspectrum=yes" and "spectrumset=''P0080940101R1S004SRSPEC1003.FIT''" Then, if you look at the rgsrmfgen documentation, you see that "If the input spectrum is enabled, its SOURCEID attribute supersedes this parameter (source), which is only used for default spectrum filename" A similar comment is written for the "order" parameter of the rgsrmfgen task. Therefore, in your case, both the order and source ID have been taken from the input spectrum (i.e. P0080940101R1S004SRSPEC1003.FIT). From its name, I infer that it is indeed the 3rd source and first order. > Is there a way to ask rgsproc to calculate the rmf of source 3 or > do I always need to rerun rgsrmfgen afterwards? > I believe this question is already answer. Just in case, rgsproc computes the response matrix for the 'primary' source, i.e. proposal source by default, or given source when the following option is applied: "withsource=yes" as it is your case. > Also... I suspect I need to re-run also rgsfluxer > because it would use the wrong rmf. > in case the response matrix was wrong, yes, you would need to re-run rgsfluxer again. However, given all the above , you do not need to re-run it. Please note that, as mentioned in both rgsproc and rgsfluxer documentation, the rgsfluxer output is to be used for QUALITATIVE purposes only (e.g. display). For quantitative scientific analysis you should use fits of the (either net -as provided by default in rgsproc- or total plus background) spectra together with its own response matrices. Hope you can now start the scientific analysis of your data. Let me wish you exciting science ! With best regards Maria
Date: Wed, 24 Apr 2002 16:05:08 +0200 From: Ilaria Cagnoni <ilaria.cagnoni@uninsubria.it> To: Maria Santos-Lleo <xmmhelp@xvsoc01.vilspa.esa.es> CC: ilaria@uninsubria.it Subject: Re: RGS extraction region offset (PR#4842)
Thanks a lot, Maria. I now have the 4 RGS1 + 4 RGS2 spectra each with its background and its response matrice. There seem to be lines, but the signal to noise is too little in each of them to really say anything. I would like to combine these spectra in a total RGS1 and a total RGS2 spectrum to increase the SNR and then fit them as two different datasets. Since rgsfluxer states to be unuseful for accurate spectral analysis, I though of mathpha, but I am having troubles to figure out if I am doing the right thing. The BACKSCAL keyword in each spectrum is 1., but according to mathpha it should be the ratio of the source (or background) extraction region divided by the detector area. How do I visualize the background regions and how do I compute the backscal values? Or is there another way to combine the spectra (different from http://asca.gsfc.nasa.gov/docs/asca/abc_backscal.html) Also... how do I combine the response matrices? Is the task addarf good enough? And yes, how powerfull should the computer be to be able to combine 4 such huge rmfs? thank you again ilaria Maria Santos-Lleo wrote: > > Dear Ilaria, > > I am happy to hear that everything looks finally fine !. It seems that > we are converging. > > With regard to your last problem, you do not need to worry (fortunately!) > everything was done correctly: > > looking into the header you sent: > > > and everything works fine BUT the rgsrmfgen part of rgsproc. > > When I look into the spectrum created by rgsproc the sourcesid keyword > > is > > properly set to 3 (the source I added to the list using ned coordinates) > > but when I look into the rmf the sourceid is 0 (proposal coordinates). > > > > PROC0 = 'rgsrmfgen evlist=''P0080940101R1S004EVENLI0000.FIT'' > > file=''P008094&' > > CONTINUE '0101R1S004matrix1003.FIT'' > > srclist=''P0080940101R1S004SRCLI_0000.F&' > > CONTINUE 'IT'' source=0 order=1 emax=2.8 emin=0.3 ebins=4000 > > withbackground=n&' > > CONTINUE 'o withspectrum=yes > > spectrumset=''P0080940101R1S004SRSPEC1003.FIT'' &' > > CONTINUE 'fftdim=3 # (rgsrmfgen-0.50.2) [xmmsas_20020413_2031-5.3.0]' > > > > You can see that rgsrmfgen is run with "withspectrum=yes" and > "spectrumset=''P0080940101R1S004SRSPEC1003.FIT''" > > Then, if you look at the rgsrmfgen documentation, you see that > "If the input spectrum is enabled, its SOURCEID attribute supersedes > this parameter (source), which is only used for default spectrum filename" > > A similar comment is written for the "order" parameter of the rgsrmfgen > task. > > Therefore, in your case, both the order and source ID have been taken > from the input spectrum (i.e. P0080940101R1S004SRSPEC1003.FIT). From > its name, I infer that it is indeed the 3rd source and first order. > > > Is there a way to ask rgsproc to calculate the rmf of source 3 or > > do I always need to rerun rgsrmfgen afterwards? > > > > I believe this question is already answer. Just in case, rgsproc > computes the response matrix for the 'primary' source, i.e. proposal > source by default, or given source when the following option is > applied: "withsource=yes" as it is your case. > > > Also... I suspect I need to re-run also rgsfluxer > > because it would use the wrong rmf. > > > > in case the response matrix was wrong, yes, you would need to re-run > rgsfluxer again. However, given all the above , you do not need to > re-run it. > > Please note that, as mentioned in both rgsproc and rgsfluxer > documentation, the rgsfluxer output is to be used for QUALITATIVE > purposes only (e.g. display). For quantitative scientific analysis > you should use fits of the (either net -as provided by default > in rgsproc- or total plus background) spectra together with its own > response matrices. > > Hope you can now start the scientific analysis of your data. Let > me wish you exciting science ! > > With best regards > > Maria -- Ilaria Cagnoni Dipartimento di Scienze Universita' dell'Insubria/Como Via Valleggio 11, 22100 Como, Italy tel: +39-031-2386311 fax: +39-031-2386119 e-mail: ilaria.cagnoni@uninsubria.it ...or simply ilaria@uninsubria.it
From: Maria Santos-Lleo <xmmhelp@xmm.vilspa.esa.es> To: ilaria.cagnoni@uninsubria.it Subject: Re: RGS extraction region offset (PR#4842) Date: Thu Apr 25 15:27:25 2002
Dear Ilaria, > Thanks a lot, Maria. > I now have the 4 RGS1 + 4 RGS2 spectra each with its background and its > response matrice. > There seem to be lines, but the signal to noise is too little in each of > them to really say anything. > I would like to combine these spectra in a total RGS1 and a total RGS2 > spectrum to increase the SNR > and then fit them as two different datasets. > You must be aware that combining different RGS (even RGS1 with RGS1) spectra is not recommended. As you have already realised, this is far from simple: 1. As you know, the response matrices need to be created for every exposure, there is no (simple) way to combine them. I cannot judge the ftool command you are asking about (I guess addrmf , more than addarf, probably a typo in your mail), this is beyond our control, as we are not responsible for ftools and even more because we do not recommed to do it. 2. Different exposure times, background subtraction, etc, are (partly) often handled with the backscal keyword. Your problems with this keyword being equal to 1 in your spectra come from the fact that RGS spectra generated with sas 5.3 use a different approach than the standard one. The RGS spatial extraction mask has a spatial width which is a varying function of wavelength and therefore , instead of a single BACKSCAL keyword per spectrum, the spectra have an AREASCAL column (one number for each wavelength channel). 3. Last, but not least, error propagation is not simple either The recommended way to 'combine' different RGS spectra in order to improve the SNR is to fit them together , this is simpler and more accurate (from the statistical point of view). You can use, e.g., xspec xspec> data 1:1 file1.fit 1:2 file2.fit xspec> model .... In any case, let me also tell you that the need for a tool to combine two or more observations has been felt since early phases of the SAS development. Unfortunately, (mostly) manpower limitations have prevented us from tackling this issue so far. This would be a major change in the SAS structure, and a substantial amount of work is expected to implement it. With best regards Maria
Date: Fri, 26 Apr 2002 15:37:19 +0200 From: Ilaria Cagnoni <ilaria.cagnoni@uninsubria.it> To: Maria Santos-Lleo <xmmhelp@xvsoc01.vilspa.esa.es> Subject: Re: RGS extraction region offset (PR#4842)
They are not good news, but thanks a lot anyway ilaria Maria Santos-Lleo wrote: > > Dear Ilaria, > > > Thanks a lot, Maria. > > I now have the 4 RGS1 + 4 RGS2 spectra each with its background and its > > response matrice. > > There seem to be lines, but the signal to noise is too little in each of > > them to really say anything. > > I would like to combine these spectra in a total RGS1 and a total RGS2 > > spectrum to increase the SNR > > and then fit them as two different datasets. > > > > You must be aware that combining different RGS (even RGS1 with RGS1) > spectra is not recommended. As you have already realised, this > is far from simple: > > 1. As you know, the response matrices need to be created > for every exposure, there is no (simple) way to combine them. I cannot > judge the ftool command you are asking about (I guess addrmf , more than > addarf, probably a typo in your mail), this is beyond our control, > as we are not responsible for ftools and even more because we do not > recommed to do it. > > 2. Different exposure times, background subtraction, etc, are > (partly) often handled with the backscal keyword. Your problems > with this keyword being equal to 1 in your spectra come from the fact that > RGS spectra generated with sas 5.3 use a different approach than > the standard one. The RGS spatial extraction mask has a spatial > width which is a varying function of wavelength and therefore , instead > of a single BACKSCAL keyword per spectrum, the spectra have an > AREASCAL column (one number for each wavelength channel). > > 3. Last, but not least, error propagation is not simple either > > The recommended way to 'combine' different RGS spectra in order to > improve the SNR is to fit them together , this is simpler and more > accurate (from the statistical point of view). You can use, e.g., xspec > > xspec> data 1:1 file1.fit 1:2 file2.fit > xspec> model .... > > In any case, let me also tell you that the need for a tool to > combine two or more observations has been felt since early phases of > the SAS development. Unfortunately, (mostly) manpower limitations have > prevented us from tackling this issue so far. This would be a major > change in the SAS structure, and a substantial amount of work is expected > to implement it. > > With best regards > > Maria -- Ilaria Cagnoni Dipartimento di Scienze Universita' dell'Insubria/Como Via Valleggio 11, 22100 Como, Italy tel: +39-031-2386311 fax: +39-031-2386119 e-mail: ilaria.cagnoni@uninsubria.it ...or simply ilaria@uninsubria.it