-
Notifications
You must be signed in to change notification settings - Fork 4
/
116.text
114 lines (86 loc) · 4.09 KB
/
116.text
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
From: [email protected] (M Holdaway)
Subject: Where do we go from here
Date: Mon, 16 Mar 92 14:35:38 EST
1) EXTEND THE PROTOTYPE!
Most of our effort in this prototype has been put into
making self-consistent sub-systems. Very little
effort has gone into making sure these subsystems
can interact with one another in a simple and clear
manner. It is my opinion that we need to push this
"exercise" further. While I understand the time
constraints on the report, we are really writing
the report before we have finished the object of
the report. And the last steps of putting it all
together are by no means just "academic"...they
are fundamental, and will tell us what is wrong
with the class design.
2) A BROADER DEEPER 2ND PROTOTYPE!
Our feet are wet. Lets go for a more intense system
that has more than one TelModel and possibly more than
one Imaging Model. Multiple models are needed to test
the "associators" scheme. Also, this enters into the
realm of "detailed instrumental requirements": we could
have one imaging model for the VLA and one for a linear
array like AT or WSRT; we could try to do polarization
calibration for the VLA and WSRT. [I am actually a bit worried
about polarization.]
And finally, I think that we NEED to get some spectral
line stuff into the prototype. One of the biggest fears
in Socorro is that AIPS++ would not be much better than
AIPS at dealing with spectral line data. We NEED to
get spectral line on board as early as possible!
If we break everything down into YEGS, we need to
be damn clever at reconstructing the QUADS and the
SPECTRA.
3) A BROADER SYSTEM REQUIRES OBJECT PERSISTENCE!
We at least need to be able to write out images, visibility
data sets.....so that we don't fall into the ONE MAIN PROGRAM
syndrom. (Bob Sault suggests FITS readers and writers.
This would also enable us to work with some real data
sets. Performance could be tested against SDE
which has a very flexible timer.)
4) GET THE REAL PROGRAMERS ONBOARD!
We should get Mark S and Bob P
involved in THIS prototype...so we can test out their
wares, so we don't have to design vector classes, so
we can tell them what is useful and what is hard to
use. Also, the last two points dealt with
"associators" and object persistence. This would be
a good place to deal with the DATABASE and get Chris
onboard.
5) MORE INTER_GROUP COMMUNICATION!
In the past, systems such as this one were designed
by 1 or 2 people working in close cooperation.
While communication inside each group seems to be
fine, communication among groups is not good.
I think shifting the group lines will only change
the lines accross which communication does not
easily flow. It may help, but wont solve.
It is my feeling that the more complicated and realistic a system we
are dealing with, the more complicated and realistic problems
we will uncover. There will always be hacks and fixes that can
be applied to these problems, but that is EXACTLY what broke
old AIPS. If AIPS++ is to be the best system we can write
at the present time, we need to program the next prototype as
much like a real (but limited in some particular ways) system
as we can.
Here is my suggestion for a timescale:
Spend 2.5 months designing, building, and evaluating
the next prototype. Work on the current prototype
would wind down as work on PROTO++ winds up.
By June 1, we need to have evealuated this prototype
and be in a position to start AIPS++. I imagine
a good deal of code will be reused from PROTO++
to AIPS++ if PROTO++ is designed with polarization and
spectral line in mind. If the code cannot be reused,
then we must consider ourselves lucky for
doing such a broad prototype.
By July 1, we will have the bones of the real system.
We will know how polarization and spectral line
data and images fit together. It is difficult enough
to convince colleagues that there is a problem when
we talk to each other FACE-TO-FACE! If there are
still major design flaws after July 1, we will
have a LOT OF TROUBLE WORKING THEM OUT!
Hence, I support a very ambitious PROTO++.
-Mark Holdaway