[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ALMA Science Software Requirements (SSR) -- Step 1



> I'm surprised that this list has been quiet - perhaps a question will
> change that.
>
> Should the "usual" data product of ALMA  be images or UV data? Based on
> my communications with various people and committees I have always
> assumed the former (where the meaning of "usual" is TBD), however one of
> the recommendations of the NSF cost audit this summer is that this
> assumption should be reconfirmed.

I think that our paradigm, which grew out of Steve Scott's computer
working group back in 1996, makes a nice self-consistent story:

Given the potentially huge amounts of data that ALMA will produce, you'd
very much like images rather than UV data, just from astronomer-sanity
arguments, assuming good images can be produced.  Many observations will
be noise-limited, implying that they are not difficult to image, or
require little in the way of human intervention.  However, some
observations will not fit into these assumptions and will require the
observer to image the calibrated or raw (u,v) data.

To get the most out of ALMA, we will need dynamic scheduling.  I'll
assert: dynamic scheduling results in something like double the
astronomical output of the array at the high frequencies.  (The most
limiting factor for high frequency observations will be phase stability,
even with radiometric correction.  While the phase stability shows strong
diurnal trends, it is not simple to predict, and changes more quickly than
the opacity.  This points to a dynamic scheduling system based on, among
other things, frequent monitoring of the phase stability.)  I currently
have a project on hold which would quantify the improvement made by
dynamic scheduling compared to an LST-only based schedule (ie, like the
current VLA) or a static schedule made with knowledge of the historic
seasonal and diurnal trends (ie, only observe high frequencies at night).

In addition, most astronomical projects will observe somewhere close to
transit over several days to optimize the sensitivity (most projects will
not need much earth rotation to get good (u,v) coverage).  However, with
dynamic scheduling and near-transit observing, each project will be broken
into several small-ish chunks of time.  Few astronomers would voluntarily
stand for calibrating 10 chunks of data for one 20 hour observation.
Therefore, we need an automated calibration system that interfaces well
with the automated scheduling system.

The automated imaging system is a modest extension of the automated
calibration system.

The automated sheduling, calibration, and imaging will transform ALMA from
an interferometer that could only be used by technically-oriented ALMA
experts into an astronomical tool that can be used by generic astronomers.

Larry D'Addario has suggested that if an ALMA design feature only speeds
up the science, rather than provides a fundamentally new scientific
capability, it is not needed.  From that argument, the dynamic
scheduling/automatic imaging is not needed.

However, there is a reason why the collecting area is so large: to speed
up the science.  I am guessing that the dynamic scheduling/automatic
imaging system is a way to make a large improvement in scientific speed,
and a large improvement in the ease of use of the instrument, for a modest
expense.  In the spirit of a cost audit, I would suggest that a hard
cost-benefit approach be used, in addition to the punditry Brian's e-mail
will generate.

        -Mark