Fake companions and reference frame choices

[rmjc]

Hi all,

I'm working with the contrast curve code with the new annular RDI mode. It looks like when the throughput function injects fake companions, the choice of the RDI reference frames are affected relative to the no fake companion case. Is this correct?

It seems that the throughput should use the same reference frames as the no fake companion case.

[oabsil]

Hi Becky,

This is a tough question. I guess you're refering to the fact that the
reference frames are selected based on maximum correlation with the
science frame? If it's the case, then I think it's a healthy behaviour
of VIP. Indeed, if there was a companion in the cube with the
characteristics of the injected fake companion, it would indeed affect
the selection of the RDI reference frames in the PCA processing. If we
want to properly assess the throughput of the RDI-PCA algorithm in
presence of companions with various fluxes and positions, I think we
need to let the possibility for the RDI reference frames to change as a
function of the injected fake companion.

Note that this reasoning would probably not hold any more if we were
injecting several fake companions at a time, unless all the companions
are treated in separate regions during the RDI-PCA processing (because
the other injected companions could also change the choice of the
reference frames). Am I right that in the current version of VIP, only
one companion is injected at a time?

Let me know if this answers your question, or if I've missed your point...

Cheers,
Olivier.

Le 16/02/16 19:47, Rebecca Jensen-Clem a écrit :

Hi all,

I'm working with the contrast curve code with the new annular RDI
mode. It looks like when the throughput function injects fake
companions, the choice of the RDI reference frames are affected
relative to the no fake companion case. Is this correct?

It seems that the throughput should use the same reference frames as
the no fake companion case.

—
Reply to this email directly or view it on GitHub
#33.

---

Dr. Olivier ABSIL
F.R.S.-FNRS Research Associate
Dept. of Astrophysics, Geophysics and Oceanography
Université de Liège (ULg), bât. B5c
17 allée du Six Août Tel: +32-(0)4-366.97.24
B-4000 Sart-Tilman Fax: +32-(0)4-366.97.46

Email: absil (at) astro.ulg.ac.be

[dmawet]

Hi Olivier,

Yes to your response but this is not the point (Becky correct me if I am
wrong). When injecting FC for throughput calibration VIP goes through the
selection of new reference stars, rather than keeping the same ones as for
the first step without FC.

Dimitri

On Wednesday, February 17, 2016, Olivier Absil notifications@github.com
wrote:

Hi Becky,

This is a tough question. I guess you're refering to the fact that the
reference frames are selected based on maximum correlation with the
science frame? If it's the case, then I think it's a healthy behaviour
of VIP. Indeed, if there was a companion in the cube with the
characteristics of the injected fake companion, it would indeed affect
the selection of the RDI reference frames in the PCA processing. If we
want to properly assess the throughput of the RDI-PCA algorithm in
presence of companions with various fluxes and positions, I think we
need to let the possibility for the RDI reference frames to change as a
function of the injected fake companion.

Note that this reasoning would probably not hold any more if we were
injecting several fake companions at a time, unless all the companions
are treated in separate regions during the RDI-PCA processing (because
the other injected companions could also change the choice of the
reference frames). Am I right that in the current version of VIP, only
one companion is injected at a time?

Let me know if this answers your question, or if I've missed your point...

Cheers,
Olivier.

Le 16/02/16 19:47, Rebecca Jensen-Clem a écrit :

Hi all,

I'm working with the contrast curve code with the new annular RDI
mode. It looks like when the throughput function injects fake
companions, the choice of the RDI reference frames are affected
relative to the no fake companion case. Is this correct?

It seems that the throughput should use the same reference frames as
the no fake companion case.

—
Reply to this email directly or view it on GitHub
#33.

---

Dr. Olivier ABSIL
F.R.S.-FNRS Research Associate
Dept. of Astrophysics, Geophysics and Oceanography
Université de Liège (ULg), bât. B5c
17 allée du Six Août Tel: +32-(0)4-366.97.24
B-4000 Sart-Tilman Fax: +32-(0)4-366.97.46

Email: absil (at) astro.ulg.ac.be

—
Reply to this email directly or view it on GitHub
#33 (comment)
.

Dimitri Mawet
Associate Professor of Astronomy
JPL Senior Research Scientist

Astronomy Dept. MC 249-17
Caltech, 1200 E. California Blvd.
Pasadena, CA 91125
Tel: 626-395-1452
E-mail: dmawet@astro.caltech.edu

[rmjc]

Hi Olivier and Dimitri,

The contrast is ((sigma * noise_samp_sm)/thruput_interp_sm)/starphot, where noise_samp_sm is the interpolated noise from the science frame with no fake companion. My understanding is that the purpose of dividing by the throughput is simply to convert (sigma * noise_samp_sm) into the units of "companion's signal", given that a companion's signal is attenuated by the PCA that we applied in order to get our noise_samp_sm.

When the throughput corresponds to a different set of reference frames (and perhaps a different number of principal components applied), than what we used to get noise_samp_sm, than this conversion doesn't quite make sense to me.

[carlos-gg]

Hi all,

The point of pca_rdi_annular is keeping the best correlated frames (annular patches) so indeed the frames and even the number of frames in the reference library might change. Becky, It makes sense what you say, and the ideal way to compute the noise and to get the attenuation caused by PCA is by keeping the same parameters of the post-processing. But by leaving all the frames (or same set of frames) with annular PCA RDI we might be reducing the improvement we obtain wrt the full-frame PCA RDI version and even full-frame PCA ADI (this needs more testing).

If you still want to keep the same library each time then a simple workaround is to set the min_corr parameter to 0 (it uses all of them). Another way is just using the full-frame PCA with a set of reference frames (cube_ref). Then the library will be the same no matter how many companions were injected in the cube, because there is no correlation-based rejection. Also set a number of PCs for PCA so this parameter stays constant.

Olivier, the companions are not injected one at a time, but in non-overlaping radial patterns to sample the throughput each FWHM.

One thing that occurs to me, is to include a parameter percent_reject (or something like that) which overrides the min_corr and just defines a percentage of least correlated frames (patches) to be removed from the library to keep it at least of the same size between runs.

Cheers,
Carlos