jorgemarpa/psfmachine

Tool kit for doing PSF photometry

• 👋 Hi, I’m @jorgemarpa
• 👀 I’m interested in ...
• 🌱 I’m currently learning ...
• 💞️ I’m looking to collaborate on ...
• 📫 How to reach me ...

psfmachine's Issues

Saturated pixels often have a "halo" around them, which will break our method.

Saturated stars cause a halo of light, and any stars that are inside this halo shouldn't be analyzed with this method.

We could do an investigation into how to build the halo shape of a saturated star, in order to remove it.

A good first approach might be to take the FFIs, identify the saturated stars, and come up with a data-driven approach to choose which pixels to remove/discount because they are in a halo.

We need a diagnostic for the `source_mask` and `uncontaminated_source_mask`

We need a diagnostic for the source_mask and uncontaminated_source_mask, so that we can see if they are performing well. We need something like a quick panel of figures to show what these masks are cutting out, some simple graphs will be perfect.

Model iteration should be in the `build_model` stage

At the moment there is a build_model and fit_model step. This is great. When we run fit_model, it is actually iterating. This is not what we want, we want a first step to build the model, which iterates to remove significant outliers, and then a second step which fits that model.

`build_machine` should accept a user specified mask on which TPFs to train on

At the moment, build_machine selects which TPFs/sources to run on itself. It would be very useful to allow the user to specify their own mask, which would select which TPFs to build the model on. By doing this, we could pass in additional TPFs that we might want to train on. This would augment the masks that go on under the hood.

Possible use case:
We should pass in two copies of the same (uncontaminated) TPF, one original copy, and one copy where e.g. half the pixels have been removed (a test copy). We should train only on original copies, and then apply the model to both the copies. By comparing the resultant light curves, we'll be able to see how good our method is at returning the true flux.

We need a way to see each TPF, and diagnose what the light curves look like.

Something like this:

Default phi spacing is too narrow in `_make_A_wcs`

The default knot spacing in _make_A_wcs is too narrow to capture the fine detail of the PSF. Here's a model with the current spacing:

It looks like it's not capturing the fine detail, the knots are too widely separated. Increasing the knots to 10 seems like a good fix:

Gaia query does not return all targets

I'm testing out psfmachine, and have come across the following issue. It looks like Gaia is not identifying all the targets in TPFs. This is a test of the 100 TPFs around K2-18.

You can see lots of TPFs aren't highlighted. I set a pretty tolerant magnitude limit (down to 20th magnitude) and they still aren't being found. This -could- be a bandpass problem, but I'm not sure. It seems like we might have to rely on both Gaia (for source positions and source identification) and the original mission input catalogs (for additional source identification) . This creates a bit of a nasty crossmatch problem.

psfmachine does not currently produce a good model fit.

I've been testing PSF machine on some K2 data. It seems like there is a problem with the model fit. I am using 100 TPFs, and psfmachine gives the following fit:

This is not a good fit to the data. It does this whether I use bin=True or bin=False.

I run the following to get this result:

tpfs = lk.search_targetpixelfile('K2-18', cadence='long', campaign=1, limit=100, radius=3*u.deg).download_all()
tpfs = lk.TargetPixelFileCollection([tpf for tpf in tpfs if tpf.hdu[0].header['kepmag'] > 10])
a = psm.Machine.from_TPFs(tpfs, magnitude_limit=20)
a.build_model()
a.fit_model()

There's definitely something funny going on!

Testing issues

psfmachine/psfmachine/machine.py

Line 3 in de48072

# help functions

Add a better description of this python file