drphilmarshall / OM10

Tools for working with the Oguri & Marshall (2010) mock catalog of strong gravitational lenses
MIT License
8 stars 19 forks source link

Paint galaxies and quasars with synthetic SEDs #43

Open drphilmarshall opened 7 years ago

drphilmarshall commented 7 years ago

We're going to try computing the magnitudes of the lens galaxies and lensed quasar images using @tcollett's lenspops code (as he suggested earlier this year).

@jennykim1016 : Can you please make a copy of the ColoredCatalogs notebook called "PaintingByHand.ipynb" and then modify the OM10 code, and this notebook, to develop this new functionality? You should start by working through this notebook locally, any parts that we don't need (like placing galaxies on the sky) and changing the text to describe what we are trying to do. Then, you'll need to read and understand the OM10 DB class method paint to figure out what the code is currently doing, and then add a method="synthetic" option so that we can do

db.paint(method="synthetic")

This should call the relevant functions from lenspops in order to compute the required magnitudes.

As you figure out more things that need to be done, you can issue them here so we can discuss them. Here are some predictions:

and so on. As a rule, whenever you identify an item for a to-do list, you should write an issue on it. Then you can use the GitHub issue lists as your to-do lists :-) What do you think?

drphilmarshall commented 7 years ago

PS. As you make more issues, you should assign them to either yourself or one of us as appropriate, and also to the "Synthetic Multi-filter Catalogs" milestone.

drphilmarshall commented 7 years ago

Also @jennykim1016 : let me know offline if you want advice on working in branches. We'll do the development work described above in a branch called issue/43/painting, which I have just made. You can view it here, and you can push commits to it with

git push origin issue/43/painting

For sanity, you'll want to work in a local mirror of it, which you should be able to get to by doing

git pull
git checkout issue/43/painting

before you start editing.

jennykim1016 commented 7 years ago

@drphilmarshall I was running PaintingByHand.ipynb and it threw an error KeyError: 'MAGG_LENS when I called db.assign_sky_positions().

/Users/Jenny/anaconda/envs/python2/lib/python2.7/site-packages/om10/db.py in assign_sky_positions(self, verbose) for lens in self.sample: print "here" lens_features = np.array([lens['ZLENS'], lens['MAGG_LENS']-lens['MAGR_LENS'], \ lens['MAGR_LENS']-lens['MAGI_LENS'], lens['MAGI_LENS']-lens['MAGZ_LENS'], lens['APMAG_I']])

So, I tried to print lens.keys() out, and this returned ['LENSID', 'FLAGTYPE', 'NIMG', 'ZLENS', 'VELDISP', 'ELLIP', 'PHIE', 'GAMMA', 'PHIG', 'ZSRC', 'XSRC', 'YSRC', 'MAGI_IN', 'MAGI', 'IMSEP', 'XIMG', 'YIMG', 'MAG', 'DELAY', 'KAPPA', 'FSTAR', 'DD', 'DDLUM', 'ABMAG_I', 'APMAG_I', 'KCORR', 'DS', 'DDS', 'SIGCRIT', 'DSLUM', 'L_I', 'REFF', 'REFF_T', 'RA', 'DEC']. Apprantely, there is no MAGG_LENS or any information about G magnitude in the keys; would there be any way to fix this error? I know that assigning the sky position is not what I should worry about when working with lenspop to calculate the magnitude, but if I just comment this db.assign_sky_positions() out and proceed to the db.paint(lrg_input_cat='../data/LRGo.txt',qso_input_cat='../data/QSOo.txt') method, this method also throws error because the constructor does not have all the necessary information. So, I thought I should first fix the error associated with db.assign_sky_positions() and proceed to the db.paint* code. Thanks!

jennykim1016 commented 7 years ago

I hope you are having a really good thanksgiving break! Sorry for interrupting you, but I had one question to make sure that the code I am heading to the right direction.

I thought we would want to compute just the color index or integrated magnitude by calling the function db.paint(method='synthetic), but according to my note that I took during the meeting, I drew a diagram where two lensed quasars were painted blue and one center elliptical galaxy was painted red. Would I have to produce one coadd image at the very end? Would just computing the color index and integrated magnitude be enough?

Thanks! Have a nice holiday.

tcollett commented 7 years ago

Hi Jenny, Phil,

I only just noticed this thread. Let me know what I can do to help.

[NB/ LensPop can simulate colours for elliptical galaxies, and can simulate observations of mock lenses. I'm happy to skype sometime to talk about adding quasars in (I'm planning on doing this already, but from your dependencies, it looks like you're going to splice LensPop with OM10). Anyway, consider using FastLensSim.py (in LensPop) if you want to make simulated images for DES/LSST]

jennykim1016 commented 7 years ago

Dear Dr. Collett,

It is really an honor to meet you! I am currently working on coloring the pictures of quasars and the elliptical galaxies that are produced by OM10 using functions in the lenspop. Yesterday, I was modifying tools.py in https://github.com/tcollett/LensPop/tree/master/stellarpop/tools.py to calculate the magnitude of those objects, but I was not entirely sure whether I was doing the right thing, so I wanted to check with Dr. Marshall first. I don't think I have to generate simulated images as of now, but I will make sure to keep in mind to use FastLensSim.py if I have to make simulated images for DES/LSST. I will comment on this issue if I need any help; thank you so much, and have a nice week!

drphilmarshall commented 7 years ago

Hi @jennykim1016 - apologies for absence. Also hi @tcollett :-)

OK, let's see - first things first:

@drphilmarshall I was running PaintingByHand.ipynb and it threw an error KeyError: 'MAGG_LENS when I called db.assign_sky_positions(). ... Apparently, there is no MAGG_LENS or any information about G magnitude in the keys; would there be any way to fix this error? I know that assigning the sky position is not what I should worry about when working with lenspop to calculate the magnitude, but if I just comment this db.assign_sky_positions() out and proceed to the db.paint(lrg_input_cat='../data/LRGo.txt',qso_input_cat='../data/QSOo.txt') method, this method also throws error because the constructor does not have all the necessary information. So, I thought I should first fix the error associated with db.assign_sky_positions() and proceed to the db.paint* code.

Good that you identified this problem. Perhaps you can make out from the om10 code that what we were previously doing was trying to match real galaxies (with actual sky positions and actual measured magnitudes in several filters) to OM10 objects. This dis not work very well, so we are scrapping the idea and starting with lenspop instead. The way to think about the om10 code (and in fact any code) is "what do I want the code to do?" and then make it do it. In this case, You don't want to assign_sky_positions(). All you want to do is paint() galaxies and quasars - so you should edit the paint() method until it does what you want it to. Using the optional argument paint(method='synthetic') should allow you to keep all the old code in a separate part of the if block, and focus on making paint(method='synthetic') work.

According to my note that I took during the meeting, I drew a diagram where two lensed quasars were painted blue and one center elliptical galaxy was painted red. Would I have to produce one coadd image at the very end? Would just computing the color index and integrated magnitude be enough?

For now, we're after just the predicted magnitudes (and hence colors) - once we have them, we could think about making mock images, but I am hoping that we won't need to. We are interested in finding lens candidates (well, targets really) based on their catalog properties, so that we can then feed the resulting target positions to some sort of image analyzer. So for now, let's just make mock lens catalog entries - starting with magnitudes in the ugrizy filters.

Yesterday, I was modifying tools.py in https://github.com/tcollett/LensPop/tree/master/stellarpop/tools.py to calculate the magnitude of those objects, but I was not entirely sure whether I was doing the right thing.

Ideally, you would import lenspops and then call the lenspops functions as they are - but if you find you need to modify them in sensible ways, you should do that, in your fork. However, you should try hard to preserve the default functionality of lenspops so that it is easy for @tcollett to accept any pull requests you make! Again, working with optional keyword arguments is a good idea. When we next meet, I'd like you to talk @mbaumer and I through your use of lenspops so far; we can ask Tom for assistance any time, but we should make sure we only ask him when we are stuck (his time is very valuable!). See you on Tuesday, Jenny!

jennykim1016 commented 7 years ago

Dear Dr. Marshall,

Thank you so much, and I hope you are having a great thanksgiving break.

I made it possible for the ColoredCatalog.ipynb to import lenspop and call functions from lenspop. However, I asked the previous question because I haven't directly been using the function in lenspop. I have rather been using the module called tools.py in lenspop/stellarpop/tools.py to calculate the magnitude.

If I give filters, SEDs, and redshifts as input arguments to tools.py, then tools.py returns both AB magnitude and Vega magnitude in each filter(R/G/I/Z). There was no SED for quasars in lenspop/stellarpop/templates/, so I downloaded few different SEDs for quasars and ran the code.

I have been getting strange values for magnitudes(i.e. -21.20 for AB_G, -21.32 for AB_I, and -21.38 for AB_Z). The magnitudes themselves make sense if I just take absolute values, but I know that it not what I ought to do.

So I thought maybe this is because I am calling wrong functions or using unreasonable SEDs. I am trying to figure out what mistakes I have been making, and I think I will be able to finish that before Tuesday.

Thank you so much for spending your time for me, and have a nice weekend. I am really looking forward to talking to you again on Tuesday!

drphilmarshall commented 7 years ago

Hi @jennykim1016 - from the demo notebook issue #46 I can tell that you are close to being able to close this issue - depending on how the code review goes when you make your pull request! :-) When you start a pull request, you are asked which branch on the base repo you want your commits to be pulled into. You should choose issue/43/painting as I outlined above. This is so that we can all work on that branch before we finally merge into master in the base (drphilmarshall) repo: the drphilmarshall master branch is special, because its the one you get when you pip install OM10 - so we try to protect it. Thanks!

drphilmarshall commented 7 years ago

Update on this issue: @jennykim1016 's notebooks in #50 go most of the way to closing this issue: when we merge that PR we'll close this out.