Date: Mon, 10 Dec 2012 09:58:16 -0500
From: Eric R. Keto 
To: ccyganowski@cfa.harvard.edu, cespaillat@cfa.harvard.edu, cqi@cfa.harvard.edu, dwilner@cfa.harvard.edu, hwei@cfa.harvard.edu,
     ijimenez-serra@cfa.harvard.edu, joannabrown@cfa.harvard.edu, jzhao@cfa.harvard.edu, kyoung@cfa.harvard.edu,
     mgurwell@cfa.harvard.edu, npatel@cfa.harvard.edu, rbussmann@cfa.harvard.edu, sandrews@cfa.harvard.edu,
     tksridharan@cfa.harvard.edu, tbourke@cfa.harvard.edu, keto@cfa.harvard.edu, rblundell@cfa.harvard.edu,
     spaine@cfa.harvard.edu, etong@cfa.harvard.edu, rburgos@cfa.harvard.edu, jmoran@cfa.harvard.edu, pmyers@cfa.harvard.edu,
     mreid@cfa.harvard.edu, lgreenhill@cfa.harvard.edu, agoodman@cfa.harvard.edu, clada@cfa.harvard.edu,
     pthaddeus@cfa.harvard.edu, jforbrich@cfa.harvard.edu, zwang@cfa.harvard.edu, mashby@cfa.harvard.edu, qzhang@cfa.harvard.edu,
     ckatz@cfa.harvard.edu, bzauderer@cfa.harvard.edu, gmelnick@cfa.harvard.edu, gpetitpas@cfa.harvard.edu,
     jweintroub@cfa.harvard.edu, asoderberg@cfa.harvard.edu, jueda@cfa.harvard.edu, rjharris@cfa.harvard.edu,
     krosenfeld@cfa.harvard.edu, eberger@cfa.harvard.edu, cgottlieb@cfa.harvard.edu, lwatson@cfa.harvard.edu,
     svanloo@cfa.harvard.edu, aargon@cfa.harvard.edu, rwilson@cfa.harvard.edu, ydai@cfa.harvard.edu, mazimlu@cfa.harvard.edu,
     xjiang@cfa.harvard.edu, pgrimes@cfa.harvard.edu, cpapa@cfa.harvard.edu, jbarrett@cfa.harvard.edu, sleiker@cfa.harvard.edu,
     rkimberk@cfa.harvard.edu, priddle@cfa.harvard.edu, ydai@cfa.harvard.edu, lkristensen@cfa.harvard.edu,
     stefan.kraus@cfa.harvard.edu, xlu@cfa.harvard.edu, slai@phys.nthu.edu.tw, gfazio@cfa.harvard.edu, amaury@cfa.harvard.edu
Subject: Tomorrow's SMA science meeting, Tues Dec 10th

SMA Science Meeting
Tuesday, December 11, 11 AM
M340, 160 Concord Ave, 3rd Fl conference room

After a fall semester with many interesting science talks, we will
finish up the year with a technical discussion about mosaicing
capabilities for the SMA. This topic is timely since we are still
revising our data format, and still have the opportunity to easily
incorporate new information. Mosaicing will also become more 
important as the SMA changes focus from a general purpose observatory
to more targeted and dedicated science projects, many of which
will involve large-scale mapping.

This will be the last SMA science meeting until after the
AAS meeting. 

Hope to see you tomorrow and Happy Holidays.

Eric Keto
SMA Project Scientist


Some topics suggested by Taco:

1) How do we want to allow the PI to describe his or her mosaic?
Regular rectangular arrays only?   HCP patterns too?   Arbitrary
sets of offsets?   Polynomial boundaries?   Has anyone seen an
observatory which has a particularly clever way of allowing mosaics
to be defined?   How can we implement realtime feedback to the person
preparing the script, so that they'll know how long a mosiac will
take to run given their imput parameters?   Is it important for them
to see what the resulting UV coverage or synthsized beam will be
for their proposed mosaic?

2) Is it insane for us to consider on-the-fly mosaicing?   I think
it is, because of our Walsh fuction sideband separation, but maybe
someone knows how to do it.

3) We have space in the data file for two offset positions,
presumably we can store RA and Dec offsets there.   Do we want to
allow other types of offsets such as Az-El or galactic coordinates?
Perhaps even arbitrary positions angle rastering, for big galaxies
line Andromeda?   If so, we need to define the slots in the
data structure that we'll need to fully specify the coordinate system.

4) The current naming system for mosaics is not good.   We
append the offsets to the source name, so that the +35",-20"
offset positing for SgrB2N is named "SgrB2N_+35_-20" in the data
set.  This is really kludgy.   Do we want all mosaic positions to
have the same name?   If so, we'll need to modify the file
corrPlotter uses, so that we can distinguish between pointings
on corrPlotter.   How will we do that?

5) Are there things we would like to store in the data set, besides
the offsets, which would be useful for mosaics?   Would it be useful
for the realtime system to know how many times each position has
been observed, so that the system could seek to bantain uniform
coverage, even when the script needs to be restarted?

6) Shall we modify the existing script generator to support mosaics too,
of would a separate tool be better?   Are special restart options
needed for mosaicing scripts?