Simulating ALMA observations of a simulated protoplanetary disk at 50 and 100pc
Sebastian Wolf kindly provided a 900 GHz FITS image of a protoplanetary disk with a jovian planet forming (
Wolf and D'Angelo 2005). The image had been converted into FITS format using IDL, and like most numerical simulations, did not come with header values such as a position (why should it?). Also, the image had 64 floating place bits per pixel (
BITPIX = -64
), which is so far beyond the normal depth of astronomical images that most astronomical software, including CASA, could not display it. Fortunately
kvis
, from the karma package, could, so the first step was to view it in
kvis
and export it as a
miriad
image, which downsampled it to
BITPIX = -32
. At the time CASA had no task for adding arbitrary headers, so I used
miriad
to specify the position, epoch, and brightness unit:
-
puthd in=inputthrukarmass.mir/epoch value=2000.0
-
puthd in=inputthrukarmass.mir/bunit value=Jy/pixel
-
puthd in=inputthrukarmass.mir/crval2 value=-23.0,dms
(declination)
-
puthd in=inputthrukarmass.mir/crval1 value=18.0,hms
(RA)
-
puthd in=inputthrukarmass.mir/cdelt1 value=0.00311,arcsec
-
puthd in=inputthrukarmass.mir/cdelt2 value=0.00311,arcsec
-
puthd in=inputthrukarmass.mir/ra value=18.0,hms
-
puthd in=inputthrukarmass.mir/dec value=-23.0,dms
-
puthd in=inputthrukarmass.mir/ctype1 value=RA---SIN
-
puthd in=inputthrukarmass.mir/ctype2 value=DEC--SIN
-
fits in=inputthrukarmass.mir op=xyout out=inputthrukarmass.fits
Then I read
inputthrukarmass.fits
into CASA with
idlfitstocasaim.py, which also added frequency and Stokes axes.
Changing frequency
Wolf and D'Angelo produced a 900 GHz image from their simulation, which maximizes both the dust brightness for ALMA's frequency range, and the sharpness of
ALMA's point spread function. However, ALMA's T
sys is also expected to go up with frequency, the effect of phase noise worsens, and there is always a tradeoff between surface brightness sensitivity and beam sharpness. Taking those effects into account led us to pick 672 GHz as the optimum observing frequency. This meant that two aspects of the input image had to be changed:
- its frequency header (handled as in idlfitstocasaim.py), and
- its pixel values, using an appropriate spectral index for dust.
The input image after being adjusted to 672 GHz:
Changing distance
The input image came with a distance of 50pc, which is nearly the distance of the closest known example of such objects, the Butterfly Star, at 53pc (actually, the real Butterfly Star is in Taurus, at 140 pc). ALMA should be able to do a good job of imaging protoplanetary disks as far away as 100pc, so I made a copy of the input image and moved the copy out to 100pc by
- halving the pixel size (in the header), and
- multiplying each pixel value by (50pc/100pc)2. CASA is in the process of writing "task" wrappers for "tools" that essentially come straight from AIPS++, and image arithmetic is an example of where it is still necessary to use a tool directly, specifically the imageanalysis (
ia
) tool:
ia.open('input672GHz_50pc.image')
ia.imagecalc(outfile='input672GHz_100pc.im', pixels='0.25 * input672GHz_50pc.image')
ia.close()
Adding the star
[[http://www.mpia.de/homes/swolf/homepage/html/public/alma/alma-simus.html][Wolf
and D'Angelo]] did not include the flux density from the star in the image they
supplied, but a star is easy to add using a CLEAN component:
- dec = -23
- direction = "J2000 18h00m00.03s %sd0m0.0s" % dec # Be careful to get this right.
- cl.addcomponent(dir=direction, flux=1.0, freq='672.0GHz')
- compname = "star672GHz_dec%d.cl" % dec
- cl.rename(compname)
- cl.done()
The blackbody flux density of the star is only 0.25 mJy at 50pc, and that has
been included in most of the images below. Presumably that is a lower bound,
since the dominant source for submm flux from the star and its immediate
neighborhood is could well be dust (as it is for the protojovian). However,
the star could have destroyed dust grains in its immediate vicinity, or
(unlikely at these wavelengths) be attenuated by the dust. We intend to update
these simulations soon with a brighter star, if only to test the dynamic range
capabilities of ALMA.
Adding noise
Top left: Protoplanetary disk simulation provided by Sebastian Wolf, as "observed" at 672 GHz by ALMA's Y1 configuration for 8h, but
without any noise or phase errors. The disk mass is set to that of the
Butterfly Star in Taurus, with an embedded planet of 1Mjup around a 0.5M\u2299
star (orbital radius: 5AU). The assumed distance is 50 pc. The image of the
star appears slightly off center because it was added later. The Y1
configuration is the most compact Y configuration, with a 0.025" x 0.020" beam
(maximum baseline = 8km, Briggs weighting).
|
Top right: A same simulated observation, with only thermal noise (Tsys = 540K).
|
Bottom left: The same simulated observation (incl. thermal noise), with phase
corruption from a 100m thick screen with 0.5mm PWV exhibiting Kolmogorov
turbulence. (pwvtodelay = 300.0 # fs / mm)
|
Bottom right: The same simulated observation, also with 0.5 mm PWV, but
with residual phase errors (using a specification found in ALMA memo 521)
after correction from fast switching and WVR. (pwvtocorrecteddelay = 1.4142
* 0.02 * pwvtodelay + 0.01 / 2.9978e-4, for now see the memo and
noisify_alma.py for more details.)
|
Each image is displayed with the same spatial and intensity scales, and is
linked to its FITS file.
The observation simulations were performed by casapy's "almasimmos", which
currently does not add thermal or phase noise. That was done with noisify_alma.py, by Kumar Golap and Rob Reid. It's
not very general, but it's a start. This object is rather small and easily
fits within a single primary beam, so I didn't worry about pointing errors
after calculating that they should not make much difference.
New: Wed Apr 18 14:34:13 EDT 2007
The same sim, at 672 GHz, with 30 degrees of phase noise uniformly distributed among the antennas.
. This should be nearly the same
setup as used by
Wolf and D'Angelo 2005 (scroll to bottom), except for the change in frequency.
--
RobReid - 21 Sep 2007