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.