benmontet/nutella

Great (point) spreads for beautiful Kepler/K2 inference

nutella's Issues

When a good fit is found, the inferred shift is half the real shift

Am I accidentally shifting twice somewhere

We should also implement derivatives into the minimizer

So it can minimize faster.

model should be larger than the entire psf

We were missing the dumb (right) way to calculate the total expected flux from a star in each cadence:

pred_flux = [np.sum(np.exp(model(*results[i], gds))) for i in range(len(tpf)]

Duh. Just calculate the model explicitly and sum over all pixels.

Anyway, when we do this (see the old notebook) we still get too much noise. I think this might be in part because the model region is smaller than the entire PSF and so the movement carries it out of the model region. The residuals look like noise (which is good!) but there is too much of it.

The good news is that we can see the sinusoidal pattern in the data. The residuals aren't quite centered around 0, but I believe this is a background issue and will be fixed when we fix #1.

PRF should never go below zero

Extend to consider multiple stars

I propose we fit for [Nstar x Ncadence] fluxes, [Nstar x2] positions (x and y), and [(Nstar-1) x2] offsets between stars. As the detector moves around the relative positions of stars will be fixed, so any apparent changes in the centroids of each is actually telling us something about the flat field.

replace our custom gradient-descent implementation to scipy.minimize(method=powell)

Using the powell method I can directly optimize a matrix of parameters (although looks like that's not intended scipy/scipy#8262), but I think we can give it a shot.

Handing negative pixels

Any pixel that might have a negative value is a pixel that by definition is not receiving any flux from the star, so perhaps it shouldn't contribute to our models at all. I propose we consider NaNning these pixels.

Optimal stepsize for gradient descent

GD is slow (as currently implemented)

Are numerical derivatives correct?

@mirca please check my math here. Since we're multiplying the terms together now they were definitely wrong as written previously! I'm still not convinced they're right.

Investigate how litigious Ferrero is

Let's make sure we don't get sued for the name of this code. (A cease and desist is okay---perhaps encouraged)

Movement isn't quite right

In a simulated test with a simple PSF and no noise and no motion, it works perfectly and we get the ideal PSF back.

As soon as we build in even simple motion, everything goes to hell. Why? Positions are not inferred correctly, need to explore to see what's going on (did we miss a minus sign somewhere?)

better interpolation

I'm using a PSF which is a simple square of height one in the central 9 pixels, and motion that carries this only directly up and down. The norm_super_tpf must have sharp vertical edges in this case, as the columns outside the central 3 never receive any flux.

This is what we're getting with RectBivariateSpline which clearly is an issue.

likelihood function

What are our errors anyway, really? Perhaps a Poisson likelihood function is relevant. Does that ruin everything in some subtle way?