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 Data/22851
Full headers

From: jonmm@umich.edu
Subject: 3C 287 observations
Compose reply
Download message
Move To:
1 replies: 1
1 followups: 1

Private message: yes  no

Notes:

Notification:


Date: Wed, 09 Aug 2006 17:57:23 -0400
From: jonmm@umich.edu
Subject: 3C 287 observations
To: xmmhelp@xmm.vilspa.esa.es
This message is in MIME format.

--=_6tm9vkogmso4
Content-Type: text/plain;
	charset=ISO-8859-1;
	format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Hi,

I have downloaded the ODFs for 0401260101, and 0401260201, and 
attempted to make PPS products myself.

I cannot get products for 201.

The EPIC-pn images that result from 101 are very strange indeed; it 
appears that neither epchain nor epproc can make a reliable pn event 
list.

I just wanted to flag this, in case extra attention can be given on the 
XMM side of things when the standard PPS files are produced.

Many thanks,

Jon Miller

plot of pn image attached



--=_6tm9vkogmso4
Content-Type: application/postscript;
	name="0401260101.ps"
Content-Disposition: attachment;
	filename="0401260101.ps"
Content-Transfer-Encoding: 7bit

%!PS-Adobe-3.0 EPSF-3.0
%%Creator: Tk Canvas Widget
%%For: Jon Miller
%%Title: Window .ds9.image
%%CreationDate: Wed Aug  9 17:33:37 2006
%%BoundingBox: 36 178 577 614
%%Pages: 1
%%DocumentData: Clean7Bit
%%Orientation: Portrait
%%EndComments

%%BeginProlog
/CurrentEncoding [
/space/space/space/space/space/space/space/space
/space/space/space/space/space/space/space/space
/space/space/space/space/space/space/space/space
/space/space/space/space/space/space/space/space
/space/exclam/quotedbl/numbersign/dollar/percent/ampersand/quotesingle
/parenleft/parenright/asterisk/plus/comma/hyphen/period/slash
/zero/one/two/three/four/five/six/seven
/eight/nine/colon/semicolon/less/equal/greater/question
/at/A/B/C/D/E/F/G
/H/I/J/K/L/M/N/O
/P/Q/R/S/T/U/V/W
/X/Y/Z/bracketleft/backslash/bracketright/asciicircum/underscore
/grave/a/b/c/d/e/f/g
/h/i/j/k/l/m/n/o
/p/q/r/s/t/u/v/w
/x/y/z/braceleft/bar/braceright/asciitilde/space
/space/space/space/space/space/space/space/space
/space/space/space/space/space/space/space/space
/space/space/space/space/space/space/space/space
/space/space/space/space/space/space/space/space
/space/exclamdown/cent/sterling/currency/yen/brokenbar/section
/dieresis/copyright/ordfeminine/guillemotleft/logicalnot/hyphen/registered/macron
/degree/plusminus/twosuperior/threesuperior/acute/mu/paragraph/periodcentered
/cedilla/onesuperior/ordmasculine/guillemotright/onequarter/onehalf/threequarters/questiondown
/Agrave/Aacute/Acircumflex/Atilde/Adieresis/Aring/AE/Ccedilla
/Egrave/Eacute/Ecircumflex/Edieresis/Igrave/Iacute/Icircumflex/Idieresis
/Eth/Ntilde/Ograve/Oacute/Ocircumflex/Otilde/Odieresis/multiply
/Oslash/Ugrave/Uacute/Ucircumflex/Udieresis/Yacute/Thorn/germandbls
/agrave/aacute/acircumflex/atilde/adieresis/aring/ae/ccedilla
/egrave/eacute/ecircumflex/edieresis/igrave/iacute/icircumflex/idieresis
/eth/ntilde/ograve/oacute/ocircumflex/otilde/odieresis/divide
/oslash/ugrave/uacute/ucircumflex/udieresis/yacute/thorn/ydieresis
] def

50 dict begin
% This is a standard prolog for Postscript generated by Tk's canvas
% widget.
% RCS: @(#) $Id: mkpsenc.tcl,v 1.1.1.1 2004/04/02 22:35:05 joye Exp $
% The definitions below just define all of the variables used in
% any of the procedures here.  This is needed for obscure reasons
% explained on p. 716 of the Postscript manual (Section H.2.7,
% "Initializing Variables," in the section on Encapsulated Postscript).
/baseline 0 def
/stipimage 0 def
/height 0 def
/justify 0 def
/lineLength 0 def
/spacing 0 def
/stipple 0 def
/strings 0 def
/xoffset 0 def
/yoffset 0 def
/tmpstip null def
/cstringshow {
{
dup type /stringtype eq
{ show } { glyphshow }
ifelse
}
forall
} bind def
/cstringwidth {
0 exch 0 exch
{
dup type /stringtype eq
{ stringwidth } { 
currentfont /Encoding get exch 1 exch put (\001) stringwidth 
}
ifelse 
exch 3 1 roll add 3 1 roll add exch
}
forall
} bind def
% font ISOEncode font
% This procedure changes the encoding of a font from the default
% Postscript encoding to current system encoding.  It's typically invoked just
% before invoking "setfont".  The body of this procedure comes from
% Section 5.6.1 of the Postscript book.
/ISOEncode {
dup length dict begin
{1 index /FID ne {def} {pop pop} ifelse} forall
/Encoding CurrentEncoding def
currentdict
end
% I'm not sure why it's necessary to use "definefont" on this new
% font, but it seems to be important; just use the name "Temporary"
% for the font.
/Temporary exch definefont
} bind def
% StrokeClip
%
% This procedure converts the current path into a clip area under
% the assumption of stroking.  It's a bit tricky because some Postscript
% interpreters get errors during strokepath for dashed lines.  If
% this happens then turn off dashes and try again.
/StrokeClip {
{strokepath} stopped {
(This Postscript printer gets limitcheck overflows when) =
(stippling dashed lines;  lines will be printed solid instead.) =
[] 0 setdash strokepath} if
clip
} bind def
% desiredSize EvenPixels closestSize
%
% The procedure below is used for stippling.  Given the optimal size
% of a dot in a stipple pattern in the current user coordinate system,
% compute the closest size that is an exact multiple of the de

Message of length 449092 truncated

Reply 1

Resend
From: Matthias Ehle <xmmhelp@sciops.esa.int>
To: jonmm@umich.edu
Subject: Re: 3C 287 observations (PR#22851)
Date: Thu Aug 10 09:38:42 2006
Dear Jon,

In ObsId 0401260201 only MOS1 and MOS2 exposures were performed with the
CALCLOSED filter position and in a special diagnostic mode for internal
calibration only. So there is no science data in this observation.

I processed ObsId 0401260101 myself with epproc (no special parameter
settings) in SAS 7.0 and did not find any problem. I am sending you
the afterwads produced pn image in a minute from my private e-mail account.
The only selection I applied for the image generation was 
(PI>=300)&&(PATTERN<=12)&&(FLAG==0).

I also processed the data with epchain (both foe the OoT event file
and the 'normal event file generation) and also there I did not get any
error messages and the resulted image looks fine to me as well.

So in fact I have no clue on what's going wrong at your site.
I also attach in my other e-mail to you the log file of the epproc run.
Maybe comparing this with what you get could give us a hint?

Cheers,
   Matthias

> Hi,
> 
> I have downloaded the ODFs for 0401260101, and 0401260201, and 
> attempted to make PPS products myself.
> 
> I cannot get products for 201.
> 
> The EPIC-pn images that result from 101 are very strange indeed; it 
> appears that neither epchain nor epproc can make a reliable pn event 
> list.
> 
> I just wanted to flag this, in case extra attention can be given on the 
> XMM side of things when the standard PPS files are produced.
> 
> Many thanks,
> 
> Jon Miller--
   Dr Matthias Ehle 
   XMM-Newton User Support Group
   European Space Astronomy Centre


Followup 1

Compose reply
Download message
Date: Thu, 10 Aug 2006 06:26:20 -0400
From: jonmm@umich.edu
Subject: Re: 3C 287 observations (PR#22851)
To: Matthias Ehle <xmmhelp@sciops.esa.int>
Many thanks, Matthias.

At least this makes it clear that it is a problem on my end, not a 
problem with the data, and knowing that makes a starting point.

Best regards,

Jon



Quoting Matthias Ehle <xmmhelp@sciops.esa.int>:

> Dear Jon,
>
> In ObsId 0401260201 only MOS1 and MOS2 exposures were performed with the
> CALCLOSED filter position and in a special diagnostic mode for internal
> calibration only. So there is no science data in this observation.
>
> I processed ObsId 0401260101 myself with epproc (no special parameter
> settings) in SAS 7.0 and did not find any problem. I am sending you
> the afterwads produced pn image in a minute from my private e-mail account.
> The only selection I applied for the image generation was
> (PI>=300)&&(PATTERN<=12)&&(FLAG==0).
>
> I also processed the data with epchain (both foe the OoT event file
> and the 'normal event file generation) and also there I did not get any
> error messages and the resulted image looks fine to me as well.
>
> So in fact I have no clue on what's going wrong at your site.
> I also attach in my other e-mail to you the log file of the epproc run.
> Maybe comparing this with what you get could give us a hint?
>
> Cheers,
>   Matthias
>
>> Hi,
>>
>> I have downloaded the ODFs for 0401260101, and 0401260201, and
>> attempted to make PPS products myself.
>>
>> I cannot get products for 201.
>>
>> The EPIC-pn images that result from 101 are very strange indeed; it
>> appears that neither epchain nor epproc can make a reliable pn event
>> list.
>>
>> I just wanted to flag this, in case extra attention can be given on the
>> XMM side of things when the standard PPS files are produced.
>>
>> Many thanks,
>>
>> Jon Miller--
>   Dr Matthias Ehle
>   XMM-Newton User Support Group
>   European Space Astronomy Centre
>
>
>



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