I propose to implement this in the following way:

In addition to the already existing input data, ETS takes an additional (optional) input, which is simply a (string->int) dictionary mapping science target IDs to the number of times they have already been observed previously.

When planning a new observation, this is left empty.

When re-planning the rest of an observation that has already been partially carried out:

• this dictionary is filled with the information on the science targets that have already been (partially) observed
• the rest of the input contains the updated target lists, observation times, or whatever else has changed, and only the not-yet-done visits are requested

Comments or questions welcome!

I committed an experimental version to `tickets/FIBERALLOC-15` branch. Please let me know your thoughts!

At the moment the code wants to know the number of visits that have already been spent on a given science target. It would also be possible to change this to the observation time in seconds. I don't know which is more convenient.

Thank you for the proposal. This function looks useful. Just to be sure, is this going to work in the `netflow` world? 

Yes, this is an enhancement to the netflow code. The plan is roughly like this:

• you plan an observation that has, say, 5 visits
• after 3 completed visits, the parameters change for some reason (i.e. the cost function changes, targets are removed/added, telescope pointing is changed, Cobras are disabled, really anything that can be imagined)
• now you plan another observation, but only for the remaining 2 visits, and pass to it the information which targets have been observed how often in the preceding visits. The code will then try to optimize the cost function according to this changed information.

@rhl I think this is a feature you asked for.

It would be absolutely great to have some feedback on this. Merging this soon would have the additional advantage that the "master" branch would work again; it is currently broken due to an interface change in ics.cobraOps.

If I don't hear anything, I plan to merge in early January.

Hi Martin Reinecke , thank you for this update. I really like to test this, but unfortunately I need to do other works during this week, and I will be on vacation next week, so I can start to test this after Jan 6. Is this too late for you?

Dear Kiyoto, thank you very much for the offer! Sure, early January is fine. Maximilian has already tested this as well and seemed happy with it.

Although I only tested for very limited use cases, I think it works as you intended. It may be good to describe this functionality briefly in README.md as well. Thanks.

Thank you very much, that is an important point! I have updated the README.md file accordingly.

After nine months of no feedback I'm proposing to merge this now, since I need to make other changes on the code (e.g. switching to the official pfs_utils coordinate routines), and I don't want to maintain diverging branches.