Mon Jul 8 08:51:44 METDST 2002 ---001-------------------------------------------------------------------------- (joeSchwarz) ---002-------------------------------------------------------------------------- (prebenGrosbol) ---003-------------------------------------------------------------------------- (tonyWillis) ---004-------------------------------------------------------------------------- (wimBrouw) ---005-------------------------------------------------------------------------- (joeSchwarz) p. 1 3.8.2 Sensitivity calculation 8.2-R1 It's not clear to me that this is really a simulation; isn't it more an estimate, or an approximate calculation, of the sensitivity levels and dynamics ranges. I don't see any data being *simulated* here. I'm also puzzled by the 0.1-5 minute execution timescale. What kind of calculation could require 5 minutes, even on an ordinary laptop? I think that this section ought to be aligned with what's already in 3.3.1-R11. Maybe this section and 3.3.1-R11 could be combined... In 3.3.1-R11, there is a requirement there to estimate dirty beams, which doesn't appear here. Finally, since the PI would normally specify SNR and get integration time as a result, I think that this calculation needs to be able to go both ways. REPLY: The sensitivity estimate is not that straightforward as system noise depends on elevation and atmospheric transparency, thus on the hour angle when the observing is done. Also the noise is frequency dependednt across the bandpass ... one might be tempted to do too much here hence the time limit (may be should it be lower like 1 minute?). We'll add the dirty beams. 3.3.1-R11 has been grought down to a mere reference to the present section (as discussed in Granada). Doing it both ways is a good suggestion that we accept (get the integration time from the sensitivity required). ---006-------------------------------------------------------------------------- (prebenGrosbol) p.1 3.8.1 8.1-R2 'Relevant parts ... should be available early in the software production cycle ...' . Although this is correct, it is rather a software scheduling issue than a SSR. REPLY: We still believe it's useful here: otherwise why should we have set priorities in general? ---007-------------------------------------------------------------------------- (prebenGrosbol) p.1 3.8.1 8.1-R3 'schedule preparation phase' suggests a certain operations model where somebody runs and checks simulations before scheduling is done. This seems to be a very complex operations model. If this is required, it should be added to the Scheduler requirements in e.g. 3.4 Dynamic scheduling. 'preferably integrated seamlessly' seems to be a design or/and implementation issue which in principle could be repeated for all parts of the system. REPLY: - By 'schedule preparation phase' we think rather of long/mid-term scheduling, i.e. as an aid to the staff people that will decide on the schedule of the reconfiguration operations (antenna moves). This long/mid-term scheduling is considered as an input the short term dynamic scheduling, which is the subject of 3.4. - Seamless integration is a general requirement that particularly needs to be mentioned here (as we have here two rather different software systems that have to be used at the same time in a sort of iterative, interactive way. ---008-------------------------------------------------------------------------- (prebenGrosbol) p.1 3.8.1. 8.2-R1 'schedule preparation' see comment above on 8.1-R3 REPLY: See reply above (007) ---009-------------------------------------------------------------------------- (wimBrouw) p. 1 3.8.1 Capability .... for planning OF OBSERVING PROPOSALS (with ....reduction), AND TESTING OF DATA REDUCTION PROCEDURES AND THEIR RELIABILITY. Various ... REPLY: Accepted. ---010-------------------------------------------------------------------------- (wimBrouw) p. 1 8.1 -R3 A primary ...simulator DURING OPERATIONS is ... REPLY: I do not understand, this is not during observations? ---011-------------------------------------------------------------------------- (wimBrouw) p. 1 8.2-R1 ...should CONTAIN a validity ... REPLY: I do not understand ?? [validity wad in a validation requirement that we dropped in Granada, and thus was no more in the version to be reviewed] ---012-------------------------------------------------------------------------- (wimBrouw) p. 1 8.3-R1 - it says 'sensitivity levels'. Is a table expected for say point sources; and for various surface sensitivities? - it states a variety of parameters; but misses on spectral resolution (or continuum bandwidth; calibration strategies. Is this all embedded in 'configuration? But where is than the spatial resolution taken care of? REPLY: [8.2-R1] The plural is just for different spectral resolutions observed simultaneously. We forgot spectral resolution and bandwidth here (to be added). Configuration should be 'array configuration', which is in fact determined by spatial resolution. ---013-------------------------------------------------------------------------- (joeSchwarz) p. 2 8.3-R8 & R9 In both of these sections, we need a bit more clarity. What is the purpose of each simulation (e.g., what parameters of his/her observing program would an observer change as a result of the simulation)? What goes in? What comes out? In the same vein, array configurations would be *selected* rather than "simulated". (Although it would be useful for the proposer to be able to get an answer to the question "What fraction of the year will ALMA be in configurations that can be used by my program? I didn't think that was what you had in mind for this requirement.) The "interactive response" required by 8.3-R8 and the availability to the general user at proposal preparation (8.3-R9) should apply, I think, not (just) to the simulated data, but to the results of processing that data through the pipeline. The proposer, after all, will want to see what kind of image he might get under the hypotheses of the simulation. Do you expect pipeline processing to be available to the astronomer who is preparing an observing proposal with the OT? If so, this has major implications for the software and the need for connectivity to a pipeline service (I don't think that we want to force proposers to load AIPS++ onto their laptops--especially those on which it won't even be supported). Or did you have in mind some kind of "light" pipeline (in which case it needs to be written!). REPLY: The main parameters the user is expected to change are sensitivity requirement and angular resolution. First time users have a hard time understanding that these two parameters are so intimately related. The simulator is there to help them see the limits of what can be dome on a realistic source model. Array configurations would not be directly selected, but rather selected by the OT on the basis of a resolution requirement from the user. The Simulator should use the configuration as an input from the OT. It's observations in selected array configurations that are simulated, yes. We expect the simulator to be closely related to the data reduction package (e.g. aips++) in which the data reduction of the simulated data will be done to produced images. This is a subset of the pipeline of course (mostly single-channel data). It seems more realistic that the OT in order to get the simulation done connects to a server that will do the simulation and associated data reduction (that server may be the user's laptop of course). But isn't this implementation? ---014-------------------------------------------------------------------------- (prebenGrosbol) p.2 3.8.3 8.3-R11 'preferably integrated with the off-line data reduction package' Although it sounds nice, it is not clear if this is the better approach. A separation between the simulator and data reduction package would make a possible to test one with the other and thereby find errors which otherwise would be difficult to locate. REPLY: I agree with you. We should rather say that the user interfaces are integrated (to hide the actual interface from the user). The actual modules should be well separated (as they are more or less in the WBS). ---015-------------------------------------------------------------------------- (tonyWillis) p.2 8.3-R4 The requirement that all Baseline correlator modes should be supported is only given priority 3. While it would probably not be necessary to simulate the behaviour of the entire correlator for proposal preparation (where we probably mostly need information re UV coverage, noise level etc) it will be necessary to do so in order to test the throughput of the pipeline and of the offline reduction package. So I would give this requirement a priority of 1. REPLY: Following this we would get only priority 1. We agree that the feature is needed, but we need priority ranking. The data reduction developers might want to have it available early for their own purpose, but the ALMA user will most likely not need this at such a high priority. ---016-------------------------------------------------------------------------- (wimBrouw) p. 2 8.4-R1 - is the word 'simple' here correct? Simple is ok for the observing tool phase to get to estimates of sensitivities and dynamic range. Simle is not sufficient for data simulation - .. given observing parameters and models of the instrument, atmosphere AND SKY, INCLUDING SPECTRAL DISTRIBUTION REPLY: [=8.3-R1] - what we list here is not *that* simple, if you add all priority 3 items. Data reduction may want to do more, but this may be a waste of time as we do not know yet many of the *complicated* effects that will appear when the instrument is built and tested. - add reference to source model. ---017-------------------------------------------------------------------------- (wimBrouw) p. 2 8.4-R7 Too restrictive. What about a spectral line profile. It would be essential to be able to model the full line too see the effects in possible broad wings. REPLY: [8.3-R3] The atmosphere model will compute the atmospheric line wings. ---018-------------------------------------------------------------------------- (wimBrouw) p. 2 8.4-R9 ... minutes FOR a ... REPLY: OK ---019-------------------------------------------------------------------------- (wimBrouw) p. 2 8.4-R13. - I suppose this too provide a real-life noise and systematic error basis for simple source modelling; and as a base for Monte Carlo experiments? REPLY: [=8.3-R12] to simulate other, similar data taking and get an idea of the imaging fidelity, but also to simulate how specific observations could be improved by adding data in different configurations. ---020-------------------------------------------------------------------------- (prebenGrosbol) p.3 3.8.3 8.3-R12 'incorporating' should be clarified. Either is it almost identical to 8.3-R10 or done by the data reduction package which will combine real and simulated data. REPLY: see 019. We'll explicite. ---021-------------------------------------------------------------------------- (remoTilanus) Aloha Gianni, I have essentially no comments on the section '3.8 Simulation'. Goals as for the rest of Alma are laudable but challenging. Given the sophistication of the simulation package proposed, better make very sure it is labeled as 'simulated' data or otherwise recognizable as such. REPLY: Unfortunately, your comment prevents ALMA from saving a lot of money on hardware ... _____oOo_____