GSoC 2016 Application Kumar Ayush:Implement PSF photometry for fitting several overlapping objects at once

Organization/Sub Organization

OpenAstronomy/AstroPy

Personal Information

Name: Kumar Ayush
Email: cheekujodhpur@gmail.com
Telephone: +91 946 88 54691
Time zone: GMT +5:30
Github username: cheekujodhpur
Homepage: http://cheekujodhpur.github.io
Blog: http://cheekujodhpur.github.io/gsoc

University Information

University: Indian Institute of Technology, Bombay
Major: Engineering Physics
Current Year and Expected Graduation date: Sophomore, graduating in 2018
Degree: B. Tech

Project Proposal

Title: [AstroPy] Implement PSF photometry for fitting several overlapping objects at once
Abstract: There are several ways to do photometry and the package currently implements aperture photometry (just add up all the flux in an image in some some area) and single source point-spread-function (PSF) fitting (fit a function such as a Gaussian to the image). In many situations, sources may overlap in the image, e.g. when observing a dense star cluster, so that we need to fit many functions at once. However, the simple brute-force approach “just fit a model with hundreds of parameters” if there are hundreds of stars usually fails.

The popular standard DAOPHOT splits the sources into subgroups to reduce the number of parameters. In this project, I try to implement this algorithm at least and a proposed modification based on Barnes-Hut tree [2] and then look at how other more modern astronomy codes tackle this problem. Speed critical parts would be jitted or coded in Cython. I plan to do elaborate testing at every stage to compare performance both in terms of quality of fits and speed.

I want to be less ambitious and first perfect a system which works at par with an established code before looking at modern alternatives.

Technical Details:
Here are the technical details referenced in my timeline and proposal.

• DAOPHOT GROUP: This is the DAOPHOT algorithm that I keep mentioning through the loop [2]. The task of fitting N stars involves O(N³) computations which can be reduced to O(N³/v²) computations if divided into v subgroups. This division can be done based on a parameter where stars that fall closer than this are part of the same group.
• The exact method of grouping the stars can be relevant to the optimization you obtain in terms of quality of the fit. In addition to the naive single paramter based approach, I am thinking of using a Barnes-Hut tree [3] to form and store these groups.
• The above grouping can lead me towards a modification in DAOPHOT GROUP. We can fit for fewer parameters for all groups on a higher level and then fit for more parameters on a lower level only if the residuals exceed a pre-defined error limit. For example, in a field of 400 stars, we can fit for 300 stars ignoring the 100 stars which are close to some of the other 300 and if the residuals between PSF and aperture magnitude vary by more than a parameter for a subgroup of say 25 stars, we fit again withing this subgroup. This is partially inspired from Adaptive Quadrature. [4]

Timeline:

Period	Task	Description
April 25- April 29	Bond Formation	I would like to get familiar with people who have worked on Photutils during this time, learn more about their preferred coding styles; community bonding.
May 2- May 6	Measuring the mountain	arXiv:1212.0564 provides a performance comparison for source extraction between DAOPHOT/ALLSTAR and SExtractor. Their emphasis is on the reliability of detection and quality of results in terms of magnitudes and centroids. They use artifical image simulations from Stuff and SkyMaker which allow us to know exactly the percentage and the type of input sources and their photometric properties. I will test the performance of photutils and IRAF DAOPHOT/ALLSTAR in crowded stellar fields based on photometric depth, residuals between PSF and input magnitudes and several other paramters as described in the reference. [1] You would notice and point out that I am already placing an emphasis on DAOPHOT. Being a part of IRAF, DAOPHOT stands to be the standard among professional astronomers as of now. Before we step into checking what else is available, I believe it is a safer bet to try imitating DAOPHOT's results
May 9- May 13	The Secret Ingredient	My test results from previous week should describe the problems with photutils naive fitting approach better. I am guessing there are issues with quality of the fits rather than this being a computational cost problem alone. This week, I will try to implement the naive DAOPHOT GROUP algorithm this week. Most importantly, I will write the pseudo code for my modified approach to GROUP as mentioned.
May 16- May 20	Sharpening the Sword	Before I go ahead to implement the said pseudo-code, I would want to take a quick look into literature and learn more about the alternative approaches. I have used photutils for aperture photometry but am not very familiar with PSF photometry aspects. This is also the time I get familiar with the code in detail, deepen my community bonding and gather opinion about my implementation ideas.
May 23- May 27	Strike #1	Implement the modified DAOPHOT algorithm for fitting multiple sources in Python
May 30-June 3	Strike #1 contd.	With the critical assumption that I am able to make the algorithm work in the previous week, I think it will take me this full week to integrate it with the astropy and photutils data types and framework, while furnishing the code to work with different parameters or options and documentation.
June 6-June 10	Testing the prototype	I will run performance tests whose nature I have already mentioned in the second week, to compare how my code works against the DAOPHOT standard. In the ideal scenario, there should be a difference in speed but the quality of fitting ought to be identical or better. If we're deviating from the ideal scenario, I will have to find the cause and fix it. In either case, I will also identify the speed critical parts of the code.
June 13-June 17	Strike #2	Write speed critical parts in Cython. If I am able to get that working within a week, I am enthusiastic about trying out jit for the speed critical parts or a wrapper on FORTRAN code. This is partly for learning and fun.
June 20- June 25	Midterm Evaluation	One day can be devoted to midterm evaluations. I should have a demo for the photutils implementation of the DAOPHOT algorithm for fitting overlapped sources. I will write preliminary documentation for that too.
June 27- July 1	Strike #2 contd./Buffer	I will complete the cythonization as mentioned. And I am keeping this week as buffer if there are unprecedented delays in my timeline above.
July 4- July 8	Strike #3	Write methods and/or object classes for the complete loop of processing overlapped sources:detecting, fitting, subtracting; detecting again to find sources which we missed in the previous run because of neighboring brighter sources, fitting, subtracting;repeat. If I have the code for fitting multiple sources ready, writing and perfecting this loop should be finished withing this week.
July 11- July 15	Strike #3-contd./Buffer	I have a system that works. I can now document and test it against IRAF DAOPHOT. Second buffer this week if something is off schedule.
July 18- July 22	What's new in town?	There are several other packages for PSF fitting such as T-PHOT and PYGFIT. Modern literature holds claims into advanced machine learning and statistical methods such as Artifical Neural Networks and RJMCMC. I can compare performances of these packages versus my code for a variety of odd situations such as asymmetric fitting and noisy background.
July 25- July 29	Doing something about it	Write object classes and skeletal structures which can incorporate some of these new ideas easily into our current framework. I can then open feature request issues. I do not plan to get even close to completing. integrating these fancier methods into photutils but I believe opening up a path and taking a step is important
August 1- August 5	Roughed Up Strikes/Buffer	I have no major task for the previous two weeks, so I can buffer this week to fix issues if they arise form the community within that time. I will write as much code as possible for newer methods from literature as mentioned above if the community deems them useful. Again, the aim is to jot down a skeleton which can be filled later.
August 8- August 12	Documentation, tests and CI	I will write documentation about my code, write the tests I've been using into standard photutils tests and pay greater attention to CI warnings if any. The current tests look fairly simple but as perfect as they have to be, I believe much thought goes into them so that could take time to write.
August 15- August 23	Final Blow	Correcting lints, improving documentation, checking if all tests and builds work fine. Anyone should be able to use and improve the code without my intervention - those are the ideals I aim to achieve this week. 1 day for writing mentor evaluation
August 24-August 30	Party	I would take some time to visit the beautiful beaches in Mumbai or maybe take a weekend off to Goa.

Possible Extensions:

• There are always newer methods coming up in the literature. I have highlighted some of them which I won't be implementing but writing skeletal structures and pseudo code which can be implemented as an extension to my project
• We are very oriented towards crowded stellar fields throughout this project but odd situations such as extended sources with asymmetric PSF and noisy background need to be tested and dealt with.

Pull Request: [Pending] https://github.com/astropy/photutils/pull/335

Bio

About Me: A 19 year old who loves doing Physics and writing code. I play the Violin in my free time. I also love road trips.
Astronomy Experience:

• I have represented India twice at International Astronomy Olympiads and can brag silver medals.
• Last year, I contributed to selecting and mentoring the Indian team to the Olympiad which won 3 golds and the Best Team Award.

I would like you to take a look at my Astronomy [Projects](http://cheekujodhpur.github.io/projects):

• Writing an artificial neural network for calculating photometric redshifts
• Primarily a data analysis and fitting project, An X-Ray Study of Black Hole Candidate X Norma X-1
• My most recent Astronomy project which introduced me to photutils where I had to study variable star populations and microlensing events in globular clusters. The relevant code for this is documented in the appendix of our report here.
• I also gave a talk on CCD Photometry this semester catering to the Astronomy Club in my institute.

Coding Experience:

• ganit: C++ code for a symbolic computation parser, does minimal stuff. Wrote in high school as my CS project.
• Started my Open Source experience at Google Code-In with Sugar Labs. I participated twice and completed only a handful of tasks as I always used to have other commitments in December. But this tiny experience taught me all about IRC, Github, PRs, CI. My first merged PR: Shows path instead of activity name
• Solved a beginner bug for Mozilla.
• Wrote a software system for International Physics Olympiad held in India last year.
• Radio Dipole Anisotropy: We were trying to find anisotropy in the universe with respect to distribution of radio sources in NRAO survey. This was my first bit of FORTRAN code.
• I've done some commercial web development: https://www.grandimagazzinibomboniere.it/; wrote this e-commerce website from scratch.

References

[1]: arXiv:1212.0564
[2]: DAOPHOT 1987PASP...99..191S
[3]: Barnes Hut
[4]: Adaptive Quadrature