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-3 Target to fiber allocation and configuration <p>I understand this is for a testing purpose, but please remove this constraint or loosen (say 250 mm?). Now the distribution of allocated objects looks like "circle" not "hexagon".</p> FIBERALLOC-3

Objects in a distance >190mm are discarded

Task Major Done Done Martin Reinecke Kiyoto Yabe Wed, 9 Nov 2016 05:15:51 +0000 Wed, 2 May 2018 06:15:37 +0000 Wed, 2 May 2018 06:15:37 +0000 0 3 <p>I can certainly remove this radius limitation. The only problem (as long as the code is being tested for correctness and quality) is that, if we do this, the "fract" parameter immediately loses its meaning, since the (unconstrained) input data set will most likely contain targets that the telescope can never observe in the requested configuration. So it will be hard to experiment with questions like "how many exposures do we need for observing at least x percent of the targets with a particular allocation strategy?"</p> <p>A possible compromise would be to first determine a lilst of all targets that the telescope can observe in all its allowed positions (nposang*nptg*nptg), and use this to determine the fractions. However that will artificially increase the required number of exposures, since some of the targets will only be visible for a single telescope position.</p> <p>Alternatively I can change the code in a way that it doesn't constrain the target list, and instead of a fraction of sources to observe, it just takes a maximum number of exposures to perform.</p> <p>I'd appreciate any comment on this.</p> <p>I have an implementation ready which removes the radius constraint and replaces the "fract" parameter with an "n_exposures" parameter. I'll commit if we conclude that this is the desired solution.</p> <p>Yes, I got your concern. Probably putting constraint is OK for calculation of the fraction, but the current value of 190mm (probably the width of the FoV in X direction) is too small for the hexagonal FoV. I propose 230 mm (the width in Y direction), so that we can define the circumscribed circle as the available region.</p> <p>If we choose 230mm as the cutoff radius, then the PFS will still not be able to observe all positions in that circle, unless we allow completely free rotation. And even if we do, the probability of a target being observable drops very quickly in this outer region. (E.g. a target that's at a distance of 230mm from the center will only be observable by choosing a very specific PA, whereas a target at a distance of 190mm will be observable by almost any PA.)<br/> Using this large radius and specifying a large fraction of targets to observe will result in very, very many exposures which, at the end, are trying to observe single targets at the largest radii. This is not a realistic situation (I hope).<br/> It is very possible that I am misunderstanding your suggestion. If so, please let us discuss further.</p> <p>I think it is true that the probability of observation is low in outer region, and the "fract" parameter may never reach the required value (especially if we fix the position angle), but I think it seems to be OK. We should stops the code if the change of the fraction almost converges (the current code does so, I think). I think the only problem in the current situation is that we can never assign objects within the FoV but outside the 190mm circle. Perhaps, I am wrong on my side...</p> <p>As I said, these problems can be overcome for the most part if we first establish a list of targets that can be observed by any of the possible telescope configurations and then run the code for a predefined number of observations.<br/> I have the necessary changes in my local tree, and they behave exactly as expected. I will commit them to the repository for evaluation. It's easy to revert them if desired.</p> <p>Thank you for pushing you updates. I will check this version.</p> <p>Where are these numbers coming from?  We need <b>one</b> source of PFS numbers that everyone can import.  A possible place would be in the datamodel project on GitHub, but we could invent another.  The mappings from cobra-&gt;slit should be there too.</p> <p> </p> <p>And I'm totally confused by the discussion!  Why do we need a field-radius when we know the exact geometry of the cobras?  Is there some approximation being made somewhere that affects the targeting (and if so does it affect the network-flow solver?)</p> <p>Hi Robert,</p> <p>no need to worry, I think. This issue is actually closed since late 2016, and I'm not sure why it was reopened (along with a few others) a few minutes ago. The current software does not have any such constraints.</p> Development Rank 0|ii00w7: