Target Table Updates

Question

Target Table Updates

Closed this issue 5 years ago · 13 comments

Perhaps the most challenging task will be updates to the target table itself. The "base" position row(s) will change depending upon the selected asterism. We should probably show the base position for dual target mode. Unfortunately it isn't an SPTarget, but rather just Coordinates. The options available in the + menu and the "type change" menu will have to be updated as well.

Standard Resolution Asterism
Here single-target vs. dual-target could just be determined by whether an IFU2 star is specified. There will always be an IFU1 star. In the table I think we should show the label "IFU1" instead of "Base" if in single-target mode. The + would include an option for IFU2 and would add the IFU2 star below IFU1. Once an IFU2 star is added, it becomes dual-target and we need to also display the "Base" coordinate. The user could delete the IFU2 star but not the IFU1 star. Once an IFU2 star is added, the option should be removed from the + menu or disabled.
High Resolution Asterism
Here we just replace "Base" with "IFU1" or maybe "HR IFU1" to re-inforce the fact that we're using the HR fiber bundles. As for the standard resolution single-target mode, IFU1 is the base position.

In the "type change" menu, the corresponding IFU option(s) will replace "Base". It seems like it should be possible to use this menu to swap IFU1 and IFU2 stars.

Answer 1 · 2018-03-13T13:43:04.000Z

My thoughts:

Agreed on the Standard Resolution Asterism notes. I have some hesitations with the logic flow of "Base" suddenly appearing when IFU2 is added, as I think that that may be odd and confusing, but on the surface, I don't see another better way of doing this. I think the most complicated part by far will be the "Base" now being Coordinates instead of SPTarget: having worked on the target editor table awhile back, I have no idea off the top of my head how we can implement this in an easy way, as the code is already quite cluttered and, I think, highly dependent on SPTargets appearing in the table.
The type change menu is what I have more trepidation over. This menu is already - IMO - rather confusing: for example, if I add a GMOS OI guide star, and then change its type to "Base" (would this ever be something that a user would even want to do?), then it sets the OI star to the base as expected, but then takes the existing base and throws it in at the end as a user target. This may be a good opportunity to rethink what type changes we should allow for given target types in this menu, and how they behave in cases like setting a target to "Base."
High Resolution Asterism seems much more straightforward and I don't foresee any issues in implementing this.

Answer 2 · 2018-03-13T17:09:34.000Z

How often is the type change thing used? It's very complicated and very confusing.

Answer 3 · 2018-03-13T17:26:46.000Z

BTW, thanks, @swalker2m, for capturing the details of the discussion in such clear and thorough detail, and for the helpful diagrams to illustrate the various concepts and possible changes.

Answer 4 · 2018-03-13T19:33:26.000Z

I'm all for throwing out the type change "feature", if we can. I do seem to recall that there is some switching between base and user targets. It's worth bring up with @andrewwstephens / Bryan.

Answer 5 · 2018-03-13T19:42:51.000Z

Agreed. I'll ask them to make some comments on this. If we can get rid of this, it would be great.

Answer 6 · 2018-03-13T19:59:27.000Z

As for the base position with dual target mode, we should confirm that we need to display it before we go to a lot of trouble to make that work. Perhaps we can fool the UI with a dummy SPTarget with those coordinates if necessary.

Answer 7 · 2018-03-13T20:17:50.000Z

The target change feature is handy for swapping the base and blind-offset star to verify that the same guide star will work for both. In theory, the new OT should check that automatically.

Answer 8 · 2018-03-13T20:31:18.000Z

I'm not familiar with the GHOST observing model, but I can imagine that when observing a pair of targets it might be reassuring to see that the coordinates on the Telescope Status Display (TSD) match the Base coordinates in the OT.

Answer 9 · 2018-03-13T20:46:56.000Z

That definitely seems like a clunky way to check the properties of the guide star, and the menu seems like overkill in what it does if that's the primary reason it's used.

I'm hoping we can rig a dummy SPTarget, then, if we need to show the base coordinates. I don't see any reason why not offhand.

Answer 10 · 2018-03-14T20:49:28.000Z

This is the task that terrifies me, and the one I feel the least comfortable estimating.

I'm thinking it could realistically take upwards of two weeks.

Answer 11 · 2018-03-15T12:24:45.000Z

I've used the type change menu for manual manipulation of GeMS asterisms, among other things. It would be good to keep this functionality, though if it is done in a different way then it is probably ok.

Answer 12 · 2018-03-16T17:56:38.000Z

Steve stated a preference to explicitly label SR vs HR, so "SR IFU1", "SR IFU2", and "HR IFU1".

Answer 13 · 2019-04-23T14:55:12.000Z

This task is (thankfully) done.