Bug in meas_extensions_shapeHSM?

Support
#1

Hey folks!

I’m running through the drp on v27_0_0 and have noticed that all of the shape measurements coming from the hsm extension are assigned NAN. I’ve dumped the debug log and it looks like the extension keeps crashing with the error:

lsst.measure.measurement.ext_shapeHSM_HsmShapeRegauss DEBUG: Exception in ext_shapeHSM_HsmShapeRegauss.measure on record 1441151880758582426: 'lsst.afw.table._table.SubSchema' object has no attribute 'get'

Checking out the current stack the only .get() call in hsm is line 190, and commenting out the second call on this line suppressed the specific debug output above… but I’m running through the rest of my pipeline now to see if the shape measurements have been restored. I’ve encountered this bug before on a weekly build as well, but it was not an issue in v26_0_0. Is there a proper fix for this (other than commenting out a line in the stack… which I know isn’t a great idea generally speaking)

Thanks!

Anthony

#2

Hi Anthony - it is possible that there is a bug, if this worked in the past and is not working now. I will alert the DM folk about it.

1 Like
#3

Thanks Greg!

For the time being I’ll backdate to v26, I think omitting the .get(…) call will mean that, effectively, parent sources not deblended into children (e.g. a parent source with nChild = 0) won’t have their shapes measured, which shouldn’t be the case. The weird part is that if I try to manually load-in source records and call the .get(…) function I don’t run into any issues, so I think this has something to do with the fact that record is a SubSchema rather than a SourceRecord… why all of the other functions implemented in the SourceRecord class below this line work I’m not sure…

Hopefully this get’s resolved or the fix is just a few lines, if so I can implement that manually on my stack until the next version of the stack is released :slight_smile:

#4

Thanks for reporting this. I’m positive that the fix is at most a couple of lines and we are looking into it.

#5

Hi @arunkannawadi, do you have any updates on this bug fix? Thanks!

#6

Could someone post a minimal snippet? We do run this measurement plug-in on a regular basis and haven’t seen this error pop up so far.

#7

This is very strange. record should not be a SubSchema. Even if you fix that one line, the subsequent call to record.getFootprint().getBBox() will almost certainly fail if it’s not actually a SourceRecord.

#8

Hi @antenglert , just wanted to follow up with you on the bug you were encountering to see if it’s still an issue for you.