Collected Comments on Pipeline/Offline Requirements Document V3.x This document is online at http://www.aoc.nrao.edu/~smyers/alma/offline-req/olr-v3.0-comments.txt ------------------------------------------------------------------------------- 24-Jul-2001: V3.0 ------------------------------------------------------------------------------- Date: Tue, 24 Jul 2001 17:27:13 -0600 (MDT) From: Steven T. Myers Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: ALMA Science Software Working Group Subject: [alma-sw-ssr] Post-Berkeley draft of Offline Requirements Based on discussions during the Berkeley meeting, I have generated a new draft (v3.0) of the ALMA Offline Data Processing Requirements document. This includes the removal of the Pipeline section (to be included in the ALMA SW-11 Memo under 3.6), abbreviation of the Simulator requirements (main simulator requirements to go to SW-11 under 3.1-R11 or new section), and incorporation of assigned priorities. It appears we had completed discussion of about 3/4 of the document, and this includes everything with an assigned priority in this draft - the remainder remains as-is for now. I will try to go through the remaining sections in the next week or so. You can find this document at http://www.aoc.nrao.edu/~smyers/alma/offline-req/ as myers-report-3.ps The LaTeX source is myers-report-3.tex The removed Simulator section, with changes made as we discussed in Berkeley, can be found as simulation-24jul01.tex This would be a good start for what to include into the SW-11 doc. Note that the priorities assigned here conform to the SW-11 priorities, not the scheme Ive used in the Offline Reqs. Comments welcome on this draft, though it might be best to focus on the things with priorities and wait until I go through the rest before commenting on those. -Steve ------------------------------------------------------------------------------- Date: Fri, 27 Jul 2001 17:44:21 -0600 (MDT) From: Barry Clark Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: alma-sw-ssr@cv3.cv.nrao.edu Subject: Re: [alma-sw-ssr] Post-Berkeley draft of Offline Requirements I think we need a specific requirement that the Package include an antenna location analysis tool (I would say "baseline determining tool" but "baseline" means many different things) and an antenna pointing model parameter determination tool. ------------------------------------------------------------------------------- Date: Sun, 29 Jul 2001 13:44:46 -0600 (MDT) From: Steven T. Myers Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: alma-sw-ssr@cv3.cv.nrao.edu Subject: Re: [alma-sw-ssr] Post-Berkeley draft of Offline Requirements Do you think this should be more specific than in 2-4.2-R10 and 2-4.3-R5? Or higher priority (these were at 3 because we felt these would mostly be done in the Online or Pipeline software)? For example, I could break all the instances out into sub-requirements as in 2-4.1-R6.x -s ------------------------------------------------------------------------------- Date: Fri, 3 Aug 2001 11:47:29 -0600 (MDT) From: Barry Clark Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: alma-sw-ssr@cv3.cv.nrao.edu Subject: Re: [alma-sw-ssr] Post-Berkeley draft of Offline Requirements There are two distinct things involved. One is the determination of parameters from a single scan of interferometer data. This is what I thought was covered by 2-4.2-R10 and 2-4.3-R5. The other is combining a large set of such things to get a set of parameters for the phase and pointing models, and maybe the focus model. ------------------------------------------------------------------------------- Date: Wed, 08 Aug 2001 21:57:28 +0900 From: K. Tatematsu Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: alma-sw-ssr@cv3.cv.nrao.edu Subject: Re: [alma-sw-ssr] Post-Berkeley draft of Offline Requirements Dear All, At 11:09 01/06/26 -0600, Tim Cornwell wrote: >"7.1-R4 The output of the display should be possible in many different >formats..." > >No, I think you choose one and let other software (e.g. ImageMagick) do any >conversion. That's what we do in AIPS++: we write xpm and recommend that people >use a converter of which there are plenty. In Berkeley, we did not have enough time to discuss the Visualization section. The above requirement is still in new 2-7.1-R4 without priority. I am afraid that "many" means 30 or more. How about just saying... 2-7.1-R4 The output of the display should be possible in at least one popular image format, from which one can convert to various image formats by using a commercial or free graphic converter software. I think this is a minimum requirement, and I like to give a high priority(1). If we keep the original sentence, I suggest a lower priority (3?). How do you think? By the way, I think that FITS (if you mean the Flexible Image Transport System) is the data output rather than the display output, right? Cheers, Ken Tatematsu >>>SMyers: This requirement has been updated to more or less what you suggested in the latest version 3.1 (08Aug01, see below) as OL-7.1-R5.1 for at least one standard format (I chose fits but could be something else) at Pri 1 and R5.2 for other formats at Priority 3. FITS works as an image format (the "I" part originally meant image I believe) and is supported by a number of viewers (e.g. xv).<<< ------------------------------------------------------------------------------- 08-Aug-2001: Offline V3.1 ------------------------------------------------------------------------------- Date: Wed, 8 Aug 2001 17:27:12 -0600 (MDT) From: Steven T. Myers Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: ALMA Science Software Working Group Subject: [alma-sw-ssr] Version 3.1 of Offline Requirements - comments requested! I have completed a full pass through the Offline Requirements document, assigning priorities and beefing up the thin sections that we didnt cover in Berkeley. You can find this version at http://www.aoc.nrao.edu/~smyers/alma/offline-req/myers-report-3.1.ps with the TeX files there as myers-report-3.1.tex also. This is the version you should read and comment on. Pay extra attention to the sections we did not cover in Berkeley: 2.4.3 - 2.4.5, 2.5 - 2.7. Note that its only 1 month to the ASAC meeting in Chile, so if we want to get a draft to them by then we had better get this one turned around in the next few weeks! -Steve ------------------------------------------------------------------------------- Date: Thu, 9 Aug 2001 11:25:01 -0600 (MDT) From: Steven T. Myers Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: ALMA Science Software Working Group Subject: [alma-sw-ssr] Offline Requirements v3.1 in pdf You can get the Offline Data Processing Requirements v3.1 (2001-08-08) in PDF form also at http://www.aoc.nrao.edu/~smyers/alma/offline-req/myers-report-3.1.pdf -Steve ------------------------------------------------------------------------------- From schilke@mpifr-bonn.mpg.de Tue Aug 14 09:13:46 2001 Date: Tue, 14 Aug 2001 09:31:41 +0200 From: Peter Schilke Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: alma-sw-ssr@cv3.cv.nrao.edu Subject: [alma-sw-ssr] graphic formats At present, programs like xv and ImageMagick seem to be able to do fits, but without colors, but that may change. That as an aside. I thought it would be important to have all kind of output formats, in particular one should have postscript or pdf (capable of vector graphics) and a bitmap format, but I'd like to see as many choices as possible. The idea of course would not be to write as many graphic drivers as output formats, but to let an existing program (such as convert) do the conversion - but quietly, and without the user knowing about it, unless he/she chooses to read the manual. I can deal with these things (and most if not all of you can too), and occasionally I have to hop through quite a few programs until I get what I want, but I know very many people who are at sea with all this. We should keep in mind that we have to design the thing not for the black belt user, but for Joe Sixpack, as Jeff would call him. It should always be possible to bypass these things, but the default should be something that works out of the box as much as possible, with reasonable defaults. In the end this is implementors choice, but many good things are out there, so why to try to reuse them? Peter ------------------------------------------------------------------------------- From wright@astron.berkeley.edu Tue Aug 14 11:47:06 2001 Date: Tue, 14 Aug 2001 10:32:00 -0700 (PDT) From: mel wright 456 Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: alma-sw-ssr@cv3.cv.nrao.edu Subject: Re: [alma-sw-ssr] graphic formats Peter, > The idea of course would not be to write as many graphic > drivers as output formats, but to let an existing program (such as > convert) do the conversion - but quietly, and without the user knowing > about it, unless he/she chooses to read the manual. - I agree; the users should not have to "hop through quite a few programs" to convert to their preferred format. Melvyn ------------------------------------------------------------------------------- From lucas@iram.fr Mon Aug 20 08:42:56 2001 Date: Mon, 20 Aug 2001 10:17:07 +0200 From: Robert Lucas Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: alma-sw-ssr@cv3.cv.nrao.edu Subject: Re: [alma-sw-ssr] Offline Requirements v3.1 Hi all: I haven't seen many comments yet on v3.1. I think the following requirements are missing, both for interferometric and single dish data (-> n=4.2 ??). Best regards Robert --------------------- Rn.1 Atmospheric modelling shall be available in the data reduction package. The model shall be able to predict the absorption, emission and pathlength on the line of sight through the atmosphere at all ALMA bands. The prediction will be based on the following data: Rn.1.1 - measured atmospheric parameters at the site: temperature, pressure, humidity Rn.1.2 - measured atmospheric emission in the observed ALMA bands Rn.1.3 - measured FTS data Rn.1.4 - measured atmospheric profiles of temperature and water content if available from atmospheric sounders prio 1 Rn.2 Atmospheric modelling shall be usable to derive by model fitting the system temperatures corrected for atmospheric absorption in all astronomical bands in use, in order to correct the observed amplitudes at various elevations. prio 1 Rn.3 Atmospheric modelling shall be also usable to provide the conversion factors between WVR data and the water contribution to the astronomical phase in the astronomical bands. prio 1 >>>SMyers: Agreed, add as subsection of 4 as new 4.2. Note that since many of these are in the Pipeline requirements, the Offline package inherits these also. Are these all really priority 1? This will mostly be done in the pipeline.<<< ------------------------------------------------------------------------------- From wright@astron.berkeley.edu Mon Aug 20 14:29:34 2001 Date: Mon, 20 Aug 2001 12:12:00 -0700 (PDT) From: mel wright 456 Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: alma-sw-ssr@cv3.cv.nrao.edu Cc: wright@astron.berkeley.edu Subject: Re: [alma-sw-ssr] Offline Requirements v3.1 Hello Steve, Robert, I've worked thro' the requirements a few times. Looks complete, but I'd put more emphasis on efficiency and efficacy. If the package only does priority 1 - it could be very inconvenient and inefficient. e.g. 1. combining multiple data sets. OL-3.1-R14 -R15 OL-5.1-R2 2. bloat OL-3.2-R4 are given low priority. >>>SMyers: Priority 2 is still high priority - I think these are fine.<<< An analysis based on this document, could easily miss some powerful features built into the low level routines of the MIRIAD software which make it efficient and convenient for the astronomer. 1. A powerful data selection mechanism with Boolean combinations ---------------------------------------------------------------- e.g. these times and these antennes, and these times for those antennas. e.g. this uv-range not shaddowed by more than 10% and that uv-range not shaddowed by more than 50% [I want to self-cal on the compact emission, and to mosaic large scale structure.] OL-4.1-R6 also applies to plotting and imaging. >>>SMyers: Added "Boolean" as desirable feature.<<< 2. On-the fly spectral re-binning. --------------------------------- . plot, uv-data for these 10 velocity intervals for this spectral line. (amplitudes and/or phases, with or without the calibration [gain, bandpass, polarization],applied). . derive bandpass for averaged channels. . image this spectral line in these 32 contiguous velocity intervals. 3. Bloat. --------- OL-3.2-R4 is given low priority. . when imaging a spectral line, the spectra can be processed as a vector; much more efficient. (MIRIAD was 13x faster than aips last time I tried) [1 day versus 2 weeks ?]. . only one beam per pointing is needed for most spectral imaging; a huge saving in bloat. Sure, one can argue about precision, but the final mosaiced image may only have 100:1 fidelity, and you can always make one beam per channel if you want. A large spectral line mosaic should be included in the test suite. Melvyn ------------------------------------------------------------------------------- 21-Aug-2001: Pipeline V3.1 now available ------------------------------------------------------------------------------- From bglenden@cv3.cv.nrao.edu Tue Aug 21 17:01:46 2001 Date: Tue, 21 Aug 2001 16:41:30 -0600 From: Brian Glendenning Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: alma-sw-ssr@cv3.cv.nrao.edu Subject: [alma-sw-ssr] Pipeline and offline comments Not many - probably that means that I've read earlier drafts of the documents too recently and am hence "blind" to them. Cheers, Brian -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Pipeline ===== p.0 The Canadian proposal should be read with an eye to missing requirements (which we might or might not agree with, but should be discussed) p.6 2-0.0-R2 I would only require the reduction script for the science operation. I can imagine the calibration pipeline might work in some direct programmatic fashion (i.e., call subroutines!) and only record the results. p.6 s-0.0-R3 should we say that the flagging must be reversible in a post-processing system here? p.7 s3 Shouldn't the third "dashed" point be handled by the science calibration operation (rather than RT) p.7 3-0.0-R1 Should "scan" be observation here? p.11 s5 It should be mentioned (probably as a general requirement) that the output goes in the archive. Similarly for s6. Off-line ===== (Sections 2.4.3 - 2.4.5, 2.5 - 2.7 only) p.20 OL-4.5-R1 I don't understand this? I thought WVR (etc) was already applied (or not) to the data, and hence would be impossible not to use (other than by throwing a top-level switch: use/don't use) the corrected data. >>>SMyers: The WVR and/or FTS will provide monitoring data which can be used, for example to flag bad stretches. This is not meant to replace the online phase correction!<<< p.21 OL-5.1-R4.1 List the weightings? (Natural, Uniform, Briggs I assume). >>>SMyers: done<<< p.23 OL-5.3-R2.2 A standard set of ALMA primary beams must be distributed with the package. >>>SMyers: done<<< p.24 OL-6.1-Rxx A line catalog should be distributed with the package and used "appropriately"? Maybe this is covered by OL-6.2-R8.3 (although the usefulness isn't just tied to data cubes) >>>SMyers: done<<< p.24 OL-6.2-R1 Cube rotations need not be orthogonal to cube faces. >>>SMyers: add<<< p.25 OL-6.2 R3.3 seems more like a priority 3 to me. Maybe because I don't understand what it means. >>>SMyers: e.g. slices or cuts. pretty basic<<< p.25 OL-6.2-R4 It should be possible to calculate moments along any axis. >>>SMyers: add<<< p.25 OL-6.2-R7.1 (I'd say 1D & 2D are priority 1, ND is priority 2). >>>SMyers: I dont think we need to distinguish<<< p.26 OL-6.2-R7.13 I don't understand this. >>>SMyers: define as objects, pass them, do math (eg. add cubes)<<< p.26 OL-6.2-R8.3 I would have thought this to be at least priority 2 (at least for the listed examples). >>>SMyers: agreed<<< p.27 OL-7.2-R1 "immediate" isn't reasonable if there is a lot of data. More objective to say so many pixels or points per second. Similarly for R2 (unzooming might require going back to the data). >>>SMyers: add benchmarks<<< p.30 OL-7.5-R8 by "arbitrary" I assume you mean not aligned with a cube face (which should be priority 1). >>>SMyers: add aligned as pri 1<<< ------------------------------------------------------------------------------- From scott@ovro.caltech.edu Tue Aug 21 22:11:27 2001 Date: Tue, 21 Aug 2001 16:42:03 -0700 From: Steve Scott Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: alma-sw-ssr@cv3.cv.nrao.edu Subject: [alma-sw-ssr] Re: Offline Requirements v3.1 General: In total, a very nice but intimidating list of requirements. Worried about feasibility of realization (but maybe that's not important at this stage). The use of "must, should, and desirable" instead of "shall" depending on priority results in redundant information. There are instances int the document where the priority has changed but the appropriate word has not. Perhaps it would be best to accept the style of the SSR Requirements ("shall", independent of priority) for consistency. >>>SMyers: good idea, will try to do this in later version.<<< p.21 5.1-R1 "data" -> "calibrated data" >>>SMyers: I dont think this matters in this context.<<< "ALMA exported data" Has this been defined? Can we list what it is? "other instruments supporting common export formats" ; this is very general; can we be more specific? Would a multiple detector single dish data set be allowed (SCUBA like)? >>>SMyers: these should be in a list maintained by project<<< p.21 5.1-R5 Really like the 2nd sentence with the emphasis on spectral cube. Maybe it should be elevated to the intro? >>>SMyers: done<<< p.22 5.1-R6 Is this for single dish (not needed for interferometry)? However, both need to blank spectral channels. >>>SMyers: add spectral channel<<< p.22 5.1-R7 This seems like a calibration or realtime requirement. >>>SMyers: probably, I will leave in until I get ok to remove. might be some implications for accuracy<<< p. 24... Section 2.6.2 The temporal (4th!) axis has been omitted. Driven by periodic and time variable phenomena, e.g. solar, planetary, stellar science. Needs include (some of this may belong in Visualization section): Display of cube slices vs time FFT to temporal frequency of a stack of cubes or slices Periodic averaging or display of cubes Cube movie >>>SMyers: already at some level in vis. Add explicit here. pri 2 ok?<<< p.25 6.2-R7.1 And resampling at lower resolution after the smoothing? >>>SMyers: add<<< p 26 6.2-R8.2 "display for should" -> "display should" >>>SMyers: done<<< p.27 7.1-R7 "edition" -> "editting" >>>SMyers: done<<< ------------------------------------------------------------------------------- From wright@astron.berkeley.edu Tue Aug 21 22:13:01 2001 Date: Tue, 21 Aug 2001 17:58:42 -0700 (PDT) From: mel wright 456 Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: alma-sw-ssr@cv3.cv.nrao.edu Subject: Re: [alma-sw-ssr] Offline Requirements v3.1 Robert, or others, 1> Phone number +1-434-972-7268 (NRAO/CV conference hub, Room 209) Is there a toll free equivalent number ? 2. A lot of people using IDL or matlab in preference to custom-built software. Should we re-visit OL-1.2-R6 ? Melvyn ------------------------------------------------------------------------------- From scott@ovro.caltech.edu Tue Aug 21 22:13:11 2001 Date: Tue, 21 Aug 2001 18:54:11 -0700 From: Steve Scott Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: alma-sw-ssr@cv3.cv.nrao.edu Subject: Re: [alma-sw-ssr] Offline Requirements v3.1 Excellent point. The requirement doesn't seem to reflect the Berkeley discussion as I recall it. IMHO, commercial software should be an option (even if it costs more than "nominal") unless, of course, the ASAC mandates otherwise. It seems like there are quite a few options available for smaller institutions, including reducing data remotely at one of the regional data centers. Steve mel wright 456 wrote: > > 2. A lot of people using IDL or matlab in preference > to custom-built software. Should we re-visit OL-1.2-R6 ? > > Melvyn ------------------------------------------------------------------------------- From twillis@drao.nrc.ca Tue Aug 21 22:13:17 2001 Date: Tue, 21 Aug 2001 19:23:23 -0700 (PDT) From: Tony Willis Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: alma-sw-ssr@cv3.cv.nrao.edu Subject: [alma-sw-ssr] RE: Offline Requirements Most of those 'must be able to arbitrarily undo' any operation requirements seem to have thankfully disappeared from the Offline Requirements document; however the Pipeline Requirements still contains such a requirement (2-0.0-R5). Tony ------------------------------------------------------------------------------- From smyers@cv3.cv.nrao.edu Tue Aug 21 22:13:28 2001 Date: Tue, 21 Aug 2001 22:11:13 -0600 (MDT) From: Steven T. Myers Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: alma-sw-ssr@cv3.cv.nrao.edu Subject: Re: [alma-sw-ssr] Offline Requirements v3.1 The current req text reflects what I thought we had decided (though the parenthetical Comment may not) - it is allowed, for nominal cost. I would say an IDL liscense as it stands is more than "nominal". My experience (with MATLAB and IDL) is that you take a tremendous performance hit using these packages, one I doubt we can afford given the processing requirements. However, if it meets the benchmark specs (tbd) and the rest then it would pass of course. We may wish to dodge the question entirely by deleting this requirement (OL-1.2-R6), though personally I think it is fine as-is. >>>SMyers: I rephrased comment but left req as-is.<<< ------------------------------------------------------------------------------- From k.tatematsu@nao.ac.jp Wed Aug 22 07:54:35 2001 Date: Wed, 22 Aug 2001 18:15:31 +0900 From: K. Tatematsu Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: alma-sw-ssr@cv3.cv.nrao.edu Subject: Re: [alma-sw-ssr] Post-Berkeley draft of Offline Requirements At 11:08 01/08/13 -0600, Steven T. Myers wrote: >This requirement has been updated to more or less what you suggested in >the latest version 3.1 (08Aug01) as OL-7.1-R5.1 for at least one standard >format (I chose fits but could be something else) at Pri 1 and R5.2 for >other formats at Priority 3. # My bounced mail was sent just before version 3.1. Sorry about that. >FITS works as an image format (the "I" part originally meant image I >believe) and is supported by a number of viewers (e.g. xv). Dear Steve, and all, A late comment. Isn't it good to produce one (or a few) in very popular format(s), for which almost the all converter can read? Then we can convert in a black-box way or manually to various formats at once. If it is not popular enough, we will need two or more converters to reach the destination format. I am not sure whether FITS is one of the bests for this purpose (priority-1 to hardcopy the display), although it is very useful to contain astronomical (n-dimensional or more) data. Off course, we definitely need FITS. We may need to change the contour level or coloring later. But, it is not just to hardcopy the display. ------------------------------------------------------------------------------- From k.tatematsu@nao.ac.jp Wed Aug 22 07:54:45 2001 Date: Wed, 22 Aug 2001 18:18:37 +0900 From: K. Tatematsu Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: alma-sw-ssr@cv3.cv.nrao.edu, alma-sw-ssr@cv3.cv.nrao.edu Subject: [alma-sw-ssr] Pipeline Dear all, I felt that 2-0.0-R6 in pipeline "A manual, interactive mode of operations shall be available ..." may fit more to the offline. How do you think? Cheers, Ken Tatematsu ------------------------------------------------------------------------------- From lucas@iram.fr Wed Aug 22 07:55:05 2001 Date: Wed, 22 Aug 2001 12:28:32 +0200 From: Robert Lucas Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: alma-sw-ssr@cv3.cv.nrao.edu Subject: Re: [alma-sw-ssr] pipeline requirements Some additional comments, on the pipeline draft. I'm orry, this comes too late for our US colleagues to read befor the meeting. Robert --------------------------------------------------------------- Note: ----- requirement numbers will change when introduced in general document (all pipeline reqs prefixed with 6.) p5. General Requirements : generally operation -> operations. at many places 'Calibration Operation" -> "Pipeline" p5. R T C Op : add WVR p6: The first two are RTCal Operations as ... p6. 2-0.0-R7 runnable p7 3-1.0-R3 scan -> observation p 9 4-0.0-R3.2 (natural weighting) p 9 4-0.0-R3.5 from theory and actual system temperatures p 9 4-0.0-R4.3 window automatically determined ? p 9 4-0.0-R4.4 spectra on a rectangular grid (why pseudo?) p 9 4-0.0-R6.3 baseline summation with and without shifting phases to specified position ? p 9 4-0.0-R6.4 add: intensity (amp & Pha) as a function of frequency and time (for a baseline) (useful to find out a strong delay error) p 12 6-0.0-R1: after a breakpoint, or end of any `observing object' e.g. when all data for a given map has been obtained, but not necessary at end of each session. Valid also for Science imaging. ------------------------------------------------------------------------------- From k.tatematsu@nao.ac.jp Wed Aug 22 07:57:07 2001 Date: Wed, 22 Aug 2001 21:33:29 +0900 From: K. Tatematsu Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: alma-sw-ssr@cv3.cv.nrao.edu Subject: [alma-sw-ssr] Re: Pipeline, sorry one more Sorry, one more comment. p.5 on Quick Look Operation, Occurence: when requested,... I feel that at least at OSF the quick look should be automatically shown so that "Astronomer on Duty" can check them without invoking, if service observing is common. Ken Tatematsu ------------------------------------------------------------------------------- From bbutler@cv3.cv.nrao.edu Wed Aug 22 08:57:32 2001 Date: Wed, 22 Aug 2001 08:08:44 -0600 From: Bryan Butler Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: alma-sw-ssr@cv3.cv.nrao.edu Cc: alma-sw-ssr@cv3.cv.nrao.edu Subject: Re: [alma-sw-ssr] Offline Requirements v3.1 On 2001.08.21 22:11 Steven T. Myers wrote: > > The current req text reflects what I thought we had decided (though the > parenthetical Comment may not) - it is allowed, for nominal cost. I would > say an IDL liscense as it stands is more than "nominal". My experience > (with MATLAB and IDL) is that you take a tremendous performance hit > using these packages, one I doubt we can afford given the processing > requirements. i can confirm this. i did detailed tests of this a few years ago when simulating holography errors - i.e., lots of FFT/DFTs. the difference between optimized FORTRAN and IDL implementations was about a factor of 20 in speed. you can see more details at: http://www.aoc.nrao.edu/~bbutler/work/nraomemos/holo_sim.ps.gz if you want (see table 1). while packages like IDL and matlab are very nice when visualizing things, and for smaller problems, they just cannot deliver the speed we will need (in my experience/opinion) for ALMA data processing. ------------------------------------------------------------------------------- From mholdawa@cv3.cv.nrao.edu Wed Aug 22 11:39:24 2001 Date: Wed, 22 Aug 2001 09:08:36 -0700 (MST) From: Mark Holdaway Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: alma-sw-ssr@cv3.cv.nrao.edu Subject: Re: [alma-sw-ssr] Offline Requirements v3.1 > > > > The current req text reflects what I thought we had decided (though the > > parenthetical Comment may not) - it is allowed, for nominal cost. I would > > say an IDL liscense as it stands is more than "nominal". My experience > > (with MATLAB and IDL) is that you take a tremendous performance hit > > using these packages, one I doubt we can afford given the processing > > requirements. > > i can confirm this. i did detailed tests of this a few years ago when > simulating holography errors - i.e., lots of FFT/DFTs. the difference > between optimized FORTRAN and IDL implementations was about a factor of > 20 in speed. you can see more details at: > http://www.aoc.nrao.edu/~bbutler/work/nraomemos/holo_sim.ps.gz > if you want (see table 1). > > while packages like IDL and matlab are very nice when visualizing things, > and for smaller problems, they just cannot deliver the speed we will need > (in my experience/opinion) for ALMA data processing. > I see some important uses of an IDL-like package: * prototyping imaging or calibration algorithms -- trying things out before you hard code them * display - visualization - problem-solving: if you don't know what is wrong with your data, IDL or something similar may be useful in exploring and understanding the data * post imaging analysis: the imaging will be the big time consuming step. After you make the image, you want to be able to perform some sort of quantitative analysis on the image -- and this analysis may be non-standard and experimental. AIPS++'s glish seeks to do these jobs already, and will probably succeed to a large degree. Glish is powerful in that it will already be well-integrated with the data and other aspects of the data processing (ie, efficiently coded tasks written with C++ and Fortran code), but is not nearly as familiar to so many people nor as polished as something like IDL. So, I think much of the functionality you would get from IDL is there in glish, so it comes down to a political choice: make people learn a new package, or give them what some of them know already? -Mark ------------------------------------------------------------------------------- From bclark@aoc.nrao.edu Wed Aug 22 11:39:30 2001 Date: Wed, 22 Aug 2001 10:19:40 -0600 (MDT) From: Barry Clark Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: alma-sw-ssr@cv3.cv.nrao.edu Subject: Re: [alma-sw-ssr] pipeline requirements Last minute thoughts. OL 2.2. I occasionally use a GUI that displays the equivalent command that one would type to the CLI, which I find a handy feature. I don't think we should require this, but we might suggest it. >>>SMyers: suggested wording?<<< OL 4.2-R7. If the package supports full matrix polarization calibration, why should it also be required to support the linearized version? >>>SMyers: this may be moot in 2007 but it is still useful to be able to reproduce standard recipes. I guess there have been enough comments that I will remove this :-(<<< ------------------------------------------------------------------------------- From scott@ovro.caltech.edu Wed Aug 22 11:39:34 2001 Date: Wed, 22 Aug 2001 10:02:21 -0700 From: Steve Scott Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: alma-sw-ssr@cv3.cv.nrao.edu Subject: Re: [alma-sw-ssr] Offline Requirements v3.1 I would like to explain why I'm quibbling over the "nominal cost" wording in the offline requirements doc. It is not unusual for the cost of commercial software to individual institutions to dominate the choice of buy or build (for whatever reasons). These total costs may be completely out of proportion to the cost of building software - say saving 20 institutions a $3k license each verses building $10M of software. The evaluation of an implementation should look at "total cost", as well performance, convenience, operations, maintainability, etc. Given the comments of Steve Myers and Bryan Butler, a commercial option may not be adequate, but the evaluation should not be biased by giving undue weight to the license costs for individual institutions. There are administrative and operational alternatives available to deal with this issue. While there is nothing that meets the requirements better than writing your own software, there is also nothing that is more expensive. Cheers, Steve (Scott) ------------------------------------------------------------------------------- From bglenden@cv3.cv.nrao.edu Wed Aug 22 11:39:37 2001 Date: Wed, 22 Aug 2001 11:06:34 -0600 From: Brian Glendenning Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: alma-sw-ssr@cv3.cv.nrao.edu Subject: Re: [alma-sw-ssr] Offline Requirements v3.1 I personally think "nominal cost to the user" is a reasonable user requirement. However this could be accomplished by having ALMA buy the licenses on behalf of the user, saving the development effort. My $0.02 (is that a nominal cost?!) Cheers, Brian ------------------------------------------------------------------------------- From wright@astron.berkeley.edu Wed Aug 22 11:39:41 2001 Date: Wed, 22 Aug 2001 10:27:21 -0700 (PDT) From: mel wright 456 Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: alma-sw-ssr@cv3.cv.nrao.edu Subject: Re: [alma-sw-ssr] Offline Requirements v3.1 Mark's and Steve's comments express well what I've been hearing from an increasing number of people, who will take their data off into a familiar and versatile environment to analyse it, whether of not ALMA spends $10M writing code. ALMA should look at the total cost here. I'm not an IDL or MATLAB person myself, so I have no bias there. The performance issue could be addressed by providing efficiently coded algorithms like the various flavors of deconvolution and mosaicing, which could be used in the user's favored package. Melvyn ------------------------------------------------------------------------------- From bbutler@cv3.cv.nrao.edu Wed Aug 22 14:14:18 2001 Date: Wed, 22 Aug 2001 11:58:10 -0600 From: Bryan Butler Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: alma-sw-ssr@cv3.cv.nrao.edu Subject: Re: [alma-sw-ssr] Offline Requirements v3.1 it's fine to do image (or spectral cube) analysis in whatever package the user wishes to - *after* that image or spectral cube has been created. IDL and matlab are very good at this. i would not propose that this should not be recommended/supported. but nothing really needs to be 'spec'ed in this respect does it? all you have to be able to do is write out a FITS file of your image/spectral cube. whether you want to say that the off-line processing produced specifically for ALMA should *not* have to do any type of image/spectral cube analysis (i.e., it is assumed that it will *always* be done in other software packages) is a different question... IDL and matlab (and cohorts) are *not* very good at the creation of these images/spectral cubes (i.e., they are not good for "various flavors of deconvolution and mosaicing"). the problem is not that it cannot be done (see, e.g., the LUCY procedure in IDL, and there are various implementations in matlab as well - but note that they all work with the dirty image and beam, not straight from the visibilities [a'la the cotton-schwab CLEAN]) - the problem is that to "provide efficiently coded algorithms", you have to actually do alot of work (if it is even possible). you can, in principle, provide your own extensions/procs to IDL or matlab which are C (or C++, probably) code - but they are not easy. in general, the add-ons to these packages (which is what you are proposing, essentially) are just bundled up calls to the package functions themselves, in which case you are still stuck with the speed issue. if you want to code your own very efficient routine to do the entire deconvolution process that hooks into IDL or matlab, i would guess that this is a really major software undertaking (more so than making sure it works properly in AIPS++, e.g.). -bryan ------------------------------------------------------------------------------- From twillis@drao.nrc.ca Wed Aug 22 14:14:23 2001 Date: Wed, 22 Aug 2001 11:18:28 -0700 (PDT) From: Tony Willis Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: alma-sw-ssr@cv3.cv.nrao.edu Subject: Re: [alma-sw-ssr] Offline Requirements v3.1 (fwd) I agree completely. 1) The aips++ consortium has invested something like 150 person-years developing the aips++ class library for the processing of radio astronomy data from visibilities to images. Even if extensive tuning and modification of this library is necessary to meet ALMA requirements, the time spent will be far less than would be required to do the equivalent in some 3rd party package. However, once images exist, then indeed one should be able to transport them into other packages for further viewing / analysis. Already the offline document has this requirement in a rather fuzzy form - OL-7.1-R5.2. If it becomes apparent over then next few years than some particular commercial package with its own data format is particularly suited for the analysis of astronomical images, then we could consider outputting data in that format as an additional option. >>>SMyers: should it be there in less fuzzy form?<<< Tony ------------------------------------------------------------------------------- From wright@astron.berkeley.edu Wed Aug 22 14:14:30 2001 Date: Wed, 22 Aug 2001 11:40:08 -0700 (PDT) From: mel wright 456 Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: alma-sw-ssr@cv3.cv.nrao.edu, alma-sw-ssr@cv3.cv.nrao.edu Subject: Re: [alma-sw-ssr] Offline Requirements v3.1 Hello Bryan, I guess I'm questioning whether ALMA should spend a lot of money re-creating the things for which there are apparently well liked and supported alternatives. For the professional radio astronomer it would be nice to stay within a custom environment, but for the optical/IR/etc user it would be nice to use the package which they are familiar with, and probably to analyse ALMA images together with images from other instruments. I understand that "IDL and matlab (and cohorts) are *not* very good at the creation of these images/spectral cubes (i.e., they are not good for "various flavors of deconvolution and mosaicing")." What I am suggesting is that the efficiently coded, radio-astronomy specific algorithms could be provided with clean interfaces for use (perhaps as externally called routines) from other packages which the user might prefer to use. As Mark notes, using aips++ these algorithms are "well-integrated with the data", but the IR astronomer may wish to work in a more familiar environment, better suited to data from some other instrument. The scientific potential of ALMA will be best realised by making it easy for a wide community of users to analyse the data in a wide range of packages, rather that by forcing them to use a specific custom built environment. A corrolary is the algorithms developed by the radio astronomy community may have application in other fields if they are available in other packages. just a though, Melvyn ------------------------------------------------------------------------------- From tcornwel@cv3.cv.nrao.edu Wed Aug 22 14:14:40 2001 Date: Wed, 22 Aug 2001 13:48:29 -0600 From: Tim Cornwell Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: alma-sw-ssr@cv3.cv.nrao.edu Subject: RE: [alma-sw-ssr] Offline Requirements v3.1 Interoperability between packages has been talked about at ADASS for a number of years (>5) with no substantial advances for the major packages. It's a hard problem, made more so by data formats (it's easy to agree cross package on images but not on visibility datasets) and technology (e.g. many people argue that CORBA is too heavy weight for what we need to do). I'd recommend adding interoperability as a desired but not essential feature, but I bet that the costs will rule it out. >>>SMyers: is there a suggested text for a requirement?<<< Exporting data to another package is much simpler but is covered already by the requirement to write FITS. Tim > What I am suggesting is that the efficiently coded, radio-astronomy > specific algorithms could be provided with clean interfaces for > use (perhaps as externally called routines) from other packages > which the user might prefer to use. As Mark notes, using aips++ > these algorithms are "well-integrated with the data", but the > IR astronomer may wish to work in a more familiar environment, > better suited to data from some other instrument. ------------------------------------------------------------------------------- From wright@astron.berkeley.edu Wed Aug 22 15:10:44 2001 Date: Wed, 22 Aug 2001 14:05:12 -0700 (PDT) From: mel wright 456 Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: alma-sw-ssr@cv3.cv.nrao.edu Subject: RE: [alma-sw-ssr] Offline Requirements v3.1 Tim, I'm not sure what 'Interoperability' means so let me give an example: Most image analysis packages have a module which can be executed: CONVOLVE(image, beam, method, output_image) Radio astronomers have developed algorithms we could supply: DECONVOLVE(image, beam, method, output_image) where method= clean[Hogbom,Clark,SDI,mfsclean,MRclean,maxen,maxempty,etc] If these algorithms are written in an modular fashion, it should not require much extra work to write the code so that it can be incorporated into and invoked from other packages. I think it is appropriate to state this as a high priority requirement. The users have probably already imported the image and beam into their favorite package via FITS. ALMA could provide them with efficient code to do the appropriate deconvolution. I agree uv-data is a much harder problem. I see ALMA as an imaging machine, and most users will not deal with uv-data. Melvyn ------------------------------------------------------------------------------- From tcornwel@cv3.cv.nrao.edu Wed Aug 22 15:18:16 2001 Date: Wed, 22 Aug 2001 15:15:05 -0600 From: Tim Cornwell Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: alma-sw-ssr@cv3.cv.nrao.edu Subject: RE: [alma-sw-ssr] Offline Requirements v3.1 Ah yes, BUT many (most) of the imaging and calibration algorithms will require the uv-data. Even the Sault image-plane based mosaicing algorithm requires a fair amount of extra contextual information to be passed on with the images. Shoe-horning such information into another package is hard work. If the deconvolution algorithm is "independent" of knowledge of radio astronomy then another package probably already has it. If not, then exporting the relevant contextual information (e.g. pointing centers for mosaics) is a lot of work for relatively little gain. Taking a slightly different tack, I thought that the ALMA model was that all data are pipeline reduced. Accessing the images can presumably be done from any package so the canonical IR astronomer in your example wouldn't be that interested in e.g. performing a mosaic deconvolution from inside IRAF or whatever. Tim ------------------------------------------------------------------------------- From morita@nro.nao.ac.jp Thu Aug 23 08:10:37 2001 Date: Thu, 23 Aug 2001 15:34:59 +0900 From: Morita Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: alma-sw-ssr@cv3.cv.nrao.edu Subject: Re: [alma-sw-ssr] Offline Requirements v3.1 Dear Mel, I am using IDL for analysis of imaging results and I like it very much. Such package is very convenient for not only image analysis but also prototyping or test of new imaging algorithms. At Nobeyama we are using IDL for single dish continuum data reduction. The manpower cost for the developments was very cheap. Several outside people installed this system in their own computer system. Most of the case, they already had IDL licences. NRO does not prepare any money for such export of the system. The software company often upgrade the package version and we need to pay some money for each version up. So, the total cost is big and our institute cannot give these expenses to every end users. Fortunately, almost no people have blame us, because imaging process of single dish continuum is simple and people only need this system just after their observations. > Most image analysis packages have a module which can be executed: > CONVOLVE(image, beam, method, output_image) > > Radio astronomers have developed algorithms we could supply: > DECONVOLVE(image, beam, method, output_image) > > where method= clean[Hogbom,Clark,SDI,mfsclean,MRclean,maxen,maxempty,etc] > > If these algorithms are written in an modular fashion, it should > not require much extra work to write the code so that > it can be incorporated into and invoked from other packages. > I think it is appropriate to state this as a high priority requirement. I like this concept. But, even for IDL, it is not simple to make such external modules written with standard languages(Fortran, C, C++). Memory interface between package and external modules is problem and I think it depends on commercial packages. Maybe, we need to develop individual libraries for every packages. Regards, Koh-Ichiro ------------------------------------------------------------------------------- From wright@astron.berkeley.edu Thu Aug 23 17:03:59 2001 Date: Thu, 23 Aug 2001 11:03:56 -0700 (PDT) From: mel wright 456 Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: alma-sw-ssr@cv3.cv.nrao.edu Subject: RE: [alma-sw-ssr] Offline and Pipeline Requirements The ALMA model is that that all data are pipeline reduced, including, probably, a deconvolution of the synthesised images. The best calibration and imaging procedure are more easily defined by the observing procedure and quality of the data obtained, and can be optimised in the pipeline processing. The most appropriate deconvolution is not so clearly defined, and may need to be done in alternate ways offline. In some cases, experts may wish to go back and re-process the uv-data, but I think that most users will not, and that ALMA will best serve the community by producing images. The calibration and imaging, of course require the uv-data, but almost all deconvolution algorithms do not. I think that the offline package(s) will mostly be used for analysis and display of sky images from ALMA and other telescopes. Analysis of the images requires the user to try deconvolutions with various methods and parameters to match the structure in the source, compare with other images, and extract the most information from the images. The deconvolution algorithms developed for aperture synthesis are more generally useful. e.g. Multi-resolution clean can be used to deconvolve other images with a point-spread function which has an error beam. It is in the best interests of ALMA, and science in general, to make these deconvolution algorithms widely available. It is a reasonable requirement that the offline software be re-useable, so that it may be incorporated more easily into other packages with which the users may be more familiar. >>>SMyers: I think this is beyond the scope of what need be required of the Package. Perhaps a suggestion, but need text.<<< The design should be to avoid making: > > Shoe-horning such information into another package is hard work." Melvyn. ------------------------------------------------------------------------------- From tcornwel@cv3.cv.nrao.edu Thu Aug 23 17:04:26 2001 Date: Thu, 23 Aug 2001 13:33:06 -0600 From: Tim Cornwell Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: alma-sw-ssr@cv3.cv.nrao.edu Subject: RE: [alma-sw-ssr] Offline and Pipeline Requirements > > The calibration and imaging, of course require the uv-data, > but almost all deconvolution algorithms do not. FYI, this used to be true before the advent of mosaicing but now many of the highest quality deconvolution algorithms require going back to the original data in a minor cycle/major cycle mode. In any event, I've sufficiently abused my lurker status that I'll shut up now. Regards, Tim ------------------------------------------------------------------------------- From wright@astron.berkeley.edu Thu Aug 23 17:05:10 2001 Date: Thu, 23 Aug 2001 14:10:46 -0700 (PDT) From: mel wright 456 Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: alma-sw-ssr@cv3.cv.nrao.edu Subject: RE: [alma-sw-ssr] Offline and Pipeline Requirements Tim, It's good to have your participation, and know what to expect. If there is a significant increase in image fidelity by going back to the uv-data in the deconvolution of mosaiced images, then this has a very significant effect on the operational model for ALMA image analysis. It remains to be demonstrated that there is a meaningful increase in image fidelity with telescopes with real pointing and other errors, and what the cost in performance is. These tests should be done as soon as possible, and I would be happy to provide some data. The attached MIRIAD script, takes about 5 min to make images, 10 min for SDI and 20 min for Maxen on a sun ultra 10 (93000 uv-points and 19 pointings and 64 channels). The numbers can be scaled appropriately for ALMA. cheers, Melvyn #!/bin/csh # multichannel mosaic imaging using MIRIAD rm -r hcn.mp hcn.bm invert vis=@hcn.data map=hcn.mp beam=hcn.bm line=channel,64,1,1,1 options=mosaic,double,systemp imsize=194 cell=1.4 robust=0.5 # SDI deconvolution rm -r hcn.sdi hcn.sdicm mossdi map=hcn.mp beam=hcn.bm out=hcn.sdi niters=100 'region=image(2,64)' restor map=hcn.mp beam=hcn.bm model=hcn.sdi out=hcn.sdicm # Maximum entropy deconvolution rm -r hcn.mem hcn.memcm mosmem map=hcn.mp beam=hcn.bm out=hcn.mem niters=50 'region=image(2,64)' restor map=hcn.mp beam=hcn.bm model=hcn.mem out=hcn.memcm end: ------------------------------------------------------------------------------- From wright@astron.berkeley.edu Thu Aug 23 17:05:35 2001 Date: Thu, 23 Aug 2001 14:44:27 -0700 (PDT) From: mel wright 456 Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: bbutler@cv3.cv.nrao.edu Cc: alma-sw-ssr@cv3.cv.nrao.edu, tcornwel@cv3.cv.nrao.edu Subject: RE: [alma-sw-ssr] Offline and Pipeline Requirements Hello Bryan, I intended that the test be done in aips++ by someone who knows how. I'm sorry if this was not clear. If the uv-data is essential in image analysis, this probably precludes any commercial package. cheers, Melvyn >If there is a significant increase in image fidelity by >going back to the uv-data in the deconvolution of mosaiced >images, then this has a very significant effect on the operational >model for ALMA image analysis. >It remains to be demonstrated that there is a meaningful >increase in image fidelity with telescopes with real pointing >and other errors, and what the cost in performance is. >These tests should be done as soon as possible, and I would be happy >to provide some data. > ------------------------------------------------------------------------------- From mholdawa@cv3.cv.nrao.edu Thu Aug 23 17:05:41 2001 Date: Thu, 23 Aug 2001 14:54:18 -0700 (MST) From: Mark Holdaway Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: alma-sw-ssr@cv3.cv.nrao.edu Subject: RE: [alma-sw-ssr] Offline and Pipeline Requirements Mel, I think the whole point is that we can't allow our experience with a 9 element interferometer with maximum dynamic range of 200:1 to limit our understand of what is required of the data reduction on a 64 element interferometer which will potentially have a dynamic range of many thousands to one. If there is any hope of correcting for pointing errors, it is through algorithms which combine pointing self-calibration with the deconvolution, ie, knowledge of the visibility data is directly tied together with the process of imaging and deconvolution. This is the strength of AIPS++, and it will be somewhat difficult for less developed radio-synthesis software to deal with such problems and impossible for software such as IDL to deal with them. -Mark ------------------------------------------------------------------------------- From scott@ovro.caltech.edu Thu Aug 23 17:05:47 2001 Date: Thu, 23 Aug 2001 15:15:40 -0700 From: Steve Scott Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: alma-sw-ssr@cv3.cv.nrao.edu Subject: Re: [alma-sw-ssr] Offline and Pipeline Requirements Hi Mark, I would think that if you can measure the pointing errors then you should correct the pointing in realtime and then not have to deal with them in the imaging. From the science requirements you can infer how often the pointing needs to be refined. Steve ------------------------------------------------------------------------------- From wright@astron.berkeley.edu Thu Aug 23 17:05:57 2001 Date: Thu, 23 Aug 2001 15:16:08 -0700 (PDT) From: mel wright 456 Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: alma-sw-ssr@cv3.cv.nrao.edu Subject: RE: [alma-sw-ssr] Offline and Pipeline Requirements Hello Mark, I think it is good to clearly say this. However, the image fidelity of ALMA in the submillimeter will probably be comparable to BIMA at 3mm. I would still like to see a comparison with running the test in aips++ and any other packages capable of handling the mosaiced data. cheers, Melvyn ------------------------------------------------------------------------------- From tcornwel@cv3.cv.nrao.edu Thu Aug 23 17:06:04 2001 Date: Thu, 23 Aug 2001 16:42:17 -0600 From: Tim Cornwell Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: alma-sw-ssr@cv3.cv.nrao.edu Subject: RE: [alma-sw-ssr] Offline and Pipeline Requirements > I would still like to see a comparison with running > the test in aips++ and any other packages capable > of handling the mosaiced data. Mel, Isn't the ALMA calibration and imaging group working on questions like this one? Your question has many aspects, and finding an answer will be lengthy. Cheers, Tim ------------------------------------------------------------------------------- From Wim.Brouw@atnf.csiro.au Thu Aug 23 17:06:08 2001 Date: Fri, 24 Aug 2001 08:53:36 +1000 From: Wim Brouw Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: alma-sw-ssr@cv3.cv.nrao.edu Subject: Re: [alma-sw-ssr] Offline and Pipeline Requirements Mel, At Thu, 23 Aug 2001 11:03:56 -0700 (PDT) mel wright 456 wrote: > The ALMA model is that that all data are pipeline reduced, > including, probably, a deconvolution of the synthesised images. > > The best calibration and imaging procedure are more easily > defined by the observing procedure and quality of the data > obtained, and can be optimised in the pipeline processing. > The most appropriate deconvolution is not so clearly defined, > and may need to be done in alternate ways offline. > > In some cases, experts may wish to go back and re-process > the uv-data, but I think that most users will not, and that > ALMA will best serve the community by producing images. > > The calibration and imaging, of course require the uv-data, > but almost all deconvolution algorithms do not. This is certainly not true for most procedures and telescopes nowadays that need a dynamic range of more than 20dB. Since the early 1980's deconvolution, especially for mosaicing and the lower frequencies (with many sources) and polarisation work, econvolution algorithms have been iterating between uv and image plane. Groeten, Wim Brouw ------------------------------------------------------------------------------- From wright@astron.berkeley.edu Fri Aug 24 08:04:36 2001 Date: Thu, 23 Aug 2001 16:16:53 -0700 (PDT) From: mel wright 456 Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: alma-sw-ssr@cv3.cv.nrao.edu Subject: Re: [alma-sw-ssr] Offline and Pipeline Requirements Hello Wil, yes, but we are supposed to be designing software for a multichannel mosaicing millimeter array, not a high dynamic range cm array. cheers, Melvyn ------------------------------------------------------------------------------- From lucas@iraux2.iram.fr Fri Aug 24 08:11:23 2001 Date: Fri, 24 Aug 2001 08:21:41 +0200 From: Robert Lucas Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: alma-sw-ssr@cv3.cv.nrao.edu Subject: Re: [alma-sw-ssr] Offline and Pipeline Requirements An interesting reading for getting a feeling of the fidelities expected for ALMA with realistic errors is at: http://iraux2.iram.fr/~alma/node1.html Regards Robert ------------------------------------------------------------------------------- From wright@astron.berkeley.edu Fri Aug 24 21:43:05 2001 Date: Fri, 24 Aug 2001 10:42:14 -0700 (PDT) From: mel wright 456 Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: alma-sw-ssr@cv3.cv.nrao.edu Subject: Re: [alma-sw-ssr] Offline and Pipeline Requirements Hello Robert, thanks for the support. BIMA memo 73 discusses the imaging fidelity of the CARMA array using heterogenous imaging with 6 and 10m antennas. http://bima.astro.umd.edu/memo/abstracts.html#73 good work, cheers, Melvyn ------------------------------------------------------------------------------- From gueth@iram.fr Fri Aug 31 12:49:50 2001 Date: Mon, 27 Aug 2001 08:48:10 +0200 From: Frederic Gueth Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: alma-sw-ssr@cv3.cv.nrao.edu Subject: Re: [alma-sw-ssr] Offline and Pipeline Requirements In order to study the impact of the ACA on the imaging capabilities of ALMA, there has been a considerable effort this summer to get simulations of the whole imaging process as realistic as possible. At IRAM, we have developed a simulator in GILDAS. It includes pointing errors, anomalous refraction and phase errors induced by an atmospheric phase screen, amplitude errors, etc. Mosaicing is the default mode. The deconvolution is done with CLEAN or one of its variant. You can check the (preliminary) results at: http://iram.fr/~alma Frederic. ------------------------------------------------------------------------------- 31-Aug-2001: Pipeline V3.2 now available ------------------------------------------------------------------------------- From schilke@mpifr-bonn.mpg.de Fri Aug 31 12:50:12 2001 Date: Tue, 28 Aug 2001 19:00:53 +0200 From: Peter Schilke Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: alma-sw-ssr@cv3.cv.nrao.edu Subject: [alma-sw-ssr] Pipeline Requirements new version Hi everybody, here is a new version of the pipeline requirements, where we (particularly Frederic) have tried to incorporate all the comments we received both on the mailing list and in the telecon. We have added priorities, but currently all of them are 1 - most of them will remain this way, since the pipeline will be essential for ALMA and should be functional from the beginning. The last section (Interface with the Archive) is still very sketchy. Please give you comments until thursday evening, so that we have to work them in on friday in order to meet the September 1 deadline for the ASAC documents. Cheers, Peter ftp://ftp.mpifr-bonn.mpg.de/outgoing/schilke/pipeline_3.2.pdf ftp://ftp.mpifr-bonn.mpg.de/outgoing/schilke/pipeline_3.2.ps.gz ------------------------------------------------------------------------------- From lucas@iram.fr Fri Aug 31 12:50:38 2001 Date: Wed, 29 Aug 2001 16:08:22 +0200 From: Robert Lucas Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: alma-sw-ssr@cv3.cv.nrao.edu Subject: Re: [alma-sw-ssr] Pipeline Requirements new version Peter, Frederic I attach comments to pipeline v3.2; these are mainly minor (phrasing). Regards Robert $Header: /home/lucas/ALMA/Software/SSR/Requirements/pipeline_3.2Comments.txt,v 1.3 2001/08/29 14:00:32 lucas Exp lucas $ p1. title: Mention DRAFT somewhere in title? p4. s1.1 - 'four different groups' - 'Each group should has lot of operations' -> plural in all following - Each of these groups has different functions... p4. real-time ... 4th level itemize: add side band ratio determination. astromical calibration: add somewhere: - preliminary phase and amplitude calibration calibration (for quick look) p4. quick Look Operations o quick calibration - produces uv tables: this an implementation issue. say `apply preliminary phase and amplitude calibration' p5. science imaging operations say: `final after completion of part of project' p5. o "produces and archives uv tables of calibrated visibilities": this is in contradiction with archive section where we archive calibration data, not calibrated data. p5. s1.2 astronomical source : arbitrary p5. s1.3 3rd - will polarisation leakage calibration require a time interpolation? p5. s1.3 last paragraph The third category will be handled partly as real-time calibration operations (...) as Quick Look operations (...) and as final Science Operations. p6. 2-0.0-R3 "All data processing shall operate ..." or "The pipeline ..." p6. 2-0.0-R6 "any step" is difficult. At least add "an entire series of _previous_ operations" (I doupt we can avoid redoing the operations subsequent to the incriminated step). In fact it is a question of implementation of the software whether it is optimum to `compute backwards' steps, or go back to previous states. p7. Real Time Calibration Operations p7. 3-0.0-R1 Real Time calibration operations shall ... p7. 3-0.0-R2 Whenever the results of the real time calibration allows ... p7. 3-2.0-R1 The pipeline shall reduce, ... p7. 3-2.0-R1.1 The receiver sideband ratios. p7. 3-2.0-R1.2 The temperature scale calibration data, ... p7. 3-2.0-R1.3 The bandpass calibration data. p7. 3-2.0-R2 For all observations... the pipeline shall: p7. 3-2.0-R2.1 This is not the only solution, one may also defer the actual conversion to later stages, and keep only the conversion factor (Tsys) as a function of frequency. p7. 3-2.0-R2.2 Sorry I had missed this. The first is not a pipeline operation; it is part of the data acquisition (in anyway it is not the phase but the complex data). p8. 3-2.0-R3 last paragraph: "they must also made available to later science calibration operations... p8 3-3.0-R1 'The pipeline shall ...' p8 3-3.0-R2 ditto and note contradiction with 3-2.0-R2.1 which does the same thing. ->same comment p8. 3.4.0-R1 The Pipeline... delay measurements p8. 3.4.0-R1 telescope parameter file: this is an implementation issue (may be in a data base). I would say `archived and made available ...' p8. 3.4.0-R2/3/4 The Pipeline... p9. 3-4.0-R5 The Pipeline... p9. 3-4.0-R5 Add the same req. for point sources of known flux or small sources of known visibility model and aperture efficiency? p9. 3-4.0-R6 Skydip already mentioned in R5 (I think it should be only here). - I'm not sure single dish (transmitter) holography can be handled by the pipeline as it will probably not be done on the site (?) p10. s4: Quick Look Operations p10. 4-0.0-R3 `various real time calibration results' p10. 4-0.0-R3 last paragraph: replace `observer' by `staff astronomer' p10. 4-0.0-R5.5 say '(from theory, using actual system temperatures)' p11. 4-0.0-R6.3 AoD -> Staff astronomer (for consistency). p11. 4-0.0-R6.5 or at actually observed positions (... not necessarily rectangular) p11. 4-0.0-R8.5 phase and amplitude closure (useful to detect decorrelation). both really useful for calibrators only. p11. 4-0.0-R9 resulting map shall be displayed p11. 4-0.0-R9.2 AoD -> Staff astronomer (for consistency). p12. 5-0.0-R2 The pipeline shall find ... p12. 5-1.0-R1/2/3 The pipeline shall find ... p12. 5-2.0-R2 AoD -> Staff astronomer (for consistency). p13. s6 Science Imaging Operations p13 6-1.0-R1/2/4/5 The Pipeline shall .... p13 6-1.0-R2 ... find in the Archive the visibilities and calibration data obtained ... p13 6-1.0-R4 ... , plus the continuum measurements, if required. p13 6-1.0-R5 ..., as well as continuum emission, if required. p14 6-1.0-R5 subtraction of continuum ... may be required. p14 6-1.0-R8.4 combination of single-dish and interferometer data. p14. 6-2.0-R1 For single dish data, the pipeline shall: p14. 6-2.0-R1.1 it shall use calibration data produced by science calibration operations. p14. 6-2.0-R1.2 find in teh Archive previous observations and calibration data, ... ------------------------------------------------------------------------------- From wright@astron.berkeley.edu Fri Aug 31 12:50:54 2001 Date: Wed, 29 Aug 2001 15:57:45 -0700 (PDT) From: mel wright 456 Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: alma-sw-ssr@cv3.cv.nrao.edu Subject: Re: [alma-sw-ssr] Pipeline Requirements new version Hello Peter, The pipeline can be used to derive the antenna phasing for vlbi. You could refer to ALMA vlbi memo 382, and use some words: \section{Array Phasing} For VLBI the phase correction must be applied before the IFs are summed, e.g. as a phase offset to the LO. This is different from the data correction envisioned for ALMA observations. The phase might be derived some combination of: i) WVR, ii) selfcal on strong target source, iii) rapid switching to nearby reference source. Melvyn ------------------------------------------------------------------------------- From wright@astron.berkeley.edu Fri Aug 31 12:50:58 2001 Date: Wed, 29 Aug 2001 17:12:36 -0700 (PDT) From: mel wright 456 Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: alma-sw-ssr@cv3.cv.nrao.edu Subject: Re: [alma-sw-ssr] Pipeline Requirements new version All, and hardware guys too, Another thought about antenna phasing. The "standard" model is a combination of WVR monitoring, and rapid switching to nearby phase calibrators. Some variations on this: 1. At the lower frequencies, there may be a sufficiently strong compact source within the primary beam which could be used as a continuous atmospheric phase monitor. The pipeline could derive the antenna phases. 2. At high frequencies, a suitable monitoring source may be found in the offset beam corresponding to a low frequency band. These offset beams move w.r.t. the target source, so the monitoring source will change with time, but one is only interested the phase, not the source. The simultaneous observation of the target at high frequency and a monitoring source in an offset beam at low frequency requires a few things, like 2 active receivers, sharing bandwidth and correlator, but has the advantage of a continuous phase calibration on a nearby source. 3. If one uses different frequencies for the target and phase calibrator, then a calibration of the phase offset between the 2 bands is required at an interval determined by the phase stability of the system. A stronger calibrator can be used for this. The pipeline should keep track of this phase offset, its interpolation and the calibration interval required. 4. Suitable phase calibrators could be found from a quick mosaic around the target source at the start of an observation This is a job for the pipeline too. ------------------------------------------------------------------------------- From mholdawa@cv3.cv.nrao.edu Fri Aug 31 12:51:05 2001 Date: Thu, 30 Aug 2001 08:34:22 -0700 (MST) From: Mark Holdaway Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: alma-sw-ssr@cv3.cv.nrao.edu Subject: Re: [alma-sw-ssr] Pipeline Requirements new version Mel wrote: > 1. At the lower > frequencies, there may be a sufficiently strong compact > source within the primary beam which could be used as > a continuous atmospheric phase monitor. The pipeline > could derive the antenna phases. I think this is the same as self-calibration. > 2. At high frequencies, a suitable monitoring source > may be found in the offset beam corresponding > to a low frequency band. These > offset beams move w.r.t. the target source, so the > monitoring source will change with time, but one > is only interested the phase, not the source. > The simultaneous observation of the target at > high frequency and a monitoring source in an offset beam > at low frequency requires a few things, like > 2 active receivers, sharing bandwidth and correlator, > but has the advantage of a continuous phase calibration > on a nearby source. I think dual frequency observations have been ruled out by the systems group. > 3. If one uses different frequencies for the target and phase calibrator, > then a calibration of the phase offset between the 2 bands is required > at an interval determined by the phase stability of the system. A > stronger calibrator can be used for this. The pipeline should > keep track of this phase offset, its interpolation and the > calibration interval required. This is also a requirement of fast switching. > 4. Suitable phase calibrators could be found from a quick > mosaic around the target source at the start of an observation > This is a job for the pipeline too. This is also a requirement of fast switching. -M ------------------------------------------------------------------------------- From bbutler@cv3.cv.nrao.edu Fri Aug 31 12:51:09 2001 Date: Thu, 30 Aug 2001 09:54:18 -0600 From: Bryan Butler Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: alma-sw-ssr@cv3.cv.nrao.edu Subject: Re: [alma-sw-ssr] Pipeline Requirements new version i agree with mark here - simultaneous dual-frequency operation has been completely ruled out (if you don't count the WVR). i'm pretty sure we are beyond the point at which this decision can be changed. the current design is that there is one 'hot' receiver - i.e., the one currently being used; there is one 'warm' receiver, which can be switched to on short timescales (1 sec or so, i think is the spec) - i.e., the low frequency Rx for fast switching calibration; and one which is 'ready to be warmed up' - i.e., the next observing frequency (it takes 10 or 15 secs for this to be ready, IIRC). note that we are seriously considering this kind of a calibration scheme for the EVLA, where all of the receivers are 'on' all of the time. there are some difficulties with transferring the phase, but it certainly looks promising. -bryan ------------------------------------------------------------------------------- From lucas@iram.fr Fri Aug 31 12:51:14 2001 Date: Thu, 30 Aug 2001 18:42:48 +0200 From: Robert Lucas Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: alma-sw-ssr@cv3.cv.nrao.edu Subject: Re: [alma-sw-ssr] Pipeline Requirements new version mel wright 456 wrote: > > All, and hardware guys too, > > Another thought about antenna phasing. > The "standard" model is a combination of WVR monitoring, > and rapid switching to nearby phase calibrators. > > Some variations on this: > > 1. At the lower > frequencies, there may be a sufficiently strong compact > source within the primary beam which could be used as > a continuous atmospheric phase monitor. The pipeline > could derive the antenna phases. Agreed. We had this before (6.3-R6) in sw memo 11. Self Cal should be mentioned in the new reqs. > > 2. At high frequencies, a suitable monitoring source > may be found in the offset beam corresponding > to a low frequency band. These > offset beams move w.r.t. the target source, so the > monitoring source will change with time, but one > is only interested the phase, not the source. > The simultaneous observation of the target at > high frequency and a monitoring source in an offset beam > at low frequency requires a few things, like > 2 active receivers, sharing bandwidth and correlator, > but has the advantage of a continuous phase calibration > on a nearby source. I agree with the other replies that this appears now excluded by hardware design; it seems to me unlikely in any case that there are enough sources to do that kind of calibration in a significant number of projects. > 3. If one uses different frequencies for the target and phase calibrator, > then a calibration of the phase offset between the 2 bands is required > at an interval determined by the phase stability of the system. A > stronger calibrator can be used for this. The pipeline should > keep track of this phase offset, its interpolation and the > calibration interval required. This also is mentioned in our Observing Modes Use Cases and in the OffLine Reqs. OL 4.2 R4; it should be mentioned in the piline reqs. > 4. Suitable phase calibrators could be found from a quick > mosaic around the target source at the start of an observation > This is a job for the pipeline too. I'm not sure the pipeline reqs are at this level of detail yet (as there is no very specific data processing here). Thi sis more at the `observing mode' level. Robert ------------------------------------------------------------------------------- From bbutler@cv3.cv.nrao.edu Fri Aug 31 12:51:23 2001 Date: Thu, 30 Aug 2001 10:25:01 -0600 From: Bryan Butler Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: alma-sw-ssr@cv3.cv.nrao.edu, mmaimcal@cv3.cv.nrao.edu Subject: [bbutler@cv3.cv.nrao.edu: Re: [alma-sw-ssr] Pipeline Requirements new version] On 2001.08.30 10:22 Bryan Butler wrote: al is right here (i was thinking of the situation for only 1 antenna). but sub-arraying is essentially the 'paired antennas' (or 'clustered antennas') calibration concept, which is terribly inefficient for calibration. -bryan On 2001.08.30 10:19 Al Wootten wrote: > Bryan Butler writes: > > On 2001.08.30 09:34 Mark Holdaway wrote: > > > > > > Mel wrote: > > > > > > > 2. At high frequencies, a suitable monitoring source > > > > may be found in the offset beam corresponding > > > > to a low frequency band. These > > > > offset beams move w.r.t. the target source, so the > > > > monitoring source will change with time, but one > > > > is only interested the phase, not the source. > > > > The simultaneous observation of the target at > > > > high frequency and a monitoring source in an offset beam > > > > at low frequency requires a few things, like > > > > 2 active receivers, sharing bandwidth and correlator, > > > > but has the advantage of a continuous phase calibration > > > > on a nearby source. > > > > > > I think dual frequency observations have been ruled out by the systems > > > group. > > > > > > > i agree with mark here - simultaneous dual-frequency operation has > > been completely ruled out (if you don't count the WVR). i'm pretty > > sure we are beyond the point at which this decision can be changed. > > the current design is that there is one 'hot' receiver - i.e., the > > one currently being used; there is one 'warm' receiver, which can > > be switched to on short timescales (1 sec or so, i think is the > > spec) - i.e., the low frequency Rx for fast switching calibration; > > and one which is 'ready to be warmed up' - i.e., the next observing > > frequency (it takes 10 or 15 secs for this to be ready, IIRC). > > > > note that we are seriously considering this kind of a calibration > > scheme for the EVLA, where all of the receivers are 'on' all of the > > time. there are some difficulties with transferring the phase, but > > it certainly looks promising. > The only way one can effect simultaneous dual-frequency operation is through > the use of sub-arrays. One is using different antennas in that case, but > depending on the configuration one may be observing a similar patch of > atmosphere. > > Al ------------------------------------------------------------------------------- From lucas@iram.fr Fri Aug 31 12:51:46 2001 Date: Thu, 30 Aug 2001 18:51:57 +0200 From: Robert Lucas Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: alma-sw-ssr@cv3.cv.nrao.edu Subject: Re: [bbutler@cv3.cv.nrao.edu: Re: [alma-sw-ssr] Pipeline Requirements new version] I would think the only wise use of that mode (for interferometry) is to observe time-varying phenomena (e.g. next comet crash, solar flares, ...) at several frequencies simultaneously. Robert ------------------------------------------------------------------------------- From wright@astron.berkeley.edu Fri Aug 31 12:51:52 2001 Date: Thu, 30 Aug 2001 09:59:29 -0700 (PDT) From: mel wright 456 Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: alma-sw-ssr@cv3.cv.nrao.edu Subject: Re: [alma-sw-ssr] Pipeline Requirements new version Bryan, > this appears now excluded by hardware design too bad, EVLA looks more fun. > unlikely in any case that there are > enough sources to do that kind of calibration in a significant number of > projects. Robert, you can check my numbers (maybe wrong ?) obsrms freq=40 antdiam=12 tsys=40 nants=60 bw=8000 inttime=.1 min => Rms Flux density: 0.142 mJy/beam in 6s. Kellerman gives N(S) = 60 S^{-1.5} Sr^{-1} [at 5 GHz (?); I think Frazer had some better estimates at mm] calc '60/.7e-3**1.5*2.1*2.1/3400/3400' => 1.2 sources in a 2.1' beam above 5 x RMS in 6s. ------------------------------------------------------------------------------- From lucas@iram.fr Fri Aug 31 12:51:55 2001 Date: Thu, 30 Aug 2001 19:37:31 +0200 From: Robert Lucas Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: alma-sw-ssr@cv3.cv.nrao.edu Subject: Re: [alma-sw-ssr] Pipeline Requirements new version mel wright 456 wrote: > Robert, > you can check my numbers (maybe wrong ?) > > obsrms freq=40 antdiam=12 tsys=40 nants=60 bw=8000 inttime=.1 min > => Rms Flux density: 0.142 mJy/beam in 6s. > > Kellerman gives N(S) = 60 S^{-1.5} Sr^{-1} > [at 5 GHz (?); I think Frazer had some better estimates at mm] > > calc '60/.7e-3**1.5*2.1*2.1/3400/3400' > => 1.2 sources in a 2.1' beam above 5 x RMS in 6s. > Mel: I think you're using the sensitivity for detecting a point source, while you should use the sensitivity for getting the phase for each antenna which is sqrt(60)~8 times worse. Robert ------------------------------------------------------------------------------- From wright@astron.berkeley.edu Fri Aug 31 12:52:01 2001 Date: Thu, 30 Aug 2001 11:20:50 -0700 (PDT) From: mel wright 456 Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: alma-sw-ssr@cv3.cv.nrao.edu Subject: Re: [alma-sw-ssr] Pipeline Requirements new version Robert, Bryan, >I think you're using the sensitivity for detecting a point source, while >you should use the sensitivity for getting the phase for each antenna >which is sqrt(60)~8 times worse. Agreed, this source could be used for continuous monitoring but not for deriving antenna phases every 6s. Same calculation for EVLA looks promising for both. Melvyn ------------------------------------------------------------------------------- From mholdawa@cv3.cv.nrao.edu Fri Aug 31 12:52:07 2001 Date: Thu, 30 Aug 2001 12:10:41 -0700 (MST) From: Mark Holdaway Reply-To: alma-sw-ssr@cv3.cv.nrao.edu To: alma-sw-ssr@cv3.cv.nrao.edu Subject: Re: [alma-sw-ssr] Pipeline Requirements new version Other guys wrote: > Robert, > you can check my numbers (maybe wrong ?) > > obsrms freq=40 antdiam=12 tsys=40 nants=60 bw=8000 inttime=.1 min > => Rms Flux density: 0.142 mJy/beam in 6s. > > Kellerman gives N(S) = 60 S^{-1.5} Sr^{-1} > [at 5 GHz (?); I think Frazer had some better estimates at mm] > > calc '60/.7e-3**1.5*2.1*2.1/3400/3400' > => 1.2 sources in a 2.1' beam above 5 x RMS in 6s. > > I think you need to do better than this. This is a detection of 5 sigma of the entire array in 6 seconds, which means the noise on each visibility will actually be sqrt(n(n-1)/2) = 42 times worse, or the signal is 1/8 sigma per baseline, which is equivalent to phase noise spinning around all 360 degrees. In my simulations, 1 sigma detection per baseline is a good rule of thumb, which puts you up by a factor of 8 in source flux. -M ------------------------------------------------------------------------------- 31-Aug-2001: Offline V3.2 now available ------------------------------------------------------------------------------- 02-Sep-2001: Offline V3.3 now available for ASAC meeting in Chile ------------------------------------------------------------------------------- From lucas@iram.fr Wed Dec 5 13:33:02 2001 Date: Tue, 06 Nov 2001 20:32:22 +0100 Steve: The comments I got (orally) from A. Benz: 1.2-R3 Not only bug fixing should be provided but also improvements in particular on the user interfaces, whenever needed. >>>SMyers: agreed. Add new R4.<<< 2.2-R5: Priority 1? >>>SMyers: I am inclined to keep this as Pri 2 as it is not crucial but is important (and the package will be graded on this). We probably need to downgrade items in priority, not upgrade them!<<< 5.1-R7: accuracy is at least 10 times better e.g. assuming S/N ratio larger than 10. But it is recognized that this is a placeholder. >>>SMyers: I am removing this from the draft, as there seems little justification.<<< 7.1-R5.1 Not that gif is out of fashion >>>SMyers: Fashion is irrelevant. The question is whether it is useful to be able to output gif as well as jpeg etc. I am removign jpeg and gif from 5.1 and leaving them in 5.2. Are there other primary formats in additon to FITS?<<< 7.1-R5.2 should be higher priority (e.g. 1); ps too is out of fashion >>>SMyers: Fashion again? ps is useful. Do you actually publish? But I dont think priority should be boosted to 1, 2 at most, and I will leave at 3.<<< 7.2-R1 z-axis limits should be explicitly mentioned for color maps >>>SMyers: I don't see why.<<< I did not get any other from ASAC people. The first one is the only which is really important. >>>SMyers: agreed. Sigh.<<< Cheers Robert ------------------------------------------------------------------------------- 06-Dec-2001: Offline V3.4 now available for review ------------------------------------------------------------------------------- Date: Fri, 14 Dec 2001 12:53:57 +1100 From: Wim.Brouw@csiro.au To: smyers@cv3.cv.nrao.edu Cc: graffi@eso.org, jschwarz@eso.org, Neil.Killeen@csiro.au Subject: Re: ALMA offline DPR Steve, A few comments on the above. Some of them were made before I saw the answer in a later part. Hope you got back safely to Socorro. Groeten Wim (I am not sure that page numbers are the same in A4...) p6: 'C': Observational wise I agree. However, to get bandpass and other calibrations, noise characteristics play a role if a lot of energy is in parts of the overall band. Some kind of self-cal in the frequency domain could be necessary in a spectral-line rich region >>>SMyers: Hmmm, could be. I dont think that impacts this doc<<< p6: 'F': I think the requirements are prefixed with 'OL' >>>SMyers: Oops.<<< p7 1.1-R5: seems to me that this should be p1 >>>SMyers: there is some room for very special pipeline modes that may be beyond the package.<<< 1.2-R1: drop the (on Unix): NT certainly has 'root' ('administrator') >>>SMyers: done<<< p8 1.2-R9 (and R8): if it is considered p2, changes are it will never be done. Both these items need at the minimum some define 'hooks' in the software from day 1. Therefore maybe better p1 >>>SMyers: I keep pointing out that the intention is that 90% of P2 items will be done (i.e. the Package could fall short on only a couple of P2 items. If we really think that only P1 will get done, then there is no reason for prioritizing - or we should only have P1 and P2. Actually, we need to *demote* more P1 items to P2, not the other way around. However, if people really dislike putting some important things in P2 then we should adjust the system. On the subject of these specific 1.2-R8 and R9, these are not so critical to the operation of the package that under the current scheme they go to P1.<<< p9 2.1-R3 raises locking issues which should be mentioned at an early stage (I noticed that later locking was mentioned, but should be up-front) >>>SMyers: There is file-locking in 3.1-R12 as that is under data management, where it should be. I will insert an "Operational Issue" as 1.2-R3 to mention locking and multi-task interference.<<< p10: 2.4-R1: always dangerous to try to make an inclusive list. E.g. the 'efficient vector and matrix': make it array, a lot of data is 3d I also miss the, important, interrupts and error handling in this list. >>>SMyers: Add interrupts and error-handling. Note there are special vector and matrix operations that are not covered by general array handling, but add array handling as a P1 general item.<<< p12 2.5-R6: full search is essential from start (and definition of documentation). You do not want to have in this day and age a non-context sensitive, html only based search... >>>SMyers: again you seem unclear on how the priorities work. This is not the scheme of SW11. P2 does not imply anything more than it is not critical to the package, but very important.<<< p13 3.1-R2 is dualistic, or at least not precise enough. Do you always want to make a copy from data in the archive into local datasets; or allow the use of 'virtual' combination and virtual access (may save a lot of overhead). In either case it will be difficult to be able to add all calibration tables (if such beasts are used) and history coupled to the data in the archive. Any idea on how to do that; what access to archive writing is needed in those cases etc. >>>SMyers: This is a tricky one indeed, not precise enough for a real spec, but I do think we need some sort of placeholder list here. Any suggested rewrites would be welcome, but we should probably not move closer than this to implementation issues.<<< 3.1-R3: you want to select on mosaic fields; SD pointings (OTF); probably be able to do OTF (time, and maybe baseline) integration (for [self]calibration) >>>SMyers: Add pointings for mosaic and scanning modes<<< 3.1-R6: really 2 points: 1. OTF integration; 2. creating a 'compressed' new dataset. OTF is in generally much more efficient in computers (IO operations are slower than Flops. In creating a compressed dataset you also have to worry about the 'centre-of-gravity' of the averaged band (and/or time) >>>SMyers: I don't understand what you are saying. The intent here is really just averaging in time, band, channel. More complex compression should probably go to another req (add as 3.1-R16 P3)<<< 3.1-R8: 'A' flagging mask... (rather than 'the'?) >>>SMyers: how about 'Any existing'?<<< p14: 3.1-R9: ... if requested... I hope they will always be preserved in the original data, and only be omitted (if requested, not other way around) in offline copies of data >>>SMyers: I would imagine that is the default. Just need the possibility to be built in.<<< 3-1-R11: does manipulation include 'changing'? >>>SMyers: yes - reword<<< 3-1:R12: read locking should be possible (i.e. when changing a header defining say a data length no reading should be active). Again the question: should the default operation be working from archived data with no write access? Most/all operations be done OTF (stops processing bloat) or through auxiliary data files. >>>SMyers: Dunno. That was my model for operation (read archive, fiddle, write new stuff). As for other (read) locking, that might be considered for a P3 item (Im not putting one in now however).<<< 3.1-R14 and R14.1 should be reversed (I think), with 14.1 have p1 (if it is what I call 'virtual concatenation') 3.1-R14.1 -- what Boolean operations? Regular Expression maybe? >>>SMyers: I think I disagree, though I don't quite understand what you are getting at. I don't think this is P1 in any event. 14.1 is a request on how it would look to a user (e.g. "file1 + file2 + file3"). Im tired enough of explaining what this fairly obvious thing is (provided one thought about it for even a moment), and since it is probably an irrelevant implementation detail, I will delete 14.1<<< 3.2-R4: I am all for making any type of bloat forbidden if it influences the processing speed (overall). Having an external format of 8 bytes when 0.5 byte suffices makes processing 16 times slower than necessary (or probably 10 times or so due to added internal processing). However, internally, on fast processors, it would be much slower not to have the 8bytes for the data in a lot of processors with an 64-bit bandwidth and processor width. Cheaper to have 8 times the memory and speed (and if necessary an 8-way raid). Would rather say: ' The package should make sure that data is handled in such a way and format that the overall speed is optimised' Memory and speed bloat, if present, should be balanced to obtain the best overall throughput." >>>SMyers: The intent here is for diskspace bloat. Speed and efficiency are other reqs like 3.3-R.1 and even more 1.1-R4.<<< p15: 3.3-R3: ..larger than main and virtual memory of the host system. >>>SMyers: Is this a relevant distinction? Use of the VM is part of this, and should be factored in of course. No change.<<< 3.4: what is the point of having -R2 and R3? There must be many other data that must be handled (now and in the future). If a list, make it complete (which is impossible), or no list, and say: all monitoring (engineering and astronomical) data must be handled. E.g. ... >>>SMyers: more to the point, some of these are handled better in 3.1-R2 as per Bryan Butler's suggestion. 3.4 and 3.5 are now deleted, with 3.4-R3 into 3.1-R2.4. 3.4-R1 moved to after 3.1-R8.<<< 3.5: again a list >>>SMyers: 3.5-R1 moved to before 3.1-R2.7, delete 3.5<<< 3.6-R1.1: random or along axes? >>>SMyers: not relevant here, see 2.6<<< 3.6-R1.2: is images correct word? Could be misunderstood as excluding say v-ra planes >>>SMyers: add "and arrays"<<< 3.6-R1.3: pol. cubes; RM cubes,... >>>SMyers: pol not usually done as a "cube", and Im not sure what an RM cube is (I would think RM would be on the intensity axis of an image cube, though I guess adding an RM axis to a spectral cube might make sense). I would tend to leave the more complicated stuff to 2.6.<<< p16: 3.7-R2: I am not sure that 'FITS' is a good example as 'standard', especially not for non-image data. I believe that fits-like but standard based (xml or so) will be the norm at that stage. But ok. I would like to see added that ALMA produces also a standard output for use by other packages, and a standard that is understood by others. >>>SMyers: leave this to the project<<< 3.8-R1: ... is run by ALMA staff, or a VO)... >>>SMyers: Im not sure we want VO accessing the archive through the offline package, but likely using archival retrieval tools. Dodge this issue here by not mentioning VO.<<< p17 4.1-R2: re-reading... why reading (I read that as 'copying' ) anyway? >>>SMyers: meaning you don't have to read the data in again or have made a backup copy just to change these things<<< 4.1-R21.: apart from definition of 'some sort of...', which is too vague, is the question: where is the history table kept? >>>SMyers: not our intent to dictate implementation, vagueness is intentional. I don't care where the table is kept. Change 'sort of' to something less colloquial.<<< 4.1-R3: and astronomical data >>>SMyers: not the intention here.<<< 4.1-R5: ..., preferably OTF. >>>SMyers: I dont understand the relevance of OTF here. I presume you mean some "on-the-fly" manipulation of the data, not the OTF scanning mode, but this is some buzzword that I think is too vague to be of use here<<< 4.1-R6.*: again a list; with missing, important stuff like vs. UV; vs. W; vs. Tatm etc etc R6.&: monitoring data should be in that list what about closing errors; etc >>>SMyers: uvw implied in R6.1, I dont see vs. Tatm as useful, but include along with monitor data and closure in new items<<< p18 4.2-R1: a list again. I would say ..would at the minimum take account of .... Maybe in 2 years time the sodium layer reflections give some very important additional atmospheric info.. >>>SMyers: Huh? I dont think we should include that much speculation here, unless I am missing something really novel and important.<<< 4.2-R3: who provides the model -- ALMA scientist or the package providers? (I think ALMA>>SMyers: This is a policy issue - should we have ALMA provide the model or at least a standard model? This is probably reasonable, given that the Pipeline will need a model. Add text to this effect as a new R1.<<< p19 4.3-R10: mentioning of multiple datasets here is wrong. I would suppose that all calibration could work with multiple datasets; not just these ones. >>>SMyers: I'm not sure what the intent of the "multiple datasets" stipulation was now. Delete.<<< p20 4.6-R3: Environmental data .. supplied in an ALMA standard format shall be importable... (why specify specifically FITS extension tables and ASCII tables...?) >>>SMyers: I think ASCII tables are a minimum, I can see FITS tables as a useful thing to support. I really do not want to see some obscure format required.<<< p21 5.1-R2.1: should be priority 1 (and I still do not understand Boolean operations on filenames)] >>>SMyers: No - P2 I still think. Boolean gone now.<<< 5.1-R4.6/7: what are these??? Must be jargon I did not get.. >>>SMyers: they are standard modes of mosaic data reduction. I know of no better way to specify these (though example algorithm names would be useful).<<< 5.1-R4: since R5 is separated from this (and I read it as a looping/functional implementation of R4), I miss 'UV-plane subtraction'; UV-plane fitting' etc from list >>>SMyers: I think those are non-imaging data analysis things, though I see this in 5.2-R5. Note, I am demoting R5 to P2 and switching with R6.<<< p22 5.1-R8: You mean 'Image cubes' ? >>>SMyers: yes<<< 5.2-R5: needs more I think: 'clean-like' for forests of spectral lines. >>>SMyers: spectral deconvolution would probably be better placed in Data Analysis.<<< 5.2-R7: 'Imaging must deal seamlessly with mosaiced data' All the rest is superfluous, and makes it look as if these effects are only important for misaicing (and are the only important effects). Varying beams/pointing/polarization etc... >>>SMyers: These are all exacerbated in mosaicing. Reword.<<< p25 This list is basically standard image display/analysis stuff, available in umpteen packages; including commercial non-astronomical. >>>SMyers: maybe true. However, we may assume we will be guaranteed to get only what we ask for specifically.<<< p27 7.1-R5: why FITS plot output standard? pdf and/or ps are really creating an output format (FITS is an image format) >>>SMyers: that is what e.g. means (just an example), though FITS images are now fairly convertible so can be though of as sort of an output format for a strict pixel image. In this context, Im not sure what that means, I would probably choose postscript - as a trial balloon I will do so.<<< 7.2-R7: There are other standards nowadays; and Unicode seems a much more probable one than a Latex extension for 10 years from now. >>>SMyers: Unicode?<<< p29 7.4: ...will not likely be ... to assess .. Why not? Why create another package (or at least package library) for online and offlien access? >>>SMyers: there is the Pipeline which as stated at the start is not necessarily the offline package.<<< 7.4-R1.6: 'all monitor (engineering and astronomical) points' >>>SMyers: what the heck is an astronomical monitor point? A temperature sensor on Mars?<<< page 0: The bottom line, what happens with this document? It is written as a kind of RFP; is it going to be sent around with a cover letter asking for offers and cost? >>>SMyers: NMP!<<< wnb 2001.12.14 ------------------------------------------------------------------------------- Date: Fri, 14 Dec 2001 13:13:08 -0700 (MST) From: Walter Brisken Subject: Re: ALMA Solar and Pulsar requirements Without taking the time to read the current document (bad me), I'll offer just a little insight into the pulsar needs. Alma's pulsar needs will be much easier to satisfy than those of EVLA since dispersion smearing is a non-issue at these frequencies. I expect the main out-of-the-ordinary requirement will be integration into multiple phase bins. Probably 256 bins would exceed needs for anything interesting. Even 16 would be interesting enough probably. Pulsars have periods as short as 1.6 ms, so a minimum bin size of 0.1 ms would probably suffice. I expect the main use of this binning capability will be measuring the on-pulse and off-pulse brightness which can be used to estimate or place bounds on the temperature of the NS. I think it would be unlikely that pulsar timing will be done with ALMA. Its conceivable that ALMA would be a great instrument for pulsar parallaxes, especially if pulsars are detectable at 900GHz. Certainly it would be the best instrument in the southern hemisphere for pulsar parallaxes, unless SKA somehow slips way ahead of schedule. 16 pulsar phase bins would be sufficient for this work. Let me know if you want me to help further. >>>SMyers: add a req on at least 16 pulsar phase bins, and add the above flavor text as a header to that section.<<< -W ------------------------------------------------------------------------------- From mgurwell@cfa.harvard.edu Wed Jan 23 13:19:37 2002 Date: Wed, 23 Jan 2002 15:15:50 -0500 (EST) From: Mark A. Gurwell Comments on "DRAFT ALMA Offline Data Processing Requirements" (Rev 3.4; 6 Dec 2001) Mark Gurwell, SAO 23 Jan 2002 p.7 OL-1.1-R5: While I'm unsure that 'all' functionality needs to be included, it seems to me that all functionality needed in order to process data into images, etc needs to be in the offline package at priority 1. >>>SMyers: P2 is inline with our priority system. If the other P1 items are followed then basic imaging needs will be met in any event.<<< p.8 OL-1.2-R8 (and R6): This may need to be priority 1, depending on what the "standard functionality" really is. For example, observations of a fast moving comet will naturally need correction to a common distance, involving scaling of uvw coordinates and visibility amplitudes. If this is "standard functionality" then ok, but if not, it is imperative that users be able to manipulate the data through the use of his or her own supplied routines. Since there will be many many examples of this, it may be easier to define a core set of functionalities, and set the ability to include user developed routines to be priority 1. In a related matter, if source code for astronomical routines will be available, what about the ability to alter, recompile and include variants of the standard routines? >>>SMyers: again P2 is sufficient here, and for these reqs would definitely be fought for. There is much room for how this is implemented, so P2 is a better match than P1.<<< p.9 2.2.2 (the GUI): I personally would like to see a requirement that user resizing of all windows be robust and easy, priority 2 or 3. >>>SMyers: add after R1.3<<< p.11 OL-2.5-R2.7: Question...what is the difference between 'application descriptions' (see 2.5-R2.2) and 'algorithm descriptions'? I would prefer that anything that alters the visibility data get a full description at priority 1. But perhaps that is what is written here? >>>SMyers: "algorithm descriptions" is meant to be a technical description of what the code does, probably beyond what the average user needs to know.<<< p.17 OL-4.1-R1: this doesn't have a priority, I'm assuming it is 1. >>>SMyers: added P1 designation<<< p.21 OL-5.1-R2: on combining multiple data sets, it seems to me that there should be some automatic check to assure that the relative amplitude calibration between data sets is consistent. for most sources the SNR would hopefully be enough to just compare data at low spatial wavelength to see if similar u,v points have similar amplitude scales. The idea is to notify the user of possible scaling conflicts, not make a blind change. >>>SMyers: I don't see that this should be automatic, though it should be available. This is a calibration issue, add req similar to 4.5-R3 after 4.1-R8 as P2.<<< p.22 OL-5.2-R9: I don't understand what this particular requirement means...perhaps someone could just fill me in? >>>SMyers: Bryan Butler also commented on this. Im not sure what was meant either. Now I can't find who originally sent this in (I think it was either Al Wootten or one of our Japanese colleagues). My guess is that it refers to painting onto the surface of a sphere like planetary radar data, but Im not sure. Delete for now and resurrect if someone comes forward. Probably better in the Data Analysis section in any event.<<< p.22 OL-5.2: Imaging of sources 'in the near field' should be allowed by introduction of phase corrections based upon the sphericity of the incoming wave front. This will be important for Venus at some times and for comets and near-earth asteroids. This may fall under calibration but perhaps best comes under imaging? >>>SMyers: Indeed, the near-field seems to extend to millions of km (e.g. 10km baselines at 500um = 2x10^8 km = 1.25AU), so should put something in after 5.2-R8 at P2. Unless my D^2/lambda is wrong, this will be important for all the prime inner solar system targets!<<< p.24 OL-6.1-R1: OK, here the capability to create user-developed tasks is given priority 1, but OL-1.2-R8 says priority 2... >>>SMyers: True. It is more important here for data analysis, but I think it would be best to demote to P2 here also.<<< p.24 OL-6.1-R6: Units, units, what a pain...I will also point out that for much of the frequency range of ALMA the distinction between RJ and Planck brightness temperature will be important and necessary to maintain. Clearly, RJ equivalent temperatures are easier to carry, as they are linearly related to flux density. But for understanding of the physical conditions of some objects, the Planck temperature is a more direct measure. Some facility for 'seamlessly' converting images to and from Planck Tb should be supported. >>>SMyers: I assume by Planck temperature you mean the real thermal temperature. Add these to list.<<< p.29 OL-7.4-R1: In regards to plotting of ancillary data, I wonder if there will be provision for tools that use the ancillary data to estimate their effects on the visibility data? In particular, the WVR data can be used to estimate coherence loss on certain timescales and/or baseline lengths, etc. Similar effects could be estimated for pointing offsets estimated from tiltmeter measurements, etc. >>>SMyers: These fall under the calibration tools, see 4.6-R1 and R4.<<< p.31 OL-8.1-R1: Simulation. OK, this is an important issue and I don't know where it falls in the Science Software regime. The ASAC has in the past stated that the ability to do simulation will be a vital part of ALMA, not only for proposal preparation, but also for a good understanding of actual ALMA data (see the ALMA Science Advisory Committee Report from Sep 2001, Appendix C). Under what package the simulator resides is open to debate/interpretation, but for ease of use it may be best to have it as part of the Offline Analysis package, since that will be something distributable. >>>SMyers: I something needed beyond the current 8.1-R1? If so, suggest text.<<< ------------------------------------------------------------------------------- Date: Wed, 30 Jan 2002 10:12:26 -0700 (MST) From: akemball@aoc.nrao.edu Subject: ALMA offline requirements comments Steve, I've used "should" to be concise in many places, but I'm making reviewer comments rather than issuing directives to ALMA. My comments should be read in that way. I've enclosed some lengthly comments on the comprehensive ALMA offline requirements below. I reviewed the requirements primarily against the following general software requirements criteria: 1) Prioritization: are all requirements ranked in priority ? This is true for all requirements. 2) Acceptance criteria: are there sufficiently clear acceptance criteria which can be used to assess compliance with any given requirement unambiguously (i.e. when is the work complete for a given requirement). 3) Costing: is there sufficient information provided to allow accurate costing of new development effort. These conditions drive requirements towards greater specificity in many cases, but more detail will mean a stronger user contract that is more likely to be fulfilled as originally intended, with new features for ALMA added in the correct priority order. Some general comments: 1) Cases where examples are listed, as in "such as", "e.g.", "etc" or "..." should be enumerated in complete lists, so that the requirement becomes bounded and can be estimated in scope. >>>SMyers: This has been a common comment, and we should probably do so. However, this is beyond the scope of the current work that has gone into this document, and will likely require another iteration at least. I am uneasy with the current lists and feel they are woefully incomplete. I would like some help on this if we decide to do this. For example, I put subsubreqs into OL-3.1-R2. Another point is that Athol suggests that we completely specify things down to an extreme level of detail. In essence, he seems to want us to do the design work. This is not a good idea, but our requirements should be understandable enough to guide the design and to allow some evaluation of the results.<<< 2) Non-functional requirements (e.g. usability, operational issues and performance) are best separated from functional requirements (e.g. reduction completeness). This separation does not imply lower importance for non-functional requirements, but they are better separated at the requirements level as most non-functional requirements apply globally. >>>SMyers: How would we do this? As sub-reqs?<<< 3) All requirements, functional and non-functional, need to be quantified, again for costing, acceptance and in ensuring that user priorities are followed. In turn, the quantified measures should be dictated by science needs. >>>SMyers: I think this is an overstatement. The major quantifiable things I have tried to assign to the ALMA Project (like benchmarking, performace specs) as I think it is beyond this document to specify. In the FtoF meetings we had tended to try to steer this doc away from being a binding lawyer-ese contract, and it appears Athol is sterring us back toward that. IMO, this is not good, at least for us, but I can see how AIPS++ would want this.<<< 4) Although some detailed algorithms or processing options cannot be anticipated in advance for ALMA, the base requirements can enumerate specific lists with some accuracy. This has many advantages for ALMA in making sure capabilities are available in the correct priority order. It also does not restrict package changes; the base requirements could be augmented during commissioning, operations and maintenance phases, as required by ALMA project or science needs at that time. >>>SMyers: Along with the previous points, it could be argued that everything should be quantified in this single document. However, if we want to do this then much more thought must be put into it - I would estimate that this will be another 6 months of work (and would probably dominate the next FtoF meeting in Granada). Is that what we want to do? I have mixed feelings on this - I could see that it would be more efficient to have it all in this document, but I am loath to commit myself to setting these important specs, and would need committment from the SSR to have much more input to this than they have done so far on this doc.<<< 5) It helps if the lowest level requirements have similar granularity. >>>SMyers: I do not understand this statement.<<< 6) Adverbs and adjectives should be used judiciously in requirements specification; they usually mean a departure from quantifiable measures or imply some degree of subjectivity in interpretation. They may also lead a package away from the original user intent by an incorrect interpretation by the developers. >>>SMyers: Some level of non-quantifiable specification is necessary. I think we have a reasonable mix, perhaps not to the software lawyers liking, but more to the liking of the average scientist. Perhaps the standard measure should be something like "as understood by an average post-doctoral observational radio astronomer".<<< Comments on individual requirements are given below: OL-1.1-R3: "reasonable number of supported platforms" - this needs to be quantified as a cost driver, and could be done so in terms of: a) fractional use of a given OS in the ALMA community before it needs to be supported (e.g. 5%) b) a maximum number of separate OS builds supported at any given time (e.g. 5), for each of which a separate release is required. c) a requirement regarding OS revision support (latest, last two revisions, or all within a fixed time frame (e.g. last two years)). >>>SMyers: these should be designated by the project - add this to the Req<<< OL-1.1-R4: The quantifiable benchmark requirement is clearly stated, but the performance level is unspecified for costing or acceptance purposes. This could be done in terms of the duration of the original observations (i.e. the pipeline should produce a reference image within a certain multiple (or divisor) of the total duration of the observations at the telescope). This is simplistic but can be tied to science drivers and would provide a performance metric which could be costed. An ancillary requirement is that the fiducial benchmarks be representative of the telescope usage pattern and, when run, should repeat the reduction paths typical at the telescope (e.g. x% mosiac, y% single-dish etc) at any given time. The performance compliance should also be specific in terms of applicable metric, ie. mean throughput, peak throughput etc. >>>SMyers: I have put the setting of these off to "the ALMA Project" assuming that all these will be quantified. See above comments.<<< OL-1.2-R1: "non-specialized hardware" requires elaboration. It ties in to the range of OS/revision/hardware choices supported by the package at any given time in OL-1.1-R3. Is "non-specialized hardware" in this context "commodity hardware" or "almost any hardware" ? >>>SMyers: Supported platforms designated in 1.1-R3. The intent here is that you do not need something like a GRAPE processor or Cray. This may be extraneous in light of 1.1-R3, so remove phrase "non-specialized hardware". <<< OL-1.2-R2: A plausible requirement on error reporting is that messages should be written for users rather than programmers. "User-understandable" is a difficult compliance/acceptance criterion. Non-destructive error handling is expensive if required in all eventualities as it often requires almost continuous state-saving. This criterion also needs to be more specific to be able to assess compliance. I might suggest: "Common failure modes (as enumerated: invalid application parameters, resource limits (disk/memory) and algorithm failure modes (e.g. no convergence)) should be handled gracefully". >>>SMyers: that was the intent of "User-understandable". Rephrase, and break into sub-reqs.<<< OL-1.2-R3: This requires a definition of defect severity levels and a delineation of defect and enhancement requests. A strict defect definition will allow operational costing based on the package size and empirical defect rate. >>>SMyers: I have no idea how to do this. I thought the current req was sufficient.<<< OL-1.2-R4: A strong user contract and user input is vital as stated. However, responsiveness to requirements changes always depends on available resources and the extent of the required change. This risk goes down inversely with the completeness of the base requirements (as these are). OL-1.2-R5: I would re-phrase this as: "Backwards compatibility of core package components should not be broken without compelling scientific reasons. Tools should be provided to parse user scripts and warn of package changes". A blanket prohibition against breaking compatibility is difficult as a system evolves to support new ALMA observing modes for example, but this should not happen lightly. >>>SMyers: done<<< 2.2.2: I would suggest phrasing GUI usability in terms of required training time to allow neophyte or power users to become productive at particular operations. The criteria that the GUI be "pleasurable, not frustrating" needs to be replaced by a quantifiable measure of this type rather, for the reasons listed above. >>>SMyers: I think this statement needs to be here in the header - I think most GUI designers forget this (remember these headers are explanatory fluff, not requirements). Add a new 2.2-R1 with a statement to the above effect with placeholder timescales.<<< OL-2.2-R5: This requirement could be costly, and I find it difficult to cost or assess compliance as phrased. I would argue for more specificity here, perhaps broken down by the general requirements on basic and advanced reduction views. In practice this would need to be resolved by prototyping with strong user involvement. >>>SMyers: I am not sure, but I think the intent of 2.2-R5 was that there be GUIs that are easier for beginner, and more complex ones for experts? Note Bryan Butler also has comments here that he was unsure what it meant. A possible implementation is that the user selects from "Basic", "Intermediate" and "Advanced" complexity from a "View" menu. Or possibly that there are separate GUIs for novice and advanced users. Note that these are design issues, and it is not our job to do the design work for the package developers. However, it might be reasonable to use subreqs to break out features we would want in the novice and advanced "views". It seems to me that the "novice view" is the real issue, so focus the subreq items on this - I have changed the text to do so. I put in a short list of items, we might want more.<<< OL-2.4-R1: I would suggest adding event-handling and I/O as additional UI programming capabilities. >>>SMyers: process control and interrupts added already as per Wim's comments. Anything else still missing?<<< OL-2.5-R1: "User-comprehensible" is hard to quantify. I suggest linking OL-2.5-R1 directly to OL-2.5-R2, which is specific. >>>SMyers: move 2.5-R1 to 2.5-R1 (making current R2 now R1) as just up-to-date and complete<<< OL-2.5-R3: If possible, it would help to specify document formats which should be supported specifically, as multiple interchangeable document formats are difficult to cost, unless enumerated. Also, some specification of document processing would be useful, such as the source (e.g. Word, Latex) and end-products (e.g. pdf, html) of processed documentation. >>>SMyers: enumerate. Probably within our scope to give complete list here. Added "popular proprietary formats (e.g. MS-Word)" as a P3 option, should that be here? I think it may be a good thing, and is value-added but low priority so should not impact costing.<<< OL-3.1-R9: I would suggest elaborating "monitoring data", as they could be extensive and varied for ALMA. >>>SMyers: Add examples, though an inclusive list is not relevant here since as long as the monitoring data is in an ALMA standard format (e.g. extension tables) it should be preserved. Rephrase to this effect.<<< OL-3.1-R10: More specificity about the format or content would be helpful here, to replace "comprehensive and understandable". >>>SMyers: again details are a design consideration for the package providers. I think "comprehensive and understandable" says what we want. Basically, the package should preserved existing history content and add history relevant and useful to the user. Note that this is separate from other history info from the package (such as that needed to generate scripts from a GUI session like in the AIPS++ scripter) which is the subject of a Bryan Butler item which I added as 1.2-R3.<<< OL-3.1-R14ff: I would argue for separating usability issues such as "straightforward", "seamless" or "simple and robust" from all targets following OL-3.1-R14 from the underlying functional requirement (e.g. baseline subtraction), as discussed above. >>>SMyers: In this case, make subreqs. Promote in list, as some subreqs are P1 now. Did I go overboard here on subreqs? I dunno, merging of data is likely to be important in ALMA processing.<<< OL-3.1-R14.1: Which boolean operations are envisaged here ? >>>SMyers: we had meant "file1 & file2 & file 3" for example (union of files), but the "Boolean operations" is now deprecated and this subreq was removed.<<< OL-3.2-R1 and R1.1: These requirements would be improved by enumerating the data formats which should be supported in the base package. These may be augmented over time as enhancement requests but the initial set could be chosen now with some accuracy. >>>SMyers: Make as subreqs. I will need some help on this, I currently list only the ALMA Archive Data Format, and refer to a list of others.<<< OL-3.2-R2: My comments here follow OL-3.2-R1 in terms of enumeration. >>>SMyers: I currently leave this as a tbd project item. Computer types will have to provide me a comprehensive list if we are to include it here.<<< OL-3.3-R1: This requirement is implicit in OL-1.1-R4. OL-3.3-R2: This requirement is implicit in OL-1.2-R2. >>>SMyers: True. Remove 3.3-R1 and R2, move R3 to 3.2 (no more I/O section)<<< OL-3.4-R2 & 3: OL-3.5-R2: "must be handled" requires elaboration. >>>SMyers: These items were included in 3.1 items. At this point, the requirement is that the relevant data (e.g. autocorrelations) be read in, the use is specified in imaging for example.<<< OL-3.6-R2: I would argue for enumerated types here, rather than examples, for costing and compliance. >>>SMyers: OK, break types into more subreqs. Note, by disks do we mean circular disks on-sky, or projected spheres, or like protostellar disks? I think we mean the former.<<< OL-3.7-R2: Is this requirement targeted at images or data from which images could be produced ? Greater specificity here in terms of enumerated foreign formats would help to assess compliance and costing. >>>SMyers: We might be able to list some formats now, but this really depends on what standards groups like NVO develop. An archive expert might know more.<<< OL-4.1-R6: "User-definable setups" requires elaboration. >>>SMyers: I don't know what was meant by this - delete. At least it should appear as a subreq item if someone wants it back.<<< OL-4.5-R1.1: "in the absence of an internal data scan-descriptor object" requires elaboration. >>>SMyers: huh? It means when there isn't a scan description, like list of pointing centers, included in the data the user can input one! Is the meaning that unclear? Bryan had problems with this one too. Sheesh. I'll just delete the "in the absence stuff" as I guess thats extraneous. Actually, the main R1 is already in 3.1-R2, so make R1.1 a req and move it to a P3 spot.<<< OL-4.6-R2: "processable and dealt with appropriately" requires elaboration. >>>SMyers: Rephrase to say "Calibration and corrections based on pointing, focus, and subrefector status information shall be available."<<< OL-4.6-R4: Given the scope of engineering data, these cases should be enumerated and made specific. >>>SMyers: It is possible that the project can enumerate these at some later time when these are known BUT NOT HERE. Given that this is P3, I think we can be a little flexible.<<< 2.5.1: I would argue against non-quantifiable criteria here such as "user-friendly, efficient and flexible", which are difficult to assess. >>>SMyers: Well, I can easily assess AIPS++ as it stands as user-unfriendly, inefficient (with some exceptions) but very flexible ;-) Besides, this is not in a requirement but in the flavor-text header to the section.<<< OL-5.1-R1: The export formats should be enumerated. >>>SMyers: Do we wish to have an inclusive list here or tbd?<<< OL-5.2-R7.1: These should be enumerated. >>>SMyers: rephrase into subreqs. Im not sure my new version is right though. Actually, remove in favor of 5.3-R2 below, and save some subreqs as new 5.3 reqs if needed.<<< OL-5.3-R1.1: The ACA implications should be elaborated. >>>SMyers: ACA is now descoped, but we should keep a placeholder here.<<< OL-5.3-R2: "Careful" merits elaboration. >>>SMyers: actually this is a repeat of 5.2-R7.1, keep here<<< OL-5.3-R3: This has to be more specific, both in terms of problems and solutions. >>>SMyers: this is outside the scope of this document, but could be forwarded to Imaging & Calibration as an exercise. This may, however, be an already solved problem (e.g. ATCA) but the package developers should still make it work.<<< OL-6.1-R4: The line parameters should be enumerated. >>>SMyers: I suppose this is a well-studied issue and thus can be listed here. Make a first cut. Actually, line fitting seems like an important enough item to make its own section (new 2.6.2).<<< OL-6.1-R5.1: What range of catalog formats are envisaged here ? >>>SMyers: I would say just ASCII table and the ALMA format should be required.<<< OL-6.2-R3: Image feature types should be enumerated. >>>SMyers: this req overlaps with 6.2-R8 operations, keep this req for the reporting of results. Add one before R3 for definition of regions.<<< OL-6.2-R7.3: Blanking parameterization types should be enumerated. >>>SMyers: this depends on the implementation of the blanking, and thus need not be enumerated here<<< OL-6.2-R8: These operations should be enumerated. >>>SMyers: there are already 14 enumerated operations - I guess I could enumerate further using subsubrequirements. Is this really necessary? Sigh. Go ahead and break into subsubreqs.<<< OL-6.2-R9.1: There need to be enumerated. Sophisticated astrophysical modeling could easily be envisaged which would fall into this category especially for multi-transition ALMA line data. >>>SMyers: have subsumed these into long lists in R8. Removed rest of R9 as R9.2 was same as 6.1-R4 and R9.3 was same as 5.1-R7.<<< OL-7.2-R8: "etc" needs to be expanded. >>>SMyers: this is sufficiently unclear that I have removed it<<< 2.8.3 & 4: Could be large amounts of work, depending on scope. >>>SMyers: indeed, thats why we need to specify these (authors?)<<< ------------------------------------------------------------------------------- From: "Arnold Benz" Sent: Thursday, January 31, 2002 11:21 AM Subject: Re: ALMA Off-line requirements review (Deadline: January 22) Dear Gianni and Brian, I am sorry it took so long to answer. I have now read the new version and have the following small comments: Page 7, OL-1.2-R3: complement "bug-fixing" with "bug-fixing and improvements in user-friendliness" >>>SMyers: this is covered under R4.<<< Page 31, 2.8.3 Solar Observing: For the time being, I consider the following rather trivial details to require as necessary for solar and planetary observations: "Solar and planetary observations require a special effort in tracking, considering the spatial resolution of ALMA: - the sources move in the sky relative to stars - the parallax relative to Earth center is considerable and variable - in addition to motion there is also rotation to be accounted for. In the case of the Sun the rotation amounts up to 3 mas/second." It seems that these requirements are not exceedingly demanding. More may appear, the more we think about it. I think the ALMA Software Team will eventually have to include a solar person. He/she will be the first person to use ALMA for the Sun. That may be incentive enough to find a good person. >>>SMyers: incorporate into Solar System Object section<<< Best regards, ------------------------------------------------------------------------------- Date: Wed, 30 Jan 2002 17:33:31 -0500 From: awootten@cv3.cv.nrao.edu Subject: Notes on offline analysis Al provided his notes and an annotated markup of the draft in .pdf form. My translation of the substantial items: p.11 2.5-R3 add "searchable" >>>SMyers: covered under R5<<< p.15 3.3-R1 boldface >>>SMyers: done<<< p.24 6.1-R4 constrained fits (e.g. frequency separation of multi-component) >>>SMyers: add<<< p.26 6.2-R9.1 add optical depth from multiplet ratios >>>SMyers: add<<< p.31 8.3 Solar Observing (Tim Bastian or Arnold Benz) >>>SMyers: see Benz's comments, I sent a request to Bastian in December but no reply. Bryan Butler gave extensive comments on solar system objects. <<< p.31 8.4 Pulsar Observing (Ingrid Stairs) >>>SMyers: good idea. I will ask her on the next draft.<<< ------------------------------------------------------------------------------- Bryan Butler - provided a marked-up hardcopy of the draft: ============ This was on a scribbled markup of a hardcopy, and was very difficult to go through. Bryan owes me a beer or something :-) I will list the significant items below. I have made a number of minor corrections based on Bryan's markup which I do not list here, and also many of Bryan's comments were addressed by other reviewers which I sometimes do not mention below. I also used going through Bryan's list as an excuse for making changes suggested by others, and will note those here. General comments: Lots of things are duplicated. Trimming these would save space and improve clarity. >>>SMyers: there are instances where more general requirements are repeated with more detail later on. I will try to trim those where no new substance is added in the repeat.<<< This read alot more like a wish list than specs. Many of the items cannot (realistically) be turned into a meaningful constraint (or selection criterion) on the Package. >>>SMyers: This is indeed more of a wish list, since these are the things that we wish to be in the Offline Package. We are not pretending to give specifications for something that must be designed from scratch. As for the non-specificity of certain items, I think that the qualitative criteria are as useful as the more quantitative specifications, as they express the feel of what we want for the package. True, these will be harder for the lawyers to check off compliance with, but we decided some time ago that this document would not be for lawyers, but for scientifically literate programmers (or programming literate astronomers).<<< I see no spec on velocity frames supported (LSR, heliocentric, geocentric) >>>SMyers: I guess we need it somewhere, but where? I would imagine that there needs to be something in Data, Imaging, and Analysis under the current scheme, though this is a case where we would just be repeating. Maybe we should have a section under OL-1 for "overarching" requirements. For now I will add one in OL-3.1 please look these over, currently only heliocentric, geocentric and LSR are enumerated.<<< Bryan seems to object to the boilerplate italicized headers to certain sections as being self-evident and "motherhood and apple-pie" >>>SMyers: I like these as they say what we are thinking when we write the requirements. But remember they are not meant as requirements themselves. Is that too unclear? I will add item in the Nomenclature section after G to say this.<<< 1.1 add "archive user" to list of users in par 3. >>>SMyers: done<<< OL-1.1-R3 how easily? if you don't say it, its not really a spec since all packages will meet it no matter how hard it is to install >>>SMyers: Ease of installation is under OL-1.2-R1. This spec is meant to require that the package be installabe at the home institution AT ALL. One could envision a package that runs only on a cluster at the Data Center and the users must access it remotely. None of the current contenders would fit this so indeed its an easy one to pass.<<< OL-1.2-R6,R7 Bryan objects to the allowed use of proprietary or commercial code that is not open, and the possibility that not all source code be available. >>>SMyers: we had discussed this extensively in the SSR meetings. It was decided that we should not prevent the Package designers from using these components merely to have everything open source. The compromise is that these components would probably be in special non-astronomical areas, like the details of Pixons, and so the astronomical code should be open.<<< add OL-2.4-R6 Inputs to a particular task (application? tool?) shall be saved and recallable. The state of the package can be saved and recalled. >>>SMyers: There is now session logging as an item in OL-1.2, but I think this item is useful here also, as it pertains to parameter values for tools. Add after OL-2.4-R5, but keep it P2. Im not sure saved and recalled is necessary (a la TPUT/TGET and SAVE/GET in AIPS), but may be a desirable option.<<< OL-3.1-R2.10,2.11 list all items, do not use etc. >>>SMyers: break these out as subsubreqs<<< OL-3.1-R10 add "and executable by the UI" >>>SMyers: that is actually a different item for session logging, which is missing from either the Ops or UI sections. Add as 1.2-R3.<<< OL-3.1-R14 Merging (concatenation implies only 1 type of merge) >>>SMyers: list merging subreqs<<< OL-3.2-R1.1 Why is this needed? >>>SMyers: True, why should we support lots of formats beyond our standard. Demote to P3, since it would be beneficial if the package supported more than one format.<<< OL-3.2-R2 I would scrap this >>>SMyers: I think it is necessary (though realistically, the packages already do this) to support a resonable choice of tape media. Or is this a driver issue for the OS?<<< OL-3.3-R1 The Package may have no control over this >>>SMyers: has been scrapped, as it was covered in earlier req<<< OL-3.4-R2,3 already in OL-3.1-R2.5? >>>SMyers: yes, delete<<< OL-3.5-R1 should be in 3.1-R2 also? >>>SMyers: yes, done<<< OL-3.5-R2 already in 3.4-R2 and 3.1-R2.5 >>>SMyers: yes, delete<<< OL-3.6-R1.1-1.4 why not just put these into 1 as >4D images? >>>SMyers: at this point we are interested in the specific items, though could generalize here I guess. Keep as is.<<< OL-3.7-R1 "standard data exchange format" -> ALMA raw, or FITS >>>SMyers: make these the ALMA archive and supported formats. I also demoted the Foreign Data reqs to P2, in the spirit of the intention of the priority scheme.<<< OL-4.1-R1 priority? >>>SMyers: P1<<< OL-4.1-R3 and other calibration, RFI, Tsys data. Any others? >>>SMyers: probably should emumerate these. Make subreqs. People should check my list for completeness.<<< OL-4.1-R6.5, R7.1, R7.2 duplication >>>SMyers: R6 is for interactive, R7 is for automatic. R7.2 does duplicate R7.1 (delete 7.2). Should the items in 6.5 and 7.1 be enumerated separately? Will bite the bullet and enumerate in subsubreqs items in4.1-R6.1, 6.5, 7.1, 7.3, 7.4. Also reduce R7 to allowing automated editing based on all critera available in R6.<<< OL-4.2-R1 add data from tipping radiometers at P2 >>>SMyers: yes, and from site test interferometers<<< OL-4.3-R2 much of this is discussion, not specs >>>SMyers: move to italicized header to section, make 4.3-R1,R2 as specs that these be available, and split out enumerated items as subreqs<<< OL-4.5-R1 already in 3.1-R2, scrap R1.1 >>>SMyers: indeed R1 is a repeat of 3.1-R2 so delete. Promote R1.1 to R1 but demote to P3 (as R3)<<< OL-4.5-R3,4 combine into R1 >>>SMyers: keep separate, as they are different priority (instead of making these subreqs)<<< OL-5.1-R2 isnt this covered in R1 (and implied in 3.1-R14)? promote R2.1 to R2 >>>SMyers: done, though remove reference to Booleans, but as it is P2 it moves down the list<<< OL-5.1-R4.3 list flavors Hogbom, Clark, Cotton-Schwab >>>SMyers: done<<< OL-5.1-R4.5 include WIPE >>>SMyers: what is that?<<< OL-5.1-R4.9 why just Gaussian and disk? can be many more >>>SMyers: list point, Gaussian, disk. Are there more?<<< OL-5.1-R??? also full linear deconvolution which is just a special kind of inverse filter as I understand it >>>SMyers: I guess in some cases you can divide by transform of the PSF, as in Wiener filtering - if someone knows more about this and thinks it should be included, let me know.<<< OL-5.2-R7.1 why do you need a variety of options for beam correction? >>>SMyers: R7 removed to 5.3-R2 which was a duplication, see comment on Athol's comments.<<< OL-5.2-R8 shouldn't 5.2-R4 be a subset of this? >>>SMyers: 5.2-R4 is targeted toward multi-field and the FFT/DFT parts pertain to model subtraction. R8 is for the imaging part e.g. Fourier inversion using DFT. Is this too unclear?<<< OL-5.2-R9 I don't understand this - what is it you wanted here? >>>SMyers: I don't either. Deleted - see comments to Wim<<< OL-5.3-R1,R2 are not these duplicates? >>>SMyers: I don't see where they are duplicated in detail<<< OL-5.3-R2.2 I wouldn't spec this as being distributed with the Package but rather just that the Package must be able to import them, as in R2.3 >>>SMyers: I think we want the beams to be integral to the Package and built in to the distribution (like gain curves in tst AIPS)<<< OL-5.3-R3,R4,R5 duplicate >>>SMyers: R3 can be assumed under R1 (delete R3). R4 and R5 pertain to image-plane combination rather than uv-plane or joint imaging. I don't know enough about this to decide what to do, I think this needs some work (maybe R1 should enumerate uv-plane and image-plane and any other ways of handling this) and I need some help on it.<<< OL-5.3-R6 what is a stamp map? >>>SMyers: This is actually an analysis or visualization spec and is duplicated as R7.5-R8. Delete<<< OL-7.5-R8 what is a stamp map? >>>SMyers: we really need a better term for this, which refers to the little thumbnail spectra I vs. v placed at grid cells in RA, Dec.<<< OL-6.1-R2 what does this mean? >>>SMyers: is there a problem here? suggested rephrasing?<<< OL-6.1-R3 remove modifiers >>>SMyers: I guess we can assume when we ask for something one can assume that it be effective, robust and precise and not crappy.<<< OL-6.1-R3.1 do you need to more fully describe this? >>>SMyers: I think this one is OK (basically, just removal of Fourier modes instead of polynomials). I will add poly fits as a subreq. Is there anything else to add here? This does overlap with 5.2-R5 and 6.2-R8.9 in particular. Can we just delete this one (Im keeping it for now, but adding Fourier modes to 6.2-R8.9)?<<< OL-6.1-R4 "and are to be stored in a text format" why do we care as long as the user can access this? >>>SMyers: this req is now its own section, see comments to Athol<<< OL-6.1-R6 "shall be straightforward" is squishy >>>SMyers: just say "shall be available"<<< OL-6.2-R1 duplicate >>>SMyers: more to the point, the axes types should be enumerated. Check to see if I missed something. Note R1.1 is duplicated in R8 and movies are for visualization 7.5-R5, so delete.<<< OL-6.2-R3 "easy, accurate" squishy >>>SMyers: say "available, and interactive (where...)", put exportable in subreq<<< OL-6.2-R4.4 not clear to me that this should be supported. Maybe "SQL-like" should be "database" >>>SMyers: thats why its P3. make "database (e.g. SQL)"<<< OL-6.2-R8.10 smoothing, convolution, and filtering are all essentially the same thing, right? >>>SMyers: yes, but I'm not sure we would gain anything by lumping all togther now that its a set of enumerated lists, but if there is a strong opinion I can do so.<<< OL-6.2-R8.14 given this, isn't 6.2-R8.6 unnecessary? >>>SMyers: yes, except 8.14 is P3 while 8.6 is P1<<< OL-6.2-R9 its not clear to me that the Package need be required to do these things >>>SMyers: these were duplicates or moved into R8. Now gone.<<< OL-7.1-R2 what about good old X-Y plots? >>>SMyers: oops<<< OL-7.1-R3 why spec this? seems beyond our scope >>>SMyers: huh? why? its seems relatively straightforward, e.g. an X-Y plot with color denoting polarized flux. But drop to P2 (or P3?).<<< OL-7.1-R5.2 "gif" is totally proprietary and we can't spec this >>>SMyers: I don't know the details of this, if so then remove (though we have room to request proprietary things also). Note that this is P3. Do we want an enumerated list here?<<< OL-7.1-R7 duplicate >>>SMyers: yes, this is 4.1-R10. removed 7.1-R7 in favor of the one in the editing section<<< OL-7.2-R1,R2 "fast", "fast and intuitive" are squishy >>>SMyers: the intent of the benchmark is that the speed has to be some reasonable value. Split off interface speed to another req R3, need comments on this new one.<<< OL-7.2-R3 lots of squishy stuff "easily" "appropriate" >>>SMyers: remove offending words<<< OL-7.2-R5.7 what does this mean >>>SMyers: I don't know. Remove.<<< OL-7.2-R6 you can't spec this as part of the package, it depends on the physical hardcopy device >>>SMyers: the intent is that the quality of the drawing not the hardcopy is the important bit. Though these days even pgplot is fine. I am removing this req as it is virtually assured by R7.<<< OL-7.2-R8 not clear you can spec this sensibly >>>SMyers: agreed, deleted. See comments to Athol<<< OL-7.3-R1 why not just spec that you can plot any one versus another and then enumerate the BPARM(1) and BPARM(2) options to UVPLT >>>SMyers: agreed, it is better to list the quantities. Someone should check this.<<< OL-7.3-R3 isnt this just a special case of R1? >>>SMyers: delete<<< OL-7.4 all duplicated >>>SMyers: I don't see where this is duplicated, except it is asked to handle these quantities in calibration. Do we assume that if you can handle it during it you can plot it here? I dont think so.<<< OL-7.5 all duplicated, aren't they? >>>SMyers: This does have some overlap with the Data Analysis OL-6.2, but if we want a visualization section, then they have to be here. No suggestions for rewording were given, so I will wait until concrete suggestions are given. <<< OL-2.8.5 Solar System Observing ... >>>SMyers: Bryan did give some suggested items, which I have put in. Check these for completeness.<<< ------------------------------------------------------------------------------- Crystal Brogan - provided a marked-up hardcopy of the draft: ============== My translation of the substantial items: p.13 3.1-R2 Should be some equivalent of PRTAN and LISTR >>>SMyers: Make a P2 3.1-Rx item for the easy access to header info, scan summaries, etc.<<< p.13 3.1-R3 Qualifiers? >>>SMyers: Add item for user-specified qualifiers etc.<<< p.13 3.1-R8 transfer of a flagging mask to another dataset >>>SMyers: I assume you are thinking in terms of a continuum mask transfering to a line set from the same data. Add something to this effect.<<< p.17 4.1 Calibration - calibration should be scan-based >>>SMyers: add after 4.1-R2<<< p.17 4.1-R6.1 add elevation >>>SMyers: done<<< p.22 5.1 Imaging - add interactive boxing for IMAGR emulation >>>SMyers: add item after 5.1-R4<<< p.28 7.2 Display appearance - not just overlays but multiple image displays with synchronization, for spectral lines plots not just "images" >>>SMyers: add item after 7.2-R5<<< p.29 7.3-R1 add amplitude vs. elevation >>>SMyers: add item after 7.3-R1.7<<< -------------------------------------------------------------------------------