Calibrator Selection Tool
Requirements: Email from Michael Rupen 2007-07-20
Initial: 2007-Jul-25    Updated: 2007-Aug-08

The first requirement this raises is that the selection tool must be able to accept sources from multiple catalogs. While the internal SourceMap class can take sources from anywhere, the prototype application object forces selection of a single catalog. This must be changed.

The next requirement it raises is that the tool must remember the catalog from which a given source came. This is not something the SourceMap class does; in fact, it receives "naked" sources, not source-catalogs or source-groups. If we need to code by "VLBA vs. VLA", then we need to have the SourceMap class understand from where its sources came. (Assumption: "VLBA vs. VLA" refers to the catalog in which the source is contained, not some intrinsic property of the source. Also: need to discuss best way to handle sources that are in multiple catalogs.)

One use of the displayed size is certainly to indicate flux density; another would be to indicate the angular extent of the source. Using size for flux density is certainly easier, and i'm not sure we have a lot of extent data.

Our Source Model allows a source to have many different flux densities, where the densities vary with time and frequency. (I am glossing over the fact that we also allow a source to have many "subsources", and it is really each subsource that may have many flux densities. Ignore that complication here.) Question: How does the calibrator selector know which frequency to use for size determination? One solution would be to have the user input a frequency range of interest. If that range is very broad, we may still wind up with more than one choice in the size-calculation algorithm. We will also wind up with sources that have flux density data, but not for the requested frequency range. Question: Does that mean those sources are invisible and not displayed? (One option might be to represent sources that have no flux density information and/or those sources that do have flux density information, but not at the requested frequencies, by rings instead of circles, where a ring is the outline of a circle whose interior is the same color as the background.)

I would like us to poll several astronomers to see how important it is to have a visual cue for this. We can certainly include that data in any text information we present about the source (via a pop-up or some other visual device). I have a personal bias against using triangles and squares for sources, but that really shouldn't count for anything. Hey, how about dots that vibrate or twinkle if their accuracy is low? (Just kidding!)

Question: Do we have this kind of data? Polarization does enter into our model, but in the form: "this flux density of xJy is valid for frequency range ν₁-ν₂, time range t₁-t₂, and polarization P". Question: Do we need to update our source model to hold more polarization information?

As far as display goes, we could use parallel dark lines to indicate the polarization angle -- provided that the source circles are more than a couple pixels wide. Note: i can make the source circles larger than what is in the prototype if we commit to removing the names from the display. (Maybe there should be something that allows users to toggle name off/on. Could be useful for saving image -- nice to see names of calibrators near your source?)

Question: How do we know that a given source is a flux density calibrator?

This is a good place to note one aspect of the Source Model. The Source Model does not identify any particular source as being, intrinsically, a calibrator of any type. Instead it holds a whole bunch of properties, and those properties can be queried when one says "i need to calibrate instrument X for purpose Y, let's see which sources in the sky would be good for that job". I'm not saying we can't identify flux density calibrators. I am saying that the observer will have to say "show me sources that can be used as flux density calibrators for the EVLA", and that we'll need some logic that can look at a source and say "you'd be a great calibrator -- i'm gonna make you a star!" (groan).

Assumption: "move time" here means time required to slew the telescope from source to calibrator. This would require us to let the calibrator selection tool know about the telescope model (something which has not yet been developed). Note to developers: we probably want some layering of objects here. The lowest level thing would be a pure source-package object and know nothing about project model and resources. A layer above that will probably need to know about things like ScanIntent (Project Model) and telescope motion (Resource Model).

Question: Would this horizon be shown on the bullseye display or elsewhere? (The rest of this section will assume that it is on the bullseye display.)

Assumption: We're not talking here about something as coarse as "this telescope can never see below declination δ", but something more refined that takes into account a given telescope's longitude and latitude and calculates what is above the its horizon at a specific point in time.

If the above assumption is correct, we need something that allows the observer to enter a date/time for the horizon calculation. (Note that there are other items for which a date/time is needed, so we'll be providing such a control anyway.) The clause "certainly for the highest source elevation" indicates that, for a given date, the system should probably be able to calculate the time of day at which a given RA/DEC point will transit the meridian.

Question: Show on map or in some text display? (My guess: text.)

Agreed. We can discuss particulars of what information is displayed later on. We also need to decide what all the different mouse clicks do. See CONTROLS section, below.

See also Showing Source Details... document.

Question: How high a priority is this?

Request: More details, please.

Agreed. (This is another requirement that leads to conclusion that user needs to be able to specify date/time for display.) Question: Any suggestions for display? Those cool symbols ( ☿, ♁, ♂, ♃, ♄, ♅, ♆, ♇, ☉, ☾)?

Assumption: Angular distance.

Question: Show on map or in some text display? (My guess: text.)

Thank goodness for the web¹ on this one!

Question: Formula?

Uncle!

Perhaps a face-to-face would be best on this one. First thing to think about: belongs in this tool, OPT, or elsewhere.

See the Moving & Zooming section, and the Configuration section, below.

A requirement that this uncovers is the need to be able to filter the sources held by the tool by a number of criteria. (To Do: Make section on filtering.) Some work has been done in this area, but not in graphical form, and not all the work that needs to be done. The underlying source filtering is telescope-neutral (actually, ignorant). It does not deal in receiver bands (S, U, X, etc.), but in frequency ranges. The Resource Model will allow us to convert from Receivers to FrequencyRanges. We'll need to work with astronomers to understand what a neutral view of things like VLA configuration and baseline lengths are and what they mean in terms of selecting calibrators.

Yes, we need to be able to select calibrators for transfer to catalog. Question: What do you think the behavior should be: a) immediate action on selected source or b) consider the source as "selected", with a later step that says "transfer all selected sources"? I (DH) would lean toward "b". The ability to select sources might be useful for other purposes, so i'd like to divorce the selecting of a source from the action taken on selected sources.

Agreed. Take a look at the examples on this page for some ideas, which also shows some zoom and reset controls. See also the Moving & Zooming section, and the Configuration section, below.

We might even want to allow users to "mark" a display as a possible retreat-to point. The default mark would be the original display. We could allow a single mark point, with subsequent mark operations overwriting the previous mark point. Alternatively, we could allow a stack of mark points, and allow users to retreat back one mark at a time. (The next request would be to allow random movement, forward and backward, through the stack of marks.) As far as ease of implementation, either a single mark or a stack of marks with only sequential retreats (ie, you pop the top mark off the stack and throw it away) are easiest. Any random navigation means more user-interface work. Not a big deal, but we should concentrate on highest value things first.

Ability to Print: Agreed. Once we get a better idea of what the whole tool looks like (a bullseye and a bunch of controls), we'll need to discuss just what gets printed. Is it just the the bullseye, the whole enchilada, or something in between?

Ability to Save Display: Question: Do you mean save an image (png, jpg, etc.) of the display? (As opposed to saving the state of the application so that it comes up the next time just the way you left it. (Sounds like another feature. ☺)) The same question about what part of the screen to print applies here, too. One cool thing an observer will be able to do: save the image and then in her catalog for the target source, save a link to that image. That way when she uses her catalog to see that source, she can see the image used to select nearby calibrators.

Ability to Show Subset Based on Frequency of Monitoring: Question: Where do we get frequency-of-monitoring information? Does this refer to how often we see entries for this source in the Flux Density History Database?

I think this is the same thing as the last part of #6, above.

OK. Question: Does the user enter a time span over which the average is to be taken, or does the software do this on its own? If the latter, does the software average across every measurement it finds, only the last N measurements, or only measurments taken since time T₀?

Zooming the map in and out, and moving the map to different points on the celestial sphere are two obvious things to do. We need to decide just how we want to accomplish that. There are many ways to accomplish this, and more than one way to do the same thing may be offered to the user. Some ways to influence the bullseye:

• Clickable controls. E.g., there is a "+" button that is clicked to zoom in.
• Magic mouse clicks. Here you are not really clicking an icon dedicated to, for example, zooming in. Instead your mouse is position in the map and you do something like shift-click or rotate a mouse wheel to zoom.
• Keyboard presses. E.g., a press of the "+" key causes the view to zoom in.
• Direct text entry. Here there would be something that, for example, would allow the user to "zoom" the map by entering a value for the maximum bullseye radius.

Pros & Cons: All four of the above can exist simultaneously. Clickable controls tend to be obvious for first-time users and don't take up too much real estate. Magic mouse clicks are somewhat "hidden" features that can go undiscovered. On the other hand, once discovered, they can become a users preferred method. (True at least w/ wheel motions; shift/alt/ctrl-click behavior is easy to forget, as it's just not as intuitive.) Keyboard presses are not as obvious as the clickable icons, but the +, -, and arrow keys are standard enough that people will try them even if they don't know ahead of time that they're active. Direct text entry gives fine-grained control, but takes up more real estate.

In addition to, or in combination with, the above, there are tool bars, pull down menus, and pop up windows that can be used here. A zoom control could be placed in a tool bar, there could be a view pull down that has zoom controls in it, or there could be a pop up with these controls. Request: If anyone can draw a picture of what they think is a good layout, or can point us to such a picture, please do so and DH will incorporate into this document.

For all of the moving/zooming contols (other than for direct text entry), it is nice to have a configuration panel that allows the user to influence the behavior of the clicks, controls, and keys. The configuration would, for example, allow the user to say "when i zoom out one unit, give me a radius 50% larger than the current one. Of course, if we do this, then we need to store the configuration so that the next time the user visits the tool they need not revisit the configuration screen.

If we create a configuration panel, then other configurables might be: colors of the various parts of the map, the initial size of the tool on the screen, the initial position of the tool on the screen, and so on.

This is a bell/whistle feature; the first thing we need are good defaults for such things.

More information needed.

I think one thing we need to hash out early is just what job(s) this calibrator selection tool has. Question: Would it be better for the Observation Preparation Tool to be the provider of such a service?

Yes, once we're a little further along, the programming staff will ask the astronomers for priorities and will assess difficulty of each request.