Let's first make sure we have the latest version of PHOEBE 2.0 installed. (You can comment out this line if you don't use pip for your installation or don't want to update to the latest release).
In [ ]:
!pip install -I "phoebe>=2.0,<2.1"
As always, let's do imports and initialize a logger and a new Bundle. See Building a System for more details.
In [1]:
import phoebe
from phoebe import u # units
import numpy as np
import matplotlib.pyplot as plt
logger = phoebe.logger()
b = phoebe.default_binary()
Constraints live in their own context of the Bundle, and many are created by default - either when you add a component or when you set the system hierarchy.
Let's look at all the existing constraints for our binary system.
In [2]:
b.filter(context='constraint')
Out[2]:
To see what all of these constraints do, see the 'Built-in Constraints' section below.
For now let's look at a single constraint.
In [3]:
b['constraint']['primary']['mass']
Out[3]:
Here we see the equation used to derive the mass of the primary star from its orbit, as well as the current value
If we access the Parameter that it is constraining we can see that it is automatically kept up-to-date.
In [4]:
print b.get_value('mass@primary@component')
The parameter is aware that it's being constrained and all the relevant linking parameters.
In [5]:
print b['mass@primary@component']
If you change the hierarchy, built-in cross-object constraints (like mass that depends on its parent orbit), will be adjusted to reflect the new hierarchy. See the 'Changing Hierarchies' section below for more details.
In [6]:
b['asini@constraint']
Out[6]:
In [7]:
b['esinw@constraint']
Out[7]:
In [8]:
b['ecosw@constraint']
Out[8]:
This constraint handles converting between different t0 conventions - namely providing a reference time at periastron passage (t0_perpass) and at superior conjunction (t0_supconj).
Currently, this constraint only supports inverting to be solved for 't0_supconj' (ie you cannot automatically invert this constraint to constraint phshift or per0).
In [9]:
b['t0_perpass@constraint']
Out[9]:
In [10]:
b['freq@constraint']
Out[10]:
In [11]:
b['freq@binary@constraint']
Out[11]:
In [12]:
b['freq@primary@constraint']
Out[12]:
In [13]:
b['mass@constraint']
Out[13]:
In [14]:
b['mass@primary@constraint']
Out[14]:
In [15]:
b['sma@constraint']
Out[15]:
In [16]:
b['sma@primary@constraint']
Out[16]:
In [17]:
b['pot@constraint']
Out[17]:
In [18]:
b['pot@primary@constraint']
Out[18]:
In [19]:
b['period@constraint']
Out[19]:
In [20]:
b['period@primary@constraint']
Out[20]:
This constraint handles requiring the inclination of a star to be the same as that of the parent orbit. With the constraint enabled, the binary is required to be "aligned". Disabling this constraint (which currently is not yet supported) will allow for misaligned binaries.
This constraint can be inverted to solve for either 'incl'.
In [21]:
b['incl@constraint']
Out[21]:
In [22]:
b['incl@primary@constraint']
Out[22]:
NOTE: this is an experimental feature. When re-parameterizing, please be careful and make sure all results and parameters make sense.
As we've just seen, the mass is a constrained (ie derived) parameter. But let's say that you would rather provide masses for some reason (perhaps that was what was provided in a paper). You can choose to provide mass and instead have one of its related parameters constrained
In [23]:
print b['mass@primary@component'].constrained_by
In [24]:
print b['value@mass@primary@component'], b['value@mass@secondary@component'], b['value@period@orbit@component']
In [25]:
b.flip_constraint('mass@primary', 'period')
Out[25]:
In [26]:
b['mass@primary@component'] = 1.0
In [27]:
print b['value@mass@primary@component'], b['value@mass@secondary@component'], b['value@period@orbit@component']
You'll see that when we set the primary mass, the secondary mass has also changed (because the masses are related through q) and the period has changed (based on resolving the Kepler's third law constraint).
Note that the tags for the constraint are based on those of the constrained parameter, so to switch the parameterization back, we'll have to use a slightly different twig.
In [28]:
print b['constraint']
In [29]:
b['period@constraint@binary']
Out[29]:
In [30]:
b['period@constraint@binary'].meta
Out[30]:
Notice that the qualifier tag has changed from 'mass' to 'period' and the 'component' tag has changed from 'primary' to 'binary' (since sma is in the binary).
In [31]:
b.flip_constraint('period@binary', 'mass')
Out[31]:
NOTE: this is an experimental feature. Just as when re-parameterizing, please be careful and make sure all results and parameters make sense.
Some of the built-in constraints depend on the system hierarchy, and will automatically adjust to reflect changes to the hierarchy.
For example, the masses depend on the period and semi-major axis of the parent orbit but also depend on the mass-ratio (q) which is defined as the primary mass over secondary mass. For this reason, changing the roles of the primary and secondary components should be reflected in the masses (so long as q remains fixed).
In order to show this example, let's set the mass-ratio to be non-unity.
In [32]:
b.set_value('q', 0.8)
Here the star with component tag 'primary' is actually the primary component in the hierarchy, so should have the LARGER mass (for a q < 1.0).
In [33]:
print "M1: {}, M2: {}".format(b.get_value('mass@primary@component'),
b.get_value('mass@secondary@component'))
Now let's flip the hierarchy so that the star with the 'primary' component tag is actually the secondary component in the system (and so takes the role of numerator in q = M2/M1).
For more information on the syntax for setting hierarchies, see the Building a System Tutorial.
In [34]:
b.set_hierarchy('orbit:binary(star:secondary, star:primary)')
In [35]:
print b.get_value('q')
In [36]:
print "M1: {}, M2: {}".format(b.get_value('mass@primary@component'),
b.get_value('mass@secondary@component'))
Even though under-the-hood the constraints are being rebuilt from scratch, they will remember if you have flipped them to solve for some other parameter.
To show this, let's flip the constraint for the secondary mass to solve for 'period' and then change the hierarchy back to its original value.
In [37]:
print "M1: {}, M2: {}, period: {}, q: {}".format(b.get_value('mass@primary@component'),
b.get_value('mass@secondary@component'),
b.get_value('period@binary@component'),
b.get_value('q@binary@component'))
In [38]:
b.flip_constraint('mass@secondary@constraint', 'period')
Out[38]:
In [39]:
print "M1: {}, M2: {}, period: {}, q: {}".format(b.get_value('mass@primary@component'),
b.get_value('mass@secondary@component'),
b.get_value('period@binary@component'),
b.get_value('q@binary@component'))
In [40]:
b.set_value('mass@secondary@component', 1.0)
In [41]:
print "M1: {}, M2: {}, period: {}, q: {}".format(b.get_value('mass@primary@component'),
b.get_value('mass@secondary@component'),
b.get_value('period@binary@component'),
b.get_value('q@binary@component'))
Next up: let's add a dataset to our Bundle.
In [ ]: