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
-
JObserve and Observe can be used to check LST to UTC conversions.
-
IAT is the time recorded in the archive now. In the WIDAR era it will be UTC.
-
Bryan noted that single sign-on has been accomplished for the archive.
We can see John Benson for technical details.
-
Bryan will do some script testing this week but will then be away for
two weeks. Three phases to testing: visual inspection, running of simulator,
running on the array.
-
The group mentioned that the ability to export / import a project (using XML)
would be a valuable feature of the OPT. We'll schedule that task for the
upcoming quarter.
-
We spoke a little bit about the group's focus for 2008.Q4. WIDAR is the number one
priority. Any incomplete Q3 goals will be carried to completion in Q4. We expect
new users in Q4, and we have the holidays at the end of the quarter, so Dave thinks
we can tackle only one additional large scale goal. Candidates so far are the
dynamic scheduler and a tool to create projects from proposals. Bryan pointed out
that SSS does not need to provide tools to TAC for wrangling proposals; our work
starts after TAC has allocated time to proposals. This makes the scope somewhat
smaller and perhaps we can advance the scheduler and make a start on the project
creation tool, too.
* * *
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.