Subject: RE: Feedback on GBT Configuration: Requirements and Algorithms From: "Ronald J. Maddalena" Date: Thu, 15 May 2003 15:11:22 -0400 To: "Frank Ghigo" Frank, Here's a draft of a response to Mark and Melinda's questions. Make any changes you'd like and we'll send it out. Ron ===================================================== Mark & Melinda, Thanks for the comments and suggestions. We knew that two minds were not enough to peg down every detail and nuance. We also knew that, to keep the memo a reasonable size, we had to keep some discussions short. We voiced our anticipation that a round of discussion would have to follow the memo. You're the first to join in that discussion. Below are succinct responses to your suggestions. We suggest that many of your questions, and new ones that will arise from our responses, should be discussed in a small working group for a couple of hours. We expect that the working group will help provide a few addendums to the memo. Note that the UI group is almost finished with their work, and some answers and many more questions will come out of their summary. What do you think about holding off getting together for those few hours until after the UI group has published its work? Ron and Frank Here's our responses: [1] It was a close decision and we started with your suggestion and rejected it. For example, observers have used the spectral processor (and eventually the spectrometer) for continuum observations so the backend and obstype are not redundant. [2] In the plan that is emerging, there doesn't look like there will be an independent "configuration" tool. Rather there will be a command-line UI with tweaking functions and a "configuration" function built out of the tweaking functions. The details of the tweaking and configuration functions are being expounded upon by the UI group. [3] At the time the memo was written, the two parts of the K-band receiver were going to be combined into a four beam, 18-26 GHz receiver, instead of two, 2-beam receivers (18-22, and 22-26). Since then the plans to join the receivers were cancelled due to lack of resources. [4] We considered your suggestion and rejected it. When other switching modes get added in the future (e.g., beam switching with a tertiary), the number of enumerations for a combined SwMode/SwType keyword would become unruly and confusing. Additionally, picking a SwMode and picking a SwType changes the M&C system and hardware in very different and mostly orthogonal ways. [Note that we cannot expound upon the new switching types since they depend upon hardware we know will be coming in the next two years but that has not yet been specified, let alone designed. Thus, we're trying to have a proper growth path in the design of the keywords.] [5] Backend secondary keywords are listed in the text and subsequent sections. We can help you with this if you like. [6] Here we differed in what we wanted. Ron sided more in what you are argue for. Frank had equally valid arguments. [7] At this time, the management decisions is that multiple backends are not to be considered until a much later date. Our document follows that decision and postpones exploring the subject. It's a very difficult subject since we'd first have to specify or assume major changes to hardware (e.g. switching signals, redesign of the SP and Spectrometer signal interfaces, ...) before we could specify what the software is to do. That is, we deliberately punted. [8] Instead of a rewrite, we think it would be more productive to work with you to expound on this section. [9] Sure. Make us a copy. [10] We think the bullets toward the end of the page will answer your question. [11] In our experience of setting the path for various observations, we seem to be considering only the primary keywords. Do you have an example of when a secondary keyword influences the signal path? [12] We didn't think so. The current IF Rack manager does all the work for us when we set things up via CLEO or glish scripts that don't consult the cabling file. All we ever do these days is set the transfer switch if we want a OD other than the one the IF Rack picks for us. The IF Rack manager apparently must be consulting the cabling file internally. No need to reinvent code that Mark has already implemented. [13] We don't think this is the case and we can work with you to explore why this is so. [14] The diagram only shows a small subset of the branches in the tree. It's representative, not comprehensive and so shows branches that are never explored and does not show many branches that should be explored. [15] This is to cover parameters like Rcvr1_2(CryoState) which an astronomer should never touch. Replace "default" with "current". [16] Note that CLEO and Frank's Glish scripts include the antenna (and do a regChange) and we have not had any problems. [17] Is this in addition to setting the power levels and frequency? We suggest your list and ours be combined. [18] This is stated in the comments after the table. We wanted to only list keywords in the tables. [19] The switch has no function other than for the SP and, therefore, can be safely ignored. [20] Yes, we weren't explicit enough. The DCR is connected to both the AFR samplers and converters. [21] Correct, our oversight. [22] It looks like you might have a wrong page number here. [23-24] You're right but we don't think this will lead to any confusion as to what is being meant. [25] Let's wait and see if the UI group has any suggestions of what they think astronomers will want to see as keyword values. Although not necessary, it would be best if the keyword values and those presented to the user via their interface have some commonality. [26] Great! [27] Intentional, since it is not an astronomer's device just like the quadrant detector, servo monitor, etc. [28] It's unclear what you mean. The LO1 ifCenterFreq is explicitly set in section 6. The DCR test Tone may be a parameter we should have explicitly listed since it can affect observations. [29] Yes. The order in which keywords are used will be important and probably will be discussed by the UI group's memo. > -----Original Message----- > From: Melinda Mello [mailto:mmello@nrao.edu] > Sent: Thursday, May 15, 2003 10:24 AM > To: rmaddale@nrao.edu; fghigo@nrao.edu; mclark@nrao.edu; nradziwi > Subject: Feedback on GBT Configuration: REquirements and Algorithms > > > Hi, > > We have read the "GBT Configuration:Requirements and Algorithms" > document and attached our questions. > > I'd like to mention that Section A.9 is especially useful: Your > specification of the spectrometer setup using meta keywords instead of > mode strings, enables the software group to move forward with the > configuration of the system (If and when it is scheduled). Likewise, > the spectral processor and BCPM sections are equally useful. > > Melinda and Mark > > >