update next field selector interface about desisurvey

[dkirkby]

I added the required moon_alt and moon_az inputs for performance reasons, but didn't get a chance to finish to my updates related to this before merging. When I get back to this I will verify that they really should be passed in like this or else remove them.

[dkirkby]

Updates:

• conditions is no longer an arg of nextFieldSelector() since it was not being used.
• moon_alt and moon_az are no longer args of nextFieldSelector() since I removed them after trying something that I didn't end up using)
• previous_ra and previous_dec are no longer args of nextFieldSelector() since their role in determining the amount of required slew time is now handled via Progress.last_tile.

Closing since there are no outstanding issues here.

[sbailey]

Reopening this to discuss / comment on the following:

• conditions is no longer an arg of nextFieldSelector() since it was not being used.

But in the future it should be used and it includes conditions like seeing, transparency, and sky brightness that can't be derived from just an ephemeris lookup, e.g. to decide if we need to drop out of the standard DARK program and into a POOR conditions backup program. Let's establish and maintain the necessary data flow now even if we aren't using all pieces yet. i.e. I don't want to design ourselves into a corner such that when we do want to use seeing we find that it is a huge pain to get the information into the next field selector.

• moon_alt and moon_az are no longer args of nextFieldSelector() since I removed them after trying something that I didn't end up using)

That seems ok since they could be done as an ephemeris calculation on the fly.

• previous_ra and previous_dec are no longer args of nextFieldSelector() since their role in determining the amount of required slew time is now handled via Progress.last_tile.

This concerns me. The next field selector is one of our primary interfaces with the online system (quicklook and the output raw data are the others) and is the thing that Klaus/ICS calls to find out what to do next. It seems odd to require them to construct or maintain a desisurvey.progress.Progress object just so that they can call this function, and it seems to obfuscate what the actual necessary input information for the next field selector really is. Can we keep this as a simpler interface that only deals with scalars, lists/arrays, and dicts?

This has diverged considerably from what we originally defined as our interface with Klaus, and we need to revisit that. In principle this interface is supposed to be under "change control", where neither side can change it without the agreement of the other.

[dkirkby]

The next field selector is one of our primary interfaces with the online system

Can you add a link here to the formal interface definition? This isn't mentioned anywhere in the package, so I wasn't aware of it. In any case, it should be straightforward to conform to any reasonable interface.

[sbailey]

The ICS:DataSystems interface document is DESI-0560, but it is overly vague and cites this repo for details! At the time that was written, this was the preliminary interface that we had agreed upon (while recognizing that we'd update details when we actually implement the whole system):

https://github.com/desihub/desisurvey/blob/9143a76554006ef83f07c186781c79d8a540bb39/py/desisurvey/nextfield.py

we've diverged enough that that file and docstring no longer exist in current master...

Summer reviews are imminent, but on Klaus and my todo list prior to the reviews is to revisit our interfaces and polish them up; this conversation is part of that effort.

[dkirkby]

#66 adds a column available to the progress fits file that records the day number (defined by a new desisurvey.utils.day_number() function) on which the fibers for each tile are assigned. With the default monthly fiber-assignment cadence, this will always fall on the day closest to a full moon. Special values are:

• 0: fibers assigned at start of survey.
• -1: fibers never assigned (since covering tiles were not completed in time).

Note that I deliberately avoided 'YYYYMMDD' here because of headaches with bytes vs unicode in fits files.

@sbailey If you need some non-trivial processing of this column, that could be wrapped into a new Progress method but, otherwise, everything you need to sequence FA runs should be here.

[schlafly]

We have a defined interface with ICS now; closing.