more flexible semi-analytic coronagraph code needed.

[mperrin]

Issue by mperrin
Tuesday Jun 07, 2016 at 17:49 GMT
Originally opened as mperrin/poppy#169

---

The updates to webbpsf to add additional optical planes (including coordinate inversion to get the pupil geometry right, and a placeholder pupil plane for measured WFE from ISIM CV testing) breaks the assumption of the Semi-Analytic Coronagraph class that there will be precisely four planes in an optical system. So webbpsf falls back to the classical propagation which is a bit slower and less accurate unless the oversampling is increased.

This needs a more flexible implementation which is smart enough to:

1. Propagate through some number of planes using regular propagation
2. Then apply the semi-analytic method for some additional few planes
3. Then go back to regular propagation for any additional planes.

This sounds like a real pain. Mostly bookkeeping and conceptually straightforward but a bunch of work to implement.

It might be more practical rather than writing a fully general solution to make a version which is specifically customized for the case of NIRCam in webbpsf:

1. Take the input pupil
2. Then apply the coordinate inversion to get the proper OTE exit pupil orientation
3. Then the semi-analytic coronagraph method
4. Then apply the SI WFE, if specified.

@josePhoenix @neilzim @kvangorkum @Skyhawk172 - opinions? Kyle, how bad would it be from your perspective if the next version of webbpsf were to (temporarily) break the semi-analytic method for the next month or two? I'm trying to decide if the above is something that needs to get fixed this week prior to the release or not...

[mperrin]

Comment by josePhoenix
Tuesday Jun 07, 2016 at 17:54 GMT

---

Based on mperrin/webbpsf#30 I think it's safe to say the SAM implementation is already a little suspicious.

[mperrin]

Comment by josePhoenix
Tuesday Jun 07, 2016 at 17:55 GMT

---

I never did get around to doing the analytic check Laurent suggested. Other things were higher priority. I should get back to that.

[mperrin]

Comment by mperrin
Wednesday Jun 08, 2016 at 23:17 GMT

---

I misspelled @kvangorkom when tagging people on the above question yesterday. Kyle see query in this thread...

[mperrin]

Comment by kvangorkom
Thursday Jun 09, 2016 at 15:18 GMT

---

The practical drawback here is longer PSF computations for NIRCam radial occulters for a month or two? I wouldn't expect this to be a big hit on my productivity, but @Skyhawk172 might have other opinions.

[mperrin]

Comment by Skyhawk172
Thursday Jun 09, 2016 at 15:31 GMT

---

I have already generated tons of NIRCam bar occulter data, and I don't expect to need to run more for the next 1-2 months, so I have no strong objections with temporarily breaking the current paradigm.