Minutes from SSS Mtg 2008-Aug-05
Attendees: B.Butler, M.Claussen, D.Harland, G.v.Moorsel,
J.Rochford, M.Rupen, B.Truitt, S.Witz
Doppler Tracking: Velocity Input
The programming staff will update the VLA Correlator configuration user interface to take a velocity and rest frame for each of the IF pairs. We had originally planned to pull the velocity from the source attached to a scan, but have backed away from this. At the bottom of this page is an email exchange between Michael and Dave that gives the reasons for this change.
* * *
Scheduling Block Summary and Time Conventions
(This was discussed at the end of the meeting, so these notes are a little out of order.)
Dave pointed out that we are currently displaying scan start and stop times in LST, but are using solar seconds for slew time and on-source duration. The programmers wanted to know if we should instead show all four columns in the same time basis -- either solar or sidereal. Bryan said we should, but that we should add a choice for the user to display these as either LST w/ sidereal durations, or UTC w/ solar durations.
The shocker for the programming staff was the revelation that the durations and stop-times for scans, as input by the user in the OPT, should be interpreted and used as sidereal times. Up until now the programmers have been using UTC for point-in-time values, such as scan stop-times, and SI seconds for durations, such as on-source times for scans. We need to go back and assess the impact of this discovery. LST has been used only for display purposes thus far. Ouch.
* * *
Source Searching
Brian gave a demonstration of the new source searching mechanism and explained some of the reasons for the way things are as they appear. He reminded us of some of the goals of his latest work:
Brian began to discuss some of the changes he made, but we quickly moved to giving him a list of to-do items. Below is that list, along with previously known to-do items.
* * *
The following is an email from M.Rupen to D.Harland on 2008-07-31 in response to questions posed about Doppler tracking and use of the velocity(s) held by the source used in a scan.
Hi David,
we should probably sit down together and talk about this. I have two
major concerns.
First, I am worried that old-style (VLA Ka) observing is driving the
design. Doppler tracking is a major issue right now, only because of the
VLA's peculiar hardware constraints: basically the correlator allows only
narrow bandwidths with very few channels, so one *must* Doppler track under
many (if not most) circumstances. Further, the VLA's LO hardware means we
can track at most two Doppler velocities at a time. By contrast WIDAR offers
so much flexibility that we initially declared there would be NO Doppler
tracking, and even now see that as quite a low priority waiting on our
understanding of how the EVLA should be used in practice. If we *do* turn
on Doppler tracking, there is an argument for allowing separate Doppler
velocities for every sub-band, if those are tuned to different spectral
lines (the Station Board mixers do allow sufficient flexibility for this).
I am not sure that what we come up with for the current limited system
is really what we'll want in the long term. I wonder whether we wouldn't
be better off quite explicitly working towards the old-style VLA case,
and relinquishing the hope that the resulting model will be easily
extensible to the EVLA.
Second, I at least am getting confused by the conflation of Doppler tracking
and source velocities. My recollection is that we introduced source
velocities to allow people to say "I want to observe this line over this
velocity range with this spectral resolution", and have the OPT come back
with suggested setups. These line-filled regions might then also be passed
on to post-processing for use in data reduction and interpretation. So basically
those velocities have *scientific* rather than hardware content: the
information might be used to produce helpful suggestions/defaults by the
various tools, but is not used to set up the instrument directly. By
contrast, Doppler tracking modifies what is actually done during the
observation, and is tied much more directly to the hardware. For instance,
the number of independent Doppler settings is limited by (1) the number of
independently tunable LO chains (two for the EVLA), and (2) the number of
independently tunable filters in the correlator (128 for the EVLA); while
scientifically one may have an arbitrary number of separate source/line
velocities, which may or may not fall within different LO chains or even
sub-bands.
Perhaps we need either to re-define the source velocity to mean
the Doppler tracking velocity; or to allow independent specification of the
Dopper tracking and the source velocities. Is there anything else in the
source model which directly sets the hardware? The source position comes to
mind :) but is there anything else? If not that might indicate that the
source model is the wrong place for the Doppler shift. This goes along with
Lorant's idea that we may wish to Doppler track an entirely different
source, since that also does not fit our old idea of the source model.
On your specific question, perhaps one should allow one Doppler tracking
velocity per source (not even subsource!) per LO chain (two for both the VLA
and the EVLA). As stated it's not obvious to me that this belongs with the
source model, especially since we do need to allow for *two* simultaneous
Doppler settings, which makes the source model approach awkward.
TTFN,
Michael
The following is the reply to the above from D.Harland on 2008-08-01.
Michael, Let me clear up the misconception about Doppler shift logic being part of the source model. As i understand the problem, which could be flawed, the observer has some line they want to study, and they know that the object emitting that line is moving at some reasonably well known velocity relative to a given frame. They do not know when their observation will be executed, so they cannot hope to tell the OPT what the complete relative velocity between the VLA site and the emitter will be at that time. Our software has to be able to figure out how fast the VLA is moving relative to the given point in the sky and rest frame at a particular point in time. The logic to perform this calculation is outside our source and project models, lying instead in a general purpose area. The sky position input, though, will come externally from the source being observed. The general purpose logic, though, is blissfully unaware of who provided it with a sky position. Up until now i had assumed the the "reasonably well known velocity" was a property of the source, and that we would create the total relative velocity of the VLA to/from the emitter by adding the source velocity to the calculated velocity just prior to creating the execution script. What i think i hear you saying is that it's probably better not to use any velocity data from the source in this calculation. If, as you say, in any one scan one can Doppler track using more than one velocity (eg, 2 for VLA, 128 for WIDAR), then i, too, would be in favor of not using the source as the source(!) of this information. Perhaps the instrument configuration needs to ask for Doppler-tracking- velocity information. I would think this would be both the velocity value and the frame against which that velocity is measured. (If we could dictate a single frame and not ask, so much the better.) The observer would understand that the total Doppler-tracking-velocity could be determined only at execution time, in order to acct for the relative VLA motion at that time. For the Ka-band VLA project, we would accept an A/C velocity and a B/D velocity. For WIDAR, perhaps it would be subband based (or higher level w/ ability to override at subband). Am i getting this? David