Skip to content

Centroid shifts from lensing #557

Description

@rmjarvis

In addition to shear and convergence/magnification, lensing also moves the positions of objects around. We should have our lensing modules also be able to return a shift that is appropriate for the location of the galaxy. Then the user could apply that as well as the shear and magnification to get the complete lensing effect.

Activity

  1. reikonakajima commented on May 29, 2014

    @reikonakajima
    Member

    Shifts like in this paper? http://arxiv.org/pdf/1405.1432.pdf :)

  2. pmelchior commented on Jun 26, 2014

    @pmelchior
    Member

    I can implement the deflection angles for the NFW halo, so that one gets the new positions by iteratively searching for the observed positions given the pre-lensing positions.

  3. rmandelb commented on Jul 2, 2014

    @rmandelb
    Member

    What would that look like in terms of how the user interacts with the code?
    Right now they have to enter post-lensing positions. Is the idea that they would now be told to enter pre-lensing positions, which get shifted and the appropriate shear/magnifications applied?

  4. pmelchior commented on Jul 2, 2014

    @pmelchior
    Member

    I think there are two ways about that:

    1. We stick to post-lensing positions, then a new method, say getPosition() would return their pre-lensing positions. That's the easiest way, but not really useful because it doesn't solve the problem that the post-lensing positions do not reflect that presence of a halo (or any sort of matter distribution).
    2. We change to pre-lensing positions, then a new wrapper method would compute the post-lensing ones and call the existing shear/convergence methods with it. A second function call to getPosition() would return these coordinates. That's the right way of doing it, but it is costly computationally since there's an iterative solver involved for each (x/y) transformation.
  5. rmjarvis commented on Jul 2, 2014

    @rmjarvis
    MemberAuthor

    I favor the latter option. The typical use case in which one would care about these shifts is to have a uniform density of objects in the pre-lensing plane, and then want them plotted in the correctly lensed positions. So even though it is more work on our part, I think it's what the user will expect.

    As for the UI, I propose the following:

    getLensedPositions(prelensing_positions) # New function
    getPreLensedPositions(lensed_positions) # New function
    getShear(..., prelensed_positions=False) # New kwarg with default = current behavior
    ... likewise for getConvergence, etc.
    
  6. rmandelb commented on Jul 2, 2014

    @rmandelb
    Member

    So even though it is more work on our part, I think it's what the user will expect.

    +1.

  7. added
    starter projectsPossibly a good choice for someone looking to get started on GalSim development
    on Apr 11, 2016
  8. added
    lensingRelated to lensing inputs, such as the PowerSpecrum and NFWHalo classes
    and removed on Nov 21, 2016
  9. added
    descOf possible interest to LSST DESC members looking for a project
    on May 3, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    descOf possible interest to LSST DESC members looking for a projectfeature requestRequest for a new feature in GalSimlensingRelated to lensing inputs, such as the PowerSpecrum and NFWHalo classesstarter projectsPossibly a good choice for someone looking to get started on GalSim development

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions