Include common objects#

The physical objects of your system must be included in the common section. The name of the section derives from the fact each specific model required to model a given dataset will rely on physical parameters of planets and star (and more…) that are shared with all the other models eventually employed. For example, a simultaneous fit of a radial velocity curve and a transit light curve will be characterized by a single period for the planet of interest.

Let’s look at this example where we have included a transiting planet in a circular orbit (b), a non-transiting planet (c), some properties for the stellar activity, and of course the stellar parameters.

 1common:
 2  planets:
 3    b:
 4      orbit: circular
 5      use_time_inferior_conjunction: True
 6      boundaries:
 7        P: [0.25, 0.31]
 8        K: [0.01, 100.0]
 9        Tc: [7744.06, 7744.08]
10      priors:
11        P: ['Gaussian', 0.2803244, 0.0000015]
12        Tc: ['Gaussian', 7744.07160, 0.00022]
13      spaces:
14        P: Linear
15      fixed:
16        i: [86.3, 3.00]
17    c:
18      orbit: keplerian
19      boundaries:
20        P: [1.0, 1000.0]
21        K: [0.01, 100.0]
22        e: [0.00, 0.95]
23  stellar_activity:
24    kind: activity
25    boundaries:
26      Prot: [5.00, 16.00]
27      Pdec: [10.0, 2000.00]
28      Oamp: [0.01, 0.60]
29    priors:
30      Prot: ['Gaussian',13.941613, 0.66]
31      Pdec: ['Gaussian',12.203273, 3.21]
32      Oamp: ['Gaussian',0.342221, 0.054]
33  star:
34    star_parameters:
35      priors:
36        radius: ['Gaussian', 0.681, 0.018]
37        mass: ['Gaussian', 0.708, 0.028]
38        density: ['Gaussian', 2.244, 0.161]

Quite a lot to process, right? Let’s start with the main sections. planets and star are kind of special because the section names are also the reference name of the objects, i.e., these names are hard-coded and if you try to put planet or star parameters in sections with different names you will break everything. The reason is that planets and star are actually containers for the true objects, which are b, c (see the relative documentation for more details). stellar_activity instead is a label for the object with reference names activity, e.g., if you want to know more you have to look for the object named activity in the documentation and for the file activity.py in the source code. Note that if you are including just a single object of a kind, you can use its reference name as a label and omit the type keyword, as in the actual example file in the repository.

.. code-block:: yaml :linenos:

common: … activity: boundaries: Prot: [5.00, 16.00] Pdec: [10.0, 2000.00] Oamp: [0.01, 0.60] priors: Prot: [‘Gaussian’,13.941613, 0.66] Pdec: [‘Gaussian’,12.203273, 3.21] Oamp: [‘Gaussian’,0.342221, 0.054]

Note that also b and c are labels, i.e., you can give the planets any random name, but in their case it’s not necessary to specify what kind of object they are because it’s implicitly assumed for being inside the planet section (Note: this is true only for the planets! ). The use of labels will be clear when dealing with multi-band photometry.

Let’s focus on planet b as an example of the properties of an object. There are some keywords that are specific of the planet model, such as orbit and parametrization. Check the documentation of each model to know more about the specific keywords. Then there are four sections that every model must possess:

  • boundaries: all the Bayesian samplers implemented in PyORBIT require the definition of lower and upper boundaries. If not specified, very broad boundaries will be set by default according to the source code.

  • priors: is it a Bayesian analysis if you don’t specify at least one prior? When not included, the prior is assumed to be Uniform over the range specified in boundaries (or the one assumed by default)

  • spaces: the choice here is between Linear and Logarithmic. Note that the logarithmic space is in base 2. Once again, the default choice is listed in the source code.

  • fixed: You listed here every parameter you want to keep fixed. The value must be accompanied by his errors, because in some cases it will be used in the computation of the derived parameters, e.g., the real mass of a transiting planet.

Under this section you need to list only the parameters that will be actually used by the models in models section. For example, a circular orbit does not require boundaries or priors for the eccentricity.

The default choices for each possible parameter and for each section listed above are declared in the source file of the object.