https://pfspipe.ipmu.jp/jira This file is an XML representation of an issue en-us 8.3.4 803005 13-09-2019 https://pfspipe.ipmu.jp/jira/browse/FIBERALLOC-15 Target to fiber allocation and configuration <p>The code should be capable to deal with the following situation:</p> <ul class="alternate" type="square"> <li>an observation plan has been computed, and some visits have already been observed</li> <li>now, some parameters change (i.e. targets are removed or added, observation times are changed, etc.)</li> <li>based on the already performed observations and the new input data, ETS should compute an updated optimal observation strategy for the remaining visits.</li> </ul> FIBERALLOC-15

Deal with changes to a planned observation after it has started

Task Normal Done Done rhl Martin Reinecke Wed, 27 Nov 2019 10:38:35 +0000 Mon, 5 Oct 2020 15:44:33 +0000 Mon, 5 Oct 2020 15:44:33 +0000 0 2 <p>I propose to implement this in the following way:</p> <p>In addition to the already existing input data, ETS takes an additional (optional) input, which is simply a (string-&gt;int) dictionary mapping science target IDs to the number of times they have already been observed previously.</p> <p>When planning a new observation, this is left empty.</p> <p>When re-planning the rest of an observation that has already been partially carried out:</p> <ul> <li>this dictionary is filled with the information on the science targets that have already been (partially) observed</li> <li>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</li> </ul> <p>Comments or questions welcome!</p> <p> </p> <p>I committed an experimental version to `tickets/<a href="https://pfspipe.ipmu.jp/jira/browse/FIBERALLOC-15" title="Deal with changes to a planned observation after it has started" class="issue-link" data-issue-key="FIBERALLOC-15"><del>FIBERALLOC-15</del></a>` branch. Please let me know your thoughts!</p> <p>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.</p> <p>Thank you for the proposal. This function looks useful. Just to be sure, is this going to work in the `netflow` world? </p> <p>Yes, this is an enhancement to the netflow code. The plan is roughly like this:</p> <ul> <li>you plan an observation that has, say, 5 visits</li> <li>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)</li> <li>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.</li> </ul> <p>@rhl I think this is a feature you asked for.</p> <p>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.</p> <p>If I don't hear anything, I plan to merge in early January.</p> <p>Hi <a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=Martin.Reinecke" class="user-hover" rel="Martin.Reinecke">Martin Reinecke</a> , 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?</p> <p>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.</p> <p>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.</p> <p>Thank you very much, that is an important point! I have updated the README.md file accordingly.</p> <p>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.</p> Development Rank 0|zzs048: Reviewers rhl