From: Douglas Bock
Subject: Re: SKA Simulation Working Group - Aims and Strategies
Date: Fri, 02 May 2003 11:13:20 -0700

Steven,

I broadly agree with your plan, but concur with Jan's concerns
regarding resources.

For example, during the next couple of years ATA people will naturally
be concentrating on the ATA itself. Yet the ATA can offer much as a
large-N
"hardware simulator" on which imaging/beamforming/calibration/RFI
techniques can be tried. Compared to current instruments, most of the
SKA concepts are "large-N". Ideally we would institutionally commit
resources to SKA development specifically.

I suggest that the tasks of the SSWG require people with one or
several of three basic qualities:

a) (proxy?) ability to commit significant resources ($ and other
people's hrs) to the project
b) combination of scientific/technical interest to understand the
problems and a desire to get started
c) ability/willingness to expend substantial effort (say, a
significant fraction of an FTE) personally

People with *all* of these properties will be necessary to achieve our result.

Yet I'll speculate that many currently in the group fall mostly into
category (b). These people will make significant contributions and
have an important coordinating and advisory role. But lots of (c) will
be required to get things actually done. I think we run the risk of
rather low efficiency and total productivity if each person can spend,
say, only an hour or two a week.

It would be very useful if people could come to Geraldton with some
concrete idea as to what resources can already be committed at their
location. A first role of the SSWG will be to let the ISSC know what
more is needed.

To some extent, proponents of the SKA concepts will naturally have the
motivation to support simulations of their concepts. Because resources
are not uniform, the degree of effort will vary. We risk a severe
mismatch in capabilities, and subsequent choices that either are, or
are seen to be, poorly considered. (Naturally this applies to
development of entire concepts, not just their simulation). I can
offer no easy solution to this. But it should help to be aware of the
limitation from the start. One approach would be to collaborate to
build/compile simulation tools that are as general as possible,
minimizing concept-specific implementations.

cheers

Douglas