NRAO Home  >  Green Bank  |  Wiki Topic:    GB > Dynamic > DynamicSchedulingGlossary > WeatherQueue
   Changes | Index | Search | Go

Weather Queue and Sensitivity Calculations for the GBT - Under Development


Introduction

Determining the suitability of a weather queue for a given project with the GBT is a difficult task, as there are many factors in play. Opacity, cloud cover, outside temperature, wind, and time of day all are factors in deciding the suitability of running a given project. Also, though, one has to consider the desired sceintific outcome of a project. That is, if the project is a spectral line detection experiment of a narrow line, the investigators will likely have very different weather criteria then someone wishing to obtain continuum data of a small (point-like) object.

Additionally, any weather queue that is built for the GBT must be flexible enough to allow for seamless changes in the GBT weather criteria as the PTCS project progresses. E.g. if the PTCS project improves the pointing accuracy in wind, or increases the viability of observing high frequencies during the daytime, that needs to be seamlessly added into the queue information, without the investigators needed to know the fine details of the GBT PTCS models.

For the first stage of dynamic scheduling, we propose to simply create weather queues which the investigator can choose for her project. Accompanying the weather queues choices needs to be full documentation explaining how the investigator can convert the choices handed her to astronically interesting quantities (e.g. wind speed -> efficiency degradation due to pointing errors, Tsys -> rms). We also need to include enough information so that the investigators and the PSC understand how much time is available on the GBT for the various weather queues. This information should be used both to allow observers to make sensible choices about their chosen queues (e.g. not ask for 500 hours in a queue that may only have 300 hours available), and also allow the PSC to make sensible choices in assigning ranking to the proposals.

Details - The Weather Queue Choices

Opacity and Airmass

Opacities and airmass combine to increase the attenuation a signal will experience at a given elevation. Here, the signal is attenuated by the factor airmass*opacity. Opacity and and airmass, along with spillover and cosmic microwave background contributions, (what we'll call here Tsys') can be determined from the weather information available through Ron Maddelena's weather statistics. These contributions, added to the receiver temperature, provide the Tsys for the observations. As it is a readily calcuable value, Tsys' is an appropriate choice to use for one of the weather queue choices.

In an effort to keep all choices for the observer as frequency independent as possible, we propose to make four queues here, based off the amount of time a given Tsys' is available. That is, the four choices in this category will be: 25%, 50%, 75%, and 'any' Tsys' quartile, as shown in the middle panel of the following chart:

Here we will need full documentation explaining how the Tsys' value can be translated to sensitivity for spectral line, pulsar, and continuum (bolometer) measurements. This explanation will also have to include information on the recevier temperatures, to allow investigators to fully determine Tsys.

Wind

Wind speeds directly affect pointing, which in turn affects the telescope efficiency. Depending on their project, an observer my find wind speeds to be extremely important (e.g. a high frequency spectral line observation of a point source) or only minimally important (e.g. an detection experiment of an extended source). As such, investigators will also need to choose their wind speed category.

To again keep this as frequency independent as possible, we will use the PTCS criteria for wind speed, giving the observers three categories to choose from: good, usuable, or poor. These will translate directly to the PTCS tables for wind speed, which are replicated below. Note that these tables need to be updated from the PTCS ones to include Ka-band and to change the frquency of interest for Q band. Also, the numbers for the "poor" conditions need to be added.: MJM: These tables imply that the defintion of "Good" wind for X-band is different than that of "Good" for Q-band" (naturally). So for example, if the PI has specified good conditions and X-band (forget about other criteria for simplicity), then the DSS must consider receiver (or frequency , if one prefers) during the session selection/priority phase.

Table 1: Requirements, limits and observing strategies for "good" performance - (5% rms flux errors).

Receiver sortFrequency sortWavelength sortbeam FWHM sortrms tracking error sortaxial focus error sortwind limit (m/s) sortwind limit (mph) sort
L-band 1.4GHz 21cm 530" 75" 53mm Any Any
S-Band 2.0GHz 15cm 370" 50" 38mm Any Any
C-Band 5.0GHz 6cm 150" 20" 15mm 11 m/s 25 mph
X-Band 10.0GHz 3cm 75" 10" 7mm 8.0 m/s 18 mph
Ku-Band 15.0GHz 2cm 50" 7" 5mm 6.3 m/s 14 mph
K-Band - lower 20.0GHz 1.5cm 37" 5" 3.5mm 5.1 m/s 11 mph
K-Band - higher 25.0GHz 1.2cm 30" 4" 3.0mm 4.2 m/s 9 mph
Q-Band 52.0GHz 5.8mm 14" 2.0" 1.5mm Note 1 Note 1

Table 2: Requirements, limits and observing strategies for "usable" performance (10% rms flux errors).

Receiver sortFrequency sortWavelength sortbeam FWHM sortrms tracking error sortaxial focus error sortwind limit (m/s) sortwind limit (mph) sort
L-band 1.4GHz 21cm 530" 105" 105mm Any Any
S-Band 2.0GHz 15cm 370" 75" 75mm Any Any
C-Band 5.0GHz 6cm 150" 30" 30mm 14 m/s 32 mph
X-Band 10.0GHz 3cm 75" 15" 15mm 10 m/s 23 mph
Ku-Band 15.0GHz 2cm 50" 10" 10mm 8.0 m/s 18 mph
K-Band - lower 20.0GHz 1.5cm 37" 7" 7mm 6.3 m/s 14 mph
K-Band - higher 25.0GHz 1.2cm 30" 6" 6mm 5.8 m/s 13 mph
Q-Band 52.0GHz 5.8mm 14" 2.8" 3mm 3.0 m/s 7 mph

Table 3: Requirements, limits and observing strategies for "poor" performance (20% rms flux errors).

Receiver sortFrequency sortWavelength sortbeam FWHM sortrms tracking error sortaxial focus error sortwind limit (m/s) sortwind limit (mph) sort
L-band 1.4GHz 21cm 530" 105" 105mm Any Any
S-Band 2.0GHz 15cm 370" 75" 75mm Any Any
C-Band 5.0GHz 6cm 150" 30" 30mm ? ?
X-Band 10.0GHz 3cm 75" 15" 15mm ? ?
Ku-Band 15.0GHz 2cm 50" 10" 10mm ? ?
K-Band - lower 20.0GHz 1.5cm 37" 7" 7mm ? ?
K-Band - higher 25.0GHz 1.2cm 30" 6" 6mm ? ?
Q-Band 52.0GHz 6mm 14" 2.8" 3mm ? ?

Key to columns:

Quantity Definition Notes
Receiver Name of Receiver  
Frequency Typical (or upper) observing frequency  
Wavelength Wavelength corresponding to tabulated observing frequency  
beam FWHM Full-width half maximum of the beam at the specified frequency/wavelength  
rms tracking error The allowable rms tracking error which will result in "usable" or "good" performance. Note 2
axial focus error The maximum absolute axial focus error which will result in "usable" or "good" performance.  
wind limit (m/s) The approximate wind speed at which wind-induced tracking errors will exceed the limit for "usable" of "good" performance. Note 3
wind limit (mph) The corresponding quantity expressed in miles per hour. Note 3

Notes

Reference Note
Note 1 Even under benign conditions, the GBT does not routinely deliver good Q-band performance.
Note 2 "usable" and "good" rms tracking errors are defined as the values at which the expected rms flux errors due to tracking erorrs would be 10%and 5%, respectively. See PTCSPN 27? for more details.
Note 3 For frequencies below 25GHz, the wind limit corresponds to a wind-induced pointing error which, when added in quadrature to the "benign conditions" tracking error of 2.8", would cause the total tracking error to exceed the respective limit. For frequencies above 25GHz, the wind speed at which the pointing variance contributed by wind is one quarter of the total allowed pointing variance at the specified observing frequency.

Time of Day

The last choice the investigators will have is the time of day for the observations, with the two choices being "night" and "day and night". Here, night is defined as sunset+3 hours to sunrise+2 hours. We will also have a definition called "work day" for maintenance like activities.

Differential heating and cooling of the telescope alters the surface of the telescope, resulting in degradation of telescope efficiencies, and 'bends' the telescope, resulting in pointing changes. At high frequencies, these affects are important. The current recommendations are that, for best work, observing above 40 GHz should only be done at night, from 3 hours after sunset to 2 hours after sunrise. Low frequency observers may want to consider night time observing for two reasons. RFI is usually lower at night; and, in some cases, the sun has a slight negative impact on baseline shapes.

PSC Decisions and DSS "long-term" Schedules - How much time to each queue?

The GBT Proposal Scheduling Comittee (PSC) needs to have a rough idea of how much time is available in each weather queue in order to accurately asses proposal ratings without leaving the GBT with far too high a time request for a given queue. Additionally, the DSS needs to make telescope schedules (for the 1 and 2 week "look aheads"). Rather than having the PSC understand all 18 queues, and force the DSS to make 9 schedules, we will break the queues down into something simpler, along the lines of "excellent weather", "good weather" and "poor weather", with the exact definitions to be decided. MJM: Per Karen: we are temporarily tabling how many queues the DSS requires for look ahead and observer notification purposes. For session selection purposes, the DSS must evaluate all weather criteria. As it is currently understood, the best wind conditions are the least likely to occur. Therefor when promoting sessions during the session selection process, wind is the first criteria for session promotion. Promotion only occurs when there is are no sessions requiring the current weather and wind conditions.

Current Documentation

The best documentaion we currently have on the choices faced by observers are available here:

-- KarenONeil - 25 May 2006

Topic WeatherQueue . { Edit | Attach | Ref-By | Printable | Diffs | r1.13 | > | r1.12 | > | r1.11 | More }
Revision r1.13 - 02 Jan 2007 - 22:40 GMT - KarenONeil
Parents: WebHome > DynamicSchedulingGlossary
Content copyright © 1999-2007 by the contributing authors.
All material on this collaboration platform is the property of the contributing authors.

Dynamic.WeatherQueue moved from Dynamic.WeatherCalculator on 07 Jun 2006 - 10:06 by KarenONeil - put it back