Minutes from SSS Mtg 2008-Sep-30

Attendees: B.Butler,   M.Claussen, D.Harland,    B.Hesman, G.v.Moorsel, F.Owen,
           J.Rochford, M.Rupen,    L.Sjouwerman, B.Truitt, S.Witz

Doppler Tracking

We first discussed the layout for specifying central frequencies in the hardware configuration area. The group liked best a modification of Gustaaf's proposal. It will look something like this:

        +-------------------------------------------------+
        | IF AC                                           |
        |                                                 |
        |  ◉ Rest Frequency: user-input-value-here        |
        |                                                 |
        |  ○ Central Sky Frequency:                       |
        +-------------------------------------------------+
        | IF BD                                           |
        |                                                 |
        |  ○ Rest Frequency:                              |
        |                                                 |
        |  ◉ Central Sky Frequency: user-input-value-here |
        |    Sky Frequency Range:   calculated-range-here |
        +-------------------------------------------------+

We then took a look at the specification of velocities and positions used for Doppler tracking at the scan level.

Change to make now: In the POSITION column change the "Enter Value" label to "Enter J2000 Coordinates".

In addition to using the position of the target source or a directly entered position, the scientists also expressed a desire to be able to use the position of any source from a catalog. The programmers mentioned that this was problematic because sources in the catalogs might have their positions expressed in terms of an ephemeris table or table of polynomials. The solution agreed upon was to take a snapshot of the source's position and warn the user if the source used was a moving source.

Lorant reminded us that the scan should have an additional button in the Hardware Setup column that allows one to use the hardware configuration from the previous scan. The script building logic would then understand that it should leave that configuration exactly as it was when the previous scan was run; i.e., it should not recalculate sky frequencies.

This led to a discussion about specifying Doppler tracking at the scheduling block level. The programmers will need more details about this before doing any work on this feature. The idea [warning: i might have misunderstood this] is that if one is running multiple scans on a give source, "S", perhaps with calibration scans interspersed, every time we run a scan on S we should use the same LO / IF setup. For the first such scan we may have done a Doppler calculation, but we would not be doing that for each subsequent scan of S. This might mean that at the scheduling block level we would need to hold a Doppler specification per source. There are probably a few ways to slice this problem; we'll wait until we understand it better before proposing solutions.

* * *

EVLA Test Programs

Lorant submitted a ticket to the help desk for them to update all machines to java 1.6. Dave demonstrated a few of the programs and noted that the SSS Doppler calculations, which wrap a java port of SLALIB, come close to, but do not exactly match, values obtained from the on-line Dopset program. The group speculated that aberration could be the culprit and also noted that from Dopset to Modcomps to JObserver to AIPS we have a history of these small discrepancies. It would be nice if all systems used the same code, or at least algorithm, for calculating the velocity of the VLA toward a point in the sky.

* * *

Miscellaneous Items

* * *

Status Update

The following items were identified in the document OPT status per July 2008 and early Ka-band observing, Sjouwerman, van Moorsel, & Claussen, as requirements to be met in order to use the new applications for early Ka-band observing.

1. Proper documentation
The programming work needed to support this is done. The remaining work is the writing of the text itself.

2. A stable and robust web interface from users both outside and inside the DSOC
We did two things this past quarter on this topic. First, we increased the time-out values of the applications from 30 minutes to 4 hours. Next, we now automatically save unsaved changes in the event of a system time out. I do not believe we have had much usage of the applications from clients outside the DSOC, so the stability and robustness (and performance) has not been assessed for those clients.

3. A single login to the NRAO user database for web interface
We reached an agreement with OEO (formerly E2E) to get time from OpenSky to address this issue. Single login will be an offical 2008.Q4 goal.

4. Generation of readable summary listings
We implemented the initially specified reports and have made changes to these based on comments from the scientists. While we will probably fine tune the reports over time, they are in pretty good shape right now.

5. An improved (or improvement on the current) calibrator search tool
We made a lot of improvements to source searching. Users can search multiple catalogs by name, position (cone and box), calibrator code, and flux density, or a combination (using "and" logic) of any of these criteria.

6. Writing correct observing scripts and their complete testing
The OPT can be used to generate an observing script from the project model. The programming effort has been done, the testing remains.

7. Implementation of Doppler tracking
The OPT now allows users to specify Doppler tracking information at the scan level. At the time of hardware configuration, the user now states only whether a central frequency for an IF is a rest frequency or a sky frequency. The model code is using SLALIB to calculate earth velocity toward a sky position. The model2script code bases LO/IF settings on sky frequencies, where those frequencies have either been specified directly or calculated from rest frequencies, accounting for source velocity, earth velocity, and the time the scan is to be executed.

8. Capability to specify dynamic constraints
The OPT allows users to specify wind velocity and API constraints. Next quarter it will also allow users to specify minimum angular separation from the sun. Next quarter we must also communicate these constraints to the scheduler.

9. Successful testing of pointing and fast-switching scans
The model2script code handles pointing scans. By "fast-switching" I believe was meant the ability to make scan loops containing scans whose durations are small. In any case, the programming is complete and testing remains to be done.