=========================================================================== v1.11 20 May 2003 =========================================================================== Meeting - Friday 30 May 2003. >>>STM: Mention Software in title of document Frazer Contributed the following notes from Rick Perley: Date: Mon, 04 Mar 2002 16:15:48 -0700 From: Rick Perley To: fowen@zia.aoc.NRAO.EDU Subject: Some Key Imaging Problems Frazer: I spent a few moments thinking about key imaging challenges for the EVLA (both phases). Here are some thoughts: a) Mosaicing, especially using the proposed fast-slew modes. Data will be taken with rates of 10s of milliseconds. The sliding primary beam must be taken out of the image. >>>STM: This implies some sort of data-rate spec which should go into a req in section 1. Ive put these in an expanded 1.1-R2. What should these be? >>>STM: The general mosaicing and beam issues are covered in 5.3-R2.1 b) Bandwidth Synthesis modes. This is not just a Phase II problem -- people in general will be using the full bandwidth for continuum work, so we'll need to deconvolve as a function of frequency. Outputs will be not only intensity and spectral index, but other variables such as polarization, rotation measure, fractional polarization, etc. -- anything which changes with frequency. (Even optical depth?) And the real frequency-dependent effects must be separated from those caused by the changing primary beam (with frequency). >>>STM: Put in a new wide-bandwidth section? -> 5.5 c) Full-beam high-fidelity polarization imaging. The angle and time dependent changes in beam polarization must be removed by software. In many cases, these changes are small, in others, they may not. >>>STM: In 5.2-R3 d) High fidelity Imaging. We are designing the electronics to permit up to 10^7 dynamic range. We must be able to image and deconvolve accurately to this level. We're about a factor of 100 away from this for bright, partially resolved objects. (And I note there has been zero progress in this area in over ten years). >>>STM: This should be a new subsection -> 5.4 e) Wide-angle, full-beam imaging. Primarily a PHase II issue -- huge maps (at least 32 K, probably 64 K pixels on a side), ~ 128 planes deep, databases of utterly enormous size (averaging of about .5 seconds, thousands of spectral channels). Then add polarization, and all the considerations above. Could be challenging ... >>>STM: Again, implied in 5.2-R3 (for Phase I). Add your own, and please comment on what I have here. Rick Date: Fri, 05 Jul 2002 16:07:49 -0600 From: Rick Perley To: mrupen@zia.aoc.NRAO.EDU, fowen@zia.aoc.NRAO.EDU Subject: Tough Experiments Michael, Frazer: I spent a couple days trying to better solidify what's going to be needed to do some of the more ambitious proposed EVLA experiments. Attached are my notes for four 'tough' data-processing challenges that I had time to think about. Let me know if I've missed major points, and do make other suggestions on large-scale projects. Think Big. I need to get something like this to Athol/Tim shortly -- but I'll be away all of next week (holiday in Hawaii, actually). I can peruse this a bit while there (I'll check my e-mail in the evenings), and can make additions/corrections, following your advice. Rick Some High-End EVLA Experiments R. Perley V 1.0 5 July 2002 This file contains notes on 'high-end' experiments for the EVLA. 1) Solar Flares. Tim Bastian wishes to observe solar flares with 10 msec time resolution, and 0.1% frequency resolution. The flare duration is typically a few minutes. Images of the solar flare will be required for each time and frequency slot. As the flare is very bright and of limited extent, it would seem that the image size will be modest (hundreds of pixels on a side?) At L-band, the desired resolution is ~1.5 MHz, leading to ~1024 frequency channels per polarization. With two polarizations, the resulting output data rate is about 600 MB/sec. This is about 1/3 of the correlator's maximum aggregate rate (so the correlator can do this!), but is about 25 times the current planned maximum archiving rate. As flares last only a few minutes, it seems the solution could be to store, say, 10 minutes' data in fast memory -- requiring about 350 GB memory. If an interesting event occurs (as triggered by total power, or external notification), the ten minutes' storage can be written to archive -- which should take about 4 hours at a 25 MB/sec rate. As total powers will be rapidly changing over very large ranges, it will be necessary to apply Tsys corrections on the ~10 msec range, and to understand the effects of system components whose response times are slower than this. 2) 'On-The-Fly' Mosaicing. A potential observing mode will be to do fast 'on-the-fly' mosaicing of (say) star-forming regions at Ka or Q bands. Barry Clark believes that accurate pointing can be maintained at up to 10 X sidereal rates (although Ken Sowinski is more sceptical). The extent of the imaged area could be as large as 30 primary beamwidths on a side -- a few thousand 'pointings'. At a 10 X sidereal rate, and at Q-band, the primary beam will be traversed in 400 msec, requiring ~ 40 msec dumps. Data rates are not extreme, so long as such surveys are conducted in the 'C' or 'D' configurations, for which I estimate the sustained data output rates to be ~ 18 and ~5 MB/sec for 'C' and 'D' configs., presuming full polarization. Both can be handled within the currently planned archiving rates. Suspected complications: a) Pointing variations. Although we are hoping to achieve 3 arcsecond *absolute* pointing accuracy (after having determined the offsets by referenced pointing), it is more likely that we'll only be able to achieve this in 'drive accuracy' -- the locus of the scan center will move smoothly within 3", but the actual position of the scan locus will be offset by perhaps 10 arcseconds -- and be different for each antenna. However, the 'grid' which is built up over, say, a half hour, will all have the same offset (but the offsets will differ amongst antennas). As the primary beam at Q-band is ~ 60 arcsec, these differential offsets will have to be detected and removed, presumably using the stronger, more compact sources within the mosaiced field. b) Primary beam changes. The primary beams between antennas differ, and their shapes vary with elevation. Mosaicing will take place over a range of elevations, so the effect of these (slow) modulations will need to be accounted for. To a good first approximations, these will be known 'a-priori' from observations of strong point sources. Second-order corrections may be necessary for fields with very strong embedded sources -- perhaps the sources themselves can be used interactively. c) Polarization effects. Similar to primary beam changes, but see below for more detail. 3) 'Line-Stacking', using Radio Recombination Lines. Crystal Brogan believes that the magnetic fields in HII regions will be detectable from Zeeman splitting of their radio recombination lines. To get the necessary SNR, all the lines within a band must be added. High frequencies give stronger lines, but are unfavorable as there are fewer lines, and the thermal line broadening is greater (whereas the Zeeman splitting is frequency-independent). Low frequencies have more transitions and narrower lines, but the lines are weaker. Crystal's estimate is that S-band is optimum, and believes that a 300 microG field can be detected at 5-sigma. There are 29 recomb lines in S-band (2 - 4 GHz), with spacing of approximately 70 MHz. Each line is about 250 kHz wide (FWHM) (25 km/sec), and 10 kHz (1 km/sec) resolution is optimum. The WIDAR correlator can 'target' 32 sub-bands (which can cover all 29 transitions, and have 3 others as baselines) in both polarization products, with 4 MHz sub-band width, 256 channels per spectrum, and 1.6 km/sec velocity resolution. The data rate for this mode is modest -- ~5 MB/sec. But there is some doubt in my mind as to whether the correlator can provide a sub-band width of 4 MHz. If this is not possible, an alternate mode, using the 'recirculation', which will cover only 16 transitions, but will provide a total of 4096 channels per transition per polarization, with 0.4 km/sec resolution. The data rate for this mode (at 10 sec. averaging) is rather larger -- 37 MB/sec, somewhat exceeding the maximum sustained archiving rate. This can be avoided with 15 second averaging. Complications include: a) Bandpass stability -- currently the major limiting factor. Detecting the line essentially requires fitting a 'hysteresis-like' frequency profile whose amplitude is about 0.2% of the peak of a guassian profile. Current methodology is to use the 'transfer switch' to route the R and L signal paths alternately through the same backend bandpass filters, and to *not* calibrate the bandpasses, as this is felt to introduce larger errors. The EVLA system should be easily stable to these levels. Polarization switching may still be desirable, although (I hope) not required. Good bandpass calibration will surely be desirable, although perhaps not required. b) Pointing effects. If the pointing and gains are both stable, then differencing the R and L images will directly produce the characteristic hysteresis shape. Changes in pointing or gain will 'unbalance' the subtractions, which will introduce an offset in the difference -- the Stokes' 'I' line shape will be added, with an amplitude proportional to the fractional gain error. As the frequency dependence of this is different than the 'V' shape, they can be separated rather easily. (This is done now). The difference is also spatially variant for pointing errors -- this should be seen in the frequency fits, and should adhere to expected 'V' pattern introduced by the primary beam squint. That is -- the 'I' contamination will vary with spatial position. Perhaps a global spatial-frequency fit will be best. 4) Full-Field Imaging, with accurate polarimetry. Many key experiments request deep full-primary-beam imaging, reaching thermal noise in all Stokes' parameters. There are many challenges: a) Data Rate. The number of frequency channels needed is a function of the bandwidth ratio and the configuration. For L, S, and C bands, and considering only the primary beam itself, the number of channels required for each polarization product, for the A configuration, is 2048. If accurate removal of external (out-of-beam) objects is desired, more channels will be needed. Presuming 8192 channels, (2048 x 4 polarizations) and 3 second averaging for full-beam imaging, a data rate of ~ 80 MB/sec is indicated. This is 3 times above the current archiving maximum. If the full 16384 channels, and (say) 1 second averaging is desired (for more accurate far-source removal), the data rate rises to ~240 MB/sec. This makes for rather large files, after 12 hours' integration. The rates for B configuration, and shorter, will comfortably fit within the current planned maximum archiving rate of 25 MB/sec. The BWR (bandwidth ratios) for other frequency bands are 33% less than for L, S, and C bands, and the data rates are reduced in proportion. b) Dynamic Range. Although the typical strongest object in the primary beam at L-band is < 100 mJy, we must plan for those targeted objects whose peak brightness exceeds 1 Jy/beam. To reach the thermal noise of 1 microJy/beam will require a dynamic range of 10^6. But even this is rather modest -- a more desirable goal is to reach the noise with a 10 Jy/beam object in the field -- a 70 dB dynamic range. There are important secondary effects which must be considered when reaching such levels, including: i) Primary beamshape variations. This would include both the differences between antennas, and changes introduced by elevation changes, temperature changes, and the like. Keep in mind that the width of the primary beam changes by a factor of 2 across the full bandwidth. ii) Primary beam phase. The phase across the antenna beam is not a constant, with the largest effect being a slope caused by an offset in the feed direction. This may be time/elevation variable. Such changes will need to be included in any super-high-dynamic range image algorithms. The beam shape and phase effects may be known a-priori, and can be included as such. Time or elevation dependent changes will have to be monitored using strong objects within the field being imaged. It must be remembered that the primary beam changes by a factor of two over the factor of two in frequency between opposite ends of L, S, and C bands. c) Polarization. The major problem is from the 'D' terms scattering the 'I' polarization into the Q and U images. A rough argument is: The effect of errors in the 'D' terms is add to the Q (or U) image a quasi-random signal of magnitude ~ dD.I, where 'dD' is the error in the 'D' term. The phase of this false visibility have no particular relationship to the total intensity, so the effect from all 351 baselines will average down by a factor ~ 25. AS time rolls on, the false visibilities will rotate at the expected rate, but added to this will be a 'backwards' rotation by the parallactic angle -- I optimistically guesstimate that these rotations will reduce the net effect in the Q image by a further factor of 40. If we require the net effect to be less than the 1 microJy noise level, then dD < 25 x 40 x 1 microJy/I where 'I' is the total Stokes 'I' visibility. If this is 1 Jy, then a the maximum tolerable error in knowledge of 'D' is ~ 0.1%. But my estimates are quite optimistic, and I suspect that a maximum error of 0.01% is more like it. This will require knowledge, in space, frequency, and time, of the antenna polarization, to this accuracy. The software will need to make the spatial-temporal corrections using a priori values determined from strong objects over a range of elevations. If these are not sufficient, a means to self-calibrate the spatial/temporal/frequency variations will have to be developed, presumably making use of the strong objects within the field. A major complication is the non-coplanar baselines. Even at 20cm, hundreds of fields will be required, and differential calibration (i.e., spatially variant phase calibration) will likely be needed for the best fidelity. --------------------------------------------------------------------------- From bclark@aoc.nrao.edu Mon Jun 2 17:19:22 2003 Date: Mon, 2 Jun 2003 17:09:11 -0600 (MDT) From: Barry Clark To: evlassr@bclark.aoc.NRAO.EDU Cc: egreisen@bclark.aoc.NRAO.EDU Subject: [eVLASSR] Data Post-Processing Requirements I missed the meeting last Friday (another meeting ran long), so I'm unsure what the general consensis is, but there were a few specific points I thought I might mention. These below are keyed to the document (rev 1.1) which, of coure has the effect of making them opaque and unreadable. Sorry about that. A general remark. The things that the WIDAR correlator will do that will give the Package fits are 1.) the great mass of line data that will place a premium on efficiency, and 2.) continuum imaging with the very wide percentage bandwidths, which is something that has not really been dealt with before. >>>STM: see above - new section on bandwidth, and new 1.2 with data size and rate specs. Overall, the document seems to me to be reasonable, comprehensible, and complete, to the point of being quite daunting. But onward to the nitpicking. p. 7, point E. How about some abbreviation other than OL, since that stands equally well for Off Line and On Line. >>>STM: This was left over when there was "OL-" prefaced. Removed from E. p. 9, 1.1-R12.2. I don't know what this means. I suspect that it means "The Package shall have runtime options specified in an ASCII .rc file, and shall have defaults for all values that may be specified therein." But some more generic wording might carry that message. >>>STM: agreed, reword p. 11, 2.2-R6. The "where applicable" phrase, which I agree is necessary, seems to deprive this of any meaning. I suggest dropping it. >>>STM: rephrase to cover all data reduction functions (rather than system access or other ops)? p. 11, 2.2-R7. I think this rates below priority 3; that is, drop it. >>>STM: I'm not so sure about this, but if others concur, it can be dropped. p. 12, 2.3-R6. This is, I think, the equivalent of AIPS INP, and is, I think, imperative, priority 1. >>>STM: This is a matter of taste (and of course implementation). Note that both aips++ and difmap use function calls, so this is not available for these packages but they still work. What this implies is that functions for those sort of packages would be bundled into CLI-level "tasks" AIPS-style where you set parameters and run, as a convenience for users (hence P3). Maybe explain better in the req? p. 12, 2.4-R1.7. This is pretty hard, maybe we should say timescale D. >>>STM: agreed p. 12, 2.4-R1.10. Priority 3. (But likely to happen anyway). >>>STM: agreed p. 12, 2.4-R3. Passing stuff between apps is frequently a trouble spot (witness AIPS aparm, bparm etc.). I'm not sure that a generally stated requirement like this is useful. Possibly if we had a try at specifying what gets passed and what doesn't we might be helpful. But I know if I tried to do so I'd just get in trouble. >>>STM: I tried to break into some subreqs and indeed it didnt work very well - anyone got some ideas? Or should we drop it? What I did was make parameter passing (at all) P1, and put P2 and P3 subreqs. Take a look. p. 13,14, 2.6 in general. Doesn't say how help should work if the Package is not connected to the Web. >>>STM: That was the intent of 2.6-R3 on printable formats, but I will add a similar one for offline availability (not necessarily print friendly). p. 15, 3.1-R5. Because what is "raw data format" is not well defined, we should be talking about bytes per visibility instead. Do we want to specify a "compressed" format as well? (Fraser talks about such a thing in his appendix.) >>>STM: The intent here is to put a cap on how big the data gets when read in (and extra tables or columns are added by the package) - I think this spec needs to exist. Bytes per visibility is a possibility, but someone would have to work out what a reasonable "minimum" is (r, i, u, v, w, wt, ...). >>>STM: Compression is dealt with in 3.3-R16,17 - I have moved these to the end of 3.1, but we should not go as far as specifying a form. p. 15, 3.1-R6. Replace "ability" with "option". >>>STM: agreed p. 17, 3.3-R2.3.1, .2. Not clear to be what the difference is between a name and an ID; a few more words required, I think. Also, 3.3-R2.4.1, .2. >>>STM: agreed (IDs are equiv. to source number), combine name and id number p. 17, 3.3-R2 in general. Mildly annoying to have the same stuff called out both here and in section 4.x. Perhaps it would suffice to say here that information needed for operations mentioned in sections 4.4 and 4.5 should be handled as integrated data objects. (There are a few things in 3.3 that do not seem to fit that very well, though.) >>>STM: I agree this is clunky. I am not sure how to do this, suggestions for rewording welcome. I kind of like having this in one spot though. p. 17, 3.3-R2 in general. Do we want to include a mechanism to make relevant maintenance forms available to the Package? >>>STM: sort of like 3.3-R2.19. add after that one p. 19, 3.3-R3.9. I do not know what is meant. Does this just mean selecting data based on a supplied list of antennas? >>>STM: no, I mean choosing which of a set of subarrays (which may or may not go into separate files depending on implementation) p. 19, 3.3-R3.11. I think "baselines" is a typo for "visibilities." >>>STM: not quite (specification is on a baseline basis), but good enough p. 19, 3.3-R5 says all standard time systems should be supported, but doesn't say with what accuracy. For instance, I'd be inclined to say that recognizing the name TDB should have priority 2 alright, but that actually being able to calculate the TDT - TDB correction is priority 3. And recognizing the non-constant terms in ET - TDB is not worth doing at all. >>>STM: as it stands, reqs were meant for reading in and converting to internal time. Put in accuracy qualifier? Should we specify some astrometric accuracy here (10mas? 1mas?) or leave for Rick's top level specs? I'm inclined to have a separate req, applicable to all these, specifying an accuracy. p. 19, 3.3-R7 similarly doesn't talk about accuracy. Note that many B1950 positions quoted by radioastronomers are not really B1950 but have an adjustment made to the zero of right ascention so that the RA of 3C 273 remained constant. So conversion from B1950 to J2000 at accuracy greater than about 20 mas requires a lot of extra information and extra code. >>>STM: same as previous p. 20, 3.3-R6.2. Az/El per se is not well defined. Has to be Az/El at an antenna location or array center location. (Same applies to 3.3-R5.4.). >>>STM: AZ/EL (at antenna or array center) p. 19, 3.3-R7.6 ICRS is not a reference frame, but an implementation of J2000. >>>STM: Indeed, it is an extension of FK5 (R7.1) using the ICRF, but is probably worth separating from J2000.0. see http://www.iers.org/iers/earth/icrs/icrs.html Make a note to this effect. There used to be a req for the ITRS connection but it was removed. p. 20, 3.3-R8.2, .3. I think optical and redshift conventions are the same except for the factor of c. So one requirement: "Optical (redshift)". >>>STM: indeed, this is true, changed >>>STM: ref http://www.atnf.csiro.au/people/mcalabre/WCS/scs_20020530.ps p. 21, 3.3-R9.6. Priority 3. Heliocentric velocities are pretty useless. >>>STM: yes, we had a discussion with Wim Brouw about this but some people have asked for them, and it is a valid (if poorly specified) frame with a FITS keyword. Agreed to make P3. p. 22, 3.3-R11. Just to be explicit, I'd add a requirement that a flag occuring in one channel of a line data set should be extensible to other channels. (Already implied by 3.3-R11.2.) >>>STM: I don't think that goes here, but in sec 4 talking about extending flags (this is 4.2-R6). The intent here is to be able to import flag tables from one set onto another. p. 23, 3.4-R3. Maybe we should be a little more explicit about the history reader, being able to select by task and by type of information. >>>STM: agreed, add subreqs p. 25, 4.2-R2. Organization is a bit lacking; how you want things displayed are called out in parallel with what you want displayed. These need to be separated. Also, one of the things that should be displayable is a histogram. >>>STM: separate into three (plot types, stat plots etc., plot control) >>>STM: re histogram, this is covered in section 7 Visualization - I dont see how you would edit a histogram (except using it to set clipping levels) so except for that case it wouldnt belong here. Put in for setting of clipping levels at P3. p. 25, 4.2-R2.7. I'd add "or spectral range" to the "timescale(range)". >>>STM: added to R2.7 and also R4 p. 27, Italics. I think non-closing bandpasses are much less of an issue for VLA than ALMA, and that sentence could be dropped. They should only show up if the observer made a mistake in his setup (too much spectral averaging, too long integration). >>>STM: noted p. 29, 4.4-R1.1, .2. I think we need these by timescale C. Also 4.4-R2.3. >>>STM: make all of R1 C, make R2.3 P2(C). also separate beam maps (simple P2) from holography (harder, P3). p. 30, 4.5-R4.3. There are really two things here 1.) trying to sort out ionospheric models by phase curvature on long baselines, which I think is probably a little marginal in A configuration, but a useful technique on the NMA. And 2.) estimating TEC by looking at the RM of 3C 286 at L band, which I think is going to be useful anytime, especially for 4.5-R5.2, which I would bump to priority 2. (Without this correction we can't do good RMs in daytime.) >>>STM: split into 2 subreqs (note 4.3 is already P2 in current version) p. 30, 4.5-R6. "derive" -> "estimate" >>>STM: done p. 32, 5.1-R2.12. I think priority 2. I think it will be needed to get deep maps at L band. >>>STM: agreed p. 32, 5.1-R2.13. I can't even guess what a "non-linear mosaic" might be. >>>STM: I'm not sure either, currently a placeholder - removed (unless I figure out something sensible to put there) p. 33, 5.1-R3.9. DFT is only priority 2, I think. >>>STM: agreed p. 33, 5.1-R6. Doesn't seem to include UVLIN and should. >>>STM: agreed, expand the options here - note that many of the same stuff also appears as baseline fitting and subtraction in sec 6 p. 34, 5.1. Do we want to include an image registration tool? >>>STM: I think that goes more in Visualization sec 7 (registering multiple images), otherwise I guess its equivalent to doctoring the direction? p. 34, 5.1-R16. Current on-line system has the near-field sphericity correction, and I've been presuming the new one would also. I do not much see the need for having the correction in both on-line (OL) and off-line (OL) systems. >>>STM: probably true, though would there be need if you wanted to image solar system and background objects in the same field? keep (p3) for now, add note. p. 40, 6.4-R4.1. I don't know what BLC and TRC are. >>>STM: really? point out these refer to corners of a rectangle... p. 41, 6.5-R9.4. Seems odd to have the inverse at a lower priority than the direct function. >>>STM: true, but often use logs for log-log plots etc or conversion to magnitudes (not sure how useful these are on cubes though). Put both at p3. p. 43, 6.5-R17. Do we want a wavelet deconvolution (again pri 3D)? >>>STM: sure, why not p. 46, 7.2-R6.3.4. Priority 3, unless this is meant to be the display for the beam maps taken for holography, in which case mention that. >>>STM: yes, state this as an example p. 52, 9.1-R2.1.5. Short period comets have a problem in that non-gravitational forces make them unpredictable after a few years. We are probably better off without a catalog of them than with a catalog that needs maintenance. >>>STM: probably true, remove for now p. 53, 9.3-R1. Is the WIDAR backend supposed to produce (u,v,w)? >>>STM: I think the backend was meant, try to rephrase. p. 53, 9.3-R1.1. Should this be replaced by a requirement in the display section that all times displayed should be the center of the integration? >>>STM: should probably put something like that in the display section, but keep here also p. 54, 9.5. The requirements here seem to be all about how to handle pulsars with periods much longer than the integration time. Of more interest is handing the pre-binned data from the WIDAR correlator. Would that be adequately covered by adding "Pulsar phase" to the list of dimensions in 6.4-R1? >>>STM: Im getting Walter to work up real pulsar requirements. p. 57, Appendix A. The concept of Mode here is a bit of a mixed bag. Partly it applies to how the data are taken, and partly to how they are analysed. The distinction is important because the latter component can be changed post facto (if somebody gets data from the archive for a purpose not initially conceived, say). FIELD_MODE in particular seems to imply little in the way data are collected. One just might want to change SCAN_MODE post facto, to link two adjacent pointings, for instance. But once you decide to observe in single_pol or dual_pol mode, you've had it. All in all, I'm not sure this collection of modes is useful. The Package implementers may well want to have modes to make it easy to support a class of observations, but I rather hate to see us specify that, as they might want to divide the world of observation parameters in quite a different fashion. >>>STM: True. Might try to differentiate. These were meant to guide the use cases which were to go as appendices also. I'll think about what to do with these. =========================================================================== v1.2.1 03 Jul 2003 =========================================================================== Date: Mon, 07 Jul 2003 11:51:40 -0400 From: Ed Fomalont Subject: Re: [Aips2-naug] Draft of EVLA Post-Processing Requirements ready for comment Hi Steve, I gave the EVLA post-processing software requirements a quick read. Here are some comments as I went through. ---2.2-R3: Twelve hours to 40 hours dedicated use for GUI use is still pretty long. ---2-2-R5: My own preference is to give 2.2-R5 higher priority and less time-scale. ---2.4-R2: I would give these save/get functions higher priority and less time scale. They are very useful. ---3.1-R1.?: Include VLBI formats? ---3.1-R1.3: The binary fits format, which can be broken into smaller parts, should be supported as soon as possible. I have already run into this problem. ---3.1-R2.1: Should have priority 1, timescale A or B. Already a problem. ---3.1-R8: These averaging functions should stand on their own, and not only be associated with writing data in and out. ---3.1-R11: My own feeling is that these should have higher priority, and a shorter time scale. ---3.3-R2.2.2: Add other astrometric information, EOP, nutations, UT0, etc. I believe the EVLA will use the NASA/Goddard CALC for the correlator model. ---3.3-R3.11: What you really want is to have some indication of the raw data with absolutely no corrections applied. Here you are just assuming WVR corrections. In other words, with the visibility data, you must account for all corrections made in the correlator and elsewhere before the data are written. The IM and MC tables are used in AIPS for VLBA to facilitate this. ---3.3-R11: Why does 3.3_r11 have priority 1, but the two subtopics only priority 2. I suggest priority 1 and timescale C for these. ---3.3-R12: Similarly, I don't see why these are delayed so much in the future. We do this alot now. ---3.4-R1-3. Why are these timescale D (2010) If you want people to use this software with the VLA and VLBA, the timeframe should be more immediate. ---4.1-R1.1.3,4. Priority ismuch too low for these items. They may be very useful for ALMA, as well as VLBI. ---4.2: It may be there, but interactive or batch editting of calibration values, and smoothing (maybe 4.3-R5), are necessary. ---4.6: Fundamental to EVLA and ALMA. Unlike many of the other things in this document which are mainly bookkeeping, this will require serious algorithmical work. ---5.1-R2.5, 2.13: Since Sanjay is working on a pixon, multi-scale clean which may be promising, why not make these priorities and time-scales what they really are. ---5.1-R14: This requirement is Difmap which alot of people use and like. Why not up this priority and time-scale. ---5.1-R17: This requirement of monitoring and canceling large jobs is fine. However, it would be nice if the jobs could be terminated gently and perhaps restarted. Why is priority so low. ---5.5: I don't see explicitly in MFS the determination of the image brightness and spectral properties. ---6.3-R1: Parameter error determinations are extremely important. These must be included. ---6.3-R2: Holding parameters constant is VERY IMPORTANT for fitting. This should have priority 1. ---8: Some aspects of simulations are required for benchmarking speed and accuracy. Hence, I would up the priority of at least the basic simulations to priority 1. ---9.4: This section is pretty short. Actually, you should emphasize that VLBA and EVLA reductions are virtually identical, except for the determination of the phase rate with time and frequency. You nicely combined spectral and continuum data, now do it for EVLA (VLA) and VLBI data. ---B. Frazer has a good description of what it talks with the present AIPS system to obtain high quality full-field VLA images at 1.4 GHz. Have the necessary tasks in this write-up been considered in the EVLA requirements. For example, UBAVG is very useful to decrease the data set size. This essentially stores the gridded u-v data in an approriate data file, thereby compressing the data base. ===========================================================================