Hi, I've been trying to set up a stable stellar system for my fictional world to inhabit, and the simulator is excellent and a lot of fun. I appreciate the existence of this forum and I have a few questions:

I had the thought that it would be cool to have a planet in the middle of the habitable zone (the 'main planet'), with one at the outer edge and one at the inner edge (in reality this would be halfway through the MS lifetime of the star, but presumably we would assume that this is when the simulation starts). It seemed a pretty implausible scenario from the little I know about orbital mechanics, but for almost 100,000 years the three planets orbited discretely. Every time, though, they end up crossing orbits eventually. For the reason I explain below, I end up having to put all of the planets exactly in the ecliptic each time. Does this increase the chance that they will perturb one another? Also, I have not been setting the eccentricity at zero, since I thought it would be unrealistic to have perfectly circular orbits.

Ignoring the rest of the system for now, the three planets intended (optimistically) to inhabit the HZ were:

These were all in the ecliptic, although my random values for their obliquity ('inspired' by our Solar System) should have been 5.75, 7.77 and 6.19 degrees respectively. Obviously I will keep changing these values if need be until I find something that works.

The star is 1.1654141576188 solar masses and 1,531,253,667 metres in diameter.

I wondered if it was possible that other planets at the right distances inside and out might help to stabilise this configuration? My gut feeling is that they're just too close for comfort, though...

During the long, stable period, each 'edge' planet comes to almost exactly 20 million km of the middle one at its closest.

I have a problem in that when I set the planets to orbit around their barycentre with the sun, they inevitably fly off into space. I can resolve this by clearing the position and velocity boxes and setting the length of the SMA as the X coordinate in metres and the mean orbital velocity in the Y box in m/s. The problem with that is that in doing that, I must be killing the obliquity of the orbit and resetting it to the ecliptic. My maths knowledge is poor, and I'm struggling with certain aspects of the orbital mechanics. There's no way I can work out the relative positions for X, Y and X to give the correct length of SMA at a particular inclination, let alone the correct velocity component required for each direction.

Tony, since I notice that you are continually updating and improving the software, I was going to ask if it would be possible to add an input field for velocity in the Create Object box at some point in the future? It would also be great if it was possible to edit eccentricity & inclination in the Edit Object box, and another cool addition might be to add an 'orbital period' field to the Orbital Elements box. I don't know if these things are possible, though.

My other questions were, what is the fastest timestep that you would recommend using with the latest beta version, and should I set the Update Graphics Interval as high as possible? What is the function of the DoEvents interval?

Oh, and I'd be grateful if someone could point me in the direction of an explanation of rotating frames, I can't figure it out. I'm not even sure what the time unit used is. I see that they seem to be useful in determining resonances, though. I tried to induce a couple of resonances - 2:1 between the outermost planet and the next one in, and 4:1 between two of the smaller planets close to the star. I did this by deciding their orbital periods first and deriving their distances and velocities from that, and then starting them in the same position. Does this work? If so, they were both unstable...I just don't know.

At first glance , as I see your initial conditions and separation between the planets I think your system should be stable on the long term . The distance between each planet is about 20Mio km and the eccentricity is small . Adding more planets should be possible . A feature which can influence the stability slightly is the argument of perifocus and the longitude of the ascending node as both have an influence on the MOID (Minimum Orbit Intersection distance ) .

Ah, well, thanks for the feedback. So I should definitely be inclining my orbits. Although I still have the problem of having to enter the velocities, unfortunately, since I don't know how to calculate them in three dimensions.

I have a 3.8 jupiter-mass beast at about 1 billion km which stays stable for as long as I've run the sim, although it seems to like to migrate in just a little, to 800 Mil. There's a 2.5 J giant which starts at about 1.8 billion km and comes in a little to about 1.5 (IIRC). The outer two giants have problems, though. There's a 0.4 J 'Saturn' at 3.5 billion km (approx.) and a 0.075 J 'Neptune' at 5.5 billion. One or the other, usually the Neptune, ends up with eccentricity increasing until it ends up being thrown out the system. This still happens with the 2:1 resonance I tried to instigate.

The three (four since one is a double planet) planets interior to the HZ have a similar problem currently, in that they appear unstable on a timescale of 100 Ma.

There are 2 reasons you could be losing your planets. One is that they are ejecting each other, and the other is that you're using too high of a time step. For the simulation you describe, I'd say 16384 should be good.

Don't worry about the "DoEvents" unless your simulation has more than 50 objects. It just tells the program how often to return control to the interfaces, so the program doesn't appear frozen when you try to press buttons such as the menus or the pause button. But for fewer than 50 objects, the default value should be fine. For greater than 50, you'll want to lower the number.

The Graphics Updates doesn't need to be as high as possible. Beyond 500 there's little performance to be gained. Try 100. That should be fine for this simulation.

You're not the only person to want to edit orbital elements. But since editing an object isn't any different than deleting and recreating it, I haven't added this feature yet. Someday I would like to combine the two interfaces.

One problem with trying to determine stability using a simulation is that if your system stays stable for 100,000 years, that's no guarantee that it will remain stable for 110,000 years. But there are a few tricks that help you determine stability. I'll outline 2 methods.

The 1% method: As your planets orbit the star, they will perturb each other. If any planet's semi-major axis varies by more than 1% over the course of a few hundred years, it is likely not stable. You can graph your output by using menu File > Output file, and choose your planets, and semi-major axis, and output data once every year for 1000 years. Also, check the enable boxes at the top of the Output File interface. This will create a file with the same name and in the same directory as your simulation (.gsim) file, however, the extension will be .txt rather than .gsim. Open this file in Excel as a comma-delimited text file and graph your semi-major axes columns. This will help you determine if their semi-major axes varied by more than 1%.

Formulas method: On this page: http://orbitsimulator.com/formulas are two formulas: interior reach and exterior reach. Plugging in the values for your planet 2 into the interior reach calculator: 199015029488 m for aG, 0.000523 for eG, 3 for n_int, 1.200213009 M_Earth for mG, and 1 M_Sun for Mstar gives me an answer of 192563559270 meters. So any object orbiting the Sun up to 19256... meters should be stable as far as Planet 2 is concerned. Your planet 1 orbits interior to this value, so it should be stable. Use this and the exterior reach calculator to get a rough idea of stability. But I'm not sure what value you use for your star's mass. Perhaps it is greater than our Sun, since your habitable zone seems to be further out.

There's also a semi-major calculator on that page, so if you want to determine the semi-major axes for certain periods so you can set up resonances, you can use this calculator.

I've copied the formulae for interior and exterior reach into my spreadsheet so that it will calculate those for me for any given SMA and eccentricity. Should I always use the multiplier 3? The results look plausible, anyway, and it seems like there's no reason any of my planets should eject each other, going by this.

Oh, my sun is 1.1654141576188 solar masses and 1,531,253,667 metres in diameter, btw. The results come out very similar to those for our Sun. I wanted as big a star as I could get for my world, since I'm fascinated by high mass stars, but really, this is as big as I felt comfortable with, since the lifespan is a big issue for bioevolution. My ultimate goal would be to see a system that remains stable on the order of 1 Ga., since this would give me some confidence that it might last 3.5 Ga. (the approximate age of my system at the time of the stories).

I'm going to run the sim again and get it to graph the changes in SMA as you described. Perhaps the problem is that a few of the planets are exceeding the 1%. If so, should I reduce the eccentricity even further? That's the only way I can think of to reduce the variability of the SMA over time...

I have been using 16384 as the fastest timestep, so I'm thinking these predictions of long term instability must be pretty accurate...

Hmm, I am having a bit of trouble with the orbital period calculator, and I can't figure out what I'm doing wrong. I enter the distance for Planet 2 as 199,015,029,488 metres (without the commas), and the mass as 7.1703E+24 kg, and I get the result 808.13 years!! By contrast, the figure I get when I take the square root of the cube of the semimajor axis in AU is ~1.5344 years, which seems more reasonable. Am I missing something?

Anyway, cheers for your help. I'm going to play a bit with the rotating frame function and see what happens.

[edit] I've plotted the variation in SMA over 11,500 years, taking a measurement every 1000 years, and here are the results:

I've reduced the eccentricity of the offending planets a bit, and used what I think are more accurate velocities, since they were derived using the mass of the star, gravitational constant and SMA rather than just the semimajor and minor axes and the orbital period. The system looks more stable than before, to me, but I'm getting some weird results when I output the changes in SMA through time into Excel.

There are timesteps there that are outwith the range of the time that had elapsed in this run-through, and there's an abrupt change in values for every planet between 11,000 and 12,000 years.

I guess I should just leave it running and see what happens...?

And regarding the rotating frame...when I get the time period right, the object I've selected forms a little circle going round and round in the same place, and I get some pretty patterns. Is there a discussion here you could point me to that outlines the significance of certain patterns?

The system is looking quite stable now. The four giants are immovable, I can stick the timestep as high as years and they still stay in their orbits as millions of years pass. The three HZ planets do very well, too, I'm not getting the crossing orbits problem until I increase the time scale way beyond 16384.

I've been putting the moons in, and I have some trouble getting the innermost moons of the giants to stay where they should be at the 16384 timestep. I've played around with them a bit, but most of the time they fly off whenever I try to go this fast. I was thinking that perhaps when dealing with objects with higher orbital speeds (esp. around other planets), I should run the simulation slower?

Notably, the only planet in the system which still shows an unsettling variability in its SMA is the innermost, which is only 6 mil. km from the star. I guess this is related to its speed.

I'm greedy for speed, since I would like to simulate as long a time span as possible. Should I expect these moons to be stable at 16384? (In other words, is it worth my while continuing to fiddle about with them trying to get them to stay in orbit at this timestep, or do other people have the same issue with this type of satellite?)

I've been having a similar problem when I try to put two very small moons around the outermost terrestrial planet. The moons of the three habitable planets are all comfortable at 16384, though.

Your guess is correct. The faster orbits don't do as well at the higher time steps. Consider for a moment what the program is doing. In real life, the orbits are circular (or elliptical). In the simulation, the program approximates a circle or ellipse with many straight lines. For example, you can think of a stop sign as a circle approximated by 8 lines. The more lines you use, the closer you get to a true circle. A slow time step gives you more lines. So at a time step of 16K, it may take Earth 2000 steps to go around the Sun. That's pretty good. If someone drew a 2000-sided polygon, I doubt you could tell it from a circle. But at a time step of 16K, Earth's moon takes only 150 steps to go around the Earth. That's not quite as accurate, and a faster time step will cause unrealistic changes to the Moon's orbit.

Hmm, well I'm relieved. Actually, this means that I should probably go back and put my innermost moons (the ones around the giants) closer in again. I've been reading many of the other threads here, and I have deduced that for running this particular sim with a good degree of accuracy, perhaps I should reduce the timestep as low as 1024 seconds?

I'll just have to keep running the same sim every night when I go to bed. Although if something ends up getting chucked out after two weeks, I'll probably cry.

Given the errors that accumulate at higher speeds, I'm even more surprised at the stability of the system in general, though. The Earth-type planets hold on to their moons no matter what (until we get ridiculous). The middle one has two moons. I get some gnarly images when I look at those in the rotating frame...

Now that I'm happy with the moons, I have to try and work out the 'wobble' of the planet and its tides. I don't really know where to begin with that...more research, I suppose. I didn't know half of the stuff I do now a week ago (and I'd forgotten the little I did know).

Watching the simulations really helps to visualise what is going on dynamically, though. I have a much clearer picture of how comets in our solar system behave now, for example...

There's a lot I still can't do, though.

One is retrograde orbits - I'm not sure how to go about creating those.

And I'm still very fuzzy on the whole obliquity issue. All of my bodies have zero inclination, still. I have no idea how to calculate three dimensional positions and velocities.

When I was letting the program do that itself, rather than inputing the SMA (on the x axis) and orbital speed (on the y axis) myself, I had trouble getting the bodies to stay in position.

I might have made a mistake somewhere, though. This is so far from my field it's unbelievable, and I *do* make a lot of those...

There's a question here somewhere....basically, should I just let the program do its thing, rather than always going into 'Edit Object' afterwards and entering position and velocity manually?

Well, I've sort of answered my own question there. I don't know what happened when I tried it before, but it must have been my mistake somehow.

Just now, I was trying to get a small body (Mass = 1.8749E+19 kg, diameter = 242 km) to orbit a Mars-sized planet (Mass = 1.2546E+24, d. = 8,626 km), at a distance of 84,000 km, and my own calculations were way out.

The actual value as determined by the simulator (and which works) is more than 18 km/s, whereas the value I get when I take the square root of the gravitational constant times the mass of the primary divided by the average orbital radius is only 9.93 km/s, and sure enough, at this speed the moon just crashes into the planet.

The thing is, that calculation has served me well in every other instance for determining initial orbital speed. I was wondering why it has gone so wrong this time?

One is retrograde orbits - I'm not sure how to go about creating those.

Set your inclination to 180 degrees +-0%

Quote:

When I was letting the program do that itself, rather than inputing the SMA (on the x axis) and orbital speed (on the y axis) myself, I had trouble getting the bodies to stay in position.

This method should work fine. Just becareful with your calculations, and make sure you're using the proper units. Quote:

There's a question here somewhere....basically, should I just let the program do its thing, rather than always going into 'Edit Object' afterwards and entering position and velocity manually?

It's always fun to do it by hand, as it gives you the confidence that you know how to compute orbital velocity. But beyond that, there's no reason not to let the program do it for you.

Quote:

Just now, I was trying to get a small body (Mass = 1.8749E+19 kg, diameter = 242 km) to orbit a Mars-sized planet (Mass = 1.2546E+24, d. = 8,626 km), at a distance of 84,000 km, and my own calculations were way out.

The actual value as determined by the simulator (and which works) is more than 18 km/s, whereas the value I get when I take the square root of the gravitational constant times the mass of the primary divided by the average orbital radius is only 9.93 km/s, and sure enough, at this speed the moon just crashes into the planet.

Actually, both of these calculations are wrong. "square root of the gravitational constant times the mass of the primary divided by the average orbital radius" = sqr(6.673E-11 * (1.8749E19 + 1.254E24)/ 84000000)=998.089961590924 meters per second, or 0.998 km/s

I doubt the simulator came up with 18 km/s unless your value for Mars is too high. (Actually Mars' mass is 6.4185E+23 kg). Perhaps you did not have the proper objects selected in your velocity box?

Radius or diameter of the objects is not important as far as the simulator is concerned. It only tells it how large to draw the circle if you're zoomed in enough that the planets are larger than a single pixel. It also uses it in simulations that have collisions. But you don't need the value to compute orbital velocities.

Ah, I'm such an idiot. I simply got my conversion from m/s into km/s badly wrong. Everything in my spreadsheet is in metres. So I *did* mean 998 m/s (or 0.998 km/s), and I guess the value the sim came up with must have been 1.8 km/s.

My 'Mars' is both bigger and a bit denser than the real Mars. I must have made an error somewhere when entering the details into the sim, though, yes.

Anyway, I think I'm going to set up a whole new simulation with the orbits inclined. Thanks for the explanation of how to do retrograde. Now that you say it, I can see why. Eventually I hope to set up a slower-running sim that has all the smaller moons of the gas giants too, since for the moment I have restricted myself to the ones in hydrostatic equilibrium...

And thanks for putting up with my sometimes inane questions. What you say is true, it's fun to try and do it by hand, and I get a real kick out of seeing the right numbers come out. I frequently make silly mistakes, as evidenced by the above, but it's fun to try. I'm more comfortable with words than numbers...

[edit] I was thinking about the retrograde orbit. In order to have a retrograde orbit that is inclined to the orbital plane, do I simply set the inclination to a value higher than 180 where the difference represents the desired degree of inclination?

Yes, 180 + or - a certain value is like a retrograde orbit with the + or - value. But in an ephermersis, its never listed that way. They don't list retrograde and prograde. So a retrograde orbit would be considered i=180.