Posts Tagged‘planets’

Sunset on Gliese667Cf

Gliese 667C Has a Trio of Potentially Habitable Super Earths.

The idea of planets orbiting other stars doesn’t seem like a particularly novel idea today but it’s only recently that we’ve been able to definitively prove that there are planets outside our own solar system. Whilst there was the beginnings of evidence surfacing back in 1988 the first, definitive proof we had of an extrasolar planet came in 1992, a mere 2 decades ago. As our technology has increased in capability the number of planets we discover year by year has increased dramatically and, even cooler still, the different types of planets we’re discovering is also increasing. Heck we’ve even found planets that don’t have a parent star, something which was almost a fantasy as they were thought to be nearly impossible to detect.

What the last decade has revealed is that planets are not only a common occurrence in the universe but systems like are own, ones with multiple planets in them, are also commonplace. Initially most of the exoplanet discoveries were limited to certain types of planets, namely large gas giants with short orbital periods, but as our technology has improved we’ve been able to discover smaller bodies that orbit further out. Depending on the size of the star and the planet they could end up in what we refer to as the habitable (or Goldilocks) zone, the area where liquid water could exist on the surface. Finding one of these is cause for celebration as that closely matches our own solar system so you can imagine the excitement when we found 3 potentials orbiting Gliese 667C.

Gliese 667C Habitable Zone

Gliese 667C is actually part of a ternary star system which means that each of these planets technically has 3 suns, although the other 2 appear to more like bright stars that have the same illumination capacity as the full moon does here on earth. The diagram above makes it look like there’s potentially 5 planets in the habitable zone (just barely for H and D) but those ones are far more likely to be closer to Venus and Mars respectively. C, F, and E on the other hand are what we call super earths, rocky planets that have a mass around 2 to 10 times that of earth. Typically they’re also quite a bit larger than earth as well which means that the gravity on these kinds of planets is actually quite comparable. Out of all of them Gliese667Cf is the best candidate for habitability and thus extraterrestrial life.

What’s particularly exciting for me is this provides more evidence for the idea that other stars are typically swamped in planets, making the configuration of our solar system quite common. This adds fuel to the already intense discussion that surrounds the Drake Equation which I’d argue has now been tipped towards increasing the left hand side dramatically. Of course you can’t consider that equation without also considering the Fermi Paradox since, as far as we can tell, we’re still all alone out here. The only solution is for us to visit these planets and to see if there is anything there although doing so in an acceptable time frame is still beyond the current limits of our technical ability (but not our theoretical capacity, however).

Sunset on Gliese667Cf

It’s really quite amusing to see the stuff of science fiction rapidly turn into science fact. As time goes on it seems that the wildest things we could dream of, like planets with multiple suns, are not only real but may not be that unusual either. Hell it’s almost an inevitability that we’ll one day go to places like this just because it’s there. It might not be this century or heck even this millenium but we’ve shown in the past that we’re a stubborn race when it comes to things like this and we’ll be damned if anything will stop us from achieving it. I can only hope medical science advances enough for me to be able to see that and, hopefully, experience such planets for myself.

 

 

The Quest For Simplicity (or Who Pays For Rework).

I can remember sitting in one of my university lectures a long time ago being taught about development philosophies. It was all pretty standard stuff, we were walked through the “traditional” methods of development (basically the once through, waterfall technique) and then brought up to speed on the more modern iterative approaches. However one little soundbite always stuck out in my head and that was when the lecturer asked us who pays for rework when a product doesn’t fit a customer’s expectations? The simple answer was you, the one who developed it and it’s something that always plays over in my head when I’m working on a project, especially those ones I do at home.

I’ve been paying extensively for rework with my latest forays into the world of game development. My regular readers and Twitter followers would’ve noticed that I cheerfully announced my success in cracking the stable orbit problem. Indeed in a round about way I had, basically my Unity scripts would push the planet around until it hit a stable orbit and afterwards would calculate the required velocity before turning off completely, letting the heavenly body orbit in a near perfect circle around its star. This worked for the 2 planets I had in there but unfortunately the equations I had developed didn’t generalize very well and adding in planets at random locations with random weights led to all sorts of wobbly orbits with planets meeting both fiery deaths and cold extinctions at the cruel hand of my orbit stabilizer. I was back to square one and I spent most of the weekend trying to figure out a fix.

Eventually I came back around to the idea that my smart-ass subconscious came up with a while ago. I had tried to implement it before but I gave up in frustration when the results I got were no different than from my far more complicated “find the angle between the sun and body, increment it a bit, find the new position, create a vector to it then apply force in that direction” when in reality the fault lied in the orbit stabilization code. All that pushing and pulling that made the orbit look stable was in fact imparting all sorts of wild forces on the poor little planet, when in fact the best way is just to simply let gravity do the work for you. With this in mind I re-implemented my perpendicular force calculations and then devised a rudimentary equation that combined the mass, radius and a fudge factor that let me hand stabilize the orbit. In the past attempting to do this stuff manually took me an hour or so per planet, with this revised code I was able to do one in minutes and have developed a new equation that is able to accurately send a planet into a stable orbit no matter where I place it in the game.

This solution was far more simple and elegant than what I had been trying to do previously but the cost in terms of rework was tremendously high. I’m lucky in this respect in that the client for this is just myself and my friend at the moment but had this been for someone else with whom I had a contractual relationship with that kind of rework would’ve been extremely costly. Of course I could try to make the client pay for it but ask anyone who’s gone back to a client asking for more money after saying they could do it for a certain price and you’ll usually be laughed out of the office, if not walked out of there by security.

Working around this isn’t easy as clients will usually want to have a strict set of deliverables and time frames which seems to rule out any iterative or agile development methodology. It also pushes a team dangerously towards suffering from analysis paralysis as you agonize over every requirement to make sure it’s covered off in the final product. A healthy amount of analysis is good for any project, especially if it makes the product easy to maintain or modify, but it’s also incredibly easy to fall into a never ending spiral of pointlessness. Thankfully however I’ve noticed that clients are far more receptive to the idea of milestones these days which lines up well with any iterative process, skirting around these problems easily.

Going after the most simple and elegant solution might seem like the best idea at the time but in my experience it’s those kinds of solutions that take the longest to achieve. It’s almost always worth it, especially if all you’re spending is your own time, but when you’re working for someone else they might not be so keen for you to spend inordinate amounts of time chasing your white whale solution. This probably explains why a lot of software contains incomprehensible code riddled with bugs, but that’s a whole ‘nother ball game and a blog post for another day.