In the Time Estimation Details the times sometimes do not agree with those in the Time Estimation Summary.

- Implication for user: Minor inconvenience when Time Estimation Details are displayed.

- Recommended action: The times given in the Time Estimation Summary are the ones that should be used.

When working near the limit of the WBS, the time estimation for an observation will jump suddenly for a very small change in the Res. Max. value .

- Implication for user: If you set, for example, observation parameters that are - LO frequency = 532 GHz, observing mode = DBS, noise goal for max width = 0.008 K, spectrometer choice = WBS + HRS, the total time estimate for the observation will increase by a factor of 2 suddenly between Width = 0.62 and 0.63 km s-1

- Recommended action: This is a feature of HIFI when close to the limit of the WBS. Below 0.63 km/s, the resolution is too much for the WBS, but you can get it with the HRS -- that is what you get in the noise calculator. If you put in line widths larger than this, then the lowest resolution information can be obtained with the WBS but this has a fluctuation bandwidth nearer 1.6 MHz. Note that the noise estimator allows you to calculate the noise at high resolutions and low resolutions at the same time. So you can always use this to get WBS and HRS noise values at the same time for two resolutions you are interested in.

So -- you see a jump in the effective fluctuation bandwidth being used for your observations due to the fact that you chose a line width for the lowest resolution in the time estimator that was right on the edge of what is possible with the WBS and below this value the time estimator had to consider using the HRS instead (which is also somewhat less sensitive)..

When HIFI AORs are saved to disk and read back in an error message may be shown stating that an AOR is invalid because the value for "Frame" should be one of "LSR", "Heliocentric", or "Geocentric". This happens because when the AORs are written back to disk they may be saved as all lower case.

- Implication for user: Inconvenience only

- Recommended action: HSpot 6.0.0 will now automatically set anything appearing as "frame=heliocentric" to "frame=Heliocentric", and that it is strongly advised to verify that this frame is indeed the one intended for a given AOR.

There is a known bug in the LO frequency computation when a high velocity/redshift change is applied to an existing frequency setting. For high velocity/redshift, the new LO frequency is not fully accurate and therefore imply that the line position in the IF is not properly maintained. This means for example that HRS sub-band previously set may no longer cover the lines of interest once the LO frequency shift is applied.

- Implication for user: Potentially serious.

- Recommended action: When observations at high velocity/redshift are prepared, it is adviseable to prepared their frequency settings from scratch instead of adapting an already existing AOR done at another velocity/redshift. On existing AORs, users should verify that the respective spectrometers do cover the lines of interest as requested. HSpot 6.0.0 will now issue a warning message whenever a redshift change is involved in an AOR which does not have an initial redshift value of 0.

The frequency range restriction applying to the manually entered values for "Observed frequency" or "Rest frequency" in the frequency editor will be the same for the WBS and the HRS. Because this restriction takes into account the HRS sub-band width in the case of this latter backend, the range of frequency allowable for the WBS will be slightly truncated by this small margin.

- Implication for user: Mainly an inconvenience only

- Recommended action: The user has to accept this, "as is".

A serious bug has been found when working with HIFI in HSpot with Linux SUSE 9.1 and the KDE window manager. This bug, which is in KDE, causes system crashes when windows are opened to define HIFI AORs.

- Implication for user: Serious.

- Recommended action: Do not try to run HIFI AORs with this OS/platform combination.

From HSpot 5.0.4 onwards, the treatment of the spacecraft velocity shift needed on the HIFI Local Oscillator (LO) frequency has been revised. So far, HSpot was only taking care of the shift due to the source velocity entered by the user in the AOR main panel. At the time of submission, the Mission Planning System was using the reference frame provided by the user and did compute the remaining Spacecraft velocity at the time of the observation. For the LSR frame, which is used by most of the HIFI observations, this velocity can be as high as +/- 51 km/s. However, an erroneous truncation did apply in the uplink code used so far, which clipped this velocity to +/- 31 km/s. The effect was only really noticeable in HRS observations, where the intended line could appear mis-centred compared to the sub-band centre, and in the worse cases (at high frequencies) drop outside of the band coverage.

When this error was discovered, the HSC took measures to not schedule observations where this truncation applied so that the effect on observations collected so far was extremely limited. By waiting a couple of weeks usually, the velocity applying to a given observations would fall within the acceptable limit so this also did not force us to delay observations too significantly.

In order to solve this problem, HSpot will automatically shift the LO frequency into the Solar System Barycentre (SSB) frame, in which the Spacecraft velocity is always within the +/- 31 km/s range. In this way, the uplink code will never abusively truncate the intended LO frequency. In effect, this means that beyond HSpot, all observations will be treated in this common SSB frame. Of course this additional redshift will be considered on top of the source velocity that has been entered by the user in the main AOR panel.

There are some important consequences to take note of here:

1.- This shift is NOT date-dependent and only varies on the source co-ordinate. This is why when changing source in a given AOR, HSpot will ask you whether you want to apply the corresponding frequency shift to the existing Local Oscillator setting in your AOR - you should say YES.

2.- This shift does NOT apply to moving targets because the spacecraft velocity with respect to the target will always depend on the date and will be fully computed by the Mission Planning System at the time of observation.

3.- This shift does NOT apply to Spectral Scans because there is not entry for redshift of velocity frame needed in this mode.

4.- Most important: if you re-load an AOR prepared by an HSpot version older than 5.0.4, HSpot will not apply this correction as it will assume that this latter was already applied when the AOR was initially designed. So In order to have this additional correction properly taken into account the frequency setting has to be prepared from scratch in the frequency editor. This means that if you want to re-use AORs that you may have prepared in earlier programs with HSpot version older than 5.0.4, you will have to reset the settings in the Frequency Editor window.

For already existing AORs in the HSC data-base, a bulk correction has already been applied and we will contact each user individually to inform them about the changes.

A serious bug has been found when working with HIFI in HSpot with Linux SUSE 9.1 and the KDE window manager. This bug, which is in KDE, causes system crashes when windows are opened to define HIFI AORs.

- Implication for user: Serious.

- Recommended action: Do not try to run HIFI AORs with this OS/platform combination.

There is a bug in the frequency editor when only the HRS is to be used. In the first (or only, if high-resolution mode is selected) scroll-down menu for the transition, the menu only features the -no line- tab, despite the presence of an available transition in the window of interest.

- Implication for user: the user cannot select the transition of interest in the first HRS sub-band scroll-down menu.

- Recommended action: we can propose two work-arounds for this problem:

i) Select WBS simultaneously, then go to the frequency editor to assign the lines as needed (the bug does not apply then). Go back to the main window, deselect the WBS: the settings are kept for the HRS (please check again the settings in the frequency editor to confirm that they have remained as desired).

ii) The second approach consists of filling in manually the value of the requested frequency in the "Observed Frequency" box (it should turn white when ready to be filled in). Click somewhere else in order to get the chosen frequency applied.

HIFI time estimation can take more than the nominal 10 seconds for AORs of more complicated modes (spectral scans and mapping AORs with OFF positions). In extreme cases a time estimation make take up to a minute. Users should beware not to hit the Abort button too soon!

Note

This problem has been greatly reduced since the release of HSpot v3.3 and the situation appears to have improved slightly more since HSpot v3.4, but may still be important on occasions when the system is under heavy load such as before a call for proposals. For most HIFI modes the 5.* HSpot version is tolerably quick at time estimation, but large numbers of HIFI AORs may still take a long time to estimate even with no other system load. Important changes in the Sequencer code for HIFI in HSpot 6.0 have made time estimation slightly slower again, but only by about 8%. Users may notice that it takes slightly longer to estimate their HIFI AORs.

- Implication for user: Can be serious. HIFI time estimation may be extremely slow if many AORs must be computed.

- Recommended action: This problem is particularly serious when there is heavy load on the system, but there is no real solution at present apart from exercising patience. The user should be aware of this and try not to run large numbers of time estimates at peak times (e.g. near an AO closure).

For the HIFI load chop with OFF and frequency switch point modes there is the possibility of providing an OFF position that is offset in RA and Dec from the target position. Currently, if the offset reference box is checked then the following two errors are seen.

1.- If any RA offset is used the OFF position does not change its RA but changes its declination position in the visualisation overlay instead.

2.- The target position (on position) is not shown at all.

- Implication for user: Visualisation of AORs does not work correctly. AORs must be hand-checked to ensure that they are correct.

- Recommended action: If an offset in declination only is used then the visualisation is correct.

Time estimations for spectral scan AORs currently will not be given accurately if nominal times (a few minutes) are placed as a time goal to scan a whole band.

- Implication for user:

- Recommended action: Users are advised to use time goals closer to the minimum times needed (3000+ seconds).

When the WBS-only is selected, the best goal resolution possible should be at least 1.1 MHz. However, in the default time estimator window, this value is set at 0.480 MHz, which will result in an error and an explanatory error message. When the WBS-only is selected, the user should adapt the best goal resolution possible accordingly.

- Implication for user: .

- Recommended action:

In the Time Estimation Details the times sometimes do not agree with those in the Time Estimation Summary.

- Implication for user: Minor inconvenience when Time Estimation Details are displayed.

- Recommended action: The times given in the Time Estimation Summary are the ones that should be used.