Joseph Long

I think you've understood my issue correctly. > If your catalog covers a decent area, this should be fine. If it's a tiny area, like less than a single SCA,...

That does sound helpful. I feel like I should be able to do this with some trigonometry, but an analytic solution eludes me. This is what I've come up with...

Fundamentally, there are three places to store the state that determines the output of a PSF calculation, when there should only be one. We've noticed this in the past with...

This is less "this should go in the next point release!" and more "we need to improve the Instrument class internals, and I believe this would improve the API as...

This has the additional benefit of making it easy to see what FOV you're going to get if you don't specify one, without looking in the code. (Simply `print(inst.fov)`!) Using...

The problem is that we have multiple keyword arguments to `calc_psf` mapping onto the same thing. Additionally, users of the API need to look in at least three places to...

Another API could be mechanisms as attributes of instruments, and calculation options as attributes of a PSFCalculation object initialized as an attribute of the instrument: ``` inst.filter = 'F1000W' inst.psf.fov...

I solicited some comments from an anonymous WebbPSF user 😉 > User: So, hm. I agree that it's confusing to be able to have conflicting attributes and arguments passed to...

_(From #44)_ From poppy.Instrument.calcPSF: ``` rest Output sampling may be specified in one of two ways: 1) Set `oversample=`. This will use that oversampling factor beyond detector pixels for output...

I think we should try to eliminate the oversampling keyword argument defaults where ever we can, and handle it all in one place. Where that should be is unclear...