[alma-config] simulated imaging test

[Steven]

I have been working on automating the comparative imaging simulations for
the candidate arrays applied to the SIL images.

Using the supplied .MODEL images from Min's pages for the A,C,and E arrays I
have generated the raw data as far as the dirty map for  25, -23 and -70
declinations, for both snapshot and 4 hour tracks, for all the members of
the SIL for both C configurations, and for M51 for both E configurations.
Before posting all the results thus far, here is a link to one set to get a
feel for what information I am currently posting, and to ask for comments on
what might be there instead/in addition- the link is
http://www.heddle97.freeserve.co.uk/SIL/test/ALMAtemplate2.html

Comments I wish to make myself are
1) I propose to provide a similar page for each set of results. i.e. each
combination of image, array, declination and snapshot or track will have a
separate page of similar data, comparing the ring and spiral results, 90
pages in all. There will be an index.
2) I will provide a page with the original images on for direct comparison
3) I will list the default aips parameters and the batch files used to
create the images
4) I realise that the grey scale images are the negative of what they should
be, and will change that. Also I intend to add a slice at     135 degrees
and incorporate all the slices into one graph, once I write a script for
gnuplot.
5) I will explain the scripts used and list the source
6) Using different versions of the SIL images for each resolution is already
possible
7) Links to higher resolution images?
8) If anybody wants all the data on CD (CDs?) that is possible
9) I am still using the 15APR99 version of AIPS with Leonias UVCON modified
according to his prescription, hence the NUVCO
    type on the UV data. Are there any issues with this version? Updating
via a midnight job is not practical using my 56K modem!
10) CLEANing or MEM is easily bolted on to the existing data.

All comments gratefully received. This work is developed from that described
in tortuous detail in Memo 290, an html version of which may be found at
http://www.heddle97.freeserve.co.uk/alma1/alma1.html

Regards,
    Steven Heddle
        (for the UKATC, Royal Observatory Edinburgh)

P.S. A throwaway question for the Linux community- I do all this work on
Linux, then boot back into Windows98 to ftp the results to my website, the
data residing on a disk partition shared between the two OSs with a VFAT
filesystem. In Windows most, but not all filenames of my Latex2HTML output
are changed to upper case, and these have to be laboriously changed back to
lower case before uploading to my ISP's UNIX webserver, to avoid broken
graphics. Any tips? (Doing everything from Linux would be ideal, but the
kppp I have is a bit flaky, and I am reluctant to muck about with the kernel
too much when these simulations re pending.)

----- Original Message -----
From: John Conway <jconway at ebur.oso.chalmers.se>
To: Min Yun <myun at zia.aoc.NRAO.EDU>
Cc: <alma-config at zia.aoc.NRAO.EDU>
Sent: Monday, July 31, 2000 1:14 PM
Subject: Re: [alma-config] simulated imaging test


>
>
> Hi,
>
>  I think that doing it the way you have proposed, with a single
> image for all reolutions will not be a useful exercise. In your
> C-array simulation the model image is too simple, i.e. has too few
> beam areas across the image, to distinguish between the imaging
> properties of the different array designs. I predict that at this
> level of complexity the two array designs will give very similar results.
>
> I think that in order to test the different arrays one wants to use
> the most complex images consistent with single pointing imaging. Is
> the proposed C-array image of Cygnus A on your web page really the most
> complex image one can imagine coming out of non-mosiaiced imaging
> in C-array with ALMA? Surely that is what we want to have?
>
> I believe its essential to have complex images with 4 or 5 pixels
> per beam at each array tested and 100 - 200 beams across - as we
> agreed in Tuscon - for there to be any point to doing the C-array
> simulations (which are most important becausue they are  a proxy in fact
> for 3 different arrays B,C and D). After all from a physical point of
> view as one
> goes to lower reolution if anything we expect to have more filled
> beam areas because of imcreased brightness temperature sensitivity.
> There is I agree a practical limit right now because we cannot easily do
> simulations of  mosiacied images, but we should chose the
> most complex images consistent with being in the regime which
> we can easily simulate.
>
>
>  Cheers
>    John
>
>
> P.S. I have put a corrected version of the A-array pad
> positions on my web site.
>
>
>
>
>
>
>
>
>
>
>
>
> On Fri, 28 Jul 2000, Min Yun wrote:
>
> > I have conducted a small set of imaging tests on Cygnus A model in
> > order to see if we have everything we need for imaging simulations
> > and all in correct format.  You can find my initial findings at:
> > www.aoc.nrao.edu/~myun/mma/imaging/sim.html.
> >
> > This is a demonstration of the feasibility and is not meant to be
> > a rigorous test of the imaging capability of the strawperson
> > arrays.  The same input model image was used for all different
> > simulated observations. The comparison images are
> > constructed by convolving the input image with the synthesized
> > Gaussian beams of the simulated observations -- as I discussed
> > in my earlier e-mail. All images are shown with logarithmic
> > stretch in order to bring out the low level extended features.
> >
> > I find little evidence for gridding/sampling effects in the simulated
> > observation images. One practical issue I have come
> > across is that all model images needed to be scaled up by some
> > factor (numbers of pixels per beam as well as the ratio in area
> > between the model and the reconstructed beam) because the unit of
> > the input image is in "Jy/beam" rather than "Jy/pixel"
> > -- the simulated and reconstructed images are expected to be
> > in "Jy/beam" unit as well. We may need to worry about any
> > error arising from computing the beam area in numbers of pixels
> > during the comparison between the model and simulated image.
> >
> > Please comment on what I have done here.  Any suggestions to improve
> > the process are welcome.
> >
> >
> >
> > -- Min
> >
>
>