I am working on the file "2.3/tutorials/dpdt.ipynb".
The first task is:
We'll add several light curve, RV, and orbit datasets, each covering successive cycles of the orbit so that we can differentiate between them later when plotting.
Can you write Python code for it?

for i in range(3):
    b.add_dataset('lc', compute_phases=phoebe.linspace(i,i+1,101))
    b.add_dataset('rv', compute_phases=phoebe.linspace(i,i+1,101))
    b.add_dataset('orb', compute_phases=phoebe.linspace(i,i+1,101))


I am working on the file "2.3/tutorials/dpdt.ipynb".
The first task is:
Zero-point for orbital period
The orbital period itself, period, is defined at time t0 (in the system context). If the dataset times are far from t0@system then we begin to lose precision on the period parameter as a small change, coupled with the propagation of dpdt * (times - t0) can cause a large effect.  It is important to try to define the system at a time t0@system that are near the dataset times (and near the other various t0s).  By default, t0@system is set to 0 and we have set our dataset times to start at zero as well.
Can you write Python code for it?

print(b.filter('t0', context='system'))

print(b.get_parameter('t0', context='system').description)


I am working on the file "2.3/tutorials/ebv_Av_Rv.ipynb".
The first task is:
As always, let's do imports and initialize a logger and a new Bundle.
Can you write Python code for it?

import phoebe
from phoebe import u # units
import numpy as np
import matplotlib.pyplot as plt

logger = phoebe.logger()

b = phoebe.default_binary()


I am working on the file "2.3/tutorials/ebv_Av_Rv.ipynb".
The first task is:
NOTE extinction parameters were moved from the dataset to system context in the 2.3 release
Relevant Parameters
Extinction is parameterized by 3 parameters: ebv (E(B-V)), Av, and Rv.  Of these three, two can be provided and the other must be constrained.  By default, ebv is the constrained parameter.  To change this, see the tutorial on constraints and the b.flip_constraint API docs.
Can you write Python code for it?

print(b.filter(qualifier='ebv'))

print(b.get_parameter(qualifier='ebv', context='system'))

print(b.get_parameter(qualifier='ebv', context='constraint'))

print(b.get_parameter(qualifier='Av'))

print(b.get_parameter(qualifier='Rv'))


I am working on the file "2.3/tutorials/ecc.ipynb".
The first task is:
As always, let's do imports and initialize a logger and a new Bundle.
Can you write Python code for it?


I am working on the file "2.3/tutorials/ecc.ipynb".
The first task is:
Influence on Radial Velocities
Can you write Python code for it?

b.add_dataset('rv', times=np.linspace(0,1,51))

b.run_compute()

afig, mplfig = b['rv@model'].plot(show=True)

b.remove_dataset('rv01')


I am working on the file "2.3/tutorials/ecc.ipynb".
The first task is:
Relevant Constraints
Can you write Python code for it?

print(b.get_parameter(qualifier='ecosw', context='constraint'))

print(b.get_parameter(qualifier='esinw', context='constraint'))


I am working on the file "2.3/tutorials/ecc.ipynb".
The first task is:
Relevant Parameters
Can you write Python code for it?

print(b.get_parameter(qualifier='ecc'))

print(b.get_parameter(qualifier='ecosw', context='component'))

print(b.get_parameter(qualifier='esinw', context='component'))


I am working on the file "2.3/tutorials/eclipse.ipynb".
The first task is:
As always, let's do imports and initialize a logger and a new Bundle.
Can you write Python code for it?

import phoebe
from phoebe import u # units
import numpy as np
import matplotlib.pyplot as plt

phoebe.devel_on() # DEVELOPER MODE REQUIRED FOR VISIBLE_PARTIAL - DON'T USE FOR SCIENCE

logger = phoebe.logger()

b = phoebe.default_binary()


I am working on the file "2.3/tutorials/eclipse.ipynb".
The first task is:
Let's just compute the mesh at a single time-point that we know should be during egress.
Can you write Python code for it?


I am working on the file "2.3/tutorials/eclipse.ipynb".
The first task is:
Native
The 'native' eclipse method computes what percentage (by area) of each triangle is visible at the current time.  It also determines the centroid of the visible portion of each triangle.
Physical quantities (temperatures, intensities, velocities, etc) are computed at the vertices of each triangle, and this centroid is then used to determine the average quantity across the visible portion of the triangle (by assuming a linear gradient across the triangle).
Let's plot the visibilities (ratio of the area that is visible) as the color scale, with red being completely hidden and green being completely visible.
Can you write Python code for it?

b.run_compute(eclipse_method='native')

afig, mplfig = b.plot(component='primary', fc='visibilities', xlim=(-0.5, 0.25), ylim=(-0.4, 0.4), show=True)


I am working on the file "2.3/tutorials/eclipse.ipynb".
The first task is:
Visible Partial
The 'visible partial' eclipse method simply determines which triangles are hidden, which are visible, and which are partially visible.  It then assigns a visibility of 0.5 to any partially visible triangles - meaning they will contribute half of their intensities when integrated (assume that half of the area is visible).  There are no longer any centroids - values are still computed at the vertices but are then averaged to be at the geometric center of EACH triangle.
Again, let's plot the visibilities (ratio of the area that is visible) as the color scale, with red being completely hidden and green being completely visible.
Can you write Python code for it?

b.run_compute(eclipse_method='visible_partial')

afig, mplfig = b.plot(component='primary', fc='visibilities', xlim=(-0.5, 0.25), ylim=(-0.4, 0.4), show=True)


I am working on the file "2.3/tutorials/emcee_continue_from.ipynb".
The first task is:
Note that niters now defines the number of additional iterations.
Can you write Python code for it?

b.set_value(qualifier='niters', solver='emcee_solver', context='solver', value=50)


I am working on the file "2.3/tutorials/emcee_continue_from.ipynb".
The first task is:
We'll then start with the bundle from the end of the emcee tutorial.  If you're running this notebook locally, you will need to run that first to create the emcee_advanced_tutorials.bundle file that we will use here.
Can you write Python code for it?


I am working on the file "2.3/tutorials/emcee_continue_from.ipynb".
The first task is:
continue_from parameter
Once we have an existing solution(s) in the bundle that used emcee, the continue_from parameter (in the emcee solver) will have those available as valid options.
Can you write Python code for it?

print(b.solvers, b.solutions)

print(b.filter(solver='emcee_solver', context='solver'))

print(b.get_parameter(qualifier='continue_from', solver='emcee_solver'))


I am working on the file "2.3/tutorials/emcee_continue_from.ipynb".
The first task is:
run_solver
Can you write Python code for it?


I am working on the file "2.3/tutorials/emcee_custom_lnprob.ipynb".
The first task is:
Defining the custom cost function
As is described in the b.run_solver API docs, a custom function can be passed which overrides the internal default cost function.  This function must accept b, model, lnpriors, priors, priors_combine as arguments and return the lnprobability (cost function).  The arguments are as follows:
* b: the bundle with the current face-values for this forward model
* model: the name of the forward model in b
* lnpriors: the pre-computed value of the log-priors by passing priors and priors_combine to b.calculate_lnp
* priors: the name(s) of the prior distributions
* priors_combine: the choice for how to combine priors if priors includes more than one distribution for any single parameter.
If a custom function is not passed, the default cost function is the sum of the lnlikelihood (from b.calculate_lnlikelihood) and the probability of drawing the current face-values from the passed priors.
Let's reproduce this default case for the sake of this example.  We'll include a print statement just for confirmation that our function is being called.  In practice, you could do any modifications here with access to parameter values, distributions, synthetic models, and observations.
Can you write Python code for it?

def default_lnprob(b, model, lnpriors, priors, priors_combine):
    print("* calling default_lnprob")
    return lnpriors + b.calculate_lnlikelihood(model=model)


I am working on the file "2.3/tutorials/emcee_custom_lnprob.ipynb".
The first task is:
We'll then start with the bundle from the end of the emcee tutorial.  If you're running this notebook locally, you will need to run that first to create the emcee_advanced_tutorials.bundle file that we will use here.
Can you write Python code for it?


I am working on the file "2.3/tutorials/features.ipynb".
The first task is:
Adding a Feature
If we look at the API docs for a spot, we can see that it can be attached to any star component, but not attached to a dataset.  So when calling b.add_feature, we need to send a valid tag for component that points to a star (i.e. 'primary' or 'secondary')
Can you write Python code for it?

b.add_feature('spot', component='primary', feature='spot01')

b.get_feature('spot01')


I am working on the file "2.3/tutorials/fti.ipynb".
The first task is:
As always, let's do imports and initialize a logger and a new bundle.
Can you write Python code for it?

import phoebe
from phoebe import u # units
import numpy as np
import matplotlib.pyplot as plt

logger = phoebe.logger()

b = phoebe.default_binary()

b.add_dataset('lc', times=np.linspace(0,1,101), dataset='lc01')


I am working on the file "2.3/tutorials/fti.ipynb".
The first task is:
Influence on Light Curves
Can you write Python code for it?

b.run_compute(fti_method='none', irrad_method='none', model='fti_off')

b.run_compute(fti_method='oversample', irrad_method='none', model='fit_on')


I am working on the file "2.3/tutorials/fti.ipynb".
The first task is:
Once we set fti_method to be 'oversample', the corresponding 'fti_oversample' parameter(s) become visible.  This option defines how many different time-points PHOEBE should sample over the width of the exposure time and then average to return a single flux point.  By default this is set to 5.
Note that increasing this number will result in better accuracy of the convolution caused by the exposure time - but increases the computation time essentially linearly.  By setting to 5, our computation time will already be almost 5 times that when fti is disabled.
Can you write Python code for it?


I am working on the file "2.3/tutorials/fti.ipynb".
The first task is:
Relevant Parameters
An 'exptime' parameter exists for each lc dataset and is set to 0.0 by default.  This defines the exposure time that should be used when fti is enabled.  As stated in its description, the time stamp of each datapoint is defined to be the time of mid-exposure.  Note that the exptime applies to all times in the dataset - if times have different exposure-times, then they must be split into separate datasets manually.
Can you write Python code for it?


I am working on the file "2.3/tutorials/fti.ipynb".
The first task is:
The phase-smearing (convolution) caused by the exposure time is most evident in areas of the light curve with sharp derivatives, where the flux changes significantly over the course of the single exposure.  Here we can see that the 1-hr exposure time significantly changes the observed shapes of ingress and egress as well as the observed depth of the eclipse.
Can you write Python code for it?

afig, mplfig = b.plot(show=True, legend=True)


I am working on the file "2.3/tutorials/general_concepts.ipynb".
The first task is:
All of these arguments are optional and will default to clevel='WARNING' if not provided.  There is therefore no need to provide a filename if you don't provide a value for flevel.
So with this logger, anything with INFO, WARNING, ERROR, or CRITICAL levels will be printed to the screen.  All messages of any level will be written to a file named 'tutorial.log' in the current directory.
Note: the logger messages are not included in the outputs shown below.
Overview
As a quick overview of what's to come, here is a quick preview of some of the steps used when modeling a binary system with PHOEBE.  Each of these steps will be explained in more detail throughout these tutorials.
First we need to create our binary system.  For the sake of most of these tutorials, we'll use the default detached binary available through the phoebe.default_binary constructor.
Can you write Python code for it?


I am working on the file "2.3/tutorials/general_concepts.ipynb".
The first task is:
Although there is no strict hierarchy or order to the tags, it can be helpful to think of the context tag as the top-level tag and is often very helpful to filter by the appropriate context first.
Other tags currently include:
* kind
* figure
* component
* feature
* dataset
* distribution
* compute
* model
* solver
* solution
* time
* qualifier
Accessing the plural form of the tag as an attribute also works on a filtered ParameterSet
Can you write Python code for it?


I am working on the file "2.3/tutorials/general_concepts.ipynb".
The first task is:
And then lastly, if we wanted to solve the inverse problem and "fit" parameters to observational data, we may want to add distributions to our system so that we can run estimators, optimizers, or samplers.
Default Binary Bundle
For this tutorial, let's start over and discuss this b object in more detail and how to access and change the values of the input parameters.
Everything for our system will be stored in this single Python object that we call the Bundle which we'll call b (short for bundle).
Can you write Python code for it?


I am working on the file "2.3/tutorials/general_concepts.ipynb".
The first task is:
As a shortcut, get_parameter also takes filtering keywords.  So the above line is also equivalent to the following:
Can you write Python code for it?


I am working on the file "2.3/tutorials/general_concepts.ipynb".
The first task is:
As with the tags, you can call .twigs on any ParameterSet to see the "smallest unique twigs" of the contained Parameters
Can you write Python code for it?


I am working on the file "2.3/tutorials/general_concepts.ipynb".
The first task is:
Each Parameter object contains several keys that provide information about that Parameter.  The keys "description" and "value" are always included, with additional keys available depending on the type of Parameter.
Can you write Python code for it?

b.get_parameter(context='compute', component='primary', qualifier='ntriangles').get_value()

b.get_parameter(context='compute', component='primary', qualifier='ntriangles').get_description()


I am working on the file "2.3/tutorials/general_concepts.ipynb".
The first task is:
Here we filtered on the context tag for all Parameters with context='compute' (i.e. the options for computing a model).  If we want to see all the available options for this tag in the Bundle, we can use the plural form of the tag as a property on the Bundle or any ParameterSet.
Can you write Python code for it?


I am working on the file "2.3/tutorials/general_concepts.ipynb".
The first task is:
However, this dictionary-style twig access will never return a ParameterSet with a single Parameter, instead it will return the Parameter itself.  This can be seen in the different output between the following two lines:
Can you write Python code for it?

b.filter(context='compute', component='primary', qualifier='distortion_method')

b['distortion_method@primary@compute']


I am working on the file "2.3/tutorials/general_concepts.ipynb".
The first task is:
If we want to view or edit a Parameter in the Bundle, we first need to know how to access it.  Each Parameter object has a number of tags which can be used to filter (similar to a database query).  When filtering the Bundle, a ParameterSet is returned - this is essentially just a subset of the Parameters in the Bundle and can be further filtered until eventually accessing a single Parameter.
Can you write Python code for it?


I am working on the file "2.3/tutorials/general_concepts.ipynb".
The first task is:
In this case, we're looking at the Parameter called ntriangles with the component tag set to 'primary'.  This Parameter therefore defines how many triangles should be created when creating the mesh for the star named 'primary'.  By default, this is set to 1500 triangles, with allowable values above 100.
If we wanted a finer mesh, we could change the value.
Can you write Python code for it?

b.get_parameter(context='compute', component='primary', qualifier='ntriangles').set_value(2000)

b.get_parameter(context='compute', component='primary', qualifier='ntriangles')


I am working on the file "2.3/tutorials/general_concepts.ipynb".
The first task is:
Let's get started with some basic imports:
Can you write Python code for it?

import phoebe
from phoebe import u # units


I am working on the file "2.3/tutorials/general_concepts.ipynb".
The first task is:
Next, we need to define our datasets via b.add_dataset.  This will be the topic of the following tutorial on datasets.
Can you write Python code for it?


I am working on the file "2.3/tutorials/general_concepts.ipynb".
The first task is:
Now that we know the options for the qualifier within this filter, we can choose to filter on one of those.  Let's look filter by the 'ntriangles' qualifier.
Can you write Python code for it?


I am working on the file "2.3/tutorials/general_concepts.ipynb".
The first task is:
Parameter types include:
* IntParameter
* FloatParameter
* FloatArrayParameter
* BoolParameter
* StringParameter
* ChoiceParameter
* SelectParameter
* DictParameter
* ConstraintParameter
* DistributionParameter
* HierarchyParameter
* UnitParameter
* JobParameter
these Parameter types and their available options are all described in great detail in Advanced: Parameter Types
Twigs
As a shortcut to needing to filter by all these tags, the Bundle and ParameterSets can be filtered through what we call "twigs" (as in a Bundle of twigs).  These are essentially a single string-representation of the tags, separated by @ symbols.
This is very useful as a shorthand when working in an interactive Python console, but somewhat obfuscates the names of the tags and can make it difficult if you use them in a script and make changes earlier in the script.
For example, the following lines give identical results:
Can you write Python code for it?

b.filter(context='compute', component='primary')

b['primary@compute']

b['compute@primary']


I am working on the file "2.3/tutorials/general_concepts.ipynb".
The first task is:
The qualifier tag is the shorthand name of the Parameter itself.  If you don't know what you're looking for, it is often useful to list all the qualifiers of the Bundle or a given ParameterSet.
Can you write Python code for it?


I am working on the file "2.3/tutorials/general_concepts.ipynb".
The first task is:
This then tells us what can be used to filter further.
Can you write Python code for it?


I am working on the file "2.3/tutorials/general_concepts.ipynb".
The first task is:
We can access the value of any parameter, including the arrays in the synthetic model just generated.  To export arrays to a file, we could call b.export_arrays
Can you write Python code for it?


I am working on the file "2.3/tutorials/general_concepts.ipynb".
The first task is:
We can then plot the resulting model with b.plot, which will be covered in the plotting tutorial.
Can you write Python code for it?


I am working on the file "2.3/tutorials/general_concepts.ipynb".
The first task is:
We'll then want to run our forward model to create a synthetic model of the observables defined by these datasets using b.run_compute, which will be the topic of the computing observables tutorial.
Can you write Python code for it?


I am working on the file "2.3/tutorials/grav_redshift.ipynb".
The first task is:
As always, let's do imports and initialize a logger and a new bundle.
Can you write Python code for it?

import phoebe
from phoebe import u # units
import numpy as np
import matplotlib.pyplot as plt

logger = phoebe.logger()

b = phoebe.default_binary()

b.add_dataset('rv', times=np.linspace(0,1,101), dataset='rv01')

b.set_value_all('ld_mode', 'manual')
b.set_value_all('ld_func', 'logarithmic')
b.set_value_all('ld_coeffs', [0.0, 0.0])
b.set_value_all('atm', 'blackbody')


I am working on the file "2.3/tutorials/grav_redshift.ipynb".
The first task is:
Besides the obvious change in the Rossiter-McLaughlin effect (not due to gravitational redshift), we can see that making the radii smaller shifts the entire RV curve up (the spectra are redshifted as they have to climb out of a steeper potential at the surface of the stars).
Can you write Python code for it?


I am working on the file "2.3/tutorials/grav_redshift.ipynb".
The first task is:
Influence on Radial Velocities
Can you write Python code for it?

afig, mplfig = b.filter(model=['defaultradii_true', 'smallradii_true']).plot(legend=True, show=True)

afig, mplfig = b.filter(model=['smallradii_true', 'smallradii_false']).plot(legend=True, show=True)


I am working on the file "2.3/tutorials/grav_redshift.ipynb".
The first task is:
Now let's run another model but with much smaller stars (but with the same masses).
Can you write Python code for it?

b['requiv@primary'] = 0.4
b['requiv@secondary'] = 0.4

b.run_compute(rv_method='flux-weighted', rv_grav=True, irrad_method='none', model='smallradii_true')


I am working on the file "2.3/tutorials/grav_redshift.ipynb".
The first task is:
Now let's run another model, but with gravitational redshift effects disabled
Can you write Python code for it?

b.run_compute(rv_method='flux-weighted', rv_grav=False, irrad_method='none', model='smallradii_false')


I am working on the file "2.3/tutorials/grav_redshift.ipynb".
The first task is:
Relevant Parameters
Gravitational redshifts are only accounted for flux-weighted RVs (dynamical RVs literally only return the z-component of the velocity of the center-of-mass of each star).
First let's run a model with the default radii for our stars.
Can you write Python code for it?


I am working on the file "2.3/tutorials/gravb_bol.ipynb".
The first task is:
If you have a logger enabled, PHOEBE will print a warning if the value of gravb_bol is outside the "suggested" ranges.  Note that this is strictly a warning, and will never turn into an error at b.run_compute().
You can also manually call b.run_checks().  The first returned item tells whether the system has passed checks: True means it has, False means it has failed, and None means the tests pass but with a warning.  The second argument tells the first warning/error message raised by the checks.
The checks use the following "suggested" values:
 * teff 8000+: gravb_bol >= 0.9 (suggest 1.0)
 * teff 6600-8000: gravb_bol 0.32-1.0
 * teff 6600-: grav_bol < 0.9 (suggest 0.32)
Can you write Python code for it?

print(b.run_checks())

b['teff@primary'] = 8500
b['gravb_bol@primary'] = 0.8
print(b.run_checks())

b['teff@primary'] = 7000
b['gravb_bol@primary'] = 0.2
print(b.run_checks())

b['teff@primary'] = 6000
b['gravb_bol@primary'] = 1.0
print(b.run_checks())


I am working on the file "2.3/tutorials/gravb_bol.ipynb".
The first task is:
Influence on Intensities
Can you write Python code for it?

b['teff@primary'] = 6000
b['gravb_bol@primary'] = 0.32

b.run_compute(model='gravb_bol_32')

afig, mplfig = b['primary@mesh01@gravb_bol_32'].plot(fc='intensities', ec='None', show=True)

b['gravb_bol@primary'] = 1.0

b.run_compute(model='gravb_bol_10')

afig, mplfig = b['primary@mesh01@gravb_bol_10'].plot(fc='intensities', ec='None', show=True)


I am working on the file "2.3/tutorials/gravb_bol.ipynb".
The first task is:
Relevant Parameters
The 'gravb_bol' parameter corresponds to the β coefficient for gravity darkening corrections.
Can you write Python code for it?


I am working on the file "2.3/tutorials/intens_weighting.ipynb".
The first task is:
As always, let's do imports and initialize a logger and a new Bundle.
Can you write Python code for it?

import phoebe
from phoebe import u # units
import numpy as np
import matplotlib.pyplot as plt

logger = phoebe.logger()

b = phoebe.default_binary()

b.add_dataset('lc', times=np.linspace(0,1,101))


I am working on the file "2.3/tutorials/intens_weighting.ipynb".
The first task is:
Influence on Light Curves (fluxes)
Let's (roughtly) reproduce Figure 5 from Prsa et al. 2016 which shows the difference between photon and energy intensity weighting.
<img src="prsa+2016_fig5.png" alt="Figure 8" width="600px"/>
Can you write Python code for it?

for teff_primary in [5000,7500,10000,12500,15000]:
    b['teff@primary'] = teff_primary
    b['teff@secondary'] = 0.9 * teff_primary

    for weighting in ['energy', 'photon']:
        b['intens_weighting'] = weighting
        b.run_compute(irrad_method='none', model='{}_{}'.format(teff_primary, weighting))

teff_colormap = {5000: 'm', 7500: 'r', 10000: 'g', 12500: 'c', 15000: 'b'}

fig = plt.figure()
ax1, ax2 = fig.add_subplot(211), fig.add_subplot(212)

for teff, color in teff_colormap.items():
    fluxes_energy = b.get_value('fluxes@{}_energy'.format(teff))
    fluxes_photon = b.get_value('fluxes@{}_photon'.format(teff))
    phases = b.to_phase('times@lc@dataset')

    # alias data from -0.6 to 0.6
    fluxes_energy = np.append(fluxes_energy, fluxes_energy[abs(phases) > 0.4])
    fluxes_photon = np.append(fluxes_photon, fluxes_photon[abs(phases) > 0.4])
    phases = np.append(phases, phases[abs(phases)>0.4]+1.0)
    phases[phases > 1.0] = phases[phases > 1.0] - 2.0

    sort = phases.argsort()
    phases = phases[sort]
    fluxes_energy = fluxes_energy[sort]
    fluxes_photon = fluxes_photon[sort]

    ax1.plot(phases, fluxes_energy, color=color)
    ax2.plot(phases, fluxes_photon-fluxes_energy, color=color)

lbl = ax1.set_xlabel('')
lbl = ax1.set_ylabel('flux')
lbl = ax2.set_xlabel('phase')
lbl = ax2.set_ylabel('flux diff')


I am working on the file "2.3/tutorials/irrad_method_horvat.ipynb".
The first task is:
As always, let's do imports and initialize a logger and a new bundle.
Can you write Python code for it?

import phoebe
from phoebe import u # units
import numpy as np
import matplotlib.pyplot as plt

logger = phoebe.logger('error')

b = phoebe.default_binary()


I am working on the file "2.3/tutorials/irrad_method_horvat.ipynb".
The first task is:
Now we'll compute the light curves with wilson and horvat irradiation, and plot the relative differences between the two as a function of phase, for several different values of the inclination.
Can you write Python code for it?

phases = phoebe.linspace(0,1,101)
b.add_dataset('lc', times=b.to_time(phases))

for incl in [0,30,60,90]:
    b.set_value('incl@binary', incl)
    b.run_compute(irrad_method='wilson')
    fluxes_wilson = b.get_value('fluxes', context='model')
    b.run_compute(irrad_method='horvat')
    fluxes_horvat = b.get_value('fluxes', context='model')
    plt.plot(phases, (fluxes_wilson-fluxes_horvat)/fluxes_wilson, label='i={}'.format(incl))

plt.xlabel('phase')
plt.ylabel('[F(wilson) - F(horvat)] / F(wilson)')
plt.legend(loc='upper center')
plt.show()


I am working on the file "2.3/tutorials/irrad_method_horvat.ipynb".
The first task is:
Relevant Parameters
For parameters that affect reflection and heating (irrad_frac_*) see the tutorial on reflection and heating.
The 'irrad_method' compute option dictates whether irradiation is handled according to the new Horvat scheme which includes Lambert Scattering, Wilson's original reflection scheme, or ignored entirely.
Can you write Python code for it?


I am working on the file "2.3/tutorials/l3.ipynb".
The first task is:
As expected, adding 5 W/m^3 of third light simply shifts the light curve up by that exact same amount.
Can you write Python code for it?

afig, mplfig = b['lc01'].plot(model='no_third_light')
afig, mplfig = b['lc01'].plot(model='with_third_light', legend=True, show=True)


I am working on the file "2.3/tutorials/l3.ipynb".
The first task is:
Influence on Meshes (Intensities)
"Third" light does not affect the intensities stored in the mesh (including those in relative units).  In other words, like distance, "third" light only scales the fluxes.
NOTE: this is different than pblums which DO affect the relative intensities.  Again, see the pblum tutorial for more details.
To see this we can run both of our models again and look at the values of the intensities in the mesh.
Can you write Python code for it?

b.add_dataset('mesh', times=[0], dataset='mesh01', columns=['intensities@lc01', 'abs_intensities@lc01'])

b.set_value('l3', 0.0)

b.run_compute(irrad_method='none', model='no_third_light', overwrite=True)

b.set_value('l3', 5)

b.run_compute(irrad_method='none', model='with_third_light', overwrite=True)

print("no_third_light abs_intensities: ", np.nanmean(b.get_value(qualifier='abs_intensities', component='primary', dataset='lc01', model='no_third_light')))
print("with_third_light abs_intensities: ", np.nanmean(b.get_value(qualifier='abs_intensities', component='primary', dataset='lc01', model='with_third_light')))

print("no_third_light intensities: ", np.nanmean(b.get_value(qualifier='intensities', component='primary', dataset='lc01', model='no_third_light')))
print("with_third_light intensities: ", np.nanmean(b.get_value(qualifier='intensities', component='primary', dataset='lc01', model='with_third_light')))


I am working on the file "2.3/tutorials/l3.ipynb".
The first task is:
Similarly to above, we can convert to actual flux units (under the same assumptions), by calling b.compute_l3s.
Note that calling compute_l3s is not necessary, as the backend will handle the conversion automatically.
Can you write Python code for it?


I am working on the file "2.3/tutorials/l3.ipynb".
The first task is:
So let's add a LC dataset
Can you write Python code for it?


I am working on the file "2.3/tutorials/l3.ipynb".
The first task is:
To compute the fractional third light from the provided value in flux units, call b.compute_l3s.  This assumes that the flux of the system is the sum of the extrinsic passband luminosities (see the pblum tutorial for more details on intrinsic vs extrinsic passband luminosities) divided by $4\pi$ at t0@system, and according to the compute options.
Note that calling compute_l3s is not necessary, as the backend will handle the conversion automatically.
Can you write Python code for it?


I am working on the file "2.3/tutorials/l3.ipynb".
The first task is:
l3_mode = 'flux'
When l3_mode is set to 'flux', the l3 parameter defines (in flux units) how much extraneous light is added to the light curve in that particular passband/dataset.
Can you write Python code for it?


I am working on the file "2.3/tutorials/latex_repr.ipynb".
The first task is:
Default Representation
By default, whenever parameters themselves are referenced in plotting (like when calling b.plot_distribution_collection, a latex representation of the parameter name, along with the component or dataset, when applicable, is used.
Can you write Python code for it?


I am working on the file "2.3/tutorials/latex_repr.ipynb".
The first task is:
If we set these, then the latex_repr parameters will take precedence over the component labels
Can you write Python code for it?

b.set_value(qualifier='latex_repr', component='primary', value='A')
b.set_value(qualifier='latex_repr', component='secondary', value='B')
b.set_value(qualifier='latex_repr', component='binary', value='AB')

_ = b.plot_distribution_collection(show=True)


I am working on the file "2.3/tutorials/latex_repr.ipynb".
The first task is:
Overriding Component Labels
By default, the component labels themselves are used within this latex representation.  These labels can be changed internally with b.rename_component.  However, sometimes it is convenient to use a different naming convention for the latex representation.
For example, let's say that we wanted to keep the python-labels as-is ('primary', 'secondary', and 'binary'), but use 'A', 'B', and 'AB' in the latex representations, respectively.  These latex-representations are stored in the latex_repr parameters.
Can you write Python code for it?


I am working on the file "2.3/tutorials/latex_repr.ipynb".
The first task is:
Overriding Parameter Latex "Templates"
Internally each parameter has a "template" for how to represent its name in latex.  Let's look at those attributes for the parameters we have been plotting here.
Can you write Python code for it?

b.get_parameter(qualifier='teff', component='primary', context='component')

print(b.get_parameter(qualifier='teff', component='primary', context='component').latexfmt)


I am working on the file "2.3/tutorials/latex_repr.ipynb".
The first task is:
The latex representations of parameters are mostly used while plotting distributions... so let's just create a few dummy distributions so that we can see how they're labeled when plotting.
Can you write Python code for it?

b = phoebe.default_binary()
b.add_distribution({'teff@primary': phoebe.gaussian_around(100),
                    'teff@secondary': phoebe.gaussian_around(150),
                    'requiv@primary': phoebe.uniform_around(0.2)})


I am working on the file "2.3/tutorials/latex_repr.ipynb".
The first task is:
These are blank (empty string) by default, in which case the actual component labels are used while plotting.
Can you write Python code for it?


I am working on the file "2.3/tutorials/latex_repr.ipynb".
The first task is:
When plotting, the {component} portion of this string is replaced with latex_repr (if not empty) and otherwise the component label itself.  Changing this template isn't technically supported (since there are no checks to make sure the string is valid), but if you insist, you can change the underlying string as follows::
Can you write Python code for it?

b.get_parameter(qualifier='teff', component='primary', context='component')._latexfmt = 'T_{{ \mathrm{{ {component} }}}}'

_ = b.plot_distribution_collection(show=True)


I am working on the file "2.3/tutorials/limb_darkening.ipynb".
The first task is:
All other limb-darkening parameters (ld_mode, ld_func, ld_coeffs_source, and ld_coeffs) are per-component and per-dataset parameters with context='dataset'.
Can you write Python code for it?


I am working on the file "2.3/tutorials/limb_darkening.ipynb".
The first task is:
Although not necesary, we can access the interpolated coefficients by calling b.compute_ld_coeffs.
Can you write Python code for it?


I am working on the file "2.3/tutorials/limb_darkening.ipynb".
The first task is:
As always, let's do imports and initialize a logger and a new bundle.
Can you write Python code for it?

import phoebe

logger = phoebe.logger()

b = phoebe.default_binary()


I am working on the file "2.3/tutorials/limb_darkening.ipynb".
The first task is:
Note that ld_func, ld_coeffs_source, and ld_coeffs aren't visible (relevant) if ld_mode is set to  'interp' (which it is by default).
Can you write Python code for it?


I am working on the file "2.3/tutorials/limb_darkening.ipynb".
The first task is:
Relevant Parameters
ld_mode_bol, ld_func_bol, ld_coeffs_source_bol, and ld_coeffs_bol are for bolometric limb-darkening, which is only currently used for irradiation/reflection.  These are per-component parameters that have context='component'.
Can you write Python code for it?

print(b['ld_mode_bol@primary'])

print(b['ld_func_bol@primary'])

print(b['ld_func_bol@primary'].choices)


I am working on the file "2.3/tutorials/limb_darkening.ipynb".
The first task is:
ld_mode = 'interp'
Unlike bolometric limb-darkening, passband limb-darkening coefficients can be interpolated directly from atmosphere tables, this is the default case, with ld_mode set to 'interp'.
Note that before PHOEBE 2.2, this was accomplished by setting ld_func to 'interp' (see this explanation for migrating from earlier versions).
Can you write Python code for it?


I am working on the file "2.3/tutorials/limb_darkening.ipynb".
The first task is:
ld_mode = 'lookup'
Setting the value of ld_mode to 'lookup' will expose the ld_func and ld_coeffs_source parameters.  Note that this behavior is slightly new as of PHOEBE 2.2 (see this explanation for migrating from earlier versions).
When set to 'lookup', then the limb-darkening will be interpolated per-element (for PHOEBE 2, other backends may interpolate per-star) for the function given in ld_func from the atmosphere table dictated by the ld_coeffs_source parameter (or the atm parameter and falling back on 'ck2004' if no match is found if ld_coeffs_source is set to 'auto').
Note that the bolometric ld_mode_bol of 'lookup' interpolates per-component, but not per-element.
Can you write Python code for it?

b.set_value(qualifier='ld_mode', dataset='lc01', component='primary', value='lookup')

print(b.filter(qualifier='ld*', dataset='lc01', component='primary'))


I am working on the file "2.3/tutorials/limb_darkening.ipynb".
The first task is:
ld_mode = 'manual'
Setting the value of ld_mode to 'manual' will expose the ld_func and ld_coeffs parameters.  Again, note that this behavior is slightly new as of PHOEBE 2.2 (see this explanation for migrating from earlier versions).
In this case, we can manually provide the coefficients through the ld_coeffs parameter, keeping care that they are of the correct length for the given value of ld_func.  To ensure this is the case, call b.run_checks (or wait until b.run_compute which will raise an error if the length is in conflict).
Can you write Python code for it?

b.set_value(qualifier='ld_mode', dataset='lc01', component='primary', value='manual')

print(b.filter(qualifier='ld*', dataset='lc01', component='primary'))

print(b.get_parameter(qualifier='ld_coeffs', dataset='lc01', component='primary'))


I am working on the file "2.3/tutorials/logg.ipynb".
The first task is:
As always, let's do imports and initialize a logger and a new Bundle.
Can you write Python code for it?

import phoebe
from phoebe import u # units
import numpy as np
import matplotlib.pyplot as plt

logger = phoebe.logger()

b = phoebe.default_binary()


I am working on the file "2.3/tutorials/logg.ipynb".
The first task is:
Flipping logg to solve for the mass is a little more involved, as mass is already constrained by period, sma and q.  So we must first flip the mass constraint to solve for either period or sma.
Can you write Python code for it?

print(b.filter(qualifier=['logg', 'mass', 'requiv'], component='secondary'))

b.flip_constraint('mass@secondary', solve_for='sma')

print(b.filter(qualifier=['logg', 'mass', 'requiv'], component='secondary'))

b.flip_constraint('logg@secondary', solve_for='mass')

print(b.filter(qualifier=['logg', 'mass', 'requiv'], component='secondary'))


I am working on the file "2.3/tutorials/logg.ipynb".
The first task is:
Flipping the Constraint
The logg constraint can be easily flipped so that logg is provided by the user in place of requiv.
See also:
 * tutorial on constraints
 * flip_constraint API docs
Can you write Python code for it?

print(b.filter(qualifier=['logg', 'mass', 'requiv'], component='primary'))

b.flip_constraint('logg@primary', solve_for='requiv')

print(b.filter(qualifier=['logg', 'mass', 'requiv'], component='primary'))


I am working on the file "2.3/tutorials/logg.ipynb".
The first task is:
Input vs Observed
As mentioned above, the logg parameter is defined explicitly to be at requiv and may not be comparable directly to an estimation of logg from observations.
To show this, we'll see that it can even differ from the flux-weighted loggs of the individual surface elements.
Can you write Python code for it?

b.add_dataset('lc', dataset='lc01')
b.add_dataset('mesh', times=[0, 0.25], columns=['loggs', 'areas', 'mus', 'visibilities', 'abs_intensities@lc01', 'ldint@lc01'])

b.run_compute(irrad_method='none')


I am working on the file "2.3/tutorials/logg.ipynb".
The first task is:
Just by plotting the mesh at two different times/phases, we can already imagine that an "observed" logg could be time-dependent.
Can you write Python code for it?

out = b['primary@mesh'].plot(time=0.0, fc='loggs', show=True, draw_sidebars=True)

out = b['primary@mesh'].plot(time=0.25, fc='loggs', show=True, draw_sidebars=True)


I am working on the file "2.3/tutorials/logg.ipynb".
The first task is:
Now we can manually compute the 'flux-weighted' logg from each of these times (similar to the way that RVs are computed to account for Rossiter-McLaughlin, but note that even flux-weighted loggs may not be a fair comparison to spectral-derived loggs).
Can you write Python code for it?

for time in [0.0, 0.25]:
    ps = b.filter(time=time, component='primary', context='model')
    fluxes = ps.get_value('abs_intensities') * ps.get_value('areas') * ps.get_value('mus') * ps.get_value('ldint') * ps.get_value('visibilities')
    visible = ps.get_value('visibilities') > 0
    logg = np.average(ps.get_value('loggs')[visible], weights=fluxes[visible])
    print("time = {}, logg weighted = {}".format(time, logg))

print("logg parameter value = {}".format(b.get_value('logg', component='primary')))


I am working on the file "2.3/tutorials/logg.ipynb".
The first task is:
Relevant Parameters
The 'logg' parameter defines the stellar surface gravity at requiv and is constrained by default.
IMPORTANT NOTE: as the logg parameter is defined to be the surface gravity given the value of mass and requiv, it may not be appropriate to compare or fix the value from an "observed" value of logg (from a spectrum, for example).
Can you write Python code for it?

print(b.filter('logg', context='component'))

print(b.filter('logg', context='constraint'))


I am working on the file "2.3/tutorials/ltte.ipynb".
The first task is:
Relevant Parameters
The 'ltte' parameter in context='compute' defines whether light travel time effects are taken into account or not.
Can you write Python code for it?


I am working on the file "2.3/tutorials/mask_phases.ipynb".
The first task is:
And then we'll build a synthetic "dataset" and initialize a new bundle with those data
Can you write Python code for it?

b = phoebe.default_binary()
b.add_dataset('lc', times=phoebe.linspace(0,5,1001))
b.run_compute()

times = b.get_value('times@model')
fluxes = b.get_value('fluxes@model')
sigmas = np.ones_like(times) * 0.01

b = phoebe.default_binary()
b.add_dataset('lc', compute_phases=phoebe.linspace(0,1,101),
              times=times, fluxes=fluxes, sigmas=sigmas,
              dataset='lc01')


I am working on the file "2.3/tutorials/mask_phases.ipynb".
The first task is:
However, when calling b.run_solver, the mask will be applied when determining what times to compute the forward-model (see Advanced: Solver Times) and within the cost-function (see calculate_residuals,  calculate_chi2, and calculate_lnlikelihood).
Phasing Options
Like the constraint between compute times and phases, phase-masking adheres to the per-dataset phases_t0 parameter to set which of the various t0s to use when mapping between time and phase.
And in the case of time-dependent systems, these will also adhere to phases_dpdt (in the case of dpdt and/or phases_period (in the case of apsidal motion (dperdt).
Can you write Python code for it?


I am working on the file "2.3/tutorials/mask_phases.ipynb".
The first task is:
If we wanted to only include the eclipses, we could set mask_phases as a list of tuples, where each tuple contains the phase range that we want to keep.
Can you write Python code for it?

b.set_value('mask_phases', [(-0.1, 0.1), (0.4,-0.4)])

_ = b.plot(show=True)

_ = b.plot(x='phases', show=True)


I am working on the file "2.3/tutorials/mask_phases.ipynb".
The first task is:
Let's get started with some basic imports.
Can you write Python code for it?

import phoebe
from phoebe import u # units
import numpy as np

b = phoebe.default_binary()


I am working on the file "2.3/tutorials/mask_phases.ipynb".
The first task is:
Note that b.run_compute, computes the forward model ignoring that mask, whether compute_phases is set or not.
Can you write Python code for it?

b.run_compute()

_ = b.plot(x='phases', show=True, marker={'model': '+'})

b.set_value('compute_phases', [])
b.run_compute()

_ = b.plot(x='phases', show=True, marker={'model': '+'})


I am working on the file "2.3/tutorials/mask_phases.ipynb".
The first task is:
This is True by default, but mask_phases is set to an empty list, meaning that no masking will actually be applied.  This mask_enabled parameter just allows for setting a mask via mask_phases and then toggling that mask on and off without having to reset mask_phases.
Can you write Python code for it?

b.get_parameter(qualifier='mask_phases', dataset='lc01', context='dataset')

print(b.get_parameter(qualifier='mask_phases', dataset='lc01', context='dataset').description)


I am working on the file "2.3/tutorials/mask_phases.ipynb".
The first task is:
We can now plot the observations to see the unmasked (fake) data.
Can you write Python code for it?

_ = b.plot(show=True)

_ = b.plot(x='phases', show=True)


I am working on the file "2.3/tutorials/mask_phases.ipynb".
The first task is:
mask_enabled and mask_phases parameters
Each dataset will have a mask_enabled parameter and, if mask_enabled=True, a mask_phases parameter.
Can you write Python code for it?

b.get_parameter(qualifier='mask_enabled', dataset='lc01', context='dataset')

print(b.get_parameter(qualifier='mask_enabled', dataset='lc01', context='dataset').description)


I am working on the file "2.3/tutorials/meshes.ipynb".
The first task is:
Any of the exposed columns are then available for plotting the mesh, via b.plot.
Can you write Python code for it?

afig, mplfig = b.plot(kind='mesh', time=0.2, fc='teffs', ec='none', show=True)


I am working on the file "2.3/tutorials/meshes.ipynb".
The first task is:
But we can also specify other columns to be included (by setting the columns SelectParameter before calling run_compute)
Can you write Python code for it?

print(b.get_parameter(qualifier='columns', kind='mesh', context='dataset'))

b.set_value('columns', value=['teffs'])

b.run_compute()

print(b.filter(kind='mesh', context='model').qualifiers)

print(b.get_value('teffs', time=0.0, component='primary'))


I am working on the file "2.3/tutorials/meshes.ipynb".
The first task is:
By default, the mesh only exposes the geometric columns of the triangles, in both plane-of-sky and roche coordinates.
Can you write Python code for it?


I am working on the file "2.3/tutorials/meshes.ipynb".
The first task is:
The 'Mesh' Dataset
You must create a mesh dataset and specify the times and columns which you'd like exposed.  For more information, see the tutorial on the MESH dataset.
The mesh will be exposed at the times specified by the compute_times Parameter, as well as any times referenced by the include_times SelectParameter.
So let's add an LC and MESH datasets.
Can you write Python code for it?

b.add_dataset('lc', times=phoebe.linspace(0,1,6))

b.add_dataset('mesh')


I am working on the file "2.3/tutorials/meshes.ipynb".
The first task is:
Unlike other datasets, the mesh dataset cannot accept actual observations, so there is no times parameter, only the compute_times and compute_phases parameters.  For more details on these, see the Advanced: Compute Times & Phases tutorial.
Can you write Python code for it?

print(b.get_parameter(qualifier='compute_times', kind='mesh'))

print(b.get_parameter(qualifier='include_times', kind='mesh'))


I am working on the file "2.3/tutorials/mpi.ipynb".
The first task is:
PHOEBE determines whether the current script is running within an MPI environment by checking for environment variables set by mpirun/mpiexec.  If you run into any issues with PHOEBE not behaving as expected, check to see whether PHOEBE thinks its within mpirun.
Can you write Python code for it?


I am working on the file "2.3/tutorials/multiprocessing.ipynb".
The first task is:
Accessing/Changing Multiprocessing Settings
To check the number of processors that will be used whenever multiprocessing is invoked, call phoebe.multiprocessing_get_nprocs.  By default, this will be the number of detected CPUs on the machine.
Can you write Python code for it?


I am working on the file "2.3/tutorials/multiprocessing.ipynb".
The first task is:
To disable multiprocessing, we can call phoebe.multiprocessing_off.
Can you write Python code for it?


I am working on the file "2.3/tutorials/multiprocessing.ipynb".
The first task is:
To re-enable multiprocessing with all available CPUs on the machine, we can call phoebe.multiprocessing_on.
Can you write Python code for it?


I am working on the file "2.3/tutorials/nelder_mead.ipynb".
The first task is:
And then adopt the final parameter values, via b.adopt_solution.  By passing trial_run=True, we can see what changes will be made without actually changing the face-values in the bundle.
Can you write Python code for it?


I am working on the file "2.3/tutorials/nelder_mead.ipynb".
The first task is:
Create fake "observations"
We'll create the same fake "observations" as in the Inverse Paper Examples.
For the sake of efficiency for this example, we'll use the ellc backend.  In practice, this is only safe for areas of the parameter space where phoebe and ellc are in sufficient agreement.
Can you write Python code for it?

b = phoebe.default_binary()
b.set_value('ecc', 0.2)
b.set_value('per0', 25)
b.set_value('teff@primary', 7000)
b.set_value('teff@secondary', 6000)
b.set_value('sma@binary', 7)
b.set_value('incl@binary', 80)
b.set_value('q', 0.3)
b.set_value('t0_supconj', 0.1)
b.set_value('requiv@primary', 2.0)
b.set_value('vgamma', 80)

lctimes = phoebe.linspace(0, 10, 1005)
rvtimes = phoebe.linspace(0, 10, 105)
b.add_dataset('lc', compute_times=lctimes)
b.add_dataset('rv', compute_times=rvtimes)

b.add_compute('ellc', compute='fastcompute')
b.set_value_all('ld_mode', 'lookup')
b.run_compute(compute='fastcompute')

fluxes = b.get_value('fluxes@model') + np.random.normal(size=lctimes.shape) * 0.01
fsigmas = np.ones_like(lctimes) * 0.02

rvsA = b.get_value('rvs@primary@model') + np.random.normal(size=rvtimes.shape) * 10
rvsB = b.get_value('rvs@secondary@model') + np.random.normal(size=rvtimes.shape) * 10
rvsigmas = np.ones_like(rvtimes) * 20

b = phoebe.default_binary()

b.add_dataset('lc',
              compute_phases=phoebe.linspace(0,1,201),
              times=lctimes,
              fluxes=fluxes,
              sigmas=fsigmas,
              dataset='lc01')

b.add_dataset('rv',
              compute_phases=phoebe.linspace(0,1,201),
              times=rvtimes,
              rvs={'primary': rvsA, 'secondary': rvsB},
              sigmas=rvsigmas,
              dataset='rv01')

b.add_compute('ellc', compute='fastcompute')
b.set_value_all('ld_mode', 'lookup')


I am working on the file "2.3/tutorials/nelder_mead.ipynb".
The first task is:
For this example, let's try to fit the RV first, so we'll optimize q, vgamma, and t0_supconj.
Can you write Python code for it?

b.set_value('fit_parameters', ['q', 'vgamma', 't0_supconj'])

b.get_value('fit_parameters', expand=True)


I am working on the file "2.3/tutorials/nelder_mead.ipynb".
The first task is:
Here we get to choose which set of compute-options will be used while optimizing (we'll choose the ellc compute options we called 'fastcompute' just for the sake of efficiency)
Can you write Python code for it?


I am working on the file "2.3/tutorials/nelder_mead.ipynb".
The first task is:
Interpreting the Returned Solution
We can now look at the new parameters this has added to the bundle:
Can you write Python code for it?


I am working on the file "2.3/tutorials/nelder_mead.ipynb".
The first task is:
Note that by default, all fitted parameters will be adopted.  But we can change this by setting adopt_parameters (in the solution) or by passing adopt_parameters directly to adopt_solution.
Can you write Python code for it?


I am working on the file "2.3/tutorials/nelder_mead.ipynb".
The first task is:
This adds new parameters to our bundle with the options for running nelder-mead.
Can you write Python code for it?


I am working on the file "2.3/tutorials/nelder_mead.ipynb".
The first task is:
We'll also set maxiter and maxfev to smaller values (these are just passed directly to scipy.optimize.minimize.
Can you write Python code for it?

b.set_value('maxiter', 1000)
b.set_value('maxfev', 1000)


I am working on the file "2.3/tutorials/nelder_mead.ipynb".
The first task is:
We'll set the initial model to be close to the correct values, but not exact.  In practice, we would instead have to use a combination of manual tweaking, LC estimators, and RV_estimators to get in the rough parameter space of the solution before starting to use optimizers.
Can you write Python code for it?

b.set_value('sma@binary', 7+0.5)
b.set_value('incl@binary', 80+10)
b.set_value('q', 0.3+0.1)
b.set_value('t0_supconj', 0.1)
b.set_value('requiv@primary', 2.0-0.3)

b.run_compute(compute='fastcompute', model='orig_model')

_ = b.plot(x='phases', show=True)


I am working on the file "2.3/tutorials/nelder_mead.ipynb".
The first task is:
fit_parameters does accept partial-twigs as well as wildcard matching.  To see the full list of matched parameters for the current set value, you can pass expand=True to get_value.
Can you write Python code for it?

b.set_value('fit_parameters', ['teff', 'requiv'])

b.get_value('fit_parameters', expand=True)


I am working on the file "2.3/tutorials/optimizing.ipynb".
The first task is:
If disabled, you can always manually run the checks via b.run_checks().
Can you write Python code for it?

print(b.run_checks())

b.set_value('requiv', component='primary', value=50)

print(b.run_checks())


I am working on the file "2.3/tutorials/optimizing.ipynb".
The first task is:
Interactive Constraints
By default, interactive constraints are always enabled in PHOEBE, unless explicitly disabled.  Whenever a value is changed in the bundle that affects the value of a constrained value, that constraint is immediately executed and all applicable values updated.  The ensures that all constrained values are "up-to-date".
If disabled, constraints are delayed and only executed when needed by PHOEBE (when calling run_compute, for example).  This can save significant time, as each value that needs updating only needs to have its constraint executed once, instead of multiple times.
This default behavior can be changed via phoebe.interactive_constraints_on() or phoebe.interactive_constraints_off().  The current value can be accessed via phoebe.conf.interactive_constraints.
Let's first look at the default behavior with interactive constraints on.
Can you write Python code for it?

print(phoebe.conf.interactive_constraints)

print(b.filter('mass', component='primary'))

b.set_value('sma@binary', 10)

print(b.filter('mass', component='primary'))


I am working on the file "2.3/tutorials/optimizing.ipynb".
The first task is:
No need to worry though - all constraints will be run automatically before passing to the backend.  If you need to access the value of a constrained parameter, you can explicitly ask for all delayed constraints to be executed via b.run_delayed_constraints().
Can you write Python code for it?

b.run_delayed_constraints()

print(b.filter('mass', component='primary'))

phoebe.reset_settings()


I am working on the file "2.3/tutorials/optimizing.ipynb".
The first task is:
Note that the mass has already updated, according to the constraint, when the value of the semi-major axes was changed.  If we disable interactive constraints this will not be the case.
Can you write Python code for it?

phoebe.interactive_constraints_off()

print(phoebe.conf.interactive_constraints)

print(b.filter('mass', component='primary'))

b.set_value('sma@binary', 15)

print(b.filter('mass', component='primary'))


I am working on the file "2.3/tutorials/optimizing.ipynb".
The first task is:
Now if we disable check_visible, we'll see the same thing as if we passed check_visible=False to any filter call.
Can you write Python code for it?


I am working on the file "2.3/tutorials/optimizing.ipynb".
The first task is:
Passband Options
PHOEBE automatically fetches necessary tables from tables.phoebe-project.org.  By default, only the necessary tables for each passband are fetched (except when calling download_passband manually) and the fits files are fetched uncompressed.
For more details, see the API docs on download_passband and update_passband as well as the passband updating tutorial.
The default values mentioned in the API docs for content and gzipped can be exposed via phoebe.get_download_passband_defaults and changed via phoebe.set_download_passband_defaults.  Note that setting gzipped to True will minimize file storage for the passband files and will result in faster download speeds, but take significantly longer to load by PHOEBE as they have to be uncompressed each time they are loaded.  If you have a large number of installed passbands, this could significantly slow importing PHOEBE.
Can you write Python code for it?


I am working on the file "2.3/tutorials/optimizing.ipynb".
The first task is:
check_default
Similarly, PHOEBE automatically excludes any parameter which is tagged with a '_default' tag.  These parameters exist to provide default values when a new component or dataset are added to the bundle, but can usually be ignored, and so are excluded from any filter calls.  Although not at all expensive, this too can be disabled at the settings level or by passing check_default=False to any filter call.
This default behavior can be changed via phoebe.check_default_on() or phoebe.check_default_off().
Can you write Python code for it?

print(b.get_dataset())

print(b.get_dataset(check_default=False))

phoebe.check_default_off()

print(b.get_dataset())

phoebe.reset_settings()


I am working on the file "2.3/tutorials/parameters.ipynb".
The first task is:
As with Python, an empty string will cast to False and a non-empty string will cast to True
Can you write Python code for it?

param.set_value('')
print(param.get_value())

param.set_value('some_string')
print(param.get_value())


I am working on the file "2.3/tutorials/parameters.ipynb".
The first task is:
Bool Parameters
BoolParameters are even simpler - they accept True or False.
Can you write Python code for it?

param = phoebe.parameters.BoolParameter(qualifier='myboolparameter',
                                        description='mydescription',
                                        value=True)

print(param)

print(param.attributes)


I am working on the file "2.3/tutorials/parameters.ipynb".
The first task is:
But note that the limits are still stored as a quantity object in the originally defined default_units
Can you write Python code for it?


I am working on the file "2.3/tutorials/parameters.ipynb".
The first task is:
But we can also request the value in a different unit, by passing an astropy Unit object or its string representation.
Can you write Python code for it?


I am working on the file "2.3/tutorials/parameters.ipynb".
The first task is:
Calling get_value will then return a float in these units
Can you write Python code for it?


I am working on the file "2.3/tutorials/parameters.ipynb".
The first task is:
Filtering
Any of the tags can also be used to filter the ParameterSet:
Can you write Python code for it?


I am working on the file "2.3/tutorials/parameters.ipynb".
The first task is:
FloatArrayParameters also allow for built-in interpolation... but this requires them to be a member of a Bundle, so we'll discuss this in just a bit.
ParametersSets
ParameterSets are a collection of Parameters that can be filtered by their tags to return another ParameterSet.
For illustration, let's create 3 random FloatParameters and combine them to make a ParameterSet.
Can you write Python code for it?

param1 = phoebe.parameters.FloatParameter(qualifier='param1',
                                          description='param1 description',
                                          default_unit=u.m,
                                          limits=[None,20],
                                          value=5,
                                          context='context1',
                                          kind='kind1')

param2 = phoebe.parameters.FloatParameter(qualifier='param2',
                                          description='param2 description',
                                          default_unit=u.deg,
                                          limits=[0,2*np.pi],
                                          value=0,
                                          context='context2',
                                          kind='kind2')

param3 = phoebe.parameters.FloatParameter(qualifier='param3',
                                          description='param3 description',
                                          default_unit=u.kg,
                                          limits=[0,2*np.pi],
                                          value=0,
                                          context='context1',
                                          kind='kind2')

ps = phoebe.parameters.ParameterSet([param1, param2, param3])

print(ps.to_list())


I am working on the file "2.3/tutorials/parameters.ipynb".
The first task is:
FloatParameters
FloatParameters are probably the most common Parameter used in PHOEBE and hold both a float and a unit, with the ability to retrieve the value in any other convertible unit.
Can you write Python code for it?

param = phoebe.parameters.FloatParameter(qualifier='myfloatparameter',
                                         description='mydescription',
                                         default_unit=u.m,
                                         limits=[None,20],
                                         value=5)

print(param)


I am working on the file "2.3/tutorials/parameters.ipynb".
The first task is:
FloatParameters also have their own method to access an astropy Quantity object that includes both the value and the unit
Can you write Python code for it?


I am working on the file "2.3/tutorials/parameters.ipynb".
The first task is:
For the special case of the 'value' attribute, there is also a get_value method (will become handy later when we want to be able to request the value in a specific unit).
Can you write Python code for it?


I am working on the file "2.3/tutorials/parameters.ipynb".
The first task is:
However, SelectParameters also allow you to use * as a wildcard and will expand to any of the choices that match that wildcard.  For example,
Can you write Python code for it?

param.set_value(["choice*"])

print(param.get_value())

print(param.expand_value())


I am working on the file "2.3/tutorials/parameters.ipynb".
The first task is:
If we print a ParameterSet, we'll see a listing of all the Parameters and their values.
Can you write Python code for it?


I am working on the file "2.3/tutorials/parameters.ipynb".
The first task is:
If we print the parameter object we can see a summary of information
Can you write Python code for it?


I am working on the file "2.3/tutorials/parameters.ipynb".
The first task is:
If you ever need to know the type of a Parameter, you can always use python's built-in type functionality:
Can you write Python code for it?


I am working on the file "2.3/tutorials/parameters.ipynb".
The first task is:
If you want to access the actual Parameter, you must use get instead of (or in addition to) filter.  All of the following lines do the exact same thing:
Can you write Python code for it?

print(ps.filter(context='context1', kind='kind1').get())

print(ps.get(context='context1', kind='kind1'))


I am working on the file "2.3/tutorials/parameters.ipynb".
The first task is:
IntParameters
IntParameters are essentially the same as FloatParameters except they always cast to an Integer and they have no units.
Can you write Python code for it?

param = phoebe.parameters.IntParameter(qualifier='myintparameter',
                                       description='mydescription',
                                       limits=[0,None],
                                       value=1)

print(param)

print(param.attributes)


I am working on the file "2.3/tutorials/parameters.ipynb".
The first task is:
Let's get started with some basic imports
Can you write Python code for it?

import phoebe
from phoebe import u # units
import numpy as np

logger = phoebe.logger(clevel='INFO')


I am working on the file "2.3/tutorials/parameters.ipynb".
The first task is:
Like FloatParameters above, IntParameters still have limits
Can you write Python code for it?


I am working on the file "2.3/tutorials/parameters.ipynb".
The first task is:
Note that this returned the ParameterObject itself, so you can now use any of the Parameter methods or attributes we saw earlier.  For example:
Can you write Python code for it?


I am working on the file "2.3/tutorials/parameters.ipynb".
The first task is:
Of course, once you get the Parameter you can then use dictionary keys to access any attributes of that Parameter.
Can you write Python code for it?


I am working on the file "2.3/tutorials/parameters.ipynb".
The first task is:
Or we can use those twigs.  Remember that twigs are just a combination of these tags separated by the @ symbol.  You can use these for dictionary access in a ParameterSet - without needing to provide the name of the tag, and without having to worry about order.  And whenever this returns a ParameterSet, these are also chainable, so the following two lines will do the same thing:
Can you write Python code for it?


I am working on the file "2.3/tutorials/parameters.ipynb".
The first task is:
SelectParameters
SelectParameters are very similar to ChoiceParameters except that the value is a list, where each item must match one of the prescribed choices.
Can you write Python code for it?

param = phoebe.parameters.SelectParameter(qualifier='myselectparameter',
                                          description='mydescription',
                                          choices=['choice1', 'choice2'],
                                          value=['choice1'])

print(param)

print(param.attributes)

print(param['choices'], param.choices)

print(param.get_value())


I am working on the file "2.3/tutorials/parameters.ipynb".
The first task is:
The 'qualifier' attribute is essentially an abbreviated name for the Parameter.
These tags will be shared across all Parameters, regardless of their type.
Attributes, on the other hand, can be dependent on the type of the Parameter and tell the Parameter its rules and how to interpret its value.  You can access a list of available attributes as follows:
Can you write Python code for it?


I am working on the file "2.3/tutorials/parameters.ipynb".
The first task is:
The 'visible_if' attribute only comes into play when the Parameter is a member of a ParameterSet, so we'll discuss it at the end of this tutorial when we get to ParameterSets.
The 'copy_for' attribute is only used when the Parameter is in a particular type of ParameterSet called a Bundle (explained at the very end of this tutorial).  We'll see the 'copy_for' capability in action later in the Datasets Tutorial, but for now, just know that you can view this property only and cannot change it... and most of the time it will just be an empty string.
StringParameters
We'll just mention StringParameters again for completeness, but we've already seen about all they can do - the value must cast to a valid string but no limits or checks are performed at all on the value.
ChoiceParameters
ChoiceParameters are essentially StringParameters with one very important exception: the value must match one of the prescribed choices.
Therefore, they have a 'choice' attribute and an error will be raised if trying to set the value to any string not in that list.
Can you write Python code for it?

param = phoebe.parameters.ChoiceParameter(qualifier='mychoiceparameter',
                                          description='mydescription',
                                          choices=['choice1', 'choice2'],
                                          value='choice1')

print(param)

print(param.attributes)

print(param['choices'], param.choices)

print(param.get_value())

#param.set_value('not_a_choice') # would raise a ValueError
param.set_value('choice2')
print(param.get_value())


I am working on the file "2.3/tutorials/parameters.ipynb".
The first task is:
The Bundle
The Bundle is nothing more than a glorified ParameterSet with some extra methods to compute models, add new components and datasets, etc.
You can initialize a bundle for a default detached binary system as follows:
Can you write Python code for it?


I am working on the file "2.3/tutorials/parameters.ipynb".
The first task is:
The set_value method also accepts a unit - this doesn't change the default_unit internally, but instead converts the provided value before storing.
Can you write Python code for it?

param.set_value(10)
print(param.get_quantity())

param.set_value(0.001*u.km)
print(param.get_quantity())

param.set_value(10, unit='cm')
print(param.get_quantity())


I am working on the file "2.3/tutorials/parameters.ipynb".
The first task is:
The value attribute is also the only attribute that you'll likely want to change, so it also has a set_value method:
Can you write Python code for it?


I am working on the file "2.3/tutorials/parameters.ipynb".
The first task is:
This returns None since not all objects in this ParameterSet share a single context.  But you can see all the options for a given tag by providing the plural version of that tag name:
Can you write Python code for it?


I am working on the file "2.3/tutorials/parameters.ipynb".
The first task is:
Twigs
The string notation used for the Parameters is called a 'twig' - its simply a combination of all the tags joined with the '@' symbol and gives a very convenient way to access any Parameter.
The order of the tags doesn't matter, and you only need to provide enough tags to produce a unique match.  Since there is only one parameter with kind='kind1', we do not need to provide the extraneous context='context1' in the twig to get a match.
Can you write Python code for it?


I am working on the file "2.3/tutorials/parameters.ipynb".
The first task is:
We can see the "rule" that dictates the parameter's visibility
Can you write Python code for it?

print(b.get_parameter(qualifier='ld_coeffs_bol', component='primary'))

print(b.get_parameter(qualifier='ld_coeffs_bol', component='primary').visible_if)


I am working on the file "2.3/tutorials/parameters.ipynb".
The first task is:
You can see here that we've defined three a few things about parameter: the qualifier, description, and value (others do exist, they just don't show up in the summary).
These "things" can be split into two groups: tags and attributes (although in a pythonic sense, both can be accessed as attributes).  Don't worry too much about this distinction - it isn't really important except for the fact that tags are shared across all Parameters whereas attributes are dependent on the type of the Parameter.
The tags of a Parameter define the Parameter and how it connects to other Parameters (again, more on this when we get to ParameterSets).  For now, just know that you can access a list of all the tags as follows:
Can you write Python code for it?


I am working on the file "2.3/tutorials/parameters.ipynb".
The first task is:
You may notice that the final result was a Parameter, not a ParameterSet.  Twig dictionary access tries to be smart - if exactly 1 Parameter is found, it will return that Parameter instead of a ParameterSet.  Notice the difference between the two following lines:
Can you write Python code for it?


I am working on the file "2.3/tutorials/parameters.ipynb".
The first task is:
You'll notice here a few new mentions in the summary... "Constrained by", "Constrains", and "Related to" are all referring to constraints.
Can you write Python code for it?


I am working on the file "2.3/tutorials/parameters.ipynb".
The first task is:
and again, each of these are available through both a dictionary key and as an object attribute.  For example, all parameters have a 'description' attribute which gives additional information about what the Parameter means:
Can you write Python code for it?


I am working on the file "2.3/tutorials/parameters.ipynb".
The first task is:
and filter just as you would for a ParameterSet
Can you write Python code for it?


I am working on the file "2.3/tutorials/passband_updates.ipynb".
The first task is:
PHOEBE allows you to check for online updates to local install passbands.  If we add a new atmosphere table or feature (extinction as in this release, for example) to a passband table, you can now update directly from the python interface of PHOEBE.
If you try using extinction in a version of a table that does not support extinction, for example, an error will be raised (either during run_compute or you can check by calling run_checks manually).  If extinction tables are available in the online version of the passband (from tables.phoebe-project.org), then the local installed version will automatically be updated if the timestamps on the passbands match, otherwise a message will be raised with instructions to manually call phoebe.update_passband.
If you'd like to manually check for updates, you can use phoebe.list_all_update_passbands_available or phoebe.update_passband_available.
Can you write Python code for it?

import phoebe

print(phoebe.list_installed_passbands())

print(phoebe.list_all_update_passbands_available())

print(phoebe.update_passband_available('Johnson:V'))


I am working on the file "2.3/tutorials/passband_updates.ipynb".
The first task is:
To update a single passband to the latest online version with the same contents as the locally installed version (or with new tables, see the content argument), call phoebe.update_passband.
Can you write Python code for it?


I am working on the file "2.3/tutorials/passbands.ipynb".
The first task is:
Checking the content property again shows that the table has been successfully computed:
Can you write Python code for it?


I am working on the file "2.3/tutorials/passbands.ipynb".
The first task is:
Getting started
Let us start by importing phoebe, numpy and matplotlib:
Can you write Python code for it?

%matplotlib inline
import phoebe
from phoebe import u # units
import numpy as np
import matplotlib.pyplot as plt

logger = phoebe.logger(clevel='WARNING')


I am working on the file "2.3/tutorials/passbands.ipynb".
The first task is:
Let us now plot a range of temperatures, to make sure that normal emergent passband intensities do what they are supposed to do. While at it, let us compare what we get for the Johnson:V passband.
Can you write Python code for it?

jV = phoebe.get_passband('Johnson:V')
teffs = np.linspace(5000, 8000, 100)
plt.xlabel('Temperature [K]')
plt.ylabel('Inorm [W/m^3]')
plt.plot(teffs, pb.Inorm(teffs, atm='blackbody', ld_func='linear', ld_coeffs=[0.0]), label='mypb')
plt.plot(teffs, jV.Inorm(teffs, atm='blackbody', ld_func='linear', ld_coeffs=[0.0]), label='jV')
plt.legend(loc='lower right')
plt.show()


I am working on the file "2.3/tutorials/passbands.ipynb".
The first task is:
Let us now save these data in a file that we will use to register a new passband.
Can you write Python code for it?


I am working on the file "2.3/tutorials/passbands.ipynb".
The first task is:
Let us plot this mock passband transmission function to see what it looks like:
Can you write Python code for it?

plt.xlabel('Wavelength [nm]')
plt.ylabel('Passband transmission')
plt.plot(wl, ptf, 'b-')
plt.show()


I am working on the file "2.3/tutorials/passbands.ipynb".
The first task is:
Note, of course, that you will need to change the path to point to the directory where you unpacked the ck2004 tables. The verbosity parameter verbose will report on the progress as computation is being done. Depending on your computer speed, this step will take up to a minute to complete. We can now check the passband's content attribute again:
Can you write Python code for it?


I am working on the file "2.3/tutorials/passbands.ipynb".
The first task is:
Now we can compare all three model atmospheres:
Can you write Python code for it?

plt.xlabel('Temperature [K]')
plt.ylabel('Inorm [W/m^3]')
plt.plot(teffs, pb.Inorm(teffs,               atm='blackbody', ldatm='ck2004',  ld_func='linear', ld_coeffs=[0.0]), label='blackbody')
plt.plot(teffs, pb.Inorm(teffs, loggs, abuns, atm='ck2004',    ldatm='ck2004',  ld_func='linear', ld_coeffs=[0.0]), label='ck2004')
plt.plot(teffs, pb.Inorm(teffs, loggs, abuns, atm='phoenix',   ldatm='phoenix', ld_func='linear', ld_coeffs=[0.0]), label='phoenix')
plt.legend(loc='lower right')
plt.show()


I am working on the file "2.3/tutorials/passbands.ipynb".
The first task is:
Passband transmission function
The passband transmission function is typically a user-provided two-column file. The first column is wavelength, and the second column is passband transmission. For the purposes of this tutorial, we will simulate the passband as a uniform box.
Can you write Python code for it?


I am working on the file "2.3/tutorials/passbands.ipynb".
The first task is:
Quite a difference. That is why using model atmospheres is superior when accuracy is of importance. Next, we need to compute direction-dependent intensities for all our limb darkening and boosting needs. This is a step that takes a long time; depending on your computer speed, it can take a few minutes to complete.
Can you write Python code for it?


I am working on the file "2.3/tutorials/passbands.ipynb".
The first task is:
Registering a passband
The first step in introducing a new passband into PHOEBE is registering it with the system. We use the Passband class for that.
Can you write Python code for it?

pb = phoebe.atmospheres.passbands.Passband(
    ptf='my_passband.ptf',
    pbset='Custom',
    pbname='mypb',
    effwl=330.,
    wlunits=u.nm,
    calibrated=True,
    reference='A completely made-up passband published in Nowhere (2017)',
    version=1.0,
    comments='This is my first custom passband')


I am working on the file "2.3/tutorials/passbands.ipynb".
The first task is:
Since we have not computed any tables yet, the list is empty for now. Blackbody functions for computing the lookup tables are built into PHOEBE and you do not need any auxiliary files to generate them. The lookup tables are defined for effective temperatures between 300K and 500,000K. To compute the blackbody response, issue:
Can you write Python code for it?


I am working on the file "2.3/tutorials/passbands.ipynb".
The first task is:
Still an appreciable difference.
Saving the passband table
The final step of all this (computer's) hard work is to save the passband file so that these steps do not need to be ever repeated. From now on you will be able to load the passband file explicitly and PHOEBE will have full access to all of its tables. Your new passband will be identified as 'Custom:mypb'.
To make PHOEBE automatically load the passband, it needs to be added to one of the passband directories that PHOEBE recognizes. If there are no proprietary aspects that hinder the dissemination of the tables, please consider contributing them to PHOEBE so that other users can use them.
Can you write Python code for it?


I am working on the file "2.3/tutorials/passbands.ipynb".
The first task is:
The first argument, ptf, is the passband transmission file we just created. Of course, you would provide an actual passband transmission function that comes from a respectable source rather than this silly tutorial.
The next two arguments, pbset and pbname, should be taken in unison. The way PHOEBE refers to passbands is a pbset:pbname string, for example Johnson:V, Cousins:Rc, etc. Thus, our fake passband will be Custom:mypb.
The following two arguments, effwl and wlunits, also come as a pair. PHOEBE uses effective wavelength to apply zero-level passband corrections when better options (such as model atmospheres) are unavailable. Effective wavelength is a transmission-weighted average wavelength in the units given by wlunits.
The calibrated parameter instructs PHOEBE whether to take the transmission function as calibrated, i.e. the flux through the passband is absolutely calibrated. If set to True, PHOEBE will assume that absolute intensities computed using the passband transmission function do not need further calibration. If False, the intensities are considered as scaled rather than absolute, i.e. correct to a scaling constant. Most modern passbands provided in the recent literature are calibrated.
The reference parameter holds a reference string to the literature from which the transmission function was taken from. It is common that updated transmission functions become available, which is the point of the version parameter. If there are multiple versions of the transmission function, PHOEBE will by default take the largest value, or the value that is explicitly requested in the filter string, i.e. Johnson:V:1.0 or Johnson:V:2.0.
Finally, the comments parameter is a convenience parameter to store any additional pertinent information.
Computing blackbody response
To significantly speed up calculations, passband intensities are stored in lookup tables instead of computing them over and over again on the fly. Computed passband tables are tagged in the content property of the class:
Can you write Python code for it?


I am working on the file "2.3/tutorials/passbands.ipynb".
The first task is:
There is one extra step that we need to do for phoenix atmospheres: because there are gaps in the coverage of atmospheric parameters, we need to impute those values in order to allow for seamless interpolation. This is achieved by the call to impute_atmosphere_grid(). It is a computationally intensive step that can take 10+ minutes.
Can you write Python code for it?

pb.impute_atmosphere_grid(pb._phoenix_energy_grid)
pb.impute_atmosphere_grid(pb._phoenix_photon_grid)
pb.impute_atmosphere_grid(pb._phoenix_ld_energy_grid)
pb.impute_atmosphere_grid(pb._phoenix_ld_photon_grid)
pb.impute_atmosphere_grid(pb._phoenix_ldint_energy_grid)
pb.impute_atmosphere_grid(pb._phoenix_ldint_photon_grid)
for i in range(len(pb._phoenix_intensity_axes[3])):
    pb.impute_atmosphere_grid(pb._phoenix_Imu_energy_grid[:,:,:,i,:])
    pb.impute_atmosphere_grid(pb._phoenix_Imu_photon_grid[:,:,:,i,:])


I am working on the file "2.3/tutorials/passbands.ipynb".
The first task is:
This completes the computation of Castelli & Kurucz auxiliary tables.
Computing PHOENIX response
PHOENIX is a 3-D model atmosphere code. Because of that, it is more complex and better behaved for cooler stars (down to ~2300K). The steps to compute PHOENIX intensity tables are analogous to the ones we used for ck2004; so we can do all of them in a single step:
Can you write Python code for it?

pb.compute_phoenix_response(path='tables/phoenix', verbose=False)
pb.compute_phoenix_intensities(path='tables/phoenix', verbose=False)
pb.compute_phoenix_ldcoeffs()
pb.compute_phoenix_ldints()
print(pb.content)


I am working on the file "2.3/tutorials/passbands.ipynb".
The first task is:
This makes perfect sense: Johnson V transmission function is wider than our boxed transmission function, so intensity in the V band is larger the lower temperatures. However, for the hotter temperatures the contribution to the UV flux increases and our box passband with a perfect transmission of 1 takes over.
Computing Castelli & Kurucz (2004) response
For any real science you will want to generate model atmosphere tables. The default choice in PHOEBE are the models computed by Fiorella Castelli and Bob Kurucz (website, paper) that feature new opacity distribution functions. In principle, you can generate PHOEBE-compatible tables for any model atmospheres, but that would require a bit of book-keeping legwork in the PHOEBE backend. Contact us to discuss an extension to other model atmospheres.
To compute Castelli & Kurucz (2004) passband tables, we will use the previously downloaded model atmospheres. We start with the ck2004 normal intensities:
Can you write Python code for it?


I am working on the file "2.3/tutorials/passbands.ipynb".
The first task is:
We see that, as temperature increases, model atmosphere intensities can differ quite a bit. That explains why the choice of a model atmosphere is quite important and should be given proper consideration.
Importing Wilson-Devinney response
PHOEBE no longer shares any codebase with the WD code, but for comparison purposes it is sometimes useful to use the same atmosphere tables. If the passband you are registering with PHOEBE has been defined in WD's atmcof.dat and atmcofplanck.dat files, PHOEBE can import those coefficients and use them to compute intensities.
To import a set of WD atmospheric coefficients, you need to know the corresponding index of the passband (you can look it up in the WD user manual available at ftp://ftp.astro.ufl.edu/pub/wilson/lcdc2003/ebdoc2003.2feb2004.pdf.gz) and you need to grab the files ftp://ftp.astro.ufl.edu/pub/wilson/lcdc2003/atmcofplanck.dat.gz and ftp://ftp.astro.ufl.edu/pub/wilson/lcdc2003/atmcof.dat.gz from Bob Wilson's webpage. For this particular passband the index is 22. To import, issue:
Can you write Python code for it?


I am working on the file "2.3/tutorials/pblum.ipynb".
The first task is:
'normal_intensities' are scaled from 'abs_normal_intensities' so that the computed luminosity matches the prescribed luminosity (pblum).
Here we compute the luminosity by summing over each triangle's intensity in the normal direction, and multiply it by pi to account for blackbody intensity emitted in all directions in the solid angle, and by the area of that triangle.
Can you write Python code for it?

pblum = b.get_value(qualifier='pblum', component='primary', context='dataset')
print(np.sum(normal_intensities * ldint * np.pi * areas) * ptfarea, pblum)


I am working on the file "2.3/tutorials/pblum.ipynb".
The first task is:
Accessing Model Luminosities
Passband luminosities at t0@system per-star (including following all coupling logic) can be computed and exposed on the fly by calling compute_pblums.
Can you write Python code for it?


I am working on the file "2.3/tutorials/pblum.ipynb".
The first task is:
And lastly, if we re-enable irradiation, we'll see that the extrinsic luminosities do not match the prescribed value of pblum (an intrinsic luminosity).
Can you write Python code for it?

print(b['ld_mode'])

print(b['atm'])

b.run_compute(irrad_method='horvat')

print(b.get_value(qualifier='pblum_ext', time=t0, component='primary', kind='mesh', context='model'))

print(b.get_value('pblum@primary@dataset'))

print(b.compute_pblums(dataset='lc01', irrad_method='horvat'))


I am working on the file "2.3/tutorials/pblum.ipynb".
The first task is:
And we'll add a single light curve dataset so that we can see how passband luminosities affect the resulting synthetic light curve model.
Can you write Python code for it?


I am working on the file "2.3/tutorials/pblum.ipynb".
The first task is:
As we no longer provide pblum values to scale, those parameters are not visible when filtering.
Can you write Python code for it?

print(b.filter(qualifier='pblum'))

print(b.compute_pblums())

b.run_compute()

afig, mplfig = b.plot(show=True)


I am working on the file "2.3/tutorials/pblum.ipynb".
The first task is:
Before moving on, let's remove our fake data (and reset pblum_mode or else PHOEBE will complain about the lack of data).
Can you write Python code for it?

b.set_value('pblum_mode', 'component-coupled')

b.set_value('fluxes', context='dataset', value=[])


I am working on the file "2.3/tutorials/pblum.ipynb".
The first task is:
For any of these modes, you can expose the intrinsic (excluding extrinsic effects such as spots and irradiation) and extrinsic computed luminosities of each star (in each dataset) by calling b.compute_pblums.
Note that as its an aspect-dependent effect, boosting is ignored in all of these output values.
Can you write Python code for it?


I am working on the file "2.3/tutorials/pblum.ipynb".
The first task is:
For more options, see the b.compute_pblums API docs.
Note that this same logic is applied (at t0) to initialize all passband luminosities within the backend, so there is no need to call compute_pblums before run_compute.
In order to access passband luminosities at times other than t0, you can add a mesh dataset and request the pblum_ext column to be exposed.  For stars that have pblum defined (as opposed to coupled to another star or dataset), this value should be equivalent to the value of the parameter (at t0 if no features or irradiation are present, and in simple circular cases will probably be equivalent at all times).
Let's create a mesh dataset at a few times and then access the synthetic luminosities.
Can you write Python code for it?

b.add_dataset('mesh', times=np.linspace(0,1,5), dataset='mesh01', columns=['areas', 'pblum_ext@lc01', 'ldint@lc01', 'ptfarea@lc01', 'abs_normal_intensities@lc01', 'normal_intensities@lc01'])

b.run_compute()


I am working on the file "2.3/tutorials/pblum.ipynb".
The first task is:
Here we see the pblum_mode@lc01 is set to 'component-coupled' meaning it will follow the rules described earlier where pblum is provided for the primary component and the secondary is coupled to that.  pblum_mode@lc02 is set to 'dataset-coupled' with pblum_dataset@lc01 pointing to 'lc01'.
Can you write Python code for it?

print(b.filter('pblum*'))

print(b.compute_pblums())

b.run_compute()

afig, mplfig = b.plot(show=True, legend=True)


I am working on the file "2.3/tutorials/pblum.ipynb".
The first task is:
However, if we change the temperature of the secondary star again, since the pblums are coupled, we'd expect the synthetic luminosity of the primary to remain fixed but the secondary to decrease.
Can you write Python code for it?

b['teff@secondary@component'] = 3000

print(b.compute_pblums(dataset='lc01'))

b.run_compute()

print(b.get_value(qualifier='pblum_ext', time=t0, component='primary', kind='mesh', context='model'))

print(b.get_value(qualifier='pblum_ext', time=t0, component='secondary', kind='mesh', context='model'))


I am working on the file "2.3/tutorials/pblum.ipynb".
The first task is:
If we now set pblum to be only 2 pi, we should expect the luminosities as well as entire light curve to be scaled in half.
Can you write Python code for it?

b.set_value('pblum', component='primary', value=2*np.pi)

print(b.compute_pblums())

b.run_compute()

afig, mplfig = b.plot(show=True)


I am working on the file "2.3/tutorials/pblum.ipynb".
The first task is:
In most cases you will not want decoupled luminosities as they can easily break the self-consistency of your model.
Now we'll just undo our changes before we look at accessing model luminosities.
Can you write Python code for it?

b.set_value_all('teff', 6000)
b.set_value_all('pblum', 4*np.pi)


I am working on the file "2.3/tutorials/pblum.ipynb".
The first task is:
In this case, since our two stars are identical, the synthetic luminosity of the secondary star should be the same as the primary (and the same as pblum@primary).
Can you write Python code for it?

print(b.get_value(qualifier='pblum_ext', time=t0, component='primary', kind='mesh', context='model'))

print(b.get_value(qualifier='pblum_ext', time=t0, component='secondary', kind='mesh', context='model'))


I am working on the file "2.3/tutorials/pblum.ipynb".
The first task is:
Lastly, just to make things a bit easier and faster, we'll turn off irradiation (reflection), use blackbody atmospheres, and disable limb-darkening (so that we can play with weird temperatures without having to worry about falling of the grids).
Can you write Python code for it?

b.set_value('irrad_method', 'none')
b.set_value_all('ld_mode', 'manual')
b.set_value_all('ld_func', 'linear')
b.set_value_all('ld_coeffs', [0.])
b.set_value_all('ld_mode_bol', 'manual')
b.set_value_all('ld_func_bol', 'linear')
b.set_value_all('ld_coeffs_bol', [0.])
b.set_value_all('atm', 'blackbody')


I am working on the file "2.3/tutorials/pblum.ipynb".
The first task is:
Let's see how changing the value of pblum affects the computed light curve.  By default, pblum is set to be 4 pi, giving a total flux for the primary star of ~1.
Since the secondary star in the default binary is identical to the primary star, we'd expect an out-of-eclipse flux of the binary to be ~2.
Can you write Python code for it?

b.run_compute()

afig, mplfig = b.plot(show=True)


I am working on the file "2.3/tutorials/pblum.ipynb".
The first task is:
NOTE: other parameters also affect flux-levels, including limb darkening, third light, boosting, irradiation, and distance
If we call b.compute_pblums, we'll see that the computed intrinsic luminosity of the primary star (pblum@primary@lc01) matches the value of the parameter above.
Can you write Python code for it?


I am working on the file "2.3/tutorials/pblum.ipynb".
The first task is:
Note that in general (for the case of a spherical star), a pblum of 4pi will result in an out-of-eclipse flux of ~1.
Now let's just reset to the default case where the primary star has a provided (default) pblum of 4pi.
Can you write Python code for it?

b.set_value('pblum_component', 'primary')
print(b.get_parameter(qualifier='pblum', component='primary'))


I am working on the file "2.3/tutorials/pblum.ipynb".
The first task is:
Now if we set pblum_mode to 'dataset-scaled', the resulting model will be scaled to best fit the data.  Note that in this mode we cannot access computed luminosities via b.compute_pblums (without providing model - we'll get back to that in a minute), nor can we access scaled intensities from the mesh.
Can you write Python code for it?

b.set_value('pblum_mode', 'dataset-scaled')

print(b.compute_pblums())

b.run_compute()

afig, mplfig = b.plot(show=True)


I am working on the file "2.3/tutorials/pblum.ipynb".
The first task is:
Now let's compare the value of the synthetic luminosities to those of the input pblum
Can you write Python code for it?

t0 = b.get_value('t0@system')

print(b.get_value(qualifier='pblum_ext', time=t0, component='primary', kind='mesh', context='model'))

print(b.get_value('pblum@primary@dataset'))

print(b.compute_pblums(component='primary', dataset='lc01'))


I am working on the file "2.3/tutorials/pblum.ipynb".
The first task is:
Now we see that both pblum parameters are available and can have different values.
Can you write Python code for it?


I am working on the file "2.3/tutorials/pblum.ipynb".
The first task is:
Role of Pblum
Let's now look at the intensities in the mesh to see how they're being scaled under-the-hood.  First we'll recompute our model with the equal temperatures and irradiation disabled (to ignore the difference between pblum and pblum_ext).
Can you write Python code for it?

b.run_compute()

areas = b.get_value(qualifier='areas', dataset='mesh01', time=t0, component='primary', unit='m^2')
ldint = b.get_value(qualifier='ldint', component='primary', time=t0)
ptfarea = b.get_value(qualifier='ptfarea', component='primary', time=t0)

abs_normal_intensities = b.get_value(qualifier='abs_normal_intensities', dataset='lc01', time=t0, component='primary')
normal_intensities = b.get_value(qualifier='normal_intensities', dataset='lc01', time=t0, component='primary')


I am working on the file "2.3/tutorials/pblum.ipynb".
The first task is:
Since the luminosities are passband-dependent, they are stored with the same dataset as the light curve (or RV), but with the mesh method, and are available at each of the times at which a mesh was stored.
Can you write Python code for it?


I am working on the file "2.3/tutorials/pblum.ipynb".
The first task is:
The values of 'normal_intensities', however, are significantly samller (in this case).  These are the intensities in relative units which will eventually be integrated to give us flux for a light curve.
Can you write Python code for it?


I am working on the file "2.3/tutorials/pblum.ipynb".
The first task is:
We can then access the scaled luminosities by passing the model tag to b.compute_pblums.  Keep in mind this only scales the absolute luminosities by flux_scale so assumes a fixed distance@system.  This is useful though if we wanted to use 'dataset-scaled' to get an estimate for pblum before changing to 'component-coupled' and optimizing or marginalizing over pblum.
Can you write Python code for it?


I am working on the file "2.3/tutorials/pblum.ipynb".
The first task is:
pblum_mode = 'absolute'
By setting pblum_mode to 'absolute', luminosities and fluxes will be returned in absolute units and not rescaled.  Note that third light and distance will still affect the resulting flux levels.
Can you write Python code for it?


I am working on the file "2.3/tutorials/pblum.ipynb".
The first task is:
pblum_mode = 'decoupled'
The luminosities are decoupled when pblums are provided for the individual components.  To accomplish this, set pblum_mode to 'decoupled'.
Can you write Python code for it?


I am working on the file "2.3/tutorials/pitch_yaw.ipynb".
The first task is:
And if we set the yaw to be non-zero, we'll see the rotation axis rotate on the plane of the sky.
Can you write Python code for it?

b['pitch@secondary@component'] = 0
b['yaw@secondary@component'] = 30

b.run_compute(irrad_method='none')

afig, mplfig = b.plot(time=0.0, fc='teffs', ec='none', x='us', y='vs', show=True)

afig, mplfig = b.plot(time=0.0, fc='teffs', ec='none', x='ws', y='vs', show=True)


I am working on the file "2.3/tutorials/pitch_yaw.ipynb".
The first task is:
As always, let's do imports and initialize a logger and a new Bundle.
Can you write Python code for it?

import phoebe
from phoebe import u # units
import numpy as np
import matplotlib.pyplot as plt

logger = phoebe.logger()

b = phoebe.default_binary()


I am working on the file "2.3/tutorials/pitch_yaw.ipynb".
The first task is:
Note also that the system is aligned by default, with the pitch and yaw both set to zero.
Misaligned Systems
To create a misaligned system, we must set at pitch and/or yaw to be non-zero.
But first let's create an aligned system for comparison.  In order to easily see the spin-axis, we'll plot the effective temperature and spin-up our star to exaggerate the effect.
Can you write Python code for it?

b['syncpar@secondary'] = 5.0

b['pitch@secondary'] = 0
b['yaw@secondary'] = 0

b.run_compute(irrad_method='none')


I am working on the file "2.3/tutorials/pitch_yaw.ipynb".
The first task is:
Relevant Parameters
The 'pitch' parameter defines the misalignment of a given star in the same direction as the inclination.  We can see how it is defined relative to the inclination by accessing the constraint.
Note that, by default, it is the inclination of the component that is constrained with the inclination of the orbit and the pitch as free parameters.
Can you write Python code for it?


I am working on the file "2.3/tutorials/pitch_yaw.ipynb".
The first task is:
We'll plot the mesh as it would be seen on the plane of the sky.
Can you write Python code for it?

afig, mplfig = b.plot(time=0.0, fc='teffs', ec='none', x='us', y='vs', show=True)