hassan: I've defined a SpectralPsf base class, with an ImagePsf specialisation that should allow us to wrap a PsfexPsf from LSST. Is this sufficient definition?

I expected this to inherit from the LSST class (but would check with jbosch first).  I am very suspicious of an API that fundamentally works in terms of (fibreId, lambda) as we measure things in terms of (x, y);  I can see adding an API that takes a DetectorMap as a convenience.

Why do we have our own separate class hierarchy?

I don't think I know enough to comment usefully on most of this, but if you do need to define a new PSF API instead of using LSST's, I'd strongly recommend not defining an API that includes spatial variation in C+++ if you can avoid it (in other words if you can always evaluate the PSF at a point in Python, yielding an image or some kind of local PSF class to pass to C++, do).  That will make it a lot easier to write what is probably not performance-critical code in Python instead of C++.  It's also something LSST may have to do someday, as disruptive as it might be, in order to use Piff (it's not the only solution to that problem, but it's definitely on the table).

The fundamental requirement is that the SpectralPsf works in terms of (fiberId, lambda) (that's all we really care about when we come to subtract sky lines), so the interface is defined in terms of that. Note that there is a specialisation that composes an LSST Psf, which sweeps all the (x, y) details under the rug so the user doesn't need to worry about them.

I could re-write in python, but I think this approach (composition instead of inheritance) is the Right Way as it hides the (x, y) details from the user.

I want this PSF to work in detector coordinates, please.  That's where it defined and measured.  I understand that we will often use it in (fibreId, lambda) but that mapping is derived; we need to make it convenient, but I don't want it to be primary. For example, if we change the order of the wavelength fit it doesn't change the PSF.

I've updated the code to work in detector coordinates, and put the implementation in python as was suggested.

It's not yet clear whether we need this implementation to be in C++ or not. We need ncaplar to explain how his PSF code works so we know how difficult it will be do implement in C++.

I am not sure that I fully understand the question.

The code that generates the oversampled images is quite complex and I doubt that it can be moved outside Python without considerable effort, especially at this stage.

What I do at the moment is to supply a big array, which contains samples of PSF on many positions of the detector. From this, one can interpolate PSF at any position of the detector. Initial function is in PIPE2D-347.

I doubt this an answer to the question you are looking for, but I am not sure I can provide better one without further clarifications.

No, that's really useful, ncaplar. It looks like you've done all the difficult work outside the function you're providing, which just finds the two closest arrays and does a linear interpolation. That's something we can easily do in C++, I think.

rhl, shall I push this down to C++? And I may as well integrate Neven's code while I'm at it.

I have pushed the PSFs down to C++ and implemented the NevenPsf, based on the PSF realisations and interpolation algorithm provided by ncaplar. It sounds like Neven wants to update the realisations slightly, which we may as well do as part of this ticket, but I think this is ready for a new review. rhl and hassan, please have a look!

Just to clarify, I will update the arrays that I provide in PIPE2D-450. I propose to create 211x211 images where position of chief ray is in the center pixel (instead of current 210x210 version).

I believe this is ready to merge. It's already being used for the work in PIPE2D-326, so we should get this into master. I propose to merge tomorrow if there are no objections.

Merged to master.