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.

The Conversation

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

A Barnes-Hut tree gravity benchmark

In one of my last posts (An interactive Barnes-Hut tree) I talked briefly about one of the “fun” projects I’m working on, When Giants Collide (work in progress, GitHub repo), and promised myself to blog about its development as I went along. I just finished refining the algorithm for building the tree and calculating the gravitational force.

The small app above is a benchmark pitting the Barnes-Hut algorithm for computing gravity (an O(N log(N)) algorithm) against a brute-force direct summation (an O(N^2) algorithm). It calculates the gravitational field of a random collection of particles using both methods for N = 256 to N = 16,384; a lower amount of time spent indicates a faster algorithm. The time used to compute the gravitational force is averaged over 12 iterations to minimize fluctuations. Results are plotted in real time.

Lastly, it calculates an overall “score” for the JavaScript interpreter by only running the Barnes-Hut algorithm for N = 16,384. You can see a table of scores for a few different browsers and devices I have access to (lower is better). If you’d like, send me your score!

Some observations about JavaScript optimization

Chrome turned out to be the fastest browser at this particular benchmark. Surprisingly, a previous version of the same code was actually the  slowest on my MacBook — almost 6x as slow as Safari! That was quite unexpected, as in my (limited) experience building web apps Chrome tends to edge out other browsers in terms of JavaScript execution speed.

So I waded a little bit more into my code to understand what was making my code so inefficient. This Google optimization guide and this post on HTML5Rocks (specifically talking about optimizing for V8, the just-in-time compiler embedded in Chrome) proved very useful. What I learned:

  1. Use the idiomatic JavaScript style for creating classes (using prototypes, new, straightforward constructors etc.) instead of using an object factory and closures.
  2. Avoid creating closures, when possible.
  3. Use node.js to profile the application and identify functions that are not getting optimized (using –trace-opt).
  4. Both Safari and Firefox had good baseline scores even before these optimizations. I found it quite surprising that V8 was much more fastidious about my code than the other JavaScript engines.

Another finding was how much slower alternative browsers (e.g. Chrome, Mercury) are on iOS. Alternative browsers use the same engine as Safari, but they don’t have access to Nitro’s Just-In-Time compilation — this means that they will be quite a bit slower than Safari on a computationally-intensive benchmark. How much slower? On my iPhone 5S, almost a factor of 10!

Web workers are awesome

The benchmark runs in a different thread, so that the page itself remains responsive. This is accomplished using Web Workers, a relatively new technology that allows the page to spin off threads to do computation-heavy work. It’s quite well supported, and I found it pretty easy to learn (aside from some surprising quirks). I plan on spinning off some of the tasks in Systemic Live — which currently either block the interface or use timers — into Web Workers (it’ll be a quite a bit of work, so don’t hold your breath).

An interactive Barnes-Hut tree

[TL,DR: if you’d like to play with a simple Barnes-Hut octree code, scroll down to the little embedded app.]

Gah! It’s been quite a while since my last post. Despite my best intentions, work (and a lot of feedback from Super Planet Crash!) has taken precedence over blogging. I do have a sizable list of interesting topics that I’ve been meaning to write about, however, so over the next few weeks I’ll try to keep to a more steady posting clip.

Super Planet Crash has been a resounding success. I have been absolutely, positively astounded with the great feedback I received. My colleagues and I have been coming up with lots of ideas for improving the educational value of SPC, add new, interesting physics, and addressing some of the complaints. In order to have the ability to dedicate more time to it, over the past few months, we’ve been furiously applying for educational and scientific grants to fund development. Hopefully something will work out — my goal is to make it into a complete suite of edu-tainment applications.

When Giants Collide

I’ve recently started experimenting with a new  visualization that I think will turn out pretty darn cool. Its draft name is When Giants Collide. When  Giants Collide will address a common request from planetary crashers: “Can I see what happens when two giant planets collide”?

A sketch of the interface.

When Giants Collide will be a super-simple JavaScript app (so it will run in your browser) that will simulate the collision of two massive spheres of gas. The simulation will have to model both gravity and the dynamics of the gas: to address this, I’ve been dusting off and reviewing an old Smoothed-Particle Hydrodynamics (SPH) code I worked on for a brief period in graduate school. SPH is a very simple technique for cheaply simulating gas flows with good spatial accuracy, and is somewhat straightforward to code. There are some shortcuts that have to be taken, too — large time steps, low particle counts, and more (e.g., a polytropic equation of state for the gas giants; more on this in future posts). These shortcuts come at the expense of realism, but will enable fast, smooth animation in the browser.

Gravity with the  Barnes-Hut algorithm

Gravity is an essential ingredient of When Giants Collide! Even with very low particle counts (say, N = 1000), a brute force calculation that just sums up the mutual gravitational force between particles won’t do if you want to run the simulation at 60 frames per second. Direct summing is an N^2 operation:

(this is a simple force accumulator written in R).

A better way that involves only a slightly more complicated algorithm is to use the Barnes-Hut algorithm (a short Nature paper with more than 1,000 citations!). The algorithm involves recursively subdividing space into cubes and loading them with particles, such that every cube contains either 0 or 1 particles. This is represented in code with an oct-tree structure.  Once such a tree is constructed, one can calculate the gravitational force on a given particle in the brute-force way for close particles, and in an approximate way for distant particles; whether to use one or the other is determined by walking the tree down from the top. An excellent explanation (with great visuals!) is provided in this article.

The other advantage is that, once the tree has been already built for the gravity calculation, it can be used to identify the nearest neighbors of a given particle through the same tree-walking procedure. The nearest neighbors are needed for the hydrodynamical part of the SPH algorithm (see, e.g., this review article by Stefan Rosswog or this one by Daniel Price).

An interactive tree

Below is an interactive JavaScript applet that subdivides space with the Barnes-Hut algorithm. You can add new points by clicking on the surface, or using the buttons to add new, random ones.

The code for building the Barnes-Hut tree from an array of 3D positions is available at the GitHub repository for When Giants Collide. I will be developing the code in the open, and post periodically about my progress. Hopefully by the end of summer I will have an attractive app running on any modern device and web browser. Any ideas on how to gamify it?

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.