Details
-
Type:
Bug
-
Status: Invalid
-
Resolution: Done
-
Fix Version/s: None
-
Labels:None
-
Story Points:4
-
Epic Link:
-
Sprint:AP S21-4 (March)
-
Team:Alert Production
-
Urgent?:No
Description
Trying to process DC2 data from /datasets/DC2/repoRun2.2i/ results in the following error:
RuntimeError: FilterLabel(physical="r_sim_1.4") has no band. |
The first time this is encountered is in isr.fringe with a call to the checkFilters() function in isrFunctions.py :
https://github.com/lsst/ip_isr/blob/master/python/lsst/ip/isr/isrFunctions.py#L870-L903
There seems to be two issues here. One is that the filterList being passed in in this case is empty, so there shouldn’t even be a check being made. This begs the question of whether this function should start with a check along the lines (or an error and make the calling code responsible for passing a non-empty list?):
if len(filterList) == 0:
|
return False
|
Even if I add this condition and get past isr, I then get a similar failure in meas_astrom at the filterLabel setting here: https://github.com/lsst/meas_astrom/blob/master/python/lsst/meas/astrom/ref_match.py#L257
Indeed, the exposure in play here does not have a bandLabel associated with its FilterLabel:
filterLabel = exposure.getFilterLabel() |
print(filterLabel) |
FilterLabel(physical="r_sim_1.4") |
so the attempt to call filterLabel.bandLabel is what is failing and causing the RuntimeError. This ticket is to address the lack of bandLabel being associated
with these exposures. A separate ticket will address the issue of whether this lack of bandLabel should be caught earlier (and when/where – if at all – it would be appropriate to be checking FilterLabel.hasBandLabel() before trying to access bandLabel).
This seems to be related to the issue on DM-29313.
Yep, you could try something like:
Traceback (most recent call last):