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-47 Target to fiber allocation and configuration <p>It should be possible to reserve some fibers for later assignment to sky or calibration targets whn running the fiber allocator.</p> <p>This should not be hard to implement in principle, I only have a technical question:</p> <ul class="alternate" type="square"> <li>should we reserve a particular set of fibers (identified by their IDs), or</li> <li>should we just reserve a specified number of fibers (without specifying their IDs)?</li> </ul> FIBERALLOC-47

Reserve fibers that will be assigned to sky and calib targets later

Task Normal Done Done Martin Reinecke Martin Reinecke Fri, 23 Jun 2023 13:39:28 +0000 Fri, 20 Oct 2023 09:42:59 +0000 Fri, 20 Oct 2023 09:42:59 +0000 ets_fiberalloc 0 3 <p>Case 1 (reserving fibers by their ID) is strictly spaking already implemented,since one of the inputs to the fiber assigner is a bench description. If the fibers that should be reserved are simply deleted from the input bench object, this should lead to the desired results.</p> <p>We have started to talk with several persons of the science team. We will summarize a list of some issues and requests (including this) later.</p> <p>Can you add a few words about the motivation? This is something that the netflow handles automatically, guaranteeing the requested number of high-priority sky/calib fibres while allowing freedom to choose them from a large set. </p> <p>Personally I don't know the motivation. I opened the issue because the feature was requested during the ICS/PFI+MCS telecon on Jun 23.</p> <p>Andy reported that the netflow was really slow if a large number of scientific objects was optimized including calibration targets at the same time (for some reason). An option is that particular fibers are reserved for sky and fluxstds and removed from the full netflow problem. If you have a chance, please ask Andy for more (recent) update (he was not there in the meeting yesterday).</p> <p>I have added a tentative implementation at <a href="https://github.com/Subaru-PFS/ets_fiberalloc/pull/18" class="external-link" rel="nofollow">https://github.com/Subaru-PFS/ets_fiberalloc/pull/18</a>; please have a look!</p> <p>Sorry for the delay, but I just started to look into this finally. I added comments regarding specific part in the code on GitHub.</p> <p>I'm testing a real field for the Oct engineering run with codes to make pfsDesign on `ets_pointing` with modification for this ticket. Without this implementation, ~2300 fibers are assigned to SCIENCE targets (no calibration targets). After I set `numReservedFibers` to 1000 and `fiberNonAllocationCost`=1e+12, the number of fibers to SCIENCE targets decreases down to ~1600, which looks larger than expected. I thought that reserved fibers should be blank, but they look to be assigned as SKY targets, even if I set the number of calibration targets is 0. This may be a problem of scripts of `ets_pointing` but what do you suppose about the target class of the reserved fibers? </p> <p>And is it possible to officially implement for case 1? I like to reserved fibers proved by a list of specified fiberIds. Or it would be helpful to have an example to change bench information for this.</p> <p> </p> <p>BTW, it seems to be true that calibration targets are assigned preferentially to blank fibers among science targets.</p> <p>I hope that the strange results you are reporting are fixed by the latest commit on the branch. Please let me know whether it does improve things!</p> <p>Concerning the implementation of case 1: this should probably happen outside the `netflow` package, by manipulating the `ics.cobraOps.Bench` object that is passed to `netflow`.<br/> Alternatively I can add another argument to `buildProblem` which contains a list of Cobra IDs to be used. However this feels a bit like an unnecessary complication of the interface to me.</p> <p>Thanks. I confirmed that that fix resolved the problem. Now it looks working as expected, so I think we can close this ticket (at least for this specific functionality). For another implementation, we should file a new one if necessary (I agree and I feel that it looks outside the netflow part). And I heard that you talked to Masahiro about the two-stage implementation. I'm still not sure whether that is somewhat related to the topics on this ticket or not. Anyway, we can discuss with the science team at some point, and file the implementation tickets later.</p> <p>Thank you! I'll merge the branch and close the ticket then.</p> <p> </p> Development Rank 0|zzsy1z: