## Rarity of Jupiter-like planets means planetary systems exactly like ours may be scarce

Is our little corner of the galaxy a special place? As of this date, we’ve discovered more than 1,500 exoplanets: planets orbiting stars other than our sun. Thousands more will be added to the list in the coming years as we confirm planetary candidates by alternative, independent methods.

In the hunt for other planets, we’re especially interested in those that might potentially host life. So we focus our modern exoplanet surveys on planets that might be similar to Earth: low-mass, rocky and with just the right temperature to allow for liquid water. But what about the other planets in the solar system? The Copernican principle – the idea that the Earth and the solar system are not unique or special in the universe – suggests the architecture of our planetary system should be common. But it doesn’t seem to be.

A mass-period diagram. Each dot marks the mass and orbital period of a confirmed exoplanet.
Stefano Meschiari

The figure above, called a mass-period diagram, provides a visual way to compare the planets of our solar system with those we’ve spotted farther away. It charts the orbital periods (the time it takes for a planet to make one trip around its central star) and the masses of the planets discovered so far, compared with the properties of solar system planets.

Planets like Earth, Jupiter, Saturn and Uranus occupy “empty” parts of the diagram – we haven’t found other planets with similar masses and orbits so far. At face value, this would indicate that the majority of planetary systems do not resemble our own solar system.

The solar system lacks close-in planets (planets with orbital periods between a few and a few tens of days) and super-Earths (a class of planets with masses a few times the mass of the Earth often detected in other planetary systems). On the other hand, it does feature several long-period gaseous planets with very nearly circular orbits (Jupiter, Saturn, Uranus and Neptune).

Part of this difference is due to selection effects: close-in, massive planets are easier to discover than far-out, low-mass planets. In light of this discovery bias, astronomers Rebecca Martin and Mario Livio convincingly argue that our solar system is actually more typical than it seems at first glance.

There is a sticking point, however: Jupiter still stands out. It’s an outlier based both on its orbital location (with a corresponding period of about 12 years) and its very-close-to-circular orbit. Understanding whether Jupiter’s relative uniqueness is a real feature, or another product of selection effects, has real implications for our understanding of exoplanets.

Jupiter as seen by the Hubble Space Telescope.

## Throwing its weight around

According to our understanding of how our solar system formed, Jupiter shaped much of the other planets’ early history. Due to its gravity, it influenced the formation of Mars and Saturn. It potentially facilitated the development of life by shielding Earth from cosmic collisions that would have delayed or extinguished it, and by funneling water-rich bodies towards it. And its gravity likely swept the inner solar system of solid debris. Thanks to this clearing action, Jupiter might have prevented the formation of super-Earth planets with massive atmospheres, thereby ensuring that the inner solar system is populated with small, rocky planets with thin atmospheres.

Without Jupiter, it looks unlikely that we’d be here. As a consequence, figuring out if Jupiter is a relatively common type of planet might be crucial to understanding whether terrestrial planets with a similar formation environment as Earth are abundant in the galaxy.

Despite their relative heft, it’s a challenge to discover Jupiter analogs – those planets with periods and masses similar to Jupiter’s. Astronomers typically discover them using an indirect detection technique called the Doppler radial velocity method. The gravitational pull of the planet causes tiny shifts in the wavelength of features in the spectrum of the star, in a distinctive, periodic pattern. We can detect these shifts by periodically capturing the star’s light with a telescope and turning it into a spectrum with a spectrograph. This periodic signal, based on a planet’s long orbital period, can require monitoring a star over many years, even decades.

# Are Jupiter-like planets rare?

In a recent paper, Dominick Rowan, a high school senior from New York, and his coauthors (including astronomers from the University of Texas, the University of California at Santa Cruz and me) analyzed the Doppler data for more than 1,100 stars. Each star was observed with the Keck Observatory telescope in Hawaii; many of them had been monitored for a decade or more. To analyze the data, he used the open-source statistical environment R together with a freely available application that I developed, called Systemic. Many universities use an online version to teach how to analyze astronomical data.

Our team studied the available data for each star and calculated the probability that a Jupiter-like planet could have been missed – either because not enough data are available, or because the data are not of high enough quality. To do this, we simulated hundreds of millions of possible scenarios. Each was created with a computer algorithm and represents a set of alternative possible observations. This procedure makes it possible to infer how many Jupiter analogs (both discovered and undiscovered) orbited the sample of 1,100 stars.

Orbit of the newly discovered Jupiter-mass planet orbiting the star HD 32963, compared to the orbits of Earth and Jupiter around the sun.
Stefano Meschiari, CC BY-ND

While carrying out this analysis, we discovered a new Jupiter-like planet orbiting HD 32963, which is a star very similar to the sun in terms of age and physical properties. To make this discovery, we analyzed each star with an automated algorithm that tried to uncover periodic signals potentially associated with the presence of a planet.

We pinpointed the frequency of Jupiter analogs across the survey at approximately 3%. This result is broadly consistent with previous estimates, which were based on a smaller set of stars or a different discovery technique. It greatly strengthens earlier predictions because we took decades of observations into account in the simulations.

This result has several consequences. First, the relative rarity of Jupiter-like planets indicates that true solar system analogs should themselves be rare. By extension, given the important role that Jupiter played at all stages of the formation of the solar system, Earth-like habitable planets with similar formation history to our solar system will be rare.

Finally, it also underscores that Jupiter-like planets do not form as readily around stars as other types of planets do. It could be because not enough solid material is available, or because these gas giants migrate closer to the central stars very efficiently. Recent planet-formation simulations tentatively bear out the latter explanation.

Long-running, ongoing surveys will continue to help us understand the architecture of the outer regions of planetary systems. Programs including the Keck planet search and the McDonald Planet Search have been accumulating data for decades. Discovering ice giants similar to Uranus and Neptune will be even tougher than tracking down these Jupiter analogs. Because of their long orbital periods (84 and 164 years) and the very small Doppler shifts they induce on their central stars (tens of times smaller than a Jupiter-like planet), the detection of Uranus and Neptune analogs lies far in the future.

This article was originally published on The Conversation. Read the original article.

## latex2exp 0.3.1 is now on CRAN!

latex2exp, my package for using LaTeX in R graphics, is now available on CRAN. You can install the latest released version from CRAN with

install.packages('latex2exp')

## What is the average time between papers published in the astronomy community?

I’ve been interested for a while in mining ADS (NASA’s Astrophysics Data System, an online repository of bibliographic records). Using the ADS developer API, it is quite simple to download bibliographical records as JSON data and do some analysis on a sample of astronomical publications.

The full, detailed analysis (with some caveats) is available here. The main plot derived from the reduced dataset  tracks the number of months between successive first-author papers (i.e. between the first and the second, the second and the third, etc.) to test the hypothesis that the rate of publishing papers increases as the author becomes more experienced and entrenched.

On average, the lag between first-author papers decreases steadily from approximately a year and a half (18 months) between the first and the second paper, flattening to approximately 7-8 months by the tenth paper published.

## LaTeX2Exp — transform LaTeX strings into R expressions

latex2exp is a new R package that parses and converts LaTeX math formulas into R’s plotmath expressions. Plotmath expressions are used to enter mathematical formulas and symbols to be rendered as text, axis labels, etc. throughout R’s plotting system. I find plotmath expressions to be quite opaque and fiddly; LaTeX is a de-facto standard for mathematical expressions, so this package might be useful to others as well. You can check it out on GitHub.

## “Supported” LaTeX

Only a subset of LaTeX is supported, and not 100% correctly. Greek symbols (\alpha, \beta, etc.) and the usual operators (+, -, etc.) are supported. Additionally, the following symbols and operators should be supported:

## Link: The Sound Of Mandelbrot Set

The Ripples blog  published a very nice post about “sonifying” the Mandelbrot set. The resulting sound files (linked in the post) are quite interesting, especially the “SlowDivergence” soundbite. The post also tipped me off about  playitbyr, an R package that converts a data.frame (a table of values) into an auditory graph. The soundbites demoed on the webpage are really cool — you should check them out!

The “classic” version of Systemic (v1, Java) has a feature for sonifying the orbital dynamics of exoplanets, originally written by Aaron Wolf (now a Turner Postdoctoral Fellow at the University of Michigan).

Non-interacting planets only generate pure sine-wave tones — not very interesting. It gets much more exciting once you introduce planetary interactions. Resonant and unstable systems, in particular, generate much more delicate or dramatic samples. Oklo.org has a few posts about the sonification feature, with downloadable soundbites.

I have not been a very good steward of this feature — it didn’t make it into Systemic2 (or the web app) since I didn’t want to work on migrating the Java code.  The existence of playitbyr, though, means I do not have to reinvent the wheel, definitely reigniting my interest in implementing this feature!

[Via R-bloggers.]

## Systemic 2 Cookbook: Markov-Chain Monte Carlo

This post is the second in the “Systemic Cookbook” series, which will show how to use Systemic 2 for scientific purposes (especially its more advanced features not readily accessible from its user interface). More comprehensive documentation for Systemic is forthcoming.

All posts in this series will be collected in the “Systemic 2″ category.

I wrote a short draft guide to doing Markov-Chain Monte Carlo-type of fitting and error analysis with Systemic2. This guide covers the very basics of the algorithm, the input parameters, and a step-by-step guide on how to drive the algorithm from the user interface, or from the C library. Please note that more sophisticated MCMC algorithms are available as R packages on CRAN.

## Link: Why I’m betting on Julia

Evan Miller: Why I’m betting on Julia

Julia looks to me like a very promising programming language.  Its main appeal is bringing C-like speed to a high-level, well-designed language that is tailored to scientific computation. From the article:

I hesitate to make the comparison, but it’s poised to do for technical computing what Node.js is doing for web development — getting disparate groups of programmers to code in the same language. […]

If you work in a technical group that’s in charge of a dizzying mix of Python, C, C++, Fortran, and R code — or if you’re just a performance-obsessed gunslinging cowboy shoot-from-the-hip Lone Ranger like me — I encourage you to download Julia and take it for a spin.

The “dizzying mix” is very much how I would describe a lot of the code I use and write on a daily basis.  R is too slow for intensive computations, so I drop down to C to write most of my algorithms and then wrap the C code in a higher-level R interface (via FFI); a similar state of affairs exists for Python. Getting communication right between the two worlds (the low-level C and the high-level language) can be daunting, and frankly, the mental context switch is exhausting. (Let’s not even bring Fortran into the discussion.)

I really hope Julia will succeed. What it needs right now is a first-class plotting facility and a bit more widespread adoption, but once that is achieved, I think that Julia will be a serious contender for mindshare.

## Systemic 2 Cookbook: Parallel computation with R

This post is the first in the “Systemic Cookbook” series, which will show how to use Systemic 2 for scientific purposes (especially its more advanced features not readily accessible from its user interface). More comprehensive documentation for Systemic is forthcoming.

All posts in this series will be collected in the “Systemic 2” category.

Systemic 2 automatically parallelizes so-called “embarrassingly parallelizable” workloads that do not need shared data or synchronization. Such workloads include bootstrap resampling and periodograms (each resampled data set is analyzed independently), Markov Chain Monte Carlo (each chain runs in parallel, and only synchronizes at infrequent intervals), jackknife, and other algorithms. Some algorithms can even be launched on Xgrid-connected clusters (Why, Apple?!).

The majority of embarrassingly parallelizable workloads, however, will be better defined by the user. In the rest of this article, I will show how to easily parallelize dynamical integration over a grid using an R script. (The following problem could be just as easily set up using C, but I will be showing how to accomplish it in R since the code will be most transparent in a high-level language.)

# Setting up dynamical integration over a grid

The (somewhat artificial) problem is as follows. Imagine that we would like to investigate the survival time of a two-planet system, as we increase the eccentricity of the outer planet. Intuitively, we expect the system to become unstable faster as the eccentricity increases.

Let’s first set up a sample system and integrate it forward in time with Systemic2.

To run this script, type

Rscript scriptname.r

from the shell (edit the script beforehand to point it to the correct path to Systemic).

This script sets up a two-planet system around a 0.95 solar mass star, integrate it forward 50,000 years using the SWIFT backend and plot it to a PDF file. The “k” object is called a kernel within Systemic; it contains all the data and functions associated with the planetary system (internally, it is a handle returned by the C library). Next, we create a grid of eccentricity and longitude of periastron angles. The rationale here is to average the survival times for each eccentricity, over the longitude of pericenter in order to remove the dependency on the phase angle (again, this is an artificial exercise!).

This part of the script involve some idiomatic R functions (not too dissimilar from the strategies used by Matlab, Numpy and other vectorized languages). To create a grid of eccentricity/phase angles (a cartesian product), I used the expand.grid function. Subsequently, I loop over the (e, lop) pairs using mapply. Mapply (m-apply) applies a function over each element of the two vectors and collects the return values of the function.

The function called by mapply sets up a kernel with the given eccentricity and longitude angle, and integrates the system forward in time using kintegrate. Kintegrate is the Systemic function that integrates a system forward in time,  returning an object containing information about the dynamical evolution of the system. One of the fields of the object is “survival.time”, how long the system survives (in this case, whether there is a close encounter or an ejection of one of the bodies).  Then, we collect the survival times, group them by eccentricity (using split) and take the median (using sapply).  Finally, we plot the eccentricity vs. the survival time.

# Parallelizing the problem

Recent R builds include the parallel package. The parallel package includes various implementations of apply (map) functions that are drop-in replacements for the builtin R functions (e.g. the *apply family of functions). Parallelization is achieved by transparently launching a number of “worker” processes, executing the function on each worker and finally collecting the result (the workers are heavyweight processes rather than threads, so you will see several R processes if you inspect your running programs).

Here is the revised script:

Note that the only change was using the “mcmapply” (multicore-mapply) function instead of the “mapply” builtin! Since this problem is eminently parallelizable, the speedup is linear in the number of physical cores.

# Closing words

In this case, parallelization was trivial; in other cases, it might be more involved (for instance, when balancing is required).