Release planning / prioritization for 0.5

[mperrin]

Issue by mperrin
Thursday Apr 21, 2016 at 22:06 GMT
Originally opened as mperrin/poppy#163

---

There are a bunch of substantial enhancements & refactoring tasks on the to-do list for 0.5, and the question is how much can get done before the AAS meeting (that deadline being driven by needing to release the next WebbPSF then).

• Refactor getPhasor to get_opd, get_transmission, get_phasor #158 the refactoring of getPhasor (this is now basically ready to go in PR GetPhasor -> get_opd, get_transmission refactor #162, pending agreement from the rest of everyone that my revised API looks OK. )
• Anti-aliased apertures needed to increase numerical accuracy #129 for anti-aliased apertures (work in progress, does not work yet)
• Use astropy.units more consistently across POPPY #145 for astropy.units usage (work in progress, does not work yet)
• Consider refactoring plane types from OpticalElements to OpticalSystems #154 for cleaning up how plane types are implemented (work in progress, does not work yet)

Of the latter 3, I suspect I will only have time to do significant work on one or maybe two over the course of the next month. So the questions to you all (@josePhoenix, @neilzim, @douglase) are:

1. How would you prioritize between Anti-aliased apertures needed to increase numerical accuracy #129, Use astropy.units more consistently across POPPY #145, and Consider refactoring plane types from OpticalElements to OpticalSystems #154? Let's say I only have time to get one done in 0.5, which would it be? My personal preference is probably Use astropy.units more consistently across POPPY #145 or Consider refactoring plane types from OpticalElements to OpticalSystems #154 since those would have the most impact on API changes and we're already mucking with the API given Refactor getPhasor to get_opd, get_transmission, get_phasor #158. But Anti-aliased apertures needed to increase numerical accuracy #129 has the most impact on numerical accuracy.
2. Does anyone expect to have time to contribute to any of those? (This question is directed more at STScI folks than at @douglase since I know he's got a thesis to finish up) We should chat sometime soon IRL about dev priorities for poppy vs webbpsf too, and figure out what's really feasible to get into webbpsf 0.5.

[mperrin]

Comment by douglase
Friday Apr 22, 2016 at 14:23 GMT

---

For question 1: my ordering would be: #145,#129,#154. Units add flexibility and it has the larger impact on the API, while aliasing noticeably impacts performance. #154 doesn't seem like it adds functionality and might be tricky to implement without breaking existing systems.

For question 2: Thanks for the excuse, I am indeed still writing. The end is in sight (if not precisely defined)...

I'd also like to make sure further aberrated wavefronts don't fall off our radar (#1, #92).

[mperrin]

Comment by mperrin
Monday May 23, 2016 at 02:05 GMT

---

• Refactor getPhasor to get_opd, get_transmission, get_phasor #158 implemented in PR GetPhasor -> get_opd, get_transmission refactor #162
• Use astropy.units more consistently across POPPY #145 implements in PR Use astropy.Quantities for all wavelengths everywhere #165
• Anti-aliased apertures needed to increase numerical accuracy #129 partially implemented in branch subpixel_geometry but not going to see any more progress in time for the next release.
• Punting on Consider refactoring plane types from OpticalElements to OpticalSystems #154