Skip to content

Transiting planet

João Faria edited this page May 23, 2019 · 12 revisions

EXPERIMENTAL !!

We are sometimes faced with the situation where one planet is detected by its photometric transit and we are interested in doing RV follow-up to (i) confirm it, (ii) measure its mass, and (iii) detect additional planets in the system.

kima can now help with the analysis of the RV data in these cases.

By default, the Keplerian model we use assumes the same priors for the orbital parameters of all the planets in the system. But when doing RV follow-up, there is extra information about one of the planets: its orbital period, and some phase in the orbit, usually the time of mid-transit. We can use this information to set tighter priors for one specific planet.

Notes

  • currently, only one known transiting planet can be considered
    (this limitation is fairly easy to address if needed)
  • this feature is available only in the bgplanet branch, it is not backward-compatible, and will not be added to the master branch for now
  • setting the number of planets free will now mean something different!

Analysis of HARPS observations of GJ1132

GJ1132 is a nearby red dwarf known to host a transiting Earth-size planet (Berta-Thompson et al. 2015). An intense follow-up campaign with HARPS recently revealed the presence of at least one more planet in the system, a super-Earth with period P~8 days (Bonfils et al. 2018).

Let's use kima to analyse the set of RVs from this last paper.

First, checkout the bgplanet branch (after changing to the kima directory)

[cd kima]
git fetch 
git checkout bgplanet

after which git should tell you it switched to a new branch.
[note: bgplanet stands for background planet]

Clean up everything and recompile

make clean
make

A new example, called bgplanet, should now be compiled.
Go to the examples/bgplanet directory.

Here you will find a file called GJ1132_harps.txt, which contains the RV observations (same data as in Table 3 from Bonfils et al. 2018). First column is time in days, second column is RV in km/s, and third column is RV uncertainty also in km/s. We won't use the remaining columns.

Given this file, in kima_setup.cpp we'll have to write

char* datafile = "GJ1132_harps.txt";
Data::get_instance().load(datafile, "kms", 0);

Let's see what else kima_setup.cpp should contain.
Most of it is default code from kima, with a few extra stuff to enable the bgplanet mode. These are, basically, a boolean flag

const bool bgplanet = true;

and the definition of the priors

Gaussian *bgplanet_Pprior = new Gaussian(1.628930, 3.1e-5);
Uniform *bgplanet_Kprior = new Uniform(1.0, 20.0);
Uniform *bgplanet_eprior = new Uniform(0., 1.);
Gaussian *bgplanet_Tcprior = new Gaussian(57184.55786, 0.00032);
Uniform *bgplanet_wprior = new Uniform(0.0, 2*M_PI);

Like for any other Keplerian signal, there are five priors for the parameters of transiting planet but here we define the time of mid-transit (Tc) instead of the orbital phase (phi). This is the case only for the transiting planet.

The two Gaussian priors come directly from the constraints on the orbital period and time of mid-transit obtained from the photometric fit (see Table 1 of Berta-Thompson et al. 2015).

The rest of the code in kima_setup.cpp is quite standard. Noteworthy are the options to the model, where we will consider that the number of planets is free, with a uniform prior between 0 and 4

RVmodel::RVmodel():fix(false),npmax(4)

the priors for the GP hyperparameters,

/* GP parameters */
Uniform *log_eta1_prior = new Uniform(-5, 5);
Uniform *log_eta2_prior = new Uniform(0, 8);
Uniform *eta3_prior = new Uniform(100., 140.);
Uniform *log_eta4_prior = new Uniform(-2, 2);

TO DO: finish tutorial!