Logged in as guest
Viewing RGS/9485 Full headers
Private message: yes no
Notes: SOC-SAS-SPR 2480 SOC-SAS-SPR 2481 Notification:
Date: Mon, 10 Nov 2003 18:30:05 GMT From: mangano@mporzio.astro.it To: xmmhelp@xmm.vilspa.esa.es CC: mangano@mporzio.astro.it Subject: phase filtered spectroscopy with RGS data
Full_Name: Vanessa Mangano Submission from: (NULL) (192.156.213.169) Dear help desk, I would like to extract RGS spectra of a pulsating source corresponding, for instance, to the peak phase only. I think I could try the following steps: - run rgsproc to generate the event files (finalstage=angles) - apply barycentric correction to the event files - add the phase column to the event list with phasecalc - filter events in a given phase interval with evselect - start again rgsproc (entrystage=filter) Do you think this is the right way to build my spectra? Do you know an easier procedure? Thank you very much Vanessa
From: Pedro M. Rodriguez Pascual <xmmhelp@xmm.vilspa.esa.es> To: mangano@mporzio.astro.it Subject: Re: phase filtered spectroscopy with RGS data (PR#9485) Date: Tue Nov 11 09:46:33 2003
Hello Vanessa, > Full_Name: Vanessa Mangano > Submission from: (NULL) (192.156.213.169) > > > Dear help desk, > I would like to extract RGS spectra of a pulsating > source corresponding, for instance, to the peak phase only. > > I think I could try the following steps: > - run rgsproc to generate the event files (finalstage=angles) > - apply barycentric correction to the event files > - add the phase column to the event list with phasecalc > - filter events in a given phase interval with evselect > - start again rgsproc (entrystage=filter) > > Do you think this is the right way to build my spectra? > Do you know an easier procedure? > This is the right approach. Just a comment on the actual procedure for filtering: once you have the column PHASE, create a gti as tabgtigen table=events.fits gtiset=phase_filter.fits expression='PHASE in [0.1:0.3]' then enter this gti (phase_filter.fits) file into the rgsproc at the "filter" tab: auxgtitables=phase_filter.fits and re-run rgsproc at entrystage=filter In case you get into trouble, do not hesitate to contact us again. Sincerely, Pedro
Date: Thu, 13 Nov 2003 13:38:45 +0000 From: Vanessa Mangano <mangano@mporzio.astro.it> To: "Pedro M. Rodriguez Pascual" <xmmhelp@xmm.vilspa.esa.es> Subject: Re: phase filtered spectroscopy with RGS data (PR#9485)
This is a multi-part message in MIME format. --------------FFD0AAF2638A03831272485B Content-Type: multipart/alternative; boundary="------------A1B8F8AD7313FE516EE0B4A8" --------------A1B8F8AD7313FE516EE0B4A8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear Pedro, unfortunately I am getting into many troubles.... I will try to be as schematic as possible. First point: I am analysing the RGS data of two pulsating X-ray sources that I know very well. From the EPIC data it appears that these sources have periods of 321 s and 5.5 s respectively and their background subtracted light curves are 100% and 50% modulated respectively. I have run rgsproc, filtered the high background time intervals and re-run rgsproc according to the standard threads, then I extracted the source light curves from the RGS event files with the command evselect table=P**EVENLI***.FIT:EVENTS timebinsize=0.5 \ withrateset=yes rateset=src_lc.fit \ makeratecolumn=yes maketimecolumn=yes \ expression='((BETA_CORR,PI) IN REGION(P**SRCLI***.FIT:RGS1_SRC3_ORDER_1))&&( (BETA_CORR,XDSP_CORR) IN REGION(P**SRCLI***.FIT:RGS1_SRC3_SPATIAL))' I performed an epoch folding with efold at the known periods on the src_lc.fit files and only in one case (the 321 s case) I see the pulsation. I have also applied the barycentric correction before extracting the light curves (see second point), and the result is the same: the pulsation at 321 s is clearly visible (and the folded light curve is better than before barycentrization), while the 5.5 s pulsation cannot be seen. Then I have calculated power spectra of the two light curves and it appears that in both cases a very strong peak at about 0.2 Hz (4.595 s period) is present, and does not depend on the light curve binning time. I think this peak interferes with my expected peak at 0.18 Hz.... I send you the gif of one of these power spectra in attachment as an example: you can see the high peak on the left corresponding to the 321s pulsation and the following very high peak at about 0.2 Hz which is clearly unphysical for this source (and is not present in EPIC power spectra). Are you aware of some instrumental effect that might cause such a spurious pulsation in the RGS light curves? %%%%%%%%%%%%%%%%%%%%%%%%%%% Second point: As I told you, I have found the way to apply barycentric correction to the RGS events. I have discovered I cannot use the task barycen on the filtered event list (the ****EVENLI****.FIT files). It gives the following error: ** barycen: error (attributableNotFound), Could not find attribute with qualified name *****EVENLI****.FIT%TSTART in attributable set *****EVENLI****.FIT Anyway I can apply barycentric correction on the merged events (the ****merged****.FIT files). So, I simply did it and then rerun rgsproc to produce new filtered event files. I have inspected the old and the new filtered events with fv and ... I found that not only the times are different, but also the angles. I cannot find any couple of XDSP_CORR, BETA_CORR values of the old file in the new one. Should I worry about this? Should I trust the final RGS spectra produced in this way? %%%%%%%%%%%%%%%%%%%%%%%%%%% Third point: When I use the task phasecalc on merged or filtered events, both before and after barycentrization, I always get negative values of the phase. I used the same frequency and reference epoch already used for EPIC data, and in that case everything went perfectly well. I tried to change frequency and reference epoch... the phases are still negative. %%%%%%%%%%%%%%%%%%%%%%%%%%% Fourth point: I would like to do background subtraction in the RGS lightcurves. I was thinking to extract background lightcurves (all the CCDs, not only CCD 9 as I do for cheking the solar flare presence), estimate the average background count rate and use it for background subtraction in the source light curve. When I do this with EPIC data I have to normalise the background count rate to the source extraction region area. I think I should do also with RGS, but I don't know how to estimate the source/background extraction areas. Thank you very much for your help Vanessa "Pedro M. Rodriguez Pascual" wrote: > Hello Vanessa, > > > Full_Name: Vanessa Mangano > > Submission from: (NULL) (192.156.213.169) > > > > > > Dear help desk, > > I would like to extract RGS spectra of a pulsating > > source corresponding, for instance, to the peak phase only. > > > > I think I could try the following steps: > > - run rgsproc to generate the event files (finalstage=angles) > > - apply barycentric correction to the event files > > - add the phase column to the event list with phasecalc > > - filter events in a given phase interval with evselect > > - start again rgsproc (entrystage=filter) > > > > Do you think this is the right way to build my spectra? > > Do you know an eas
From: Pedro M. Rodriguez Pascual <xmmhelp@xmm.vilspa.esa.es> To: mangano@mporzio.astro.it Subject: Re: phase filtered spectroscopy with RGS data (PR#9485) Date: Thu Nov 13 14:13:27 2003
Dear Vanessa, First Point ----------- Note that the read-out time for one RGS CCD is ~0.6sec; so, a spurious peak near 4.8sec may appear in the power spectrum of light curves using 8 CCDs (http://xmm.vilspa.esa.es/external/xmm_user_support/documentation/uhb/node58.html). Second Point ------------ Two keywords are missing from the header of the EVENTS extension of the RGS filtered events file: TSTART and TSTOP. We have open a SOC-SAS-SPR to solve it (http://xmm.vilspa.esa.es/sas-cgi/db/spr?ViewRecord=1&Id=2480). A workaround is to add these keywords to the header of the EVENTS extension: TSTART should be the minimum of the TSTART keyword found in extensions STDGTInn and TSTOP should be the maximum of the TSTOP keyword found in extensions STDGTInn. Note that barycen changes the TIME column, and this TIME is used to calculate _CORR angles based on S/C aspect angle. Therefore, the angles may be slightly different. IT is not recommended to run barycen on the RGS merged events file. Third Point ------------ The phase calculated by phasecalc in RGS filtered events file is wrong (not only the sign) because the keyword MJDRED is missing in the header of the EVENTS extension (then it assumes it is 0, try phasecalc ... -V 4). As in previous point, we have issued a SOC-SAS-SPR (http://xmm.vilspa.esa.es/sas-cgi/db/spr?ViewRecord=1&Id=2480) for this problem to fixed. A workaround is to add such keyword with a value 50814. to the header. Fourth Point ------------- If you are constructing source and background light curves from the source and background regions defined in the RGS source lists (if not you should), you can find the number of source and background pixels as keyword PIX_ENCL in extensions RGSi_SRCn_SPATIAL and RGSi_BACKGROUND in files P****RiSmmmSRCLI_0000.FIT Hope this will help. Sincerely, Pedro