more robust when fiberassign in earlier expid #1529
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR fixes #1272 where the "look in previous exposures for the fiberassign file" could end up grabbing the wrong fiberassign file. I originally was just going to turn off this look-back behavior since it isn't needed in normal ops, but there may be special test cases of setting up on a tile and then doing some manual exposures that could result in spectrograph exposures without a matching fiberassign file in the same EXPID, so the updated logic is:
It also corrects a case where the coordinates file is missing fiber location information, by correctly flagging the fibers as FIBERSTATUS MISSINGPOSITION.
Example case of previous code finding and using an incorrect fiberassign file (now generates a RuntimeError because it can't find a good fiberassign file):
Example case of correctly walking back to find a fiberassign file, albeit with missing info in the coordinates file resulting in FIBERSTATUS flags:
This PR also introduces a utility function
desispec.io.util.checkgzip(filename)
that will look for a filename with or without the .gz extension; this is handy for cases like fiberassign where sometimes it is gzipped or not. We may also use this in the future with the pipeline if infrequently used files get post-facto gzipped and we want the code to easily find the right file either way.