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

Create a better set of simulated data for the deblender

    Details

    • Type: Story
    • Status: Done
    • Resolution: Done
    • Fix Version/s: None
    • Component/s: meas_deblender
    • Labels:
      None
    • Story Points:
      10
    • Sprint:
      DRP F17-3, DRP F17-4, DRP F17-5
    • Team:
      Data Release Production

      Description

      Currently the deblender test data (located here) has 5 simulated images created with galsim. Blends are separated by running the stack's `detection` task on them, which estimates positions for the objects and groups them together.

      Many of the "blends" detected are not actually blended objects, and many other objects are too faint to be detected by the pipeline (at least in the current catalogs). This makes it difficult to compare the deblender results with the simulated data, where there are a few big and dense blends and a larger number of "blends" whose objects aren't really blended together. The output created in this ticket will be images in all 6 LSST bands, the psf image, the variance in each band, the "truth" catalog, and a set of stack objects (calexps and merged catalogs) for use in the stack.

      This is a change in scope from the original description of this ticket, which was just to make the current images more accessible to non-LSST Stack versions of the deblender (ie. the WFIRST deblender).

        Attachments

          Activity

          Hide
          fred3m Fred Moolekamp added a comment -

          One of the problems with the current sims is that they are large images with objects randomly placed on them, using the LSST stack to detect sources and select the blended groups. A better solution would be to create a set of blends of various sizes and densities so that we know which objects are included in each blend. This will make it easier to have a non-stack version of the simulated images and greatly simplify the procedure for comparing the deblender results to the true values of the simulated blends.

          Show
          fred3m Fred Moolekamp added a comment - One of the problems with the current sims is that they are large images with objects randomly placed on them, using the LSST stack to detect sources and select the blended groups. A better solution would be to create a set of blends of various sizes and densities so that we know which objects are included in each blend. This will make it easier to have a non-stack version of the simulated images and greatly simplify the procedure for comparing the deblender results to the true values of the simulated blends.
          Hide
          fred3m Fred Moolekamp added a comment -

          Hey Peter,
          I added 3 new directories with simulated data:

          1. psf_matched_sim : psf matched simulations with different bulge/disk SEDs
          2. unmatched_sim : simulations with different bulge/disk SEDs and different psfs in different bands
          3. matched_real : psf matched simulations with real galaxy morphologies (but a single SED)

          When you get back in town, can you have a look at these and review the ticket?

          Show
          fred3m Fred Moolekamp added a comment - Hey Peter, I added 3 new directories with simulated data: psf_matched_sim : psf matched simulations with different bulge/disk SEDs unmatched_sim : simulations with different bulge/disk SEDs and different psfs in different bands matched_real : psf matched simulations with real galaxy morphologies (but a single SED) When you get back in town, can you have a look at these and review the ticket?
          Hide
          pmelchior Peter Melchior added a comment -

          These are exactly what we need. Please check the pixel_scale=0.23 parameter in the YAML file. It seems not to be read.

          Also, we'll need a new ticket to collect summary statistics of such a run with, say, 1000 objects: flux, colors, ellipticity. Position and radius are either not very relevant or dependent on the precise definition, so we can/should ignore them.

          Show
          pmelchior Peter Melchior added a comment - These are exactly what we need. Please check the pixel_scale=0.23 parameter in the YAML file. It seems not to be read. Also, we'll need a new ticket to collect summary statistics of such a run with, say, 1000 objects: flux, colors, ellipticity. Position and radius are either not very relevant or dependent on the precise definition, so we can/should ignore them.

            People

            • Assignee:
              fred3m Fred Moolekamp
              Reporter:
              fred3m Fred Moolekamp
              Reviewers:
              Peter Melchior
              Watchers:
              Fred Moolekamp, Peter Melchior
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Summary Panel