Minutes from SSS Mtg 2008-Sep-16

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

Scan Summary Reports in the OPT

Most of the meeting was spent looking at the scan summary reports. A number of suggestions were made and are listed below.

First Table

  1. Use abbreviations for some of the column headings to save horizontal space.

Second Table

  1. Needs a different title. Suggestion: "Time on Source Summary". (With an indication of whether or not LST or UTC is being displayed.)

  2. Make the first column the next-to-last column and change its content. Instead of a single scan ID, make this a count of the number of scans using this source / resource combination.

  3. Display a maximum number of decimal places of 5 for RA & 4 for Dec.
    [DMH technical note: in the toString method, let minDp be 1. That way those values that were entered to, say, only 2 dp will show up w/ 2 dp and not mislead people into thinking the value was measured to 5 dp where the msmt just happened to end w/ "000".]

  4. We'll need a velocity value for each IF pair.

  5. If we're not Doppler tracking for a particular row of the table, use something that make that obvious, such as "---", "n/a", or some other text.

  6. Add hour angle and parallactic angle ranges to this table.

Third Table

  1. The user specified start LST on the summary page does not work anymore.

  2. Parallactic angle needs units.

  3. Frequencies show should always be sky frequencies.

  4. If the row is a loop, the value in the Source column should say "Loop".

  5. If any scan in a collapsed loop has a problem, the Loop row should be red.

  6. There was a discussion regarding the failure to use a prior reference pointing in subsequent scans. We don't want the software to be too smart -- the non-use of the ref ptg results could be intentional. On the other hand, accidental non-use is common, so it would be nice to draw the user's att'n to that scan. Perhaps coloring the row something other than red? Perhaps text in the Flags column?

  7. If the user has chosen to view times in LST, the Day in the title of this table should be the VLA's LST Day, not an MJD. [DMH: the Scheduled Start LST should probably also be this VLA LST Day value, i think, to avoid the situations where the same LST time occurs twice in one UT day.]

General

  1. Use another word in place of "Flags". Perhaps "Modifiers"?

  2. The Archive system places a 12 char limit on source names. The scan summary table should display only the 1st 12 chars for source names. We could catch this in the SCT, and there are several ways we could handle it. The most severe would be to prevent input of more than 12 chars. It was pointed out, though, that if a source in the catalog were never used in an EVLA observation, the 12 char limit is pretty arbitrary. We could allow unlimited characters (as we do now), but warn at point of entry about the limit. Alternatively, we could leave the SCT alone and deal with the issue when the source is brought into the OPT.

  3. Need to change the default filename extention for scripts to be ".evla".

* * *

Script Generation

The last part of the meeting was dedicated to the production of execution scripts. The preferred way to get a script is to use the OPT. Select a scheduling block in the navigation tree and choose the third tab, "Generated Script", in the main information panel. Currently, you can not set a start time for a dynamically scheduled script despite the fact that you can set such a time in the summary tab. For testing purposes, we could potentially add such a feature to the OPT. The Generated Script tab has a button that will allow you to save the script to your hard drive.

An alternate way to generate a script is to use the standalone model2script program. One drawback to this way of doing things is that you must know the database ID for the scheduling block of interest. Moreover, model2script is not currently installed in a globally accessible place. As a temporary solution, an installation has been made accessible at /home/crikey/model2script/model2script. You must have Java 6 installed and on your path to run the aforementioned bash script.

If you would like, we can also package up a tarball with an install script and send it to you. If you would like to do this, contact Brian (btruitt@nrao.edu).

Requested model2script Upgrades

  1. Need to allow users to pass a start time (in utc or lst) and an az and el on the command line to model2script. The az/el is the position of the antennas at the time the script will start. The expected range will be AZ: -85 to 445 and EL: 8 to 125. Doing this will allow very accurate slew time calculations, even for the first scan.

* * *

Miscellaneous

A question was asked about whether editing a script would result in an update to the project model, and therefore the data displayed in the OPT. The answer is "no". There are no immediate plans for creating the model from a script.

There was a discussion about exporting a project so that one might send it to other observers. We are capable of representing the entire project model in XML form. At this point in time we have no user interface for exporting or importing the XML.

Bryan, Brian, and Dave need to meet with Barry to discuss how the OPT can create output that can be used by the dynamic scheduler.

Bryan and Barry pointed out that there are two executor simulators: simexec and clexec.