It was gratifying to watch the first systemic challenge unfold.

After a week of accepting fits, we tallied the entries and determined that Chris Thiessen had obtained to the lowest submitted chi-square. Way to go Chris! Eugenio then added the “challenge001” data set to the systemic backend, so that users can continue to improve and submit fits.

So what was the underlying synthetic planetary configuration that generated the data set?

Both Eugenio and I have had a long-running interest in the GJ 876, a 15-light year distant red dwarf star that is now known to harbor at least three planets. The two outer worlds in the system, which were discovered in 1998 and 2001, are in 2:1 resonance, and form the classic example of a configuration that demands a self-consistent (as opposed to Keplerian) model. Last year, Eugenio led the discovery and characterization of a third planet in the system, which has a mass only 7.5 times that of Earth, and orbits the star every 1.94 days. (Here’s a link to the NSF press release for Rivera et al. 2005.)

We’ve been looking into the possibility of detecting another planet in the system, and in order to do so, we’ve been studying synthetic data sets that contain the three known planets, as well as a fourth, potentially habitable planet in a potentially habitable orbit. The following table gives the parameters of our hoped-for system (which, like the real system, has its invariable plane inclined by 40 degrees with respect to the line of sight.)

The first 155 points in the challenge data set used the actual observing times given in Rivera et al 2005. The remaining 32 points were generated using the version of Eugenio’s Keck_TAC program that we use to produce the systemic synthetic data sets. We then subtracted off the the first epoch time from all 187 observing times and multiplied each of the resulting times by the golden section, 1.618033989. This gives a system that has the dynamical characteritics of the real GJ 876 system, but with orbital periods that are all 1.618 times longer.

After setting up the uploads page on the backend, Eugenio uploaded the best fit that he was able to obtain, which had a chi-square of 3.13. A lot of computation went in to getting this fit, which took several days on a fast desktop machine.

Amazingly, the next day, user Roseundy submitted an even better fit,

which brought the chi-square down to 2.82, with the following comment:

Arrrggghh!!!!!!!! I had this fit on Sep 13, but I thought the ChiSq was too high to bother to submit. Lesson learned.

Eugenio and I were quite excited. Systemic users have clearly gotten at least as good at fitting with the console as we are, and we have been thinking carefully about the problem for quite a while. In the comments section on Roseundy’s fit, Eugenio wrote:

Hi Roseundy, That is awesome work!! All the challenge systems will be based on some known model, possibly a random draw, some noise, and possibly other effects. The random draw and the noise complicate the situation for the modeler (me), so that knowledge of the model will not always result in the best fit. Actually, your result is a major success for the idea behind the systemic collaboration — distributing the process of fitting radial velocity data sets. Because I really don’t know precisely how the random draw and the noise affected the model, it may still be possible to get even lower chisq values. I encourage everyone to continue fitting this system (as well as others). It does require patience and perserverence.

Chris Thiessen wrote:

Roseundy, I’m very impressed. The two major planets have such different Keplerian and integrated fits that I was never able to get them to work well together. How did you get the two planet solution? I’m not sure I would have let the 48 day planet develop that much eccentricity if I’d seen a trend. Maybe I missed out that way. Great work!

Whereupon Roseundy revealed the secrets of his fitting method:

Once I saw how close the planets were, I realized I needed to work with integration turn on. This, of course, slowed things down painfully. To make progress, I cut down the dataset (the middle third of the velocity data) and played with that until I got a good (chi^2 of 7 or so) fit. I backed that out to the full data set (very painful) and then added additional planets based on the residuals. I polished until I got the fit you see. I’m sure it can be improved, but I lost patience with it. I would like to see three improvements to the console to make this easier in the future: 1. be able to subset the data 2. be able to select which planets are to be integrated together, using Keplerian calculations for the rest. this would help with systems where only a few planets substantially interact with each other 3. (my vote for the most important) a natively compiled console. java byte code may be portable, but I don’t it’s very optimized. Having optimized binaries (x86 on Linux preferably) would be a win, I think.

We agree. After the next release of the console, I think it would be a good idea to migrate to a strategy where the systemic community of users can work on the console code open-source style. This is clearly another area where a distributed attack will get important and interesting results.

In any event, thanks to everyone who has been reading the oklo blog and collaborating in the backend. We’ve had over 6,000 unique visitors so far this month, and the project is really starting to show promise.