I -- REVIEW CALL =============================================================================== SOFTWARE DOCUMENTATION REVIEW PROCEDURE - REVIEW CALL =============================================================================== Date : 2000-04-07 Document : ALMA Software Requirements: Preliminary Report Author(s): Robert Lucas etc. Invited reviewers: (dc) Dick Crutcher (UIUC) no response (bg) Brian Glendenning (NRAO) comment list (sg) Stephane Guilloteau (IRAM) no written comments (stm) Steve Myers (NRAO) comment list (gr) Gianni Raffi (ESO - Meeting Chair) comment list (lt) Leonardo Testi (Arcetri) comment list (rt) Remo Tilanus (JCMT) comment list (dw) David Wilner (NRAO) comment list (aw) Al Wootten (NRAO) no written comments (kim) Koh-Ichiro Morita comment list Other comments provided by Ron Heald (NRAO, rh). Authors attending the review meeting: Robert Lucas (IRAM) Steve Scott (OVRO) =============================================================================== The above document may be found at the following URL. http://www.alma.nrao.edu/memos/html-memos/abstracts/abs293.html Please send your comments directly to the author, lucas@iram.fr. All are invited to send comments, not just reviewers. Reviewers are *expected* to send comments. All comments, with disposition, will be recorded in a report. Written comments deadline: 2000-04-21 Review meeting: By phone, proposed 2000-05-04 Thursday (to avoid conflicts with travels related to Paris meeting- otherwise week after) Please confirm your attendance (graffi@eso.org) at the Telecon review on the foreseen day. Date, time (normally 5.30 pm CET, 8.30 MST) and Telecon phone number will be confirmed later. Foreseen time 2 hours. _____oOo_____ =============================================================================== COMMENT LIST, UPDATED AFTER THE REVIEW (2000-05-05). =============================================================================== GENERAL COMMENTS ---------------- Note: Some dummy comment numbers were introduced when producing this ordered list, please ignore the jumps between some numbers. ---003-------------------------------------------------------------------------- (bg) -Are there any general remarks the committee wants to make about what a reasonable amount of unplanned down time due to software is? -Does the SSR want to say anything about data rates, dump times, etc? REPLY: - We do not plan to discuss the first item at this point. The required reliability of ALMA software looks more like an overall project requirement. - second item: Yes, we will include a citation of the data rates required: 3MB/sec averaged on long times, 30MB/sec peak and sustained rate. ---005-------------------------------------------------------------------------- (dw) Attached are a few comments on ALMA memo #293, Software Requirements. I will provide more comments at the upcoming telecon. It certainly won't be easy to translate these abstract requirements into working software. This document outlines an ambitious plan for preliminary ALMA software requirements. The level of detail is uneven. I think that two overall points, implicit throughout the descriptions of the many components, could be stated more clearly at the outset: o Ensure consistency among the various parts of the system from the start of development (at least from the user point of view). o Implement each part of the system independently, to the extent possible; make sure the slowest elements do not set the pace. REPLY: We'll cite these points in the Introduction. ---006-------------------------------------------------------------------------- (gr) General comments: It is good to have a first set of Science Software Requirements. I would propose to consider this document as Version 1, even if no Use Cases could be done yet. 1) The next logical step for me will be to go for a precise list of enumerated requirements. It is probably better to go for this after review of the present document by the Science Team, so that they have a chance to interact early enough. 2) There is a need to come to scenarios (Use Cases). I would propose that this work is done in parallel with the requirements enumeration to accelerate the whole process and to better elaborate in a complete way the requirements. This would lead to Version 2 of the Science Software Requirements. Detailed comments: Title: I would propose that the word "Science" appears in the Title, to clearly mark these requirements as different from other categories of requirements for the ALMA software. REPLY: These points are clearly in our plan for the next few months. The title will be modified to include the word "Science". ---008-------------------------------------------------------------------------- (lt) There are four main points that, I think, need to be defined in the Software Requirements and a few minor things I was confused about. Of course, I mostly have a "user" approach so is the "interface to the user" section that most of the comments below are concerned about. 1) Observations Feedback. The _needed_ feedback from ALMA to the PI should be better specified. In my opinion after each Observing Block (OB) has been executed the system should send an immediate feedback to the PI concerning: a) what has been observed, b) the quality of the OB that has been executed (operator log, VLA-like, plus weather and general quality control data as offered e.g. by IRAM and OVRO). c) a short summary of all OBs executed to date (with quality flag and a sort of archive pointer), I am thinking to something very short like 1 ASCII line per executed OB with identification, quality, pointer in the archive, and d) status of missing OBs (i.e. projected observability, priority, etc...) or a clear statement that the observations for the project are complete and the exact date when the observations will become public. For point d) the "projected observability" in my mind means an estimate of the likely time at which the missing observations could be performed. For example, if a project is requiring a set of configurations, and data is still missing for a configuration that will not be available before one year, the PI should be advised that his project will not be completed before the array is reconfigured to that configuration. Note that at this point is unclear the policy of public data: will data become public after 1 year they have been obtained or all the data will become available 1 year after the PROJECT is complete?? 2) Proprietary Data & Security. This is a problem that we have discussed several times within the OVRO group in the past: sometimes observational data contain proprietary informations. For example, if somebody is observing CO(7-6) from his/her secret quasar for which he/she has obtained (but not yet published) an infrared spectrum (and thus z), anybody could eavesdrop array monitor information containing position on the sky and observing redshift during observations. Personally, I am not particularly sensitive to this problem, but many astronomers are. The same applies for the archive during the "proprietary period", unless only very limited informations are offered to whoever is consulting the archive and is not the PI of that project. A possible solution could be to protect the information via username/password defined during P2PP and removed at the end of the "proprietary period" (to be defined... see above). 3) Need for a strict standard in P1PP. I think that a strict standard in the proposal preparation is required to help management and proposal review. I completely disagree with what it is stated on # page 12 sect 3.1 fourth bullet from bottom. There are two possible solution in my opinion (but I am not sure about the technicalities): a) Strict LaTeX form (as adopted by ESO) b) Strict Web form (that has the advantage that can be accessed by everybody using any system) In particular, I do not see any reason to have a non-"computer parsable" thing at all. In my opinion we should have an electronic NOT paper archive for the proposals. Proposal submission should be ONLY electronic Al (via web form), then a electronic proposal should be made available to the time allocation committee members for evaluation. The goal must be to avoid sending paper around the world, which is expensive, useless and highly anti-ecologic, both in the direction PI => ALMA and in the direction ALMA => Time Allocation Committee. People should be free to use any text editor to write the proposal, but the text MUST go into a well defined standard (e.g. a web-form box that counts the characters used, this will avoid somebody using 7pt fonts and write an equivalent 12pt characters 10-pages Scientific Justification that nobody wants to read). 4) Scheduling and Schedule Files. Many of the details about scheduling and # P2PP requirements depend strongly on the philosophy that we will finally adopt for the array configurations (zooming array/fixed configs). In the case of the zooming array, the dynamic scheduler will have to balance: i) ambient (weather+instrument) conditions, ii) projects priorities, and iii) range of allowed array "positions" for scheduling. In fact, cfr. page 3 par 3 and 6 and section 4, the dynamic scheduler must be able to acquire not only weather, but also instrumental conditions (configuration or zoom position, receiver status, correlator status etc...) that have to be compared with the project requirements to decide whether a project can be scheduled or not in the current situation. Suppose e.g. that only 20 Ants are equipped with a particular receiver, and 10 of them are not available at a given time for a variety of reasons (maintenance, moving, baseline calibration, whatever...), then a project requiring that frequency band should not be scheduled even if weather would be favorable. Finally, since there is a top requirement to avoid observation duplications, page 12 third bullet from bottom (which I do not subscribe completely, by the way), allowing the user to change the observation strategy may create a lot of confusion: suppose that I propose to observe C34S(2-1) toward source A, I start observing and after the first few OBs I do not see anything, a logic approach may be to try for the more abundant isotopomer for the following OBs. If I then modify the schedule after P1PP and P2PP, I may perform an observation that was already performed (e.g. CS(2-1) toward source A), or that the time allocation committee would have not approved. In my opinion to "change the mosaic pattern or frequency band" one should require director's approval. REPLY: 1) We plan to have an e-mail sent after each Observation Block is executed; points c) and d) are not immediately necessary. One possibility would be to have a programming interface in the Observing Tool to define the contents of these messages. 2) The data itself will be password protected during the propriety period. For other parameters we plan to ask the ASAC to formulate the exact policy to be applied. In general we prefer to keep the system open for the sake of simplicity. 3) This is a misunderstanding; the requirement for the scientific justification is to be electronic and printable. The technical parameters will be entered through a provided Observing Tool and thus will be available to ALMA computers. 4) The breakpoints are proposed to optimize the scientific return by keeping some interactivity between the user and his/her observations. It is clear that the options to be taken by the user at the breakpoint must be chosen among a few which must have been described in the proposal too -- and thus were also available for reviewing, and for checking for conflicts. ---009-------------------------------------------------------------------------- (rh) I have been attempting to detail the software requirements for the ALMA antenna mount movement. I have found there are many areas that are not discussed in the SSR. I will try to relate these along with a few questions. 1. What are the software requirements while the antenna is on the transporter? Should you be able to connect a terminal (or laptop) and have the system do something? Will the antenna have a normal network connection in the maintenance barn and therefore be fully functional? 2. The antenna motion must have the capability of performing what I've been calling a "pattern". An example pattern is the raster scan that is applied on top of the target tracking during OTF observing. In addition to a raster I've had a spiral, circle, and rotating bow-tie requested. Are all these needed? Are there others? How is a pattern specified? Is velocity or time given? 3. What coordinate systems can be used to specify a target position and pattern? 4. Observers will need source catalogs and ephemerides available at the instrument. Which ones are needed, and can they be accesses from the Web or do they need to be locally cached? Should we invent our own ephemeris format or can we use one from JPL, BDL, etc.? 5. Normally all antennas in a sub-array move in unison. Now I've been told that for certain observing modes it is important that antennas within a sub-array be able to move together but in different orders. Can you verify and elaborate on this? 6. It has been suggested that the interferometer model software be used to point the antenna since the azimuth and elevation positions for each antenna are a byproduct of this software. Is this a good idea? Which software package will be used? 7. A complete list of the specific pointing corrections to be applied is needed. 8. How often should position data be collected during OTF observing? 9. Often it is useful to view a monitor point over a period of time. Is it necessary to maintain a long record of monitor point values so a user can immediately view them, or it is sufficient to begin recording only when requested by a user? The latter system eliminates much complexity and has been successfully used at OVRO. 10. A "virtual oscillator" capability has been discussed for diagnosing problems. For this a monitor point is sampled at a high rate with the results displayed with a time axis. Is this a useful function? Is it a requirement? REPLY: For each item: 1) is not a scientific requirement 2) We plan to require a few simple patterns (straight line, arc of circle at uniform speed) plus a way of specifying an arbitrary pattern by a list of positions and time offsets. 3) Equatorial J2000 and Local (Az,El) will be basic, other system will be available at a higher level (by conversion into these two systems). 4) The ephemeris should be available locally, so that the observations are not interrupted by a network failure; we will not invent new formats. 5) We require the `patterns' to be different from antenna to antenna for some applications (e.g. pointing/focus measurements). 6) The actual software is an implementation decision. It seems logical not to duplicate the computation of astronomical coordinates. 7) We'll provide it in the next version of this document. 8) We need a position associated with each integration. This may need interpolation between encoder readings in fast total-power OTF. This is probably not a limitation since pointing errors will probably be larger than tracking errors. 9, 10) A "Virtual Oscilloscope" will actually be a very useful engineering, but not strictly scientific, requirement. X vs Y may also be as useful as X vs T. ---010-------------------------------------------------------------------------- (rt) To start, I enjoyed reading the preliminary report for the ALMA software requirements. Lots of interesting and inspiring ideas have been presented and the outline is shaping up fine. The authors are to be commended for their efforts in attempting to tackle a rather daunting task. However, in the same breath I have to say that it is also clear that many of the ideas need maturing and need to gain focus. The wealth of ideas still needs to develop into a single, coherent plan, something which is necessary before the definitive document can be produced. This will be a challenging, but important next step. There are two general areas which need special attention. Firstly, some of the ideas themselves need to be carefully thought through and fine-tuned. At various points I came away with the impression that while the general idea was sound, the specific plan was chaotic and not well defined. I think this is one example of where the timetable is a problem. Secondly, the document left me with the impression that there is not yet a clear, overall, all-encompassing view of the requirements and the design. This is probably only natural to the current state of development, as said, but is something which is needed before the next version of the document appears. The current outline still is too much a compilation of the individual contributions of the authors. In this context the focus needs to become sharper to distinguish what is 'needed' and what may eventually be 'wanted'. Clearly, current designs should allow for the latter, but effort should be expended only if available at a late stage. In my perception there is a real danger that these 'wanted' sexy targets, such as a really smart pipeline, will undermine and confuse the development of a solid foundation which will form the real basis for the long-term operation of the instrument. While some people may thrive on such existence in their personal lives, I don't think it is a good idea to allow this attitude to enter into the development of an expensive scientific instrument ;) Admitted, the the first paragraph of the document outlines the limitations of the current document and my comments should not be taken as criticism on it, but rather as a wish-list and suggestions for the next version. Not having been partial to all discussions and aware of issues taken on, I can only comment on what has been written in this memo. In the end I am forced to admit that with regards to dynamic scheduling and the pipeline, as well as the overall model of operation, my views seem to differ fundamentally from those outlined in the memo. I would have liked to have had more time to mull over these differences, but even now it already is past the deadline. Irrespective of the different opinions, I hope that my comments will be helpful in producing a superb software requirements document. Perhaps at some point there will be the opportunity to discuss the issues verbally. I have appreciated the opportunity to comment on the memo. REPLY: We appreciated your comments. We expect Version 2 of our requirements to be much more integrated and detailed. We have taken the decision to defer the relative priorities of our requirements to Version 2, while being quite conscious that this relativization will be needed. ---012-------------------------------------------------------------------------- (stm) Summary The document outlines the "science-driven software requirements of the ALMA project", and is intended as a broad review of the considerations that will drive the software design. As such it is necessarily vague in places, as it will be followed by a more detailed document. The memo seems reasonably complete, and I do not think there are any glaring omissions. On the other hand, much of the discussion is at the technical equivalent of "mom and apple-pie" (perhaps "mere et crepes" for the European half) emphasizing the general notions that are fairly obvious and everyone can agree on. However, it will be in the details where the success of this project will be made or not. Some hard choices will have to be made, and soon, and this document seems to skirt the issue(s), and as it stands this document does not indicate what these choices are likely to be and what are the implications (even in just a general sense) of the alternatives. There appear to be three critical issues to be decided before embarking on the coding: the adoption of dynamic scheduling as the predominant default observing mode (this has been hinted as, but come up short of actually saying this) with interactive observing reserved for those very few cases that require this; the scope of the integration of the proposal, scheduling, observing, monitor and control, pipeline analysis, post-processing, and archiving software and the extent to which these will be developed in a parallel manner using the same base code (and whether a whole new package needs to be developed, and the extent to which it can be based upon existing designs); and given the above, what will be the look and feel of the GUI and script-level interfaces to the package. One thing that should come out of this document, in addition to the obvious overall picture of the software system requirements, is an idea of what things need to be investigated next, who will do so, and what has been decided already. REPLY: See reply to 010. =============================================================================== SPECIFIC COMMENTS (Section 1- Introduction) ---014-------------------------------------------------------------------------- (rt) p. 3 (paragraph 7: ...best for submillimeter observations, it will only -not- be usable... drop: -not-) REPLY: Agreed, document will be corrected. ---015-------------------------------------------------------------------------- (lt) Page 4 first paragraph: I think that Bandpass, Fluxcal and Flux-monitoring should be included as standard calibration of the array. REPLY: Bandpass calibration depends on receiver tuning and is mostly project based; for projects requiring high amplitude precision, the project observations will need to include flux measurements as well. It is foreseen that the user will specify the accuracy needs of his/her project in the Observing Tool, and will be warned in return of the price to pay in overhead time and scheduling flexibility. =============================================================================== SPECIFIC COMMENTS (Section 2.2- Real Time Software/Command Language) ---017-------------------------------------------------------------------------- (bg) p.5 2.1 pt 4 a narrow -> the required REPLY: agreed - will be corrected ---018-------------------------------------------------------------------------- (bg) p.5 2.1 Observer control of sub-arrays is mentioned on page 7 - shouldn't it also be mentioned here? REPLY: We will add here a short of description sub-arrays, from the hardware and software points of view, and how they should be handled. ---019-------------------------------------------------------------------------- (bg) p.5 2.1 I find the meaning of the sentence that begins: "Selecting an antenna" to be unclear. REPLY: We'll try to clarify . The antenna resources will be allocated to observing sessions by the operator; on de-allocation a session may have to perform some calibration, if needed and feasible, before returning it to the operator for allocation to another --e.g. maintenance or calibration -- session. ---020-------------------------------------------------------------------------- (dw) p. 5 2.1 The ``interactive'' mode functions through a GUI and receives feedback from the pipeline, but otherwise it is unclear what distinguishes this mode from the ``manual'' mode. What motivates the distinction? REPLY: Only the fact that `interactive mode' goes through the GUI and is thus restricted to well supported modes. It is thus available to outside observers which have been allocated time for interactive observing of special projects, while the `manual mode' has access to the script level and is mostly restricted to staff for testing and development. We'll add a few words to explain this. ---021-------------------------------------------------------------------------- (dw) p. 5 2.2 A simple command language readable by humans would be a great benefit. But try not to invent an entirely new scripting language, if possible, as all of the desired functionality may be found in existing unix shells. REPLY: Yes. That's the consensus in the committee. ---022-------------------------------------------------------------------------- (gr) p.5 2.1 The basic operation modes Interactive mode vs. Dynamic scheduler. I tend to see the interactive mode as a subset of mode 4, with the dynamic scheduler.I believe in fact one should always foresee in mode 4 the possibility to interact. If this is agreed the only other difference would be where the input for the next observation comes from, a choice that can be also be left to the operator/user. REPLY: This is agreed. The software interfaces are the same. The difference is mainly operational. ---023-------------------------------------------------------------------------- (gr) p.5 2.1. The basic operation modes I would propose that one says explicitly that modes 1 and 2 are reserved to technical staff (operation and maintenance staff). I would like to point out that interactive mode when used by guest astronomers can be potentially very inefficient. I wonder therefore if one should not indicate that normally guest users will be assisted by resident staff in this mode and the next. This could well be be justified by the cost of the device one uses. REPLY: Yes. Dynamic Scheduling will be the default, normal mode of operation. ---024-------------------------------------------------------------------------- (gr) p.5 .. pass control to the dynamic scheduler. I would give a name to this mode as well. Is this queue scheduling ? According to my comment above, I would argue that queue scheduling allows the operator to interact any time he needs/wishes to. REPLY: This is not really another mode. It just means that the operator allocates resources to the various sessions (interactive or dynamically scheduled). ---025-------------------------------------------------------------------------- (kim) p. 5 2. Real-time system ** Timing and synchronization accuracy The issue of time-tagged vs real-time commanding would be solved by consideration of timing. We should estimate requested timing and synchronization accuracy in real-time system. ** Confirmation of instrumental action In real-time system, how to confirm every action of instruments is important and it should be included in the description of real-time system. REPLY: We regard the issue of time-tagged vs real-time commanding as a software implementation decision. ---026-------------------------------------------------------------------------- (rh) p. 5 Section 2.1: It seems you will want the technical interface simultaneously with the manual or interactive mode. For debugging, a technician will want to have a normal observing mode while changing the value of one or two control points. Is this true? How can the two modes be kept from interfering with one another? How can the system be restored to a known state? REPLY: The technical interface and the observing sessions cannot have simultaneous active control of the same resources (antennas, receivers). Monitoring will be possible, within some limits. ---027-------------------------------------------------------------------------- (rh) p. 5 Section 2.1: Is an antenna the smallest unit for assigning to a user and mode? REPLY: Yes. The question arises whether unused receiver bands can technically be available for maintenance while observing. ---028-------------------------------------------------------------------------- (rt) p. 5 I do not have a lot of expertise to contribute in this area. However, below are the points I flagged. * (2.1) Sub-arrays: it is not explicitly mentioned, but I think the idea is that 'sub-arrays' are to be dynamic. I.e. at any point without stopping the observations, antennas can be taken out of a configuration and be made a sub-array. Similarly, they can be merged into an ongoing observation as well, although flagged 'offline' until the next calibration cycle. This requirement is not only important for the science operation, but also for maintenance and troubleshooting. Realistically the array will never work with all of its antennas online, hence maintenance and checking must be possible without stopping the observations. REPLY: Yes; the antennas will be allocated to sub-arrays by operator (at the request of observing sessions). ---029-------------------------------------------------------------------------- (stm) p. 5 The four modes described (technical, manual, interactive, and dynamic) seem to encompass the desired range of operation. However the implications of having the primary operational mode be dynamic are not fully explored or even outlined. For example, it is unlikely that the exact composition and placement of antennas in the array will be known at schedule time, which will affect the way sub-arrays are allocated. REPLY: No. The antenna positions will be known at the time of scheduling, since the scheduling will be done in real-time. ---030-------------------------------------------------------------------------- (stm) p. 5 In section 2.1 on sub-arrays it is unclear which are the "higher-level modes", I presume that the technical has the highest priority. REPLY: Agreed. Higher level means higher complexity, but the priority goes the other way. ---031-------------------------------------------------------------------------- (stm) p. 5 In section 2.2, and throughout the document, the model presented for the control language is a standard keyword-value language (which essentially still emulates the old FORTH style of programming) similar to those used on most (if not all) existing radio and millimeter arrays as well as optical telescopes. However, I feel that it is highly likely that this type of language will prove inadequate for what we will be asking of it, especially given the proposed dynamic scheduling operation. In particular, the need to interface with the analysis pipeline as well as with the hardware control suggests that it be modeled on (or at be least highly compatible with) the analysis software. Although it is not specifically stated, it is a reasonable assumption that the system software will be constructed using an Object Oriented Programming language, either directly in C++ or in a higher level OOP language (eg. glish). Since the requirements on the functionality of the control language will be rather severe, it is likely that the OO nature of the base language will carry through to the user-level, and it is important to recognize this from the beginning. I will probably harp on this issue too much, but I think it is more important to have a clear grammar and flexible software system than it is to present a deceptively simplistic control language to the putative "user". It will of course be clear during the actual software development whether a simple keyword style language will be sufficient or whether a more complex but powerful C++ or Java style language grammar is required. Given the sophistication of most observers, it is counter-productive to "dumb" them down when specifying the design requirements. The discussion of sub-arrays implies that specific antennas are to be selected for allocation to the sub-arrays, yet is unlikely that the exact array configuration, or even which antennas are available, is unknown at the time of observer scheduling, and will thus have to be described in a manner appropriate for dynamic scheduling. This was discussed in a short memo (dated 3 March 2000) sent to the alma-ssr group, and can be found archived at http://www.aoc.nrao.edu/~smyers/alma/subarrays2.txt along with some discussion of language choices (eg. keyword script style vs. OOP style). I assert that the "sub-array" is the fundamental molecule of the observation (with the antennas and correlator setups forming the atoms) and as such will have to be described in a deterministic yet flexible manner. The main distinction between types of subarrays (from the user point as well as from the operational point) is whether they inherit the same (first) LO setup as another sub-array or need a separate first LO signal - these are the ones likely to be restricted to four total. What will happen if some subarrays are already in use for VLBI or other observations and the user needs one or more? This will have to be factored into the dynamic scheduling... REPLY: It is agreed by the whole software group that object oriented technology is chosen for ALMA software. However we feel is not particularly needed at the script language level, although it may be supported in the end if the chosen language supports it. This must not be at the expense of human readability of scripts. The sub-arrays presentation will be extended in section 2.1. ---032-------------------------------------------------------------------------- (bg) p.6 2.2 Is it required or desirable that the pipeline scripting language be the same as the observing language? REPLY: It is desirable but not required. ---033-------------------------------------------------------------------------- (dw) p. 6 2.2 The importance of easily defined macros and loops in the scripting language cannot be overemphasized. (Many headaches of current VLA observe files would be avoided if such structures were possible.) REPLY: Agreed. ---034-------------------------------------------------------------------------- (gr) p.6 2.2 Control command language .. sufficiently simple to be read by experts. experts or non-experts ? Do you mean by experts (in e.g. radio astronomy) but non experts in informatics. REPLY: expert astronomers was meant there: that is astronomers with a good knowledge of the array, not of the software. ---035-------------------------------------------------------------------------- (rt) p. 6 (3rd paragraph) * (2.2): "It is not a good use...output by his tool". While I understand the intention, this sentence is confusing. REPLY: We'll try to rewrite the sentence in a less confusing way. ---036-------------------------------------------------------------------------- (bg) p.7 2.2 For the sentence "(Operators would" - would operators normally run the tool or would it be run automatically. REPLY: The LO calculation and possibly implied choices will be made, preferably automatically, when an observing session is started. ---037-------------------------------------------------------------------------- (dw) p. 7 2.2 The limitations of the LOs for, e.g. specific observing dates for particular spectral line observations, should come out as warnings when the observations are designed by the astronomer. This type of restriction is not likely to be a major constraint for many observations given the planned flexibility of the correlator. A better goal is the sort of comment presented in 4.1.2 that states the restrictions of a proposed setup. REPLY: The LO calculation and possibly implied choices will be made, preferably automatically, when an observing session is started. Advance warnings will have been given to the observer when running the Observing Tool, with predicted ranges for the LOs, and eventual restrictions. ---038-------------------------------------------------------------------------- (dw) p. 7 2.2 I do not understand the point about ``a second layer of sub-arraying.'' What distinguishes this second level from the first level where different groups of antennas are performing different functions? REPLY: The LO subarrays will most likely appear as different sessions; inside a session some commands will operate only on some antennas when needed, this is what we mean here. ---039-------------------------------------------------------------------------- (gr) p.7 last par. .. second level of sub-arraying This effectively doubles the groups of subarrays. So if it was decided they were 4, there would be effectively up to 8 clusters of antennas.. and possibly 8 consoles to control/monitor them. In fact even if one single array (user) has two sub-arrays he will need to monitor his two sets of antennas. REPLY: There is no needed one-to-one correspondence between sub-arrays and consoles. ---040-------------------------------------------------------------------------- (kim) P. 7 ** Correlator control "Second, the flexibility of the correlator hardware will be somewhat restricted because utilizing the full flexibility of the correlator would be technically difficult, and lead to more complication in the real-time system than desirable. Thus, we recommend that options to support different bandwidths or spectral windowing in the two halves of a baseband pair (usually used for opposite polarizations at the same frequency) not be supported." Japanese community is proposing a FX type correlator for an enhanced ALMA project. This correlator is large but its structure is simple. So, I think there are no technical difficulties to support different bandwidths or spectral windowing in the two halves of a baseband pair. We should keep this option for scientific merit. REPLY: We'll give to the use of base-band pairs in a non-homogeneous correlator mode a very low priority. ---041-------------------------------------------------------------------------- (lt) Page 7, second bullet: Proper motion of the source must be included. REPLY: Yes this is agreed. ---042-------------------------------------------------------------------------- (rh) p7, second bullet Section 2.2 near the end: Can you explain the following? "It is suggested that all reasonable corrections be put into the real-time system so that milliarcsecond level astrometry can be done differentially, rather than by backing out the real-time system model." REPLY: We'll drop the end of that sentence (rather ...) which is confusing. ---043-------------------------------------------------------------------------- (rt) p. 7 first bullet *(2.2 Difficult decisions): - The first point about observation files being specific to the date is unacceptable in view of dynamic scheduling as is the requirement that the operator would run the setup in that case. I also wonder what this implies about spectral line observations. How specific has the date to be? To the day, to the second? Does that mean things will fall over if an error halts the observations for 10 minutes? For 'standard' observations (by definition 95% of the total), the real-time system should be capable of translating the astronomical requirements plus a 'general correlator setup' into a correlator setup specific for the date. The approach as proposed will become a serious handicap for the operation of ALMA!!! REPLY: We'll rewrite those lines, the correlator setup calculation will be done in real time, at beginning of the observing session, with advance warnings at observer's input. ---044-------------------------------------------------------------------------- (rt) p. 7 fourth bullet - On the fourth point about second-level sub-arraying: an ability to 'arbitrarily' sub-divide the array will be a major asset for ALMA. It is easily visualized that at many times there may be 5 sub-arrays in operation: 1) main observation program; 2) calibration subset in support of 1; 3) small number of antennas following a T.O.O. i.e. a GRB; 4) 1 or more antennas involved in maintenance measurements (antenna characterization, troubleshooting problems etc.); 5) antennas off for repair, but which still need control through the technical interface. Sub-arraying may thus not only be desirable but also essential for an efficient operation. At the same time, it seems to explode the complexity of the system. Assuming unlimited(!) technical flexibility, sub-arraying argues for a very modular approach where each array effectively becomes a completely independent telescope, running under its own thread of the control task. Communications between sub-arrays i.e. picking up tipping curves should follow the same protocol as for any other 'supporting' piece of hardware (e.g. the weather station), albeit this one available only part-time. Of course, there are limiting technical factors e.g. the number of independent LO signals that can be generated and send to the antennas or the sub-divisions and capacity of the correlator. Technical limitations provide a drive away from modularity and towards a more monolithic approach. I think sub-arraying is a very important issue to study in-depth because it appears to be a major driver for a very fundamental level of design of the control system. It deserves more attention than it has been given in the memo, but maybe not at this stage (although postponing it to later makes me quite nervous). REPLY: We'll reinforce the paragraph about sub-arrays (sect. 2.1), trying to emphasize the points you mention here, plus other questions like the effect of having several subarrays in dynamic scheduling mode. =============================================================================== SPECIFIC COMMENTS (Section 2.3- Real Time Software/Graphical User Interface) ---046-------------------------------------------------------------------------- (bg) p.8 2.3 Do GUI tools generate scripts or perform run-time calls to some API? At present the requirement is that it will do "either", which isn't a requirement! REPLY: We'll precise this point: we agreed that : - it should be possible to generate a script from the GUI, - that the script when executed should give the same result the executing the GUI, - but the way this is achieved is an implementation choice. ---047-------------------------------------------------------------------------- (bg) p.8 2.3 Is it a goal that the correlator GUI should rarely be needed to be run, i.e. the system chooses the correlator setup based on the desired spectral lines, resolution, etc? REPLY: The GUI (part of the Observing Tool) should : - take defaults and show the resulting setups, with range of LO's (due to earth motion) - allow to iterate on the astronomical input parameters - allow to iterate on the setup itself if wished. ---048-------------------------------------------------------------------------- (dw) p.8 2.3 The number of interfaces seems large given the ultimate connectivity of the systems. For example, the simulator, archive search, and proposal preparation tools could be combined to a single interface. In addition, while GUIs are desirable for all the reasons listed, especially for novice users/observers, a path of array control should be maintained that does not *require* the GUI interfaces. REPLY: Agreed. ---049-------------------------------------------------------------------------- (gr) p.8 Observing (or Observation) Tool This name is used as a synonym of a Tool to prepare scripts for Observation. I would propose to use another name for this typically off-line activity (even if and when performed quasi on-line). To me Observing Tool is the Tool one uses to execute an Observation, i.e. the script which has been prepared before for this, either in interactive or in queue mode. REPLY: We'll keep this name, or may be ``Observer's Tool''. ---050-------------------------------------------------------------------------- (lt) Page 8. I am very confused by the (random) list of GUIs. Maybe it is too early for a final list, but it would be nicer to have an approximately complete list the GUIs needed under the Administrative/Engineering/Science categories (some of the GUIs will of course be repeated under some of the categories). REPLY: We'll categorize this list. ---051-------------------------------------------------------------------------- (stm) p. 8 In section 2.3 the GUI is described. Although GUIs are the "de facto standard" for many things, including current array scheduling (and analysis) packages, they can prove very cumbersome when dealing with complicated and/or large observing programs. There are many of us who carry out large surveys for whom GUIs are nearly useless - thus it will be crucial that all GUI functionality be available with some list-directed input (to allow scheduling based on user-input lists) with some automation, or separate comprehensive script-level scheduling tools. It should not be necessary for such a user to develop their own scheduling program (like I have had to do for my CLASS survey for the VLA). This should be straightforward to implement if the software is designed with the large survey user in mind as well as the "novice" single-source observer for whom simple point-and-click GUI scheduling is appropriate. The "look and feel" of the GUI will be critical in determining its utility and popularity. For example, most current GUIs that I have seen for telescope control and scheduling are basically control panel style. However, for constructing (possibly complex) schedules and assembling objects to build a pipeline analysis macro, something more along the lines of IDL and similar visualization packages might be preferable. By being able to manipulate the atomic objects graphically and assemble them molecularly into macro-objects would simplify and enhance the user's experience in constructing schedules and analysis templates. Furthermore, it would allow easy "cloning" of macro-objects to facilitate the normally tedious process of assembling large snapshot survey schedules, for example. Computer input such as automated selection of calibrators based on user supplied criteria, and choice of calibration cycle time based on weather diagnostic input data, could be objects also. I think that by fundamentally considering the whole system software package, from the proposal to processing to archiving stage, as instances of a set of base objects, will greatly aid in the design process. REPLY: We believe that surveys can be handled by GUIs acting on source lists; For unforeseenly complex projects the user will prepare dedicated scripts for which building locks will be provided. We think that panels are OK for most tools but that the Observing Tool is different and should have a `programmable look'. =============================================================================== SPECIFIC COMMENTS (Section 2.4- Real Time Software/Observing Modes) ---053-------------------------------------------------------------------------- (bg) p.9 2.4.1 phased array I don't believe the hardware at present supports the desire to correlate different phased arrays. If a requirement, the ASAC (presumably) should make this requirement known to the project. REPLY: It's true that it is not available in hardware; we'll pass this issue to the Project Scientists. ---054-------------------------------------------------------------------------- (bg) p.9 2.4.1 OTF The discussion is in terms of auto-correlations from the correlator. Would the TP detectors in the IF system ever be preferred? REPLY: Either should be possible from the software. ---055-------------------------------------------------------------------------- (bg) p.9 2.4.1 Presumably the possibility of beam switched should be mentioned since it is still TBD if we will have a nutator. REPLY: Yes, it should be an option just like frequency switch. ---056-------------------------------------------------------------------------- (dw) p. 9 2.4 The listed modes cover what is done at existing arrays. It would be prudent to retain as much flexibility as possible, however, since ALMA will likely introduce calibrations that we can't predict now (e.g. 183 GHz phase correction scale factor calibration). REPLY: Yes, that's the whole idea. New modes can be tested with scripts and later implemented as GUIs. ---057-------------------------------------------------------------------------- (dw) p. 9 2.4 Where do complex observing functions fit into this scheme, especially those that require feedback, e.g. searching for the best nearby calibrator? REPLY: The feedback will be from the pipeline. It is foreseen to have one fast pipeline for calibrator processing only, distinct from the imaging pipeline. ---058-------------------------------------------------------------------------- (gr) p.9 2.4 Observing modes There are so many modes indicated here, that it would be very good to start from there and construct observing scripts (Templates in ESO slang) corresponding to these modes. Clearly this would not prevent at all the possibility to have also much more general modes, but would provide many building blocks for observing corresponding presumably to a large number of standard cases. REPLY: That's the general idea. ---059-------------------------------------------------------------------------- (rt) p 9. *2.4) Observation Modes. If I remember a MMA meeting in Tucson a few years back, the "Special Observations" should probably mention 'solar flare tracking', which, to my recollection, involves a fast frequency sweep possibly involving more than one receiver. But, people were worried at the time about the requirements this mode would add to the system. REPLY: These are not discussed, there is a need for input by specialized astronomers since the requirements here are not only for software. We'll pass these to the Project Scientists. ---060-------------------------------------------------------------------------- (stm) p. 9 Section 2.4, there is no text under Pulsar Observations (place as an example of "Other Modes" if no further description desired). Are there other Other Modes? Planetary Radar modes (with ultra-high spectral resolution)? Phased Array mode? REPLY: Same reply as to 059. ---061-------------------------------------------------------------------------- (stm) p. 9 Under "Total Power - On The Fly Mapping" there is the statement "Every so many scans a reference auto correlation on blank sky is needed" which is not true - one of the feature of OTF (in order for it to be efficient) is that it covers the ON and OFF parts of the source during the scanning. Otherwise it is just a rasterized position switched map. The critical thing for OTF mapping is a controlled slewing while observing. REPLY: Agreed, the wording should be: "Every so many scans a reference auto correlation on blank sky may be needed". ---062-------------------------------------------------------------------------- (lt) Page 10, Phase and Bandpass calibration. I think that in this context "receiver" should be used instead of "frequency". I doubt that it will be feasible to retune a single receiver for calibration. REPLY: Agreed, the correct word is `frequency band'. ---063-------------------------------------------------------------------------- (lt) Page 10, Baseline calibration. I am not sure that inclusion of non-moved antennas will always be necessary. In fact, this is not usually the case for baseline solutions with current mm-arrays. Of course this will depend on the number of moved antennas. REPLY: Non-moved antennas are needed since baseline measurements do not measure absolute positions. ---064-------------------------------------------------------------------------- (stm) p. 10 Should "Phase Calibration" be distinct from the amplitude part of "Gain Calibration"? I would call the amplitude and phase calibration derived from cross-correlations on sources "Gain Calibration" and "Flux Calibration" would be just an instance of this. Note for weak calibrators you would do phase-only Gain Calibration, and the secondary calibrators amplitudes can be linked to the primary flux calibrator amplitudes. I would tend to call what you call "Amplitude Calibration" from sky/hot/cold auto-corrs "Temperature Calibration" or something similar. Will there be "Noise Calibration" using a noise tube? REPLY: We'll try to make sure that the terminology is coherent with that of the Project Book. We think that a noise tube is still TBD. ---065-------------------------------------------------------------------------- (dw) p. 11 2.4.2 Sample astronomer input: surely the system will be smart enough to use the observing parameters to derive default processing parameters like Map_Cell and Map_Size. (Of course, the system should also retain the ability for the astronomer to set such parameters.) REPLY: We'll provide defaults: map_cell is easy, but a default for map_size (Primary beam ?) can lead to very large image format for high resolution observation. ---066-------------------------------------------------------------------------- (rt) p. 11 2.4.2: the approach to allow the astronomer to specify 'astronomical requirements' without having to translate into instrumental parameters is very attractive as well as the quasi-intelligent response. Such system will be a first-line defense against errors by non-expert observers. REPLY: Agreed. ---067-------------------------------------------------------------------------- (stm) p. 11 On the observing tool reaction to astronomer inputs (2.4.2), what level of "fuzziness" will be assumed for parameters (especially when it comes dynamic scheduling time)? How are these uniformly specified (eg. as "Tolerance" on specs like Synth_Beam_Size or Largest_Structure_Scale which determine the allowed configurations)? Note that Beam_Size should be something like Synth_Beam_Size to be unambiguous. Also, I assume the intended info and warnings will be more specific than the example! Some thought needs to be put into a vocabulary and set of scientific specification parameters that will describe the desired observations. Can a preliminary set be included here? REPLY: This level of detail is intended in the next version of requirements. =============================================================================== SPECIFIC COMMENTS (Section 3- Proposal Submission and Handling) ---069-------------------------------------------------------------------------- (bg) p.12 3.1 It is my understanding that image fidelity is not a well defined concept for radio interferometry. REPLY: It's well defined, but difficult to quantify without simulations. ---070-------------------------------------------------------------------------- (dw) p. 12 3. The plan for proposals with two phases is excellent. The detailed process should try to take advantage of the best features used by current facilities. REPLY: Agreed. ---071-------------------------------------------------------------------------- (kim) p. 12 3. Proposal Submission and Handling Because, for many astronomers, interferometric imaging is not simple to understand. The function of imaging simulations is very important for effective operation of the array, so it should be included in the basic requirements. REPLY: Agreed. ---072-------------------------------------------------------------------------- (rt) p. 12 3.1) Basic requirements. I think that the proposed approach is basically sound. By the time ALMA will come online there should be a lot of experience with electronic submission, proposal handling etc. I agree that it will be essential that the proposal is 'parsable' and that the technical specifications and requirements can be extracted and stored in a DB. Whether this involves a direct submission to a DB or via intermediate files (e.g. XML) is an implementation detail. One minor point: it is my experience that observations need 3 'completion' parameters. A S/N, a flux or rms, and a maximum observing time. Observations are taken to be complete if any one condition is being met. REPLY: Basically agreed. ---073-------------------------------------------------------------------------- (stm) p. 12 Section 3 - Proposal Submission and Handling Section 3.1, the first requirement is that proposal is electronically submitted, yet later it says that "We don't think this needs to be computer parsable, if all the technically relevant data are available elsewhere. People should be free to use their favorite text processing system to prepare the text and to include the figures." This seems incompatible with the first, and will unnecessarily complicate the proposal review and archiving process. I *strongly* urge the adoption of some uniform and computer parsable scheme for proposal submission and archiving, either TeX based (most readable) or HTML (most archivable). I would even more strongly urge the disallowing of formatted text formats like MS-Word or Word Perfect (I used to get these from students, and they are incompatible across versions and hell to deal with.) Since the proposals are to be archived with the schedule and data, it is even more important to enforce some uniformity. On the specification (by proposer) of sensitivity goals and breakpoints, some work will be needed to come up with a proper language (with fuzzy specs or tolerances) and relative weights to allow scoring of dynamic scheduling points to determine priority and to make the necessary tradeoffs between some of the goals for a given set of in-hand data to determine breakpoints. As stated earlier (and will be again later) this will need some careful and innovative thought. It may be that a small set of parameters and tolerances (eg. Map_rms on various scales, Smallest_uv_gap, Signal_to_noise_fidelity, etc.). REPLY: We'll make the phrasing more clear: the scientific justification should be printable while the technical input should be computer parsable. Breakpoints will be introduced at both the proposer's and the reviewers' initiative. In the latter case the parameters involved will have to be well specified to avoid conflicts. ---074-------------------------------------------------------------------------- (dw) p. 13 3.2 The simulator, listed as an advanced feature, would make a lot of sense as a *basic* feature. Even very simple simulated observations can reveal flaws in expectations, science goals, observing strategy, etc. Ideally, the simulator should take exactly the same input script as the hardware. Such simulations should not be required for a proposal, but it would make sense to offer at Phase 2, once the detailed observing procedure has been defined. Note that the simulator is useless unless it keeps up with changes in the real-time system. REPLY: The idea is to have the same interfaces at both Phases 1 and 2, the simulator being optionally run at phase 1 if the proposer feels it will make his/her proposal stronger. ---075-------------------------------------------------------------------------- (stm) p. 13 Are the things in Section 3.2 Advanced Features intended as suggestions or specs? Instead of linking to some (necessarily observatory maintained) database of a hodge-podge of existing line surveys by object, would it be sufficient to have a "standard" generic line-list of transitions perhaps with a guide (e.g. link in the list) to which sources or class of sources are likely to show these? I think it would be beyond the means or even the mandate of ALMA to maintain a research database on individual objects. A single line-list is probably sufficient, and we would put knowing about the lines in a specific target into the user required scientific background work on the proposal. REPLY: It is probably more efficient to have several line lists for various object classes. In addition it is felt that a simulator based on a simple physical model with standard abundances and temperatures is not that difficult to build, using already available software. =============================================================================== SPECIFIC COMMENTS (Section 4 Dynamic Scheduling) ---077-------------------------------------------------------------------------- (bg) p.14 4.1 breakpoints -> breakpoints REPLY: Will be corrected. ---078-------------------------------------------------------------------------- (dw) p. 14 4. ALMA clearly must have the ability to schedule observations during those periods that meet critical (and quantifiable) conditions for maximum productivity. The early stages will be dominated by interactive mode with immediate feedback for debugging, but fully dynamic scheduling must take over as the ALMA reaches maturity. Exactly what time scales are considered for dynamic scheduling? Will there be, e.g. 10 minute time blocks? How often will the entire schedule be revisited? Though no one knows exactly how-- or how well-- various submm/long baseline calibration schemes will work, there's no doubt that weather will constrain a certain class of exciting observations that push the limits of the instrument and the site. Without dynamic scheduling, such observations will either never be done, or done only by the small group of insiders who influence the daily schedule. REPLY: Time scales will be set from experience and simulations, principally from atmospheric constraints. The schedule will be revisited at observation block limits, with special mandatory blocks (preface/postface) at the begin and end of each session. ---079-------------------------------------------------------------------------- (dw) p. 14 (4.2, 2nd par.) 4.2 The concept of a ``statistical approach'' to time allocation and scheduling may need some development to gain general acceptance. REPLY: Simulations may be useful to show this. But several instruments (including Plateau de Bure) have already been scheduled in this way, although manually, with good acceptance from the community. ---080-------------------------------------------------------------------------- (gr) p.14 4.1 Requirements (2nd par.) dynamic schedule accommodates both fixed queue and interactive observing. This is also the way I would see it, namely that also interactive observing would go via scripts. These might simply be chosen at the moment rather than being the ones suggested by the scheduler. Is this what is meant here ? REPLY: Yes - but one should encourage users to prepare their choices in advance even for interactive scheduling. ---081-------------------------------------------------------------------------- (gr) p.14 4.1 Last phrase is cut. REPLY: already corrected. ---082-------------------------------------------------------------------------- (gr) p.14 4.2 Implementation (end of par. before last) An expert dynamic scheduling program will probably become the default mode of observing, unless an expert observer wants to take interactive control.. I would personally agree, but this in the end will need to be written as a requirement: The default mode shall be..., with the possibility for an expert astronomer to take interactive control. REPLY: This will be made as an explicit requirement. ---083-------------------------------------------------------------------------- (rt) p. 14 *4) Dynamic Scheduling The first two paragraphs of this section give a clear and concise description of the requirements. However, I take issue with paragraph 3 as well as requirements and goals outlined for the pipeline in section 6. My views deviate from the views expressed in the memo, and your bad luck, I feel quite strongly about these. Unfortunately I am also running into the deadline which means I can not spent a lot of time trying to be subtle about this, so be prepared :). In spite of the perhaps forceful language, I am open to be convinced I am wrong. So, here goes: First of all: ALMA will need dynamic scheduling in order to be able to take advantage of rare conditions. Agreed, the first two paragraphs give a very good outline. Does this need a pipeline? No, not in itself: if the conditions apply you just do the observations. Ship off the DVDs or DLTs or Dxx and be done, period. However, dynamic scheduling implies serviced observing. Ooops, big NO NO; the astronomical community hates that: ALMA will be a fast imager and will resembled optical telescopes and single dishes more than it resembles the existing mm-arrays or e.g. the VLA. As soon as you have a fast instrument, observers prefer and demand an interactive observing mode. How do you solve this conflict between serviced observing and the demand for an interactive mode: use a (quasi-) real-time pipeline and ship the results to the observer. Added benefit: the staff astronomer on duty can catch glaring problems quickly, even while the observations are in progress from the pipeline results. Hence the fundamental idea behind the pipeline is to provide the P.I. with an interactive control over the observations similar as with 'classical' observing. One of the key ideas of dynamic scheduling is that you do not need to have the observer remotely online to make the decisions. After all you can proceed with another program until the feedback comes (in those cases which are an exception one of observing constraints will be to have the P.I. remotely online). To take the example in the document: observing a wide field followed up by detailed or high-freq. observations of detected point-sources. There are two scenarios: the wide-field observations will either take little or much time. In case the wide-field observations will take little time, it will be relatively easy (or, stated differently, have little impact) to schedule the observation e.g. with a boosted priority and to cycle it back to the observer for object selection for the follow-up. Taking the other case: the image will take a long time e.g. several days, means that partial results can be cycled back and the P.I. will already be able to identify and setup for the brightest follow-up sources before the image is done. Again, dynamic scheduling means that as far as ALMA is concerned it can proceed (indefinitely, but that is another issue) while waiting for feedback from a particular project. This example and the philosophy behind it seem to radially differ from the approach as described in the memo where it appears that the dynamic scheduler and pipeline in combination aim at automating even complex decisions. I believe that this is an extremely undesirable development. It ignores the lesson from the whole development and incredible success of the web in providing access to and hence control over resources irrespective of their location. Software automation is no longer the key, transparent access by wetware is. ALMA should integrate this aspect within its model of operation. Besides all this, I seriously doubt that the pipeline will be able to incorporate enough sophisticated decision capability to be of use in more than a few observations. I fear it will turn into one of those developments which will turn out to be very difficult to realize, will always encounter 'exceptions' for which it was not built, and will waste a lot of effort. Well, enough about this, I tend to get a bit combative about this issue I guess :). REPLY: The pipeline is necessary first to give fast, automatic feedback, by processing the calibrators in a standard way. It may also useful to give feedback based on the image (rms, flux) though it seems clear that the pipeline will not be fast and efficient enough to provide feedback enabling interactive interferometric observing. Rather breakpoints will be used to provide the possibility of scientific decisions to be fed back. The `demand for interactive mode' is not very easy to predict: the Plateau de Bure, though about twice as sensitive as the other arrays, has never been used interactively, and there has been no demand for this. The VLT, a very fast instrument, is being used in a combination of dynamic scheduling and serviced observing. However the Keck is being used interactively. So we agree, and have clearly stated so in the report, that there is the need to provide an interactive mode. But at this point we think that overall efficiency points towards dynamic scheduling. In the dynamic scheduling mode the feedback from the PI should be: - at the end of the observing session, which may happen because (i) another project has reached higher priority; (ii) a breakpoint has been reached in the project; he may look at the pipeline results, think things over, change the procedure accordingly and give a green light to dynamic scheduling so the project gets back into the queue. - at any time during observation, if he happens to be anywhere online getting some data: to decide that something is wrong and interrupt the procedure (unforeseen break point), and do the same actions as above. In both cases it is quite possible that the project will only be rescheduled the next day. This is because (i) the array will be executing other projects in the mean time, and (ii) the PI needs some time to react. We think that this reaction time is not dominated by communication efficiency but in fact by Earth rotation, getting into office and checking email, looking at pipeline results, thinking, may be trying the simulator with new parameters, thinking again, and coming to a final decision on what's next. While the capabilities for PI interaction with an observing session will in principle be available, practical considerations will probably prove limiting. The dynamic scheduling of the observation and the simultaneous availability of the observer are an obvious limitation. Pipeline speed, depending on the project, may also not be sufficient for quick turn-around. And timely network availability to a PI at any random location can certainly not be guaranteed. ---084-------------------------------------------------------------------------- (rt) p. 14 *4.2) Implementation The implication that the exact time spent on a project will not be known can be fixed by allowing a x% uncertainty in the allocation for every project both to deal with calibration issues as well as to make the observations more driven by the astronomical goals. Ideally the actual 'x' time used will average to zero but if not some 'lower priority' projects may drop off the queue just as they would if the weather would be worse than expected. Overruns have to stay within reason of course since one needs to assume that the science case was reasonable. Large overruns indicate problems with the science which should be dealt with at the proposal level and not by the schedule and operations. The part about the table and scripts is not entirely clear to me. Dynamic scheduling requires that the technical specifications of the observations as well as certain aspects of the program (do either A or B, but don't schedule C unless A or B) are available in a data base. After all, that's why the proposals are parsable. Since there can be only one definitive repository of the specifications it seems to me that the 'observations DB' should be central to the operation. Possibly scheduling an observations means extracting the information into a script for submission to the real-time system, but an ASCII files based approach seems very out of line. The whole issue of how the detailed program gets translated into telescope commands appears to be dealt with differently in different part of the memo. The memo does not outright say that the dynamic scheduling will be done via an automatic scheduler. While this may be a long-term wish, I would not waste resources on trying to build a SPIKE like scheduler. The HST scheduler works and is needed because HST has to deal with many and complex constraints on operations, but they are all perfectly predictable. ALMA's constraints will vary from hour to hour largely unpredictable. Long-term optimization will be pointless. I think a smart DB browser which presents the staff astronomer with a prioritized list of possible programs is fully adequate. An automatic scheduler would have to deal with (too) difficult issues: will it be aware that the forecast is that the weather will change two hours from now; how does it rate partially completed programs vs. high-priority programs; will it be aware of the fact that source X will only be observable for another two weeks; etc. The adoption of 'observation blocks' implies that there will be a finite granularity to the decision making process which further diminishes the need for an automated scheduler. REPLY: We did not look too deeply into the details of the scheduler. An automatic scheduler has the advantage of taking uniform decisions once the rules are set. Rules may be introduced to take into account the scientific priority, the fact that a project has been already started, the probability of being able to finish it in the current season, ... Constraints based on array configuration policy are not known at this time. The scheduling tool can be simulated and tested based on several years of weather statistics, well in advance of the first observations. ---085-------------------------------------------------------------------------- (stm) p. 14 Section 4 - Dynamic Scheduling If we are to seriously implement dynamic scheduling, which I believe is the intent, then it must be done so as the *primary* method of observing. Beyond the technical shakeout stage, a user must have a strong valid reason why their project must be done interactively (or manually) instead. There needs to be a mechanism for the review and approval or dismissal of such requests. This should hold true for all peer reviewed scientific proposals, even for internal "expert" observers. No exceptions. An observer cannot have the option to observe interactively just because they prefer to do so, enjoy doing so, or cannot be bothered to carefully set up a dynamically schedulable program. REPLY: Yes ! ---086-------------------------------------------------------------------------- (stm) p. 14 The discussion "A table driven observation is more flexible." is unclear. More flexible than what? What is meant be a "table" (I presume an ASCII table as it says a bit later)? I do not see this at all, and should be left out or demonstrated. I would think that this would be much less flexible, as it requires some rigid standard table scheme in order for it to be parsable. Some more standard method of specifying states (eg. GUI and/or state variable changing functions) would seem better. REPLY: These points will be detailed in the next version of our requirements. We view these tables more like a hierarchy of variables that describe each observation in an observation blocks. ---087-------------------------------------------------------------------------- (stm) p. 14 It says that the "expert dynamic scheduling program will probably become the default mode of observing", which seems a little weak. I would think that the decision to make it the primary mode (no "probably") is one of the (few) concrete things that this review should generate. It continues "unless an expert observer wants to take interactive control of the array" which as I stated before is insufficient - the "expert" observer needs a valid reason and permission. REPLY: Yes - we'll strengthen this point. ---088-------------------------------------------------------------------------- (bg) p.15 4.2 I don't think that "running a script" is a common definition of remote observing! REPLY: We do not foresee `remote observing' to represent a significant fraction of ALMA observing time (dynamically scheduled). However interactive observing, when scheduled, and in particular for tests by experts, should be available remotely, with all security precautions, naturally. ---089-------------------------------------------------------------------------- (dw) p. 15 4.3 The crucial aspect of dynamic scheduler will be the feedback from the rest of the system, especially the pipeline/archive, to reach decisions on what has been completed and determine what needs to be done next. Some thought could be directed to exactly what point the astronomer becomes involved after the observing starts. It won't be practical to have many break points in a fully dynamic schedule. Yet, there will be many projects where it will be possible to predict success or failure after, e.g. 1/10th of the required observing time. REPLY: Agreed. Typically one or a few breakpoints for medium - large projects seems reasonable. ---090-------------------------------------------------------------------------- (rt) p. 15 *4.3 Guidelines "...but must be done so in a way that leaves the human observers feeling in control of the observations." Ouch. Sounds like computers are getting serious about the domination of Earth. REPLY: At least we're warned. ---091-------------------------------------------------------------------------- (stm) p. 15 The section 4.3 "Guidelines" seems somewhat contradictory and vague. Again, indeed since ALMA is a valuable resource, dynamic scheduling must IMHO be the primary mode of operation. But not only should we avoid wasting time when weather is bad, we need to avoid wasting good time just so an in-house "expert" can play. ALMA will be a cutting-edge mature facility servicing the entire international community, and cannot be run as a seat-of-the pants operation, even if it would more fun for the people involved. "Leaving the human observers feeling in control" should not be a primary concern of the system, but giving the scheduler and the observers real control is important. This section as it is seems like a vestigial appendage. Perhaps it could be tightened, prioritized, and put at the beginning. REPLY: Partly incorporated in the beginning of the chapter, probably. ---092-------------------------------------------------------------------------- (stm) p. 15 I assume there will be controversy on the role of interactive observing. I hold the view that with proper planning and given the proposed set of powerful tools, monitoring, and pipeline diagnostics, that the need for interactive use of the array (after the test stage of course) can be kept to a bare minimum. This is the case with any space-based observations, and though this may take some of the "fun" out of the observing it is I think the right thing to do given the nature of ALMA. This cannot be seen as a $600M toy. REPLY: This is agreed. =============================================================================== SPECIFIC COMMENTS (Section 5 Operator Interface) ---094-------------------------------------------------------------------------- (bg) p.16 5.2 pt 1 This implies that the schedule is known ~8 hours in advance. Mightn't the dynamic scheduler work on a shorter time scale than that? REPLY: It is agreed that the time scale should be shorter. Probably the look-ahead schedule should be only available directly to the local staff, not on the Web. Whether the operator needs to approve each project change is actually an operational issue. ---095-------------------------------------------------------------------------- (dw) p. 16 5.3 Audio from the antenna cabins may prove to be as valuable as video. REPLY: Yes. ---096-------------------------------------------------------------------------- (gr) p.16 5.2 Operator responsibilities 2.. safety The point on safety should be explained better to indicate that to take out/in service needs checking with operations. He shall put off-line/on-line antennas or devices in general to allow maintenance or to introduce them in operation again. REPLY: Clearly yes. ---097-------------------------------------------------------------------------- (kim) p. 16 5. Operator Interface ** Hierarchical monitoring There are so many instruments in ALMA and the number of monitoring items is huge. To detect any trouble easily and quickly, monitoring system should have hierarchical structure. Especially, a top level monitor should be design to show integrated information and this integration should depend on current observing plans and telescope status. ** Traffic control For smooth operation, it is important to control network traffic between the site and San Pedro or headquarters in US, Europe, and Japan. REPLY: This is agreed. The system in use at OVRO for monitoring display should be taken as a guideline. Traffic control is needed but can be handled mostly by the network hw/sw. ---098-------------------------------------------------------------------------- (rt) p. 16 *5.2 Operations Responsibilities I disagree with function 1.: the operator should not be involved in the scheduling of the telescope. The scheduling is mainly an astronomical or program driven issue not an 'operations' issue. Functions 2. and 3. are plenty. The observations should be guided and monitored by a staff astronomer who will also be able to evaluate the pipeline results within the context of the scientific objectives. REPLY: On point 1 we meant only a check - just looking for possible problems with availability of hardware, making sure the observers are aware in case of interactive observations ... ---099-------------------------------------------------------------------------- (stm) p. 16 It says "Location: The Operator can either be located at the site or at the OSF in San Pedro". Duh. Where will the "operator" be and what are the issues for the two cases? If the operator is in San Pedro, then they cannot oversee operations on-site which has some impact on what duties they can assume. I could also see use in having an array operator at the site and at the same time a data manager at San Pedro monitoring the data and overseeing the pipeline (as well as a double-check on the site operator's safety) - this might be the best split of duties with the site operator more electronics oriented and the OSF data manager more computer oriented. A video link between the two would ease the isolation of the site. I don't think we should underestimate the hazards for those on-site and some connection to the OSF would be good. REPLY: This is not in the scope of our committee. We only require that operator software must be runnable remotely. ---100-------------------------------------------------------------------------- (stm) p. 16 In 5.2 Operator Responsibilities, the second item is to oversee the site work schedules and safety (which cannot be done if the operator is in San Pedro!). This seems to distract from the main duty of the operator which is to operate the array in any event. Operations of ALMA is outside the scope of this document, and I would strongly urge the decision by this committee that a DEDICATED array operator be assigned during a given shift. Note that site safety would require a second person (at least) with the operator, and the co-operator could be assigned charge of safety concerns (including array shut-down due to weather, and evacuation, possibly overriding the primary operator). Note also that this second item is in contradiction to the skills listed at the top for the operator (eg. computing and electronics doesn't equal health and safety management training etc.). I would delete 2, as site operations will need to be managed by a site manager, and add the recommendation that a dedicated operator be designated who has no managerial duties to distract them. REPLY: see 099. ---101-------------------------------------------------------------------------- (stm) p. 16 Section 5.3 seems somewhat slight, but I'm sure a list of interface tasks will be filled out by members of the group currently dealing with arrays. REPLY: This will be more detailed in the next version of our requirements. =============================================================================== SPECIFIC COMMENTS (Section 6 Data Pipeline) ---103-------------------------------------------------------------------------- (bg) p.17 6.1 Is there a goal for how often the pipeline image should suffice? 50%? 80%? REPLY: This will vary a lot depending on frequency, project type, ... ---104-------------------------------------------------------------------------- (bg) p.17 6.1 Do we archive data reduced by the observer "at home", perhaps using completely different reduction packages/strategies? REPLY: No, for data base uniformity. ---105-------------------------------------------------------------------------- (bg) p.17 6.2 Does the pipeline have to keep up with all observing in quasi-real time? Might the observer say that some high data-rate/processing projects are only accepted if the observer reduces the data elsewhere (e.g. large interferometric OTF survey might require a supercomputer for reduction). REPLY: On average only. We should not reject projects on that basis. ---106-------------------------------------------------------------------------- (dw) p. 17 6. An intelligent pipeline would certainly help at all levels, but I am skeptical that the pipeline can reach the sophistication described. If the pipeline can interact with the dynamic scheduler well enough to reach decisions on when specific goals are met, based on quantitative measures, then the leap to higher level specifications may be a reasonable aspiration. It may be possible to, e.g. perform source extraction and follow-up in real-time, without any intervention. But the details of appropriate calibration and follow up work are only not often known sufficiently far in advance. The machines will do what they are programmed to do, but the astronomer can rarely predict the optimal path without seeing the data. REPLY: The answer we propose is the use of breakpoints in the observing projects. Inside an observing session we foresee to limit at first the feedback to results of processing/analyzing the calibrators, `test quasars' if any were included, but the image itself. However we think it would be a mistake to close the door to more sophisticated pipeline fuctionalities, as described in the memo: ---107-------------------------------------------------------------------------- (rt) p. 17 *6. Data Pipeline See 4: the pipeline should deliver images for evaluation, not do the evaluation itself, except where standard observations (pointing, focus, tipping curves etc.) are involved. It is not the pipeline that should decide about meeting the specified goals: that should be left to a staff astronomer (see 5). Optimization of the pipeline to get optimal results should in general be done in an 'offline' modem, possibly at the users home institution. This raises the point of how to get the optimized images back into the second archive. It should not be the responsibility of the observatory or the pipeline to make optimized images, again this is a development which tries to remove the observers from the loop. REPLY: Pipeline evaluation will also include rms phases on quasars, decorrelation effects, ... We agree that the feedback based on astronomical results should rather go to the PI, not the staff astronomer. ---108-------------------------------------------------------------------------- (stm) p. 17 Nothing too startling here, although integration of the analysis pipeline will require coordination with the pipeline programmers (or does it fall under the SS group). What decisions have to be made when on the language specs for the system and analysis software? I think it would be a mistake to assume that some pipeline to be developed in isolation will be integrable into the ALMA system. Some tough choices will need to be made and soon (who will do this?) as to whether an existing package is adopted. REPLY: We regard the pipeline as the combination of software + hardware + scripts + local expertise. It can thus only be supported at a few places. Evaluation work on those issues come later in the software plans. ---109-------------------------------------------------------------------------- (stm) p. 17 In the lists of section 6.2, the main goal of the pipeline from the system software is to provide diagnostics usable by the online system to drive the dynamic scheduling. Whether it produces a homogeneous or scientifically useful data base is secondary (though likely to follow assuming a sane pipeline is adopted). REPLY: Disagreed. An homogeneously derived data base is important as a goal. =============================================================================== SPECIFIC COMMENTS (Section 7 Archiving) ---111-------------------------------------------------------------------------- (bg) p.18 6.2 What is done for quality control? Humans? Software? REPLY: As much as possible software (e.g. based on test quasars for interferometry, regularly checked pointing, ...) ---112-------------------------------------------------------------------------- (bg) p.18 6.2 bullet 3 on page antenna->array? REPLY: Yes. ---113-------------------------------------------------------------------------- (bg) p.18 6.2 Maybe mention here that the observing script should be attached to the data (this is mentioned later). REPLY: Yes. ---114-------------------------------------------------------------------------- (lt) page 18 section 6.3.1, I think that it will be important to monitor also the receivers performances (and of other components as well) for maintenance. REPLY: Yes. ---115-------------------------------------------------------------------------- (stm) p. 18 In the item beginning "The pipeline must interact ..." the phrase "various high levels" should read "various high-level". REPLY: Yes. ---116-------------------------------------------------------------------------- (stm) p. 18 "The pipeline must operate through a readable and comprehensive data reduction script" is irrelevant given its (rather complex) task. It is desirable that it is readable (and to do the job it must be "comprehensive" I guess, or does the author mean "comprehendable"?) but it may well (acutally, probably) have to be written directly in the lower-level (C++,glish,java,???) language to have direct control over the objects. I find most programs to as readable once you understand the language as observing scripts in any event, and I think most astronomers would agree. This whole paragraph seems a bit silly given that there is no real vision of the detailed implementation. The end bits about what it must do are sensible, though redundant with the next section (see below). REPLY: Sorry ... `comprehensible' was actually meant but obviously not achieved. The scripts themselves should be rather high-level, with building blocks efficiently programmed in lower-level languages. Here as well, flexibility is the goal. New reduction scripts will have to be developed in parallel to new observing procedures and observing scripts/GUIs. ---117-------------------------------------------------------------------------- (stm) p. 18 The last item "The pipeline should be run either at or near the telescope" doesn't seem relevant. Perhaps what is meant is that "The pipeline must have the capability of being run at the site, San Pedro operations center, remotely, and in real-time or at a later date." It will have to do all of the above. REPLY: Yes. ---118-------------------------------------------------------------------------- (stm) p. 18 Section 6.3 outlining functionalities seems somewhat redundant with parts of 6.2 as mentioned previously. Section 6.3.4 is different, though vague. The primary goal of the pipeline is to feed back relevant diagnostics of the data quality vis a vis the proposal goals. It seems unlikely that we will want to "allow several algorithms to compete", rather we will perhaps need a suite of diagnostic algorithms (both imaging and visibility based) to tell different things about the data. The agreement or lack thereof between the different methods will provide information on a combination of data quality and image properties. The "complexity" of the image may well not be known beforehand, and thus should be one of the diagnostics output by the pipeline. Zero spacings (fictitious in any event) need not and should not be included as this can be dealt with in the diagnosis, but short spacings provided by ALMA total power data or mosaicing could be. I see no good way to uniformly incorporate non-ALMA short spacing data, though maybe provisions could be made for inclusion in the archive and thus available to the pipeline user provided images. I worry about basing diagnostics on data not under our control. REPLY: We should not include data not taken by ALMA in pipeline imaging. ---119-------------------------------------------------------------------------- (bg) p.19 6.4 Should there be more than one pipeline so that observing is not affected if a PI saturates an image pipeline w/ reprocessing? REPLY: Yes. A fast pipeline could proceed array calibration, pointing, focus, calibrator scans, independently of the imaging pipeline. ---120-------------------------------------------------------------------------- (lt) page 19, sect 6.4, first indented paragraph. I think that proposal stage should be specified as P2PP stage. In my opinion Fully interactive observations should not be considered at all for the user, but only for maintenance/testing. REPLY: Already discussed above. ---121-------------------------------------------------------------------------- (stm) p. 19 In Section 6.4 on users the phrase "go beyond the informations" should be "go beyond the information". Also, "Fully or partially interactive observations should be justified during the proposal stage, with permission granted by the proposal review committee, before interrupting the normal dynamic schedule flow." might be more to the point. However, real time monitoring of observations might be accommodated if the bandwidth is high enough to the site. Do we wish to encourage or discourage this? REPLY: We should strongly encourage the examination of pipeline results by the proposers between observing sessions of a given project. Monitoring the results (by the PI) during an observation cannot be discouraged, because it could lead to a saving in observing time if the PI sees that she/he has made a mistake in her/his observing parameters. ---122-------------------------------------------------------------------------- (bg) p.20 7 In addition to the reduction scripts, do we want to attach a package-independent description of the "intentions" (size, taper, calibration strategy, etc) of the observer, e.g. in XML. This might be longer-lived than the actual reduction script. REPLY: Yes. It is foreseen that all observer's inputs, including these `intentions', is channelled through the system along with the data. ---123-------------------------------------------------------------------------- (dw) p. 20 7. It is extremely useful to include the observing script (and some form of observation history) together with the uv data in the archive, as is now done at BIMA, to help decipher the contents of the data sets. REPLY: Yes. ---124-------------------------------------------------------------------------- (lt) Page 20, second paragraph. I think that we should also keep the calibration data (the OVRO solution). So that calibration may be re-applied in case of sufficient short sampling and development of new calibration procedures. At OVRO we could recover some older tracks with a newer version of the software. REPLY: Yes. ---125-------------------------------------------------------------------------- (stm) p. 20 Some typos in the first paragraph: "inquires" should be "inquiries" and "spectra line" -> "spectral line". REPLY: Will be corrected. ---126-------------------------------------------------------------------------- (stm) p. 20 It is unclear that we will be able to afford to store both corrected and uncorrected data in all cases (especially the high data rate modes). Although it is desirable to keep the original data in cases of "irreversible on-line corrections" it should not be necessary after the initial testing and debugging stages. The goal in the end should be, however, to have a robust phase-correction system where the corrections can be applied safely in most cases (and thus if only a small number of observations are rendered unusable due to faulty irreversible modifications they can be dealt with through re-observation). I think it would be a poor use of resources to build in a factor of two storage and data rate redundancy (and this would be at the fastest speed before accumulation). On the other hand, it may be that at the slower data rates (longer integrations) where there is some excess capacity that there is some benefit in recording both uncorrected and corrected data streams. However, I would guess that in normal operation where correction is important the uncorrected data is useless to begin with, and in marginal cases the correction will not be making a difference anyway. Note that during testing it would be advantageous to be able to record both as a check on the correction algorithm. REPLY: This will be a user's choice. ---127-------------------------------------------------------------------------- (stm) p. 20 The long paragraph on object oriented post-processing might well be applied to the system software also (as I advocate). One of the innovations of the ALMA system will be the integration of all facets of the proposal, scheduling, observing, pipeline, post-processing and archiving processes into a (hopefully) seamless whole, and reusable and multi-purpose (as well as single-purpose) objects are an elegant solution. This paragraph could appear at an earlier place to stress this. REPLY: This is the policy of the Software Group as a whole. ---128-------------------------------------------------------------------------- (stm) p. 20 We will likely need some redundancy in the Chilean archives (are site and San Pedro sufficient?) as well as regular updating of main European, American, and Japanese archives. REPLY: Of course we need a safety copy at all times (however this has a cost ...). =============================================================================== SPECIFIC COMMENTS (Appendix A) ---130-------------------------------------------------------------------------- (gr) p.21 A Script language There are so many examples here that it would really be good to split them down in a number of operation scenarios. These probably give more details to the observing modes of section 2.4. The syntax I would instead take as an example, as otherwise I believe we should go for a standard scripting language, like TCl or Python/JPython. It should be seen though how one should present scripts to the astronomer to allow him easy understanding of the logic and to hide the language constructs and details. REPLY: Agreed. ---131-------------------------------------------------------------------------- (stm) p. 21 Appendix A - Script Language No comments here (I read this through earlier when proposed), seems reasonable but until a detailed system design is undertaken it is not clear whether this retro-styled script language is appropriate (my guess is "no"). REPLY: Agreed. ---132-------------------------------------------------------------------------- (lt) Page 23. I think that it is important to construct the OBSERVE cycles based on LST intervals rather than DURATION (as is done at IRAM/OVRO) otherwise flexible scheduling is much more difficult. REPLY: Yes (but actually, this is not the case at Plateau de Bure). ---133-------------------------------------------------------------------------- (lt) Page 24 A.3 first par ==> the solution for day-independency is to use LST start and stop times. REPLY: Yes, apart from some special cases. =============================================================================== SPECIFIC COMMENTS (Other) REPLY: ---135-------------------------------------------------------------------------- (stm) p. 99 Upshot There are several "actions" (decisions) that should be taken as a result of this document before progress can be made. These seem to be: 1. Once shakedown of ALMA has been carried out and standard observations commenced, should Dynamic Scheduling be the primary (enforced) mode of operation, with interruption for interactive user observations allowed only for cases of documented clear and present scientific need? Or should some interactive observing by "expert" observers be allowed in a more lenient fashion? I would argue for the former over the latter. If dynamic scheduling will be the overwhelming default, then this will drive the integrated system software to handle this fairly early on (eg. right away). Adoption of a policy here will probably need approval or at least endorsement by the ASAC and ACC. 2. Should the proposing, scheduling, observing, monitoring, control, pipeline analysis, post-processing and archiving be considered as parts of a (mostly uniform) whole, based on a particular language? How much compartmentalization and non-standarization can be allowed and still have the desired functionality? Which existing packages and platforms (if any) could fulfill this? My feeling is that we will need some decisions on standards, and fairly soon (this year). My overwhelming impression after reading this document is that the only way a working system will be developed is by basing all parts on a common software base. On the other hand, is the best we can expect a general agreement between the different programming groups on a set of compatibility specifications? 3. Given the above, what are the tradeoffs in language (eg. human friendly versus programming versus utility) specs? What style of GUIs should be adopted (eg. control panel style versus IDL style)? The "look and feel" of the user interfaces will be critical to allowing the wide community to use ALMA without unnecessary hardship. On the other hand, we as "expert" astronomers (and certainly this document as it stands) tend to "dumb down" the average user and require over-simplified specs at the cost of having a fully flexible and powerful system. Some balance must be struck. 4. One need for the system is a vocabulary to describe the scientific goals of a proposed observing program in a quantitative way that can be easily translated into technical requirements (eg. sensitivities). Does this require a "language" or a simple set of parameters? Should this be assigned to a working group? Are there other critical things to be decided asap? Should working groups be assigned to specific things now? REPLY: This an outline of our work plan for the months to come. --------------732F6F58102DF83B29EAFCF3 Content-Type: text/plain; charset=us-ascii; name="toScience.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="toScience.txt" ---------------------------------- D R A F T ---------------------------------- to ALMA Project Scientists and Alma Science Advisory Committee Members: ----------------------------------------------------------------------- Object: Project-wide issues of specific interest to Science Software Requirements During our past six months of work in the Science Software Requirements Committee we have encountered several issues on which we agree that further input on your side will be needed before our work can be completed. Our preliminary report (ALMA memo 293) has been recently officially reviewed and we take this opportunity to raise the following questions. These are mainly issues related to the way ALMA is operated as a whole. For each issue we would like to have either a definite answer or a baseline/fall-back alternative. The questions are given in order of decreasing importance. 1) Array Scheduling We have been assuming that ALMA will be dynamically scheduled so that each project is observed during weather conditions (seeing, opacity, wind) that allow its objectives to be achieved. This implies dynamic scheduling in near real time (Dynamic Scheduling) as stressed in mma memo 164, and in ALMA Project Book, Chapter 2(III.4). This has implications on the feedback from the PI, on the basis of calibration data and images produced by the pipeline: this feedback can only be offered at the end of one transit (observing session), assuming the project observations are divided into several transits either due to schedule optimization (as high elevations are preferred) or intentionally by the insertion of breakpoints. This limitation on `interactivity' has to be realized. We believe it is a small price to pay for the increase in productivity expected from dynamic scheduling. An alternate scheduling method is the traditional interactive observing, which should be available since it can be useful for test purposes and for special -- timely and unforeseen -- observations. Our question: Is dynamic scheduling to be the default mode of scheduling, accepting the restricted interactivity implied by this mode ? 2) Purpose of the pipeline The data flow ALMA Project Book, Chapter 2(III.5) will include a pipeline that may be used to fulfill several purposes: a) check that the data obtained can be calibrated, with feed back to the observing process to use the optimal phase calibration cycle. b) give feed back to the dynamic scheduler by monitoring the observed phase noise. c) produce calibrated uv data and maps of test quasars to check in real-time the quality of observations, with feed back to the dynamic scheduler. d) produce calibrated uv data and maps of the project source(s) to enable the PI to evaluate her/his data at the end of the observing session and to proceed with scientific interpretation when the project is finished (after improved reduction if needed), while incrementing the ALMA data archives. e) use calibrated uv data and maps of the project source(s) in order to derive simple quality parameters (noise level, signal to noise ratio) that may be used to define when the project goals are attained. f) use calibrated uv data and maps of the project source(s) in order to derive similar or more sophisticated parameters (source size, number of sources ... see examples in memo 293) to be fed back into the project's observing process, which may then take automatic decisions. While we believe that a, b, c and d should be implemented as baseline features, there is some concern that f) and maybe e) might be too ambitious goals (software has a cost too) or even may increase the distance between the astronomers and the instrument to an unwanted level. Our question: Which degree of sophistication should be set as a goal for the ALMA data pipeline ? 3) Operational aspects For the specification of GUI (graphical User Interfaces) a clear description of the relative duties of the operators and local staff astronomers will be needed, in view of the following tasks - Allocation of antennas to simultaneous projects (e.g. a sub-array for calibration, a sub-array used for astronomy, some antennas in maintenance) ? - Control on the dynamic scheduling process - Communication with the PIs if needed Our question: Can the relative duties of the staff in charge of controlling the array be already outlined ? 4) Policy on data propriety: We are assuming, as is the usual practice in most observatories, that only the proposing team has access to the data during a limited proprietary period and that the data ultimately become public. The actual length of the propriety period can be probably be set later, but some policy questions may affect the software requirements, such as: 4.1 is only the scientific data covered, or all header information including monitoring data, or some header information only (like coordinates and frequencies) ? 4.2 if public data is reprocessed in the pipeline by others, to search for unforeseen scientific results, does this start a new proprietary period ? Our question: Can the proprietary data policy of ALMA be already outlined ? 5) Special modes Some specific observations (Sun, Pulsars, ...) may need very short integration times, fast frequency changes, ... for which the exact scientific software (and hardware ?) requirements need to be investigated in detail. For these issues we would like having specialized astronomers as correspondents, so that we may include their contributions in our requirements, in a coherent manner. 6) Other details - is an audio channel from the antenna cabins to the operator planned ? (see comment 95) - We assume, as DSB mode is clearly an option for some frequency bands, that side band separation has to be handled by software for interferometric work in those bands. Robert Lucas, on behalf of the Science Software Requirements Committee