Gravity Simulator
http://www.orbitsimulator.com/cgi-bin/yabb/YaBB.pl
General >> Discussion >> new beta version
http://www.orbitsimulator.com/cgi-bin/yabb/YaBB.pl?num=1176774875

Message started by Tony on 04/16/07 at 18:54:35

Title: new beta version
Post by Tony on 04/16/07 at 18:54:35

***  The most recent versions are at thebottom of this thread ***

I'm going to start making the beta versions public, as the beta is now far superior to the 2.0 version, and the new featuress seem to be quite stable.

This is the latest version.  It runs about 60% faster than the previous beta version, at least on my computer.  I'd be curious to know what results others get.
http://orbitsimulator.com/gravity/beta/GravitySimulatorBeta17Apr2007.exe

Download it into the same folder as your existing gravitysimulator.exe or your existing beta version and use it instead.

Future versions of the beta will include a contribution from frankuitaalst:  an Picard integrator.  So stay tuned...

Title: Re: new beta version
Post by Nexus on 04/18/07 at 00:33:45

Yup. Runs much faster on my machine as well. Good job, Tony.

:)

Title: Re: new beta version
Post by Tony on 04/22/07 at 17:29:34

This one may be quicker yet, depending on how many objects are in your simulation.  Give it a try and let me know what you think.  Create a new folder for this one, and copy all 3 files into the folder:
http://orbitsimulator.com/gravity/beta/GravitySimulatorBeta22Apr2007.exe
http://orbitsimulator.com//gravity/beta/CodeOptomizer.dll
http://orbitsimulator.com//gravity/beta/resume.gsim

You can use any resume.gsim that you want.  It's just important that there is one in your folder.  This CodeOptomizer.dll is different than the one you have now.  It's the same code, just compiled more efficiently.  This is why I suggest you create a new folder.

And remember, this is a beta version, .so there may be bugs to be ironed out. And the new .dll may not work with all processors.  If you have trouble or successes, I'd love to know.

Richard "Publius", "Grav", and others from the Bad Astronomy forum are helping me with this one.  
http://www.bautforum.com/showthread.php?t=57336

Title: Re: new beta version
Post by publius on 04/22/07 at 19:02:42


     Hi all. I'm "publius" that Tony mentioned above. I compiled the above version of the .dll using Intel's highly optimizing compiler. The version above requires a Pentium 4 or equivalent Athlon CPU with SSE2 instructions.

         If your CPU doesn't have them, it will crash the program with an illegal instruction fault.

         Second, we were trying to get some of the code to "vectorize" and made use of some static arrays. Just testing we hard coded 800 elements max. If a simulation uses more than 800 objects, then the .dll will crash with a buffer overrun.

           So just keep that in mind. It will not run on a PIII or earlier.  Once I get everything figured out, I'll try to compiler a PIII optimized version, and see if it does any better than the original code. But the SSE2 instructions really shine on large numbers of objects.

                                                                -Richard

Title: Re: new beta version
Post by Tony on 12/04/07 at 00:17:58

Download these into the same folder:
http://orbitsimulator.com/gravity/beta/GravitySimulatorBeta4Dec2007.exe
http://orbitsimulator.com//gravity/beta/CodeOptomizer.dll
http://orbitsimulator.com//gravity/beta/resume.gsim

There are no huge changes.  But there's a new feature that lets you add a description to your simulations in the file menu.

Title: Re: new beta version
Post by Tony on 01/20/08 at 02:17:34

A bug in the new description feature is fixed
menu Objects > Create Objects now allows you to specify a Gaussian distribution.  However, my recent attempts to duplicate the odds predicted for asteroid 2007 WD5, when they were 1 in ~30 leave me wondering if I did this right.  I could only generate 1 hit for every ~300 objects, using JPL's figures and error bars, despite them claiming at the time that the odds were as low as ~1 in 30.

The rotating frame now allows you to stop plotting, without a new orientation being chosen for you when you begin plotting again.  (No one ever complained about this before, so you probably have no idea what I'm talking about :D)

And one of the most reported bugs:  The x-position box in menu Objects > Edit Objects now works as advertised!

One small concern... The previous exe's for betas were twice the file size of this one.  And I didn't do anything different to reduce the file size.  I'm still in New Zealand, and working off of a system that I'm not quite familiar with, so that may explain the difference, but I'd appreciate any feedback just to make sure.

As usual, if you already have Gravity Simulator 2.0 installed on your system, simply download these files into the same folder, and use the beta exe instead:


http://orbitsimulator.com/gravity/beta/GravitySimulatorBeta20Jan2008.exe
http://orbitsimulator.com//gravity/beta/CodeOptomizer.dll
http://orbitsimulator.com//gravity/beta/resume.gsim

Title: Re: new beta version
Post by frankuitaalst on 01/20/08 at 03:11:58


Tony wrote:
One small concern... The previous exe's for betas were twice the file size of this one.  And I didn't do anything different to reduce the file size.  I'm still in New Zealand, and working off of a system that I'm not quite familiar with, so that may explain the difference, but I'd appreciate any feedback just to make sure.

Good job , I tried the new version.
Seems to work fine , adding new bodies with the 1SD works ...
But running the program I got this flickering picture ... any idea why ?  ;D

Title: Re: new beta version
Post by frankuitaalst on 01/20/08 at 03:26:06

Concerning the 1SD used by JPL I think this is a tricky subject as I think there  is an interference between the standard deviations .
If there are 6 parameters with each their uncertainty of 1SD and you create a set on SMA of fi 10 bodies , the "outer" values  are less sure . So they must be "weighted" . The central body may have a value 1... the bodies at the side are less likely to occur ...
Second problem is that if one creates 10 bodies ranging in SMA for -1SD to +1SD , each of this bodies has a subset for e , which in turn has a subset in i ,...and so on .
So it may ( I'm not quite sure )  be necessary to create 10^6 bodies to cover the full range of uncertainty.  
I think both items may be responible for the different results .

Title: Re: new beta version
Post by Mal on 01/28/08 at 21:40:11


Tony wrote:
One small concern... The previous exe's for betas were twice the file size of this one.  And I didn't do anything different to reduce the file size.  I'm still in New Zealand, and working off of a system that I'm not quite familiar with, so that may explain the difference, but I'd appreciate any feedback just to make sure.


Are you using different compiling software? I think that can change the exe size, if it's compiled more efficiently.

Title: Re: new beta version
Post by Tony on 01/29/08 at 13:57:19


Mal wrote:
[quote author=Tony link=1176774875/0#6 date=1200824254]One small concern... The previous exe's for betas were twice the file size of this one.  And I didn't do anything different to reduce the file size.  I'm still in New Zealand, and working off of a system that I'm not quite familiar with, so that may explain the difference, but I'd appreciate any feedback just to make sure.


Are you using different compiling software? I think that can change the exe size, if it's compiled more efficiently.[/quote]
No, it's the same one only on a different computer.  This time I complied on my laptop instead of my desktop.  It doesn't sound like anyone has any trouble with the new beta, so a smaller file is good.

Title: Re: new beta version
Post by mkruer on 01/30/08 at 14:31:54

Tony,  I just tried the latest beta, I have not noticed anything wrong. So it looks good. However I did have one question, are you still planning to implement the ability to edit object using the same variables used to create them. I am working on a system with 12 planets, trying to figure out a stable resonance, and I find it somewhat frustrating having to reenter all the variable because the current edit object just give the XYZ and motion vector.

Thanks

-Matt-

Title: Re: new beta version
Post by Tony on 10/13/08 at 20:14:43

http://orbitsimulator.com/gravity/beta/GravitySimulatorBeta2008october13.exe

This version includes a linear distribution for creating objects.


Mal wrote:
... Can we please have a way to specify the width of the belt that isn't done by percentages? i.e. to specify a distance and then say "+X AU" and "-Y AU". It's much easier to specify the range that way. It'd be even easier to specify the belt's "minimum sma" and "maximum sma", so we could say "100 objects between 0.909 and 1.454 AU" without having to calculate where the middle is first.


Ask and you shall receive (unless I ignore you  ;) )
http://orbitsimulator.com/gravity/beta/GravitySimulatorBeta2008october13.exe
This version includes a linear distribution for creating objects.

What was called "Uniform" was changed to "Random".  There are now 3 modes:
Random
Random Gaussian
Linear

To use Linear, enter a range, min,max seperated by a comma.  For example, to create objects between 1 and 5 sma, enter 1,5
I spent 2 hours programming this, and 20 minutes testing it, so there probably will be bugs.
I don't police the input yet, so you can probably crash the program if you forget the comma.

Also, you may now choose different distributions for different properties, instead of having to use the same distribution for everything.  Let me know how it works.


Title: Re: new beta version
Post by Tony on 11/04/08 at 20:49:55

http://orbitsimulator.com/gravity/beta/GravitySimulatorBeta2008November4.exe

There is a feature I introduced a few versions ago, but it was buggy, so I fixed and improved it.  It's the "Pointer" feature.  To use it, choose menu View > Show Pointer
It allows you to place an arrow on the screen that points to an object of your choosing.  When you first display the pointer, it points to the Sun.  You can drag it around the screen by dragging the words "To Sun".  To change the object it points to, right click the words "To Sun" and a dropdown list will appear that allows you to change the object.

Another change I made is that you can fine-tune the rotation of the rotating frame.  As it was, if you were in rotating frame, Pressing "<" or ">" (you had to hold the shift key) rotated the rotating frame by 36 degrees, so 10 presses made a complete circle.  Now "<" and ">" shift it by 0.5 degrees, and "." and "," (which are < and > without the shift key) rotate the rotating frame by 36 degrees.


What inspired these fixes is that I wanted to recreate the diagram and trajectory on this page:
http://neo.jpl.nasa.gov/news/2008tc3.html
http://neo.jpl.nasa.gov/news/2008tc3_fig1a.gif (I'm hotlinking their image  ;))

And here's my effort
http://orbitsimulator.com/gravity/images/2008tc3b.GIF


To try this yourself, download this simulation
http://orbitsimulator.com/gravity/simulations/2008TC3earthcenteredview.gsim

This simulation is in a rotating frame with a very long period (quadrillions of years).  This allows you to have basically a non-rotating frame, while giving you the ability to adjust the orientation.


  • Run the simulation, and use the "<>,." buttons to rotate the screen until the Sun pointer points straight down.  Don't worry if you're not fast enough to do it before the asteroid impacts Earth.
  • Pause the simulation
  • Re-open the simulation (it should now be the first simulation in the "recently opened" simulations in the File menu.
  • Increase the time step to .06
  • Unpause the simulation
  • Autopilot will pause the simulation for you a few moments before impact, so the screen won't clear on you
  • You should now have the same image as above.


With the time step set to .06 seconds, and the graphics update in the Preferences menu set to 15000, you get 1 tick every 15000*.06=900 seconds, or every 15 minutes like the Nasa image.


Title: Re: new beta version
Post by abyssoft on 12/02/08 at 09:17:10

I keep getting random memory errors with this latest build on both my XP box at work and my vista box at home

if I have more then about 400 bodies

Title: Re: new beta version
Post by Tony on 02/25/09 at 15:27:37

http://orbitsimulator.com/gravity/beta/GravitySimulatorBeta2009February25.exe

menu Time > Time Step Control

Enable the control by clicking "on".
Set the minimum distance two objects are allowed to pass before the time step slows.
Set the slow time step.
Set the fast time step.
If you want a log of the time step changes, select the "report" option.

For example, if you started with a simulation of all the planets plus Earth's moon, you would want to set your minimum distance to less than about 90% of the moon's distance.  Let's choose 300,000 km.  Since the moon is always farther than this, this prevents it from triggering a slow time step.

Enter 2048 for the fast time step.
Enter 1 for the slow time step.
Choose to make a report.

Your simulation should run at time step 2048 unless any two objects are within 300,000 of each other, in which case it will run at time step 1 until the close encounter is over.

It doesn't check for close encounters with each iteration.  Rather it is controlled by the "Do Events" interval in the preferences menu.  This is set to 50 by default, but you may want to slow it down to 5.

Title: Re: new beta version
Post by Mal on 02/25/09 at 16:02:25


Tony wrote:
It doesn't check for close encounters with each iteration.  Rather it is controlled by the "Do Events" interval in the preferences menu.  This is set to 50 by default, but you may want to slow it down to 5.


This is great Tony, thanks :). But what does the part I quoted mean exactly?

Title: Re: new beta version
Post by Tony on 02/25/09 at 18:28:51

Since the process of determining whether any objects violate the minimum distance set by the user takes a bit of time, rather than do it once per time step, it is only done once every several time steps.  This is determined by the "Do Events" box in the Preferences menu.  "Do Events" tells Gravity Simulator how often to return control of the computer back to Windows.  If it is set too high, the program becomes non-responsive.  If set too low, it slows down the simulation.  50 is the default.  That's often enough that your keyboard and mouse remain responsive, and seldom enough that it doesn't significantly slow down the program.  But even lowering this number as low as 5 is almost as good as 50.  Since this number now determines how often close encounters are checked for, lowering it from the default 50 might make sense.  Or perhaps I will sepeatate them in a future version.

Title: Re: new beta version
Post by Mal on 02/26/09 at 19:04:17

It's brilliant watching my asteroid belt with the new beta... I've got it going at 65k with the trails off, and every now and then it looks like it lurches into "bullet time" when it's doing a close encounter at 1024 :).

Title: Re: new beta version
Post by chemist on 03/18/09 at 00:13:18

Would be nice if it computed orbital elements barycentrically rather than relative to the reference object. The elements of a circumbinary planet are gibberish at the moment.




Title: Re: new beta version
Post by Tony on 03/18/09 at 12:21:50


chemist wrote:
Would be nice if it computed orbital elements barycentrically rather than relative to the reference object. The elements of a circumbinary planet are gibberish at the moment.


That's on my "to do" list.  Welcome to the forum!

Title: Re: new beta version
Post by chemist on 03/18/09 at 18:48:20

Excellent. It would have to be optional because I think you'd have the opposite problem for satellites that orbit one member of a binary. Another thing: if you try to create an object in a small orbit around the barycenter (unphysical) it shoots off at tremendous velocity!

Some other suggestions.
(1) Hill sphere display. Add an option to display objects' Hill spheres relative to their reference, maybe as a translucent shading.
(2) Programmable actions. eg if an object's semimajor axis or eccentricity exceeds a threshold, delete it. This would be handy when testing orbit stability with flocks of test particles.

Title: Re: new beta version
Post by Tony on 11/22/09 at 13:29:12

This version allows you to use either "." or "," when editing numbers in the Edit Object interface, to make it compliant with non-English settings.
http://orbitsimulator.com/gravity/beta/GravitySimulatorBeta2009Nov22.exe

Title: Re: new beta version
Post by Tony on 11/23/09 at 13:35:52

http://orbitsimulator.com/gravity/beta/GravitySimulatorBeta2009Nov23.exe

I think this fixes all the comma/dot issues.  Let me know if it works for you.  It also includes a new "Edit Objects" box that allows you to edit by orbital element.

Title: Re: new beta version
Post by Mal on 08/19/10 at 20:43:21

Tony - have there been any more updates to the program recently? The most recent beta I've got is the 2009Nov23 one. Is that the one you're still using at home, or are you using a super-seekrit advanced version with lots more cool stuff? ;)

And what version is available for download on the main gravity simulator site - is that still the original version?

Title: Re: new beta version
Post by frankuitaalst on 08/20/10 at 07:06:19

Good point Mal .
Something I want to simulate once is the migration of the gas giants in early times . Herefor I need the possibility to add the gas drag as a force to smaller bodies . Would be fun to have this feature added ...

Title: Re: new beta version
Post by Tony on 08/20/10 at 19:43:37

If it were super-seekret I wouldn't tell you  ;D  I'm still using Nov2009.  I thought I'd get around to doing some coding this summer, but I cleaned out the garage and painted the house instead.

You can migrate things already.  In Autopilot, choose "Continuous Orientation", select your object, and choose "Orient Retrograde" to make an object migrate in.  Then choose "Thrust", select your object, and choose a super-slow acceleration.  Then watch as it spirals in towards the Sun.

Title: Re: new beta version
Post by Mal on 12/15/10 at 00:40:41

Just looking over the thread, and now I'm wondering - if we downloaded the latest beta, should we also have downloaded the latest version of the "codeoptomizer.dll" (sic) and resume.gsim files from earlier in the thread too? When I last updated my windows OS to windows 7 I got the latest beta but I don't think I downloaded the dll and gsim.

This is why I think it would be nice if the original Installer file available from the download page was updated with the latest versions of the new files...!

(also, the spelling obsessive in me would like to point out that it should be "codeoptimizer.dll" (if you're spelling it in american), not "codeoptomizer.dll"!)

Title: TEST MASSES, ORBITAL PLANE ROTATION
Post by phoenixshade on 01/20/11 at 11:11:43

Two things I'd like to see in a future version:

1. TEST MASSES. These would react to gravity but produce none of their own.

Why not just make a 1 kg object; isn't that the same thing? Well, for ONE object, yes, but say you want THOUSANDS of objects. The algorithm seems to compute gravity between every object in the system, no matter how small... generally a good thing, but as the number of objects rises, the number of calculations required rises according to
x-1
[ch931] n
n=1

where x is the number of objects in the simulation.

But if we could make test masses with no gravity of their own, the number of calclations becomes
x-1
[ch931] n
n=m

where x is the total number of objects and m is the number of test masses.

So let's say you want to simulate the rings of Saturn and its large moons, considering the ring particles to be of negligible mass. You put in Saturn and say its dozen largest moons and 2000 ring particles and let 'er rip. Currently this would require 2025078 gravitational calculations per frame (and would probably crash the program). But if the ring particles are test masses with no gravity of their own, the number of calculations drops by almost 99% to only 26078 per frame.

2) Rotating frames confined to rotation IN THE ORBITAL PLANE. For example, I'd like to look at the dynamics of Trojan asteroid inclination with respect to Jupiter, so I'd like to look at the rotating frame obliquely. Currently, the axis of rotation is always orthogonal to the screen.

Overall I love this program, but as with anything else, there are things I want to do that it can't... but I think both of the above are fairly easy to implement. (If you want to throw me some source code, I'll happily have a crack at it.)

Title: Re: new beta version
Post by Tony on 01/20/11 at 21:20:23

Hi.  Welcome!  You seem to have mastered the program pretty well so far.  I assume you are using the latest Beta version.  The program already has test masses.  Just make masses with 0 kg, and it will skip the computations of that object accelerating all the other objects.

One day I'm going to redo the graphics entirely.  I've been saying that for a while, but when I do, I plan on allowing you to adjust the viewing angle of the rotating frame.  Thanks for the suggestions!

Title: Secondary color for objects
Post by phoenixshade on 01/25/11 at 16:42:44

It would be nice to be able to define a secondary color for objects when z is negative. This is already a common practice in orbit illustration to show the longitude of nodes, as in this picture from the Wikipedia article on Ceres (http://en.wikipedia.org/wiki/Ceres_(dwarf_planet)):

http://upload.wikimedia.org/wikipedia/commons/thumb/a/a4/Ceres_Orbit.svg/700px-Ceres_Orbit.svg.png

Title: Re: new beta version
Post by Tony on 01/25/11 at 18:09:20

Edit the object's name and put an asterisk as the last character.  Then you will get red as your negative z color.  For example, Ceres* instead of Ceres.

Title: Re: new beta version
Post by phoenixshade on 01/30/11 at 21:09:57

My wish-list just keeps growing and growing. Almost every time I use this program, I think of one or two minor tweaks I'd like to see. Most of them end up being forgotten, but here's a simple one that wasn't.

Perhaps this would fall under the "Preferences" menu. I'd like to be able to change the value of the gravitational constant G. In the simplest case, it's just a text field that allows you to type in any number you wish, along with a "Default" button. Even better would be to have radio buttons for units that work like the radio buttons for mass units.

Normally, I could achieve the same effect just by changing my masses or distances appropriately (for example, if I want to double G, I could just multiply all my masses by [ch8730]2) except in one case: Changing the sign of G. This would make gravity act something like electricity, with opposite-signed masses attracting and like-signed ones repelling. If I only wanted two-body versions, again no problem — just make one of the masses negative — but this won't work for n-body problems.

One of these days I might just break down and write my own simulator. Not that there's anything wrong with this one; I'm just a tinkerer by nature.

Title: Re: new beta version
Post by EDG on 01/30/11 at 22:11:15

Huh. That'd be kinda interesting :)

Title: Re: new beta version
Post by frankuitaalst on 01/31/11 at 10:11:30


phoenixshade wrote:
Normally, I could achieve the same effect just by changing my masses or distances appropriately (for example, if I want to double G, I could just multiply all my masses by [ch8730]2) except in one case: Changing the sign of G. This would make gravity act something like electricity, with opposite-signed masses attracting and like-signed ones repelling. If I only wanted two-body versions, again no problem — just make one of the masses negative — but this won't work for n-body problems.
.

Be prepared to see some unexpected results if you're playing with negative G or negative masses . It may be good to define two kinds of mass in his case : inertial and gravitational mass . I guess Gravsim has in the .gsim files some space left to do so .

Title: Re: new beta version
Post by Tony on 02/01/11 at 10:57:26

There's still lots of rffu's (reserved for future use) in the gsim file.  That's something I didn't do with Gravity Simulator 1.0, and adding more stuff to save became a huge chore.

At the moment, I'm not able to compile C++, so any tinkering with G would have to be executed in the VB code.  That means ignoring codeoptomizer.dll.  The sims will run slower, but depending on what you're trying to demonstrate, that might not matter.

Title: Re: new beta version
Post by Tony on 02/01/11 at 15:56:51

http://orbitsimulator.com/gravity/beta/GravitySimulatorBeta2011Feb01.exe
This has a Preferences option for changing G.  Gravity Simulator ignores the dll if a custom value is chosen.  Let me know if it's buggy.

Title: Re: new beta version
Post by Tony on 05/30/11 at 12:47:46

http://orbitsimulator.com/gravity/beta/GravitySimulatorBeta2011May30.exe

This beta introduces a 4th order Runge Kutta engine to Gravity Simulator.  In the Beta menu you can choose between the two.  I'm working on an analysis to compare the new RK4 method with the existing Euler-Cromer method.  They both have their strengths and weaknesses.  After minimal testing, it seems that RK4 is the best choice for short-duration simulations that use small time steps, for example, a recreation of Apollo missions.  And it seems like EC is the best choice for simulations spanning years into the future, and/or using large time steps.  I hope everyone will play around with it and let me know what you think.

This beta does not use the external dll, so the integrators are done in Visual Basic rather than C++.  Later I'll make a new C++ dll for this one.

Title: Re: new beta version
Post by Tony on 06/01/11 at 17:51:58

http://orbitsimulator.com/gravity/beta/GravitySimulatorBeta2011June01.exe
This fixes a bug in the new 4th order Runge Kutta routine.  This new routine now passes every test I've thrown at it.  When run at the same time step as the Euler-Cromer routine, it is a bit slower, but to make up for that, you can take much larger time steps without compromising accuracy.  At the moment, collisions don't work with the RK4 method.

Title: Re: new beta version
Post by Tony on 06/01/11 at 17:52:30


Code:
'=======================  RK4 ==========================================
'Use current positions to compute accelerations.  Store them in arrays a1x(), a1y(), a1z().
   
   'zero out arrays a1x(), a1y(), a1z()
   For k = 1 To objects
       a1x(k) = 0: a1y(k) = 0: a1z(k) = 0
   Next k
   
   For k = 1 To objects
       Mu = ObjMass(k) * G
       For j = k + 1 To objects
           Mu2 = ObjMass(j) * G
           dx = (objx(j) - objx(k))
           dy = (objy(j) - objy(k))
           dz = (objz(j) - objz(k))
           D = Sqr(dx * dx + dy * dy + dz * dz)
           If Mu > 0 Then 'ignore massless particles
               a1 = -(1 / D) * (1 / D) * Mu
               a1x(j) = a1x(j) + (dx / D) * a1
               a1y(j) = a1y(j) + (dy / D) * a1
               a1z(j) = a1z(j) + (dz / D) * a1
           End If
           
           If Mu2 > 0 Then 'ignore massless particles
               a1 = -(1 / D) * (1 / D) * Mu2
               a1x(k) = a1x(k) - (dx / D) * a1
               a1y(k) = a1y(k) - (dy / D) * a1
               a1z(k) = a1z(k) - (dz / D) * a1
           End If
       Next j
   Next k

'Copy the current velocities into an arrays v1x(), v1y(), v1z().
   For k = 1 To objects
       v1x(k) = objvx(k)
       v1y(k) = objvy(k)
       v1z(k) = objvz(k)
   Next k

'Use the velocities stored in v1x(), v1y(), v1z() to predict positions of objects one-half a step into the future.
'Store the positions in arrays p2x(), p2y(), p2z()."
   halfstep = timescale / 2
   For k = 1 To objects
       p2x(k) = objx(k) + v1x(k) * halfstep
       p2y(k) = objy(k) + v1y(k) * halfstep
       p2z(k) = objz(k) + v1z(k) * halfstep
   Next k
 
'Use the accelerations stored in a1x(), a1y(), a1z to predict future velocities at half a step into the future.
'Store the velocities in arrays v2x(), v2y(), v2z().
   For k = 1 To objects
       v2x(k) = objvx(k) + a1x(k) * halfstep
       v2y(k) = objvy(k) + a1y(k) * halfstep
       v2z(k) = objvz(k) + a1z(k) * halfstep
   Next k

'Use the positions stored in arrays p2x(), p2y(), p2z() (these are the positions at half a step in future)
'to compute accelerations on the bodies a half timestep into the future.
'Store these accelerations in arrays a2x(), a2y(), a2z()

   'zero out arrays a2x(), a2y(), a2z()
   For k = 1 To objects
       a2x(k) = 0: a2y(k) = 0: a2z(k) = 0
   Next k
   
   For k = 1 To objects
       Mu = ObjMass(k) * G
       For j = k + 1 To objects
           Mu2 = ObjMass(j) * G
           dx = (p2x(j) - p2x(k))
           dy = (p2y(j) - p2y(k))
           dz = (p2z(j) - p2z(k))
           D = Sqr(dx * dx + dy * dy + dz * dz)
           If Mu > 0 Then 'ignore massless particles
               a2 = -(1 / D) * (1 / D) * Mu
               a2x(j) = a2x(j) + (dx / D) * a2
               a2y(j) = a2y(j) + (dy / D) * a2
               a2z(j) = a2z(j) + (dz / D) * a2
           End If
           
           If Mu2 > 0 Then 'ignore massless particles
               a2 = -(1 / D) * (1 / D) * Mu2
               a2x(k) = a2x(k) - (dx / D) * a2
               a2y(k) = a2y(k) - (dy / D) * a2
               a2z(k) = a2z(k) - (dz / D) * a2
           End If
       Next j
   Next k
 
'Use the accelerations stored in arrays a2x(), a2y(), a2z() to compute velocities at half a step into the future.
'Store these velocities in arrays v3x(), v3y(), v3z().
   For k = 1 To objects
       v3x(k) = objvx(k) + a2x(k) * halfstep
       v3y(k) = objvy(k) + a2y(k) * halfstep
       v3z(k) = objvz(k) + a2z(k) * halfstep
   Next k

'Use the velocities stored in arrays v2x(), v2y(), v2z() to predict positions of objects one-half a step into the future.
'Store these positions in arrays p3x(), p3y(), p3z().
   For k = 1 To objects
       p3x(k) = objx(k) + v2x(k) * halfstep
       p3y(k) = objy(k) + v2y(k) * halfstep
       p3z(k) = objz(k) + v2z(k) * halfstep
   Next k

'Use the positions in arrays p3x(), p3y(), p3z() (these positions are at half a step in future)
'to compute the accelerations on the bodies a half time step into the future.
'Store them in arrays a3x(), a3y(), a3z()
   For k = 1 To objects
       a3x(k) = 0: a3y(k) = 0: a3z(k) = 0
   Next k
   
   For k = 1 To objects
       Mu = ObjMass(k) * G
       For j = k + 1 To objects
           Mu2 = ObjMass(j) * G
           dx = (p3x(j) - p3x(k))
           dy = (p3y(j) - p3y(k))
           dz = (p3z(j) - p3z(k))
           D = Sqr(dx * dx + dy * dy + dz * dz)
           If Mu > 0 Then 'ignore massless particles
               a3 = -(1 / D) * (1 / D) * Mu
               a3x(j) = a3x(j) + (dx / D) * a3
               a3y(j) = a3y(j) + (dy / D) * a3
               a3z(j) = a3z(j) + (dz / D) * a3
           End If
           
           If Mu2 > 0 Then 'ignore massless particles
               a3 = -(1 / D) * (1 / D) * Mu2
               a3x(k) = a3x(k) - (dx / D) * a3
               a3y(k) = a3y(k) - (dy / D) * a3
               a3z(k) = a3z(k) - (dz / D) * a3
           End If
       Next j
   Next k

'Use the accelerations in arrays a3x(), a3y(), a3z() to compute velocities at one FULL step into the future.
'Store them in arrays v4x(), v4y(), v4z().
   For k = 1 To objects
       v4x(k) = objvx(k) + a3x(k) * timescale
       v4y(k) = objvy(k) + a3y(k) * timescale
       v4z(k) = objvz(k) + a3z(k) * timescale
   Next k

'Use the veolcities stored in arrays v3x(), v3y(), v3z() to compute the positions of objects one FULL step into the future.
'Store them in arrays p4x(), p4y(), p4z().
   For k = 1 To objects
       p4x(k) = objx(k) + v3x(k) * timescale
       p4y(k) = objy(k) + v3y(k) * timescale
       p4z(k) = objz(k) + v3z(k) * timescale
   Next k
   
'Use the positions stored in arrays p4x(), p4y(), p4z()(these are the positions at one FULL step in future)
'to compute accelerations on the bodies in the future.
'Store these accelerations in arrays a4x(), a4y(), a4z()
   For k = 1 To objects
       a4x(k) = 0: a4y(k) = 0: a4z(k) = 0
   Next k
   
   For k = 1 To objects
       Mu = ObjMass(k) * G
       For j = k + 1 To objects
           Mu2 = ObjMass(j) * G
           dx = (p4x(j) - p4x(k))
           dy = (p4y(j) - p4y(k))
           dz = (p4z(j) - p4z(k))
           D = Sqr(dx * dx + dy * dy + dz * dz)
           If Mu > 0 Then 'ignore massless particles
               a4 = -(1 / D) * (1 / D) * Mu
               a4x(j) = a4x(j) + (dx / D) * a4
               a4y(j) = a4y(j) + (dy / D) * a4
               a4z(j) = a4z(j) + (dz / D) * a4
           End If
           
           If Mu2 > 0 Then 'ignore massless particles
               a4 = -(1 / D) * (1 / D) * Mu2
               a4x(k) = a4x(k) - (dx / D) * a4
               a4y(k) = a4y(k) - (dy / D) * a4
               a4z(k) = a4z(k) - (dz / D) * a4
           End If
       Next j
   Next k


'Apply the Runge-Kutta 4th Order method to these arrays to determine the slope of the position and velocities
'Then add these slopes to the current positions and velocities to get the new positions and velocities.
'Velocity is the derivative of position.
'Acceleration is the derivative of velocity.

'The RK4 method states that the slope for velocity is
'(1/6) * timestep * (the acceleration at the beginning of the interval, stored in a1x(), a1y(), a1z()
'                    + 2 * the acceleration at the first estimate of the half time step, stored in a2x(), a2y(), a2z()
'                    + 2 * the acceleration at the second estimate of the half time step, stored in a3x(), a3y(), a3z()
'                    + the acceleration at the estimate of the end of a full time step, stored in a4x(), a4y(), a4z() ).
   
'The RK4 method states that the slope for position is
'(1/6) * timestep * (the velocity at the beginning of the interval, stored in v1x(), v1y(), v1z()
'                    + 2 * the velocity at the first estimate of the half time step, stored in v2x(), v2y(), v2z()
'                    + 2 * the velocity at the second estimate of the half time step, stored in v3x(), v3y(), v3z()
'                    + the velocity at the estimate of the end of a full time step, stored in v4x(), v4y(), v4z() ).

   
   For k = 1 To objects
       deltavx = (timescale / 6) * (a1x(k) + 2 * a2x(k) + 2 * a3x(k) + a4x(k))
       deltavy = (timescale / 6) * (a1y(k) + 2 * a2y(k) + 2 * a3y(k) + a4y(k))
       deltavz = (timescale / 6) * (a1z(k) + 2 * a2z(k) + 2 * a3z(k) + a4z(k))
       
       objvx(k) = objvx(k) + deltavx
       objvy(k) = objvy(k) + deltavy
       objvz(k) = objvz(k) + deltavz
       
       deltapx = (timescale / 6) * (v1x(k) + 2 * v2x(k) + 2 * v3x(k) + v4x(k))
       deltapy = (timescale / 6) * (v1y(k) + 2 * v2y(k) + 2 * v3y(k) + v4y(k))
       deltapz = (timescale / 6) * (v1z(k) + 2 * v2z(k) + 2 * v3z(k) + v4z(k))
       
       objx(k) = objx(k) + deltapx
       objy(k) = objy(k) + deltapy
       objz(k) = objz(k) + deltapz
   Next k

Title: Re: new beta version
Post by Tony on 06/08/11 at 20:34:55

http://orbitsimulator.com/gravity/beta/GravitySimulatorBeta2011June08.exe

It seems my last beta version wiped out the rotating frames.  That's fixed now.  The "distance and velocity box" now shows more digits, and the radial velocity reads negative if the objects are approaching each other.

This version also introduces two new integration methods:  Leapfrog and Verlet.  These are 2nd order routines whose accuracy rivals RK4, but whose execution speed rivals Euler-Cromer.  You can choose between them in the new Integrator menu.

Title: Re: new beta version
Post by abyssoft on 06/09/11 at 15:18:03

Create object appears to have broken with the latest beta.

I do create object and it doesn't adhere to the parameters I end up with stuff scattered all over the place, have a system i can occasionally use to do runs 8)

Title: Re: new beta version
Post by Tony on 06/09/11 at 17:39:48


abyssoft wrote:
Create object appears to have broken with the latest beta.

I do create object and it doesn't adhere to the parameters I end up with stuff scattered all over the place, have a system i can occasionally use to do runs 8)


I just tried it and it works fine for me.  Can you give me some details of what you're creating and the steps you're using?

Title: Re: new beta version
Post by abyssoft on 06/11/11 at 00:00:51

starting with planets only sim paused tried all 4 engines
creating 600 obs, 1/2400 mass earth, earth as central obj, +/- % at 25 for all variances, inc 5, SMA 80000, radius 250 km, orbital params un modified 180 mod 100%,

Title: Re: new beta version
Post by Tony on 06/11/11 at 10:53:19

Thanks for the report.
You'll probably find that there is a problem with onlyplanets.gsim even if you don't add more items.  There are some problems opening simulations created with previous versions that are saved with time steps other than 1 second in the new beta.  This might sound like a pain to try, but open onlyplanets in an older beta (prior to May 2011), reduce the time step to 1, resave it.  Then it should open fine in the new beta and you can create your additional objects and it should work fine.  I'll correct this soon so you can open older simulations with the Beta, but for the time being, you can only open existing sims saved at timestep = 1.

Title: Re: new beta version
Post by wil on 06/12/11 at 13:39:08

I propose new option:
show orbital inclinations and orientations (line of nodes) in invariant plane of system.

Invariant plane is perpendicular to total rotational momentum vector.
Simple sum: L = m r x v = [Lx, Ly,Lz].
Normalize it and we have normal vector of invariant plane.
----

And other one yet:

8 - 10-th order integrator.
For example RK10 will be good enough, mayby some symplectic version...

Title: Re: new beta version
Post by EDG on 06/18/11 at 22:11:50


Tony wrote:
Thanks for the report.
You'll probably find that there is a problem with onlyplanets.gsim even if you don't add more items.  There are some problems opening simulations created with previous versions that are saved with time steps other than 1 second in the new beta.  This might sound like a pain to try, but open onlyplanets in an older beta (prior to May 2011), reduce the time step to 1, resave it.  Then it should open fine in the new beta and you can create your additional objects and it should work fine.  I'll correct this soon so you can open older simulations with the Beta, but for the time being, you can only open existing sims saved at timestep = 1.


Has this been fixed yet? Is there a way to manually edit existing sims (say, in notepad) to edit the timestep to equal 1?

Title: Re: new beta version
Post by Tony on 06/18/11 at 22:17:57

It hasn't been fixed yet.  You could edit the .gsim in notepad by dividing all the velocities by the time step, and dividing all the masses by timestep^2.  But it's much easier to simply keep an older version of the beta on your system, and use it to open the file, reduce the timestep to 1, then resave the file.

Title: Re: new beta version
Post by Tony on 10/18/11 at 17:59:24

This installs a new version.  It contains dlls for RK4, and variable-step RK4.  Give it a try and let me know if it installs smoothly.
http://orbitsimulator.com/gravity/beta/setupGravitySimulatorAlpha3.exe

Title: Re: new beta version
Post by EDG on 10/20/11 at 14:51:19

Is there a changelog anywhere that shows what's been fixed/updated/removed in the various alpha and beta releases? (eg does this new alpha fix the timestep issue described above?)

Title: Re: new beta version
Post by Tony on 10/20/11 at 16:33:26

I think I fixed that one.  You can double check.  The new version lets you choose an integrator from a dropdown list.  It gives you dlls for the RK4 routines.  It has a variable time step routine, so you can run simulations at fast speed and they automatically slow down for close approaches.

Title: Re: new beta version
Post by EDG on 12/30/12 at 12:23:38


EDG wrote:
Is there a changelog anywhere that shows what's been fixed/updated/removed in the various alpha and beta releases? (eg does this new alpha fix the timestep issue described above?)


I'm still hoping a changelog exists and can be posted (surely Tony must make one whenever he updates the beta?!) - I've quite lost track of what is now possible in the program.

Is the install file downloadable from the website going to be updated to the latest beta too? I think it's still the original basic version.

Title: Re: new beta version
Post by EDG on 03/13/13 at 20:29:11

There are other integrators in the "new" GravSim3Alpha... I presume that Euler is the 'original' integrator, and you mention RK and RK4 above, but what should "Leapfrog" and "Verlet" be used for?

Title: Re: new beta version
Post by Tony on 03/14/13 at 00:52:55

The leapfrog and verlet are there for comparison.  RK4 is the best one to use.  Try creating a new simulation, then put 1 object in orbit above the Sun, just above its surface.  Open a distance and velocity box from the view menu.  Notice that in Euler, the distance varies slightly over the orbit, but it holds steady in RK4.

Title: Re: new beta version
Post by EDG on 04/16/13 at 21:09:05

It seems that the 'help' functions in the help menu aren't working in the 3.0 alpha either. Whether I go to Gravity Simulator Help or to the Gravity Simulator Online help, the program crashes whenever it tries to open Internet Explorer (I have IE 9 on my system). Though can we set a Preference to point it to a preferred browser? While I have IE9 on my computer, I don't use it - I use Firefox instead.

(I think this is where it's supposed to be pointing to: http://orbitsimulator.com/gravity/tutorials/tutorials.html - this explains all the items in the (non-alpha?) menus at least).

Title: Re: new beta version
Post by Tony on 07/25/13 at 15:54:04

http://orbitsimulator.com/gravity/beta/csv.csv
http://orbitsimulator.com/gravity/beta/GravitySimulatorAlpha2013July24_3.0.exe

Here is the latest beta with Mal's spreadsheet suggestion.  There's a very good chance you'll find bugs in this, but it works with the attached csv.  Try it out and report any bugs to me.

Instructions for importing objects from spreadsheet.

1. Pause simulation
2. Delete all existing objects using Objects > Delete Objects menu. (see note below)
3. Open "Create Objects" dialog box.
4. Press Import button.
5. Navigate to your csv file.

note: If you are importing objects onto an existing system, you do not need to delete the existing objects, but every object in your spreadsheet needs to have a ref obj.  In the attached csv file, Ixtab has no reference object, so this spreadsheet needs to be imported into a system with no existing members.

CSV file:
Follow the format of the attached csv file exactly.
Format all your spreadsheet cells as text, and save it as a csv file.
In Ref Obj, if you add 'b' to the reference object name, it is the same as choosing the barycenter option on the Create Objects interface. You must put single quotes around the b so gravity simulator doesn't consider the b to be part of the name.
Mass: Add S for sun, E for Earth, J for Jupiter, kg for kilograms.  If you put nothing, default is Earth mass.
Color: At the moment, the only options are red, black, green, yellow, blue, magenta, cyan, white.  If you want more colors, tell me the hexidecimal color code and name for each additional color.
SMA: Add  m, km, AU, LY for units

Distribution:
Use a dash for a range.  For example if you create 3 objects (first column) and put 1-3 AU, you will get an object at 1, 2, and 3 AU
Use ~ for +/- percent.
Use @ for standard deviation

The attached csv file will create a system centered around Ixtab.  
Akabna has definite values for all its parameters.  
Balamna will have an inclination of 2 degrees +/- 100 % (i.e. a random value between 0 and 4 degrees)
Balamna's LAN, Per, and MA will be 180 +/- 100% (i.e. a random value between 0 and 360 degrees)
The asteroids' eccentricity will be chosen by a random gaussian distribution centered on 0.1 with a standard deviation of 0.01.  Be careful. This can generate negative numbers which might crash the simulation.
The Kuipers will have a size of 10 km +/- 50% (i.e. a random number between 5 and 15 km)
The Kuipers eccentricities will have a linear distribution from 0 to 0.1 (i.e. 0, 0.05, 0.1)

Title: Re: new beta version
Post by stargate38 on 12/23/13 at 16:01:03

Why does the About box say this? GravSim is freeware:


Code:
Warning: ...Please do not make duplicate copies. All
new users should download and register their
shareware copy of this program from
www.gravitysimulator.com


Please replace the word "Shareware" with "Freeware" in the next version

Also, here's a sim that I found where you can change the exponent: http://www.testtubegames.com/gravity.html

Can you PLEASE integrate a law-changing function into GravSim? It would help me with formation scenarios because, on top of what I haven't uploaded, I really want to see what would result from a ring of particles in "F=G*m1*m2*f(r)" gravity, where "f" is an arbitrary function (like r^-2+r^-4, which is close to relativistic gravity, or r^-2+0.1, which I call "Gravity with a set minimum"). I hope you integrate this someday; it would help with dark-matter related sims, like galaxies (where MOND is assumed).

Advantages for such a feature:

1. r^0 is easier to simulate because it changes the force law to "F=G*m1*m2", relieving stress on the CPU.
2. no object could escape from "G*m1*m2*(r^-2+r^1)" gravity.
3. Users could potentially make a sim for 2-D Space, where gravity decreases as r^-1 instead of r^-2. Circular orbital velocity/(Total mass^2)=constant
4. r^1 gravity has 2 advantages:
  a. All objects in a system will have the same orbital period
  b. Orbits are much more stable.
5. Relativity could be simulated by an "r^-2+r^-4" law.

Gravity Simulator » Powered by YaBB 2.1!
YaBB © 2000-2005. All Rights Reserved.