Preparation for SSS Meeting of 10 Feb 2009 Added comments from the meeting, prefaced with "MTG:", below. Items that have been raised by various individuals for OPT, SCT, RCT. 1. Printing of scan page must work. [LS, 05 Feb 2009; GvM, 30 Jan 2009; EM, many times!] MTG: Brian put this in earlier today and updated webtest. He then found a problem and fixed it, but not in time to update webtest again prior to the mtg. It was suggested that if there are no errors or warnings we should suppress the heading for the errors & warnings that appears at the bottom of the page. 2. Dragging of scans must work properly [LS, 05 Feb 2009] MTG: See JIRA EVL-776. The programming staff needs to better understand the symptoms before it can assess the difficulty in making a fix. Post-Mtg Update: Removing tool tips from the tree (see #3, below) seems to fix this. Oops, not quite. Stay tuned... 3. Fly-over must work (ie complete and be visible and not fall off the page) [LS, 05 Feb 2009] MTG: All agree that this stinks, but programming staff will need to assess difficulty of the task. Post-Mtg Update: The tool tips in the tree don't provide much information, and the effort required to see what the underlying 3rd party software is doing wrong is predicted to take a long time. We have removed this flyover help. It looks like this has the added benefit of fixing #2, above. We have not address, though, the issue of a tool tip that is placed too close to the right hand edge of the browser window. 4. We need an Az/El (and RA/Dec) starting point for the motion model (SB page) Currently it uses a fixed point and that does not allow needed flexibility. [LS, 05 Feb 2009] MTG: We will put this on the SB Details page and use it in creating scripts. 5. The hard one is to revisit calcodes (PSWX? vs ABCT) in the search tool and getting them transferred in the script (seems not the case currently). This is a discussion/demonstration item as well as a programming one. [LS, 05 Feb 2009] MTG: When we populated the SCT from the text version of the VLA Calibrator List, we did not have a place in the source model for such a code. We did preserve the information, though, by adding an entry in the User Defined Values table with the key "Position Error". We did not, though, preserve the code, instead using the meaning of the code. 6. Hardcopy document - I [Lorant] plan to have a first fairly complete(?) draft ready for distribution sometime next week requesting feedback from sci and prg. [LS, 05 Feb 2009] 7. This is a very general remark, and it may be hard to implement. It con- cerns the difference in displaying and editing in the OPT at one hand, and the Sources and Instrument Configurations Tools in the other. In the former, the whole tree structure Program -> Program Block -> Scheduling Block -> Scan is available and accessible in the left panel, and editing any of them merely requires clicking on the item in the tree. In order to open a different scan one simply clicks on that scan without having to close the current scan. This is intuitive and powerful. On the other hand, the Sources and Instrument Configuration Tools do not allow such easy access. Sources or Instrument Configurations are not accessible in the tree structure, and cutting or copying one of those requires clicking in the left-hand panel, thus causing a list to be dis- played in the right hand panel. In that right hand panel, one checks a box next to the item to be cut/copied, and then accesses the edit menu for the desired action. And when editing one source, one does not have a list of other sources available to switch to, when desired. [GvM, 30 Jan 2009] MTG: Having a similar look & feel across tools is desirable. There was some concern about the length of the tree for source catalogs if we take the OPT approach. There is also a subtle difference between the grouping concept of the two catalog tools and the containment concept between projects, prog blocks, sched blocks, etc. in the OPT. There was also an opinion that this mattered more to people testing the tool, but not as much to typical users. 8. In the Scheduling Block Summary, the observing frequency is listed under Time on Source Summary and Summary Report, but not in the Instrument Con- figuration Summary, where it belongs. [GvM, 30 Jan 2009] MTG: We will move the AC Freq. / BD Freq. column out of the Time On Source Summary and into the Instr. Config. Summary. 9. Certain aspects of the various tools are too slow: response can be in the order of seconds. This may well be since I am working on webtest, not the production machine, but I'd like to emhasize to what extent a rapid response can contribute to the usability and success of the tool. [GvM, 30 Jan 2009] MTG: The programming staff is aware of one particular source of slowness, and that is the initial loading of the OPT for individuals who have many projects, or a few large projects. We believe we can mitigate this. Testers are encouraged to note any other activity that is consistently slow. 10. It appears that the system can handle IF pair differences of up to 10.5 GHz. [GvM, 05 Feb 2009] MTG: The program staff will change the test to use 10.0 GHz (the advertized max separation) and will ensure that the message is a non-blocking warning. The text will warn users that, though there is a chance the setup may work, it is more likely that it will not. 11. Display of receiver band frequencies. We're currently showing nominal ranges, but we also have 1dB and 3dB ranges for many of the bands. The warning msgs account for these ranges, but we do not display them anywhere. [LS, DH, BT, 02 Feb 2009] MTG: Preference: tool tip, but might not be able to do technically. Alternative: multiple lines in drop down. It was also noted that we're using final receiver specs, not specs of current receivers. Eg, X band is shown as 8-12 GHz, but does not yet cover that range. 12. However the executor fails to use the conversion path if f_BD is less than 32GHz and f_AC - f_BD is less than 4000-256 MHz. I have fixed this oversight but don't deem it important enough to quickly create a new executor. [KS, 02 Feb 2009; GvM, 28 Jan 2009] MTG: The programming staff will update the script producing code to be in sync with the fixed executor code. 13. Program Block Validator needs to make sure contained SBs don't use too much time. [BT, 27 Jan 2009, JIRA EVL-784] MTG: This is done on the honor system, and human eyes will be watching these observations carefully, so this is not a priority. 14. The Scheduling Block Summary page of the OPT allows a user to enter a start time for the schedule. This value is used only for calculating the values in the tables on this page; it is not a stored property of the project. We should write user help to make that clear. The confusion arises when a user has created a fixed-date schedule by stating this on the Scheduling Block Details page. Gustaaf, for one, thought that by updating the time on the summary page he had changed the time at which his fixed date scheduling block would be run. [DH paraphrasing conversation w/ GvM] MTG: Programming staff will remove or deactivate these fields when the SB is using fixed-date scheduling. 15. In the Scheduling Block Details page, for a fixed-date observation, we allow user to specify either LST or UT, and then we show the other time as a convenience. We're showing LST w/ a precision of 1 millisecond; we're showing UT w/ a precision of 1 minute. What is the preferred precision for each? [DH testing while researching #14, above.] MTG: Programming staff will use one-second precision for both types of time. 16. In the VLA source catalog, there are some duplicate names. (Remember that when we read the old html calibrator catalog we created source names programmatically by using source positions.) Each of the following source names occur twice in the catalog: J1914+1636, J0354+8009, J1300+1417. [BT, 03 Nov 2008] MTG: This is probalby fine. 17. Update script production logic for new style of tipping scans. [BB, 10 Feb 2009] MTG: This is now done. 18. Scan w/ no resource to mean leave LO / hardware settings exactly as was in the previous scan. Equiv to FIN card. [LS & BB, 10 Feb 2009] MTG: Programming staff will either allow scan to have no resource, or (and probablby better) have something like a box the user can check if they want to leave the instrument configuration exactly as it was in the previous scan. The scripting logic will need to make proper use of this user preference. 19. New icon to create a new, BLANK, scan. [LS, 10 Feb 2009] MTG: Programming staff will add a new icon for creating scans, making two "create scan" icons. One will make a new blank scan, the other keep the current behavior of making a new scan that is a duplicate of the currently selected scan. 20. MTG: Get tips & tricks to Lorant for the User Manual.