Uploaded image for project: 'Data Management'
  1. Data Management
  2. DM-10626

afwTable SourceCatalog returns garbage for invalid keys

    XMLWordPrintable

Details

    • Story
    • Status: Invalid
    • Resolution: Done
    • None
    • afw

    Description

      In python, when I have a SourceCatalog with a record in it, I should be able to call any getter for a numerical value listed in dir(record) directly on the SourceCatalog. However, in some cases the getter exists even though the field does not (see example below). In that situation calling the getter on a record raises an exception (which is good) but calling it on the catalog silently returns garbage data.

      $ import lsst.afw.table
      $ schema = lsst.afw.table.SourceTable.makeMinimalSchema()
      $ catalog = lsst.afw.table.SourceCatalog(schema)
      $ record = catalog.addNew()
      $ record['coord_dec'] = lsst.afw.geom.degrees*(-5.0)
      $ record['coord_ra'] = lsst.afw.geom.degrees*(22)
      $ record['id'] = 8
      $ record['parent'] = 3
      $ record.getModelFluxErr()
      Traceback (most recent call last):
        File "<stdin>", line 1, in <module>
      lsst.pex.exceptions.wrappers.LogicError: 
        File "include/lsst/afw/table/BaseRecord.h", line 87, in const typename Field<T>::Element *lsst::afw::table::BaseRecord::getElement(const Key<T> &) const [T = double]
          Key is not valid (if this is a SourceRecord, make sure slot aliases have been setup). {0}
      lsst::pex::exceptions::LogicError: 'Key is not valid (if this is a SourceRecord, make sure slot aliases have been setup).'
      $ catalog.getModelFluxErr()
      array([  1.02765654e-320]
      

      Attachments

        Issue Links

          Activity

            ctslater Colin Slater added a comment -

            I think the issue is coming from around here:
            https://github.com/lsst/afw/blob/53755dd0584699b5440f0532d756d60c32422c42/include/lsst/afw/table/Source.h.m4#L116

            The getters on the catalog are getting passed through to the C++ SourceColumnView, which uses the table keys without checking if they are valid. BaseRecord::getElement() does this checking, so it does not have the same problem.

            I somewhat regret looking this up, because I was previously blissfully unaware that we had m4 code in afw.

            ctslater Colin Slater added a comment - I think the issue is coming from around here: https://github.com/lsst/afw/blob/53755dd0584699b5440f0532d756d60c32422c42/include/lsst/afw/table/Source.h.m4#L116 The getters on the catalog are getting passed through to the C++ SourceColumnView , which uses the table keys without checking if they are valid. BaseRecord::getElement() does this checking, so it does not have the same problem. I somewhat regret looking this up, because I was previously blissfully unaware that we had m4 code in afw.
            ctslater Colin Slater added a comment -

            I might have spoken too soon. I think the right fix might be for BaseColumnView::operator[] to check if keys are valid (https://github.com/lsst/afw/blob/53755dd0584699b5440f0532d756d60c32422c42/src/table/BaseColumnView.cc#L71).

            ctslater Colin Slater added a comment - I might have spoken too soon. I think the right fix might be for BaseColumnView::operator[] to check if keys are valid ( https://github.com/lsst/afw/blob/53755dd0584699b5440f0532d756d60c32422c42/src/table/BaseColumnView.cc#L71 ).

            People

              Unassigned Unassigned
              mrawls Meredith Rawls
              Colin Slater, Jim Bosch, John Parejko, Meredith Rawls, Russell Owen
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Jenkins

                  No builds found.