Image Source.

In our development of the systemic console and the systemic backend, we’ve strived to build a professional-quality tool that can be used by the general public. There’s no better way to get a sense of them planetary discovery process than to participate yourself, and so we’d like to encourage astronomy instructors to fold the systemic console into their curricula.

This link points to a Word format document of a sample homework assignment that makes use of both the console and the systemic backend. We’ve had good success with this particular problem set at UCSC, and it’s currently being implemented at MIT as well. The level has been found to be appropriate to an astrobiology class for science majors. There’s no math prerequisite, so it can also be fully useful for a non-major survey course.

If you’re an astronomy instructor and you’d like to incorporate hands-on planet finding into your course, let me know, and we can set up a fit submission aggregator for your students on the systemic backend.

Image Source.

One reason why extrasolar planets are so exciting is because they are accessible. You don’t need a Ph.D. or a large laboratory or a space-borne telescope to make an important discovery. There are very few areas in science where such a wide pool of workers can contribute in a fully meaningful way.

On the systemic backend, the focus is largely on planet characterization through the analysis of radial velocity data. At Transitsearch.org, the goal is to provide the information that will allow small telescope observers to discover transiting planets. Transitsearch, however, is mainly a repository for transit predictions. We maintain information about when and where to look, but we fall short when it comes to explaining how to obtain high-precision photometry. There has long been a need for a good end-to-end manual on the art and science of photometric transit detection.

Bruce Gary is an experienced observer of transiting extrasolar planets, and is a member of the XO network, which has had made several discoveries over the past year and a half (see e.g. here). Bruce has written a book, Exoplanet Observing for Amateurs which he’s made available for free in .pdf form.

Bruce has also launched the Amateur Exoplanet Archive (AXA), which is a repository for light curves obtained for known transiting planets. If you get a photometric transit time series of one of the planets, then make sure that you submit it to Bruce’s archive. With all the data in one place, everyone will have easy access for analysis projects.

Transit midpoint times can be measured from individual light curves, and a sequence of midpoint times can be used to improve the characterization of a particular planetary system. To this end, Stefano has extend the .sys file format used by the systemic console to include “transits” data files (which take a .tds suffix, and which are separate from the .vels files that the console has used all along). If you have transit data, it’s simple to implement one of these files for yourself.

To see how it works, consider the recently discovered transiting planet XO-2. The published radial velocity data for this planet is already bundled with the console. On the AXA site, a total of five transits have already been archived for XO-2. Each of these transits has a measured Heliocentric Julian Date (HJD) for the time of transit midpoint, along with an associated uncertainty. I copied these data into a newly created “X0-2.tds” file in my console’s datafiles folder:

I then added the following lines to the .sys file for the XO-2 system:

Having done that, I launched the latest (“unstable” Aug. 21, 2007 version) of the systemic console. Stefano has been steadily improving the console’s algorithms, user interface, and performance. If you’ve been working with the standard stable downloadable console, you’ll immediately notice that there’s a lot of new functionality. We’ll be getting a manual out as soon as the much-anticipated Systemic Jr write-up is completed, but in the meantime, there’s a wide variety of resources on the backend that can help you navigate the latest console features.

With the .tds file linked in, the observed transit midpoint times appear as vertical red lines in the radial velocity timeline window. If the “fit transits” option is unchecked, then the console considers only the radial velocity data. If the “fit transits” option is checked, however, then the observed transit times are included as data to be fit. The uncertainties in the transit midpoints can be very small, and so this provides a very strong constraint on the period of the orbit and the time at which the planet crosses the plane containing the line of sight to the Earth. Note that the transit fitting can be done in a fully self-consistent N-body fashion if integration is enabled.

Try it for yourself!

As more transit data is accumulated, it will become possible to do some increasingly sophisticated analyses. Transit timing is potentially a very powerful method for detecting additional, as-yet unseen perturbing bodies in a given system. Objects like Gl 436 b are especially good candidates for this type of approach, and quite a bit of photometric data is being accumulated during the Gl 436 transits.

Image Source.

A big thank-you to everyone who’s been participating in the drive to characterize and study the catalog of synthetic “Systemic Jr.” planetary systems on the Systemic Backend. There’s now enough data to indicate that the analysis is going to be very informative. We’re looking forward to revealing the properties of the underlying planetary systems that were used to generate the data. In the meantime, we need your help to adequately characterize all 520 systems. Data in need of better characterization are marked by flags:

Our backend server is now swarming with various hard-working software robots that Stefano has assembled. The 100-year stability bot is rousted out of bed and set to work whenever a new fit is submitted. It reports a quick initial assessment of orbital stability. Planetary systems that pass through the 100-year stability screen are then put in a queue to wait for the attentions of the 1000-year stability bots. Systems that make it through 1000 years with less than a 1% change in semi-major axis of their planets are awarded a snazzy green flag:

Occasionally, systems that are in mean-motion resonance can show periodic semi-major axis variations of more than 1% while still remaining indefinitely stable. A resonance bot that will go through the fits and check for these special cases is currently being readied.

Systems that pass the minimum stability requirement are handed to a bootstrap bot which uses the bootstrap method to estimate uncertainties on the planetary orbital parameters for each stable fit. We’re currently running the bootstrap bot under the assumption that the orbits are pure Keplerian ellipses, and so the calculations are usually quite rapid. Very shortly, the error estimates for the parameters in submitted fits to the real systems and the Systemic Jr. systems will be showing up on the back-end data pages.

Finally, an “F-bot” has been activated which performs successive F-tests on submitted multiple-planet systems. Using its results, we’ll have a better idea of when the addition of a planet to a system is warranted.

Image Source.

Stefano and Eugenio have been making quite a bit of development progress on the downloadable systemic console. A new version of the console (available for beta testing on the systemic backend) is now capable of providing an estimate of the uncertainties on the orbital elements associated with a fit to a particular data set.

Radial velocity data don’t provide an exact determination of planetary orbits. The most obvious shortcoming is that Keplerian orbital fits can’t determine the inclination of the planetary orbits, and so for a given system, we’re only able to measure then mass of the planet multiplied by the sine of the unknown inclination angle. Furthermore, the stellar radial velocity signal created by a planetary system is corrupted by astrophysical noise introduced by the parent star, as well as by noise introduced during the measurement process here on Earth.

Determination of the true uncertainties in a planetary orbital model is a subtle problem (for more detail, see Eric Ford‘s recent work in this area). As a first straightforward step, we’ve implemented the so-called “bootstrap” method of error estimation into the console. The bootstrap works by taking the original data set, and then successively redrawing time + velocity + uncertainties triples from the data with replacement. This procedure creates alternate realizations of the original data set in which some of the original measurements appear more than once, and in which some don’t appear at all. The best-fit parameters obtained by the console are then used as a starting guess to fit the bootstraped data sets. The standard deviations measured from the distributions of orbital elements thus obtained give error estimates for the parameters of the original fit.

The bootstrap routine is menu-accessed, and is simple to use. First, create a fit to a dataset. In the example just below, I’ve fitted to the data for HD 80606:

Once the fit has been polished, the bootstrap can be run. In the default configuration it uses Keplerian fitting and does 100 trials.

HD 80606 has been observed for nearly 20 orbital periods, and velocities have been obtained at a wide variety of orbital phases. As a result, the orbit is very well constrained. The bootstrap indicates that the uncertainty on the e=0.932 eccentricity is only 0.003. For other systems, such as hd 20782, which also seems to have a high eccentricity:

the uncertainty on the parameters is much larger:

Give the routine a try! In upcoming posts, we’ll talk more about how uncertainty estimates will be incorporated into the planetary catalogs on the backend.