Should we enforce a single observation of a target per "PASS"?

[tskisner]

Currently fiberassign takes the list of input tiles (in order) and assigns targets to them. The tiles class internally:

https://github.com/desihub/fiberassign/blob/master/src/tiles.h#L22

does not track the "PASS" of a tile. This information does exist in the input footprint file, but it is not stored. During assignment, if a target falls into the overlap region of 2 tiles, and if that target has more than one observation remaining, then it is possible that the target would receive multiple observations from both overlapping tiles.

fiberassign can be run with tiles from multiple passes, and if we would like to restrict the targets to one observation per pass, then we should store the PASS column from the input footprint and use it during assignment.

[sbailey]

Since we are starved for LyA QSO coverage, we should allow multiple assignments within a single PASS for later passes, e.g. to allow a confirmed LyA QSO to be observed in two overlapping tiles of PASS=4 when possible. If we don't want to multiply assign a QSO in the initial PASS=1, that can be accomplished by starting with NUMOBS_MORE=1 and then upgrading confirmed LyA QSO to NUMOBS_MORE=3 (=4-1) instead of starting with NUMOBS_MORE=4 and then downgrading non-LyA QSO.

i.e. I think fiberassign should not know anything about the PASS structure, which I think is what the current state is.

[geordie666]

Doesn't setting NUMOBS_INIT=1 for the QSOs and then upgrading to NUMOBS_MORE=3 just "kick the can down the road"? Won't a QSO that is upgraded to NUMOBS_MORE=3 potentially be multiply assigned in PASS=2?

I believe that any QSO that is not categorically confirmed to be at z > 2.1 will retain NUMOBS_MORE=3 status. So, any z < 2.1 QSO target with ZWARN != 0 could then be multiply assigned in PASS=2?

[forero]

Another option would be only feeding to fiberassign the tiles within a single pass.

[tskisner]

Currently I have been assigning one pass at a time, and as @geordie666 mentions, once NUMOBS_MORE > 1, there is a chance that in any future pass a QSO that falls in the tile overlap within that pass will get 2 observations within that single pass.

So, even assigning one pass at a time, if we only want to get "2 observations in pass 4", then we would at least need to have a switch in fiberassign that allowed / disallowed multiple assignments per pass. And we would need to make fiberassign aware of passes.

Currently, fiber assign knows nothing about passes. If a target with NUMOBS_MORE > 1 occurs in the overlap of 2 tiles, it may get 2 observations regardless of whether those tiles are in the same or different passes.

[sbailey]

Doesn't setting NUMOBS_INIT=1 for the QSOs and then upgrading to NUMOBS_MORE=3 just "kick the can down the road"? Won't a QSO that is upgraded to NUMOBS_MORE=3 potentially be multiply assigned in PASS=2?

Yes, but I think that is what we want: once we have confirmed that something is a LyA QSO we want to observe it every chance we can until we reach 4 observations. That would include observing it twice in PASS=2 if we can.

i.e. the optimization I'm chasing here is preventing it from being observed twice in PASS=1 so that we get a single observation before deciding what to do with it.

I believe that any QSO that is not categorically confirmed to be at z > 2.1 will retain NUMOBS_MORE=3 status. So, any z < 2.1 QSO target with ZWARN != 0 could then be multiply assigned in PASS=2?

I think that is a separable policy decision: if we observe a QSO target and don't get a definitive answer, under what circumstances do we reobserve it? Andreu in particular has advocated re-observing a selected subset, but IIRC not necessarily all of the ambiguous cases.

Also note that David Schlegel has suggested a much more fine grained assignment strategy, e.g. start with non-overlapping tiles in PASS=1, and then only assign the remaining PASS=1 tiles after their overlapping neighbors have been observed and we have decided what to do with their QSO targets.

Regardless, I think fiberassign should remain agnostic (i.e. ignorant) about PASSes, and we should accomplish the strategy we want by a combination of MTL NUMOBS_MORE and which tiles are handed to fiberassign in a given run.

[geordie666]

@sbailey : I'm working with the LyA group at the moment to try to work out more precise strategies. But, are you confident enough that we want NUMOBS_INIT=1 for all quasars and NUMOBS_MORE=4-NUMOBS for confirmed LyA quasars that I should open this change as an issue on desitarget?

[sbailey]

@geordie666 please open a desitarget issue about QSO NUMOBS_INIT=1 vs. 4 but hold off on implementation until we have more discussion on whether we'd want to purposefully observe a QSO twice in PASS=1 if we could (pro: getting ahead on LyA for the subset that are LyA; con: "wasting" the second fiber on a confirmed z<2.1 QSO; maybe-good-maybe-bad: getting an early second obs of ambiguous classifications/redshifts).

[forero]

Currently I have been assigning one pass at a time, and as @geordie666 mentions, once NUMOBS_MORE > 1, there is a chance that in any future pass a QSO that falls in the tile overlap within that pass will get 2 observations within that single pass.

OK. Then the issue is not about tracking the PASS information, but about tracking tile overlap (i.e. onto how many tiles a target falls in).

[tskisner]

Cleaning out old issues- is this still relevant?