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/INSTRM-1640 Instrument control development <p>Fiber ID matching took ~35s. This is with the non easyId algorithm, and happened several times. </p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>2022-06-19 23:44:45.204Z cmds 20 CommandLink.py:121 &gt; 2 280 i text="loaded 2394 targets from DB" 2022-06-19 23:44:45.205Z cmds 20 CommandLink.py:121 &gt; 2 280 i text="Starting Fiber ID" 2022-06-19 23:45:19.401Z cmds 20 CommandLink.py:121 &gt; 2 280 i text="Fiber ID finished" 2022-06-19 23:45:19.689Z cmds 20 CommandLink.py:121 &gt; 2 280 i text="wrote matched cobras to database" 2022-06-19 23:45:19.689Z cmds 20 CommandLink.py:121 &gt; 2 280 i frameId=7739802; filename=/data/raw/2022-06-19/mcs/PFSC07739802.fits 2022-06-19 23:45:19.690Z cmds 20 CommandLink.py:121 &gt; 2 280 : exposureState=done </pre> </div></div> INSTRM-1640

FiberID sometimes takes too long

Task Normal Done Done karr cloomis EngRun Mon, 20 Jun 2022 00:02:59 +0000 Fri, 2 Sep 2022 12:56:35 +0000 Thu, 21 Jul 2022 02:52:54 +0000 ics_mcsActor 0 3 <p>I'll take a look at that. It definitely shouldn't be taking that long!</p> <p>Do you have examples of frameIds where this happens?</p> <p>(In the log segment): 7739802</p> <p>I've figured out what's causing the problem - in some cases when there are a lot of ambiguous fibre identifications, the determination of the distance from target is being inefficiently.</p> <p>I have the idea of what will fix it, but need to work out the complex book-keeping to go with tracking all the assignments through the loop,. </p> <p>Spoke too soon. The distance calculation is lightning fast (using cdist); the bottleneck was the use of argsort to find the global closest matches between unassigned fibres and unassigned cobras. </p> <p>Have replaced argsort with the use of argpartition, as it's only the closest points that are of interest; this is a significant improvement.  We still probably want it faster, but I need to think about how to do so. </p> <p>I've pushed an update, but I want to run it though some more tests to be really sure that I haven't broken anything. </p> <p> </p> <p>There are a couple of modifications that will speed things up in extreme cases, like the dot crossing routines, mostly via complicated book-keeping so we don't need to recompute distances between points and targets.  In addition, for regular convergence runs, once the cobra_target table is properly populated, we can save time by doing fast matching at the beginning of the sequence for no longer moving cobras, the way we match the fiducial fibres. </p> <p> </p> <p>Implemented the first set of changes. </p> <p> </p> <p><a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=karr" class="user-hover" rel="karr">karr</a> will close this ticket based on the first set of changes, and file a new ticket for the work related to the <tt>cobra_target</tt> table.</p> <p>Merged to master.x</p> Development Rank 0|02qpiq:i Sprint preEngRun07Sep