|
Forum Index : Microcontroller and PC projects : N-body Simulator for the CMM2
| Author | Message | ||||
| yock1960 Senior Member Joined: 18/08/2020 Location: United StatesPosts: 167 |
I've been taking a break from finishing the Qbert clone, to work on another program that probably nobody else will play with either. I'd been thinking about it for a week or so, after it percolated up in my brain cells...those leftover from the mid 80's....from when I typed in a basic program for the C64, from Transactor Magazine. Yes, I still have those magazines! Sadly, I could not get that program to work correctly...even after finding a few typos and being reasonably sure that I found them all....I went looking for another program to use. Anything current will be in Python, or Java or other languages that I'm not familiar with at all...or familiar enough with or have the patience or perseverance to convert. I finally stumbled on someone's thesis from 1997 or thereabouts, written in QuickBasic and badly typed by someone and just legible enough...from the photocopied pages...for me to get it working.Here then is a spiffed up adaptation, that still lacks a few bells and whistles, but is reasonably complete...enough so that it's ready for someone unfamiliar...to reveal it's shortcomings! Load a data file...I haven't progressed to giving them meaningful names yet. I'm also not expert enough to be sure of the units used...well time units anyway...so I've massaged those numbers to give a somewhat meaningful number...versus xxx.xxxxe+xx....perhaps seconds...days....not sure, but I'm more confident that mass values are in tons (metric?)...and distance in meters. Once the sim is running, press the 'H' key for help. Currently there is no facility in the program to edit body data, but that's on my todo list. Data files can of course be edited. They are pretty simple, the first two values are a 1, then the number of bodies in the data set, then name, mass, x-pos, y-pos, x velocity, y-velocity. The Quickbasic program was only a simple 2D representation and I haven't tried adding Z...yet. Oh, currently this is hard coded for mode 11...space is BIG! Allowing other screen modes will take some work...on the todo list. Getting bodies to not fly off into 'the cosmos' is something I haven't figured out how to do...other than trial and error...I've been doing some Googling to try and figure out...celestial mechanics...but the math..... Anyway...it's programming fun! Steve NBody_Simulator.zip Edited 2021-03-27 11:30 by yock1960 |
||||
| epsilon Senior Member Joined: 30/07/2020 Location: BelgiumPosts: 255 |
Hi Steve, Very nice, and a perfect fit for the CMM2. Some suggestions: Displaying a distance scale would be nice. Body masses too. E.g. with TAB you could cycle through the individual bodies and display body data such as its mass, current velocity etc. You could make the selected body blink, or have some kind of reticle around it. You could also draw the different bodies bigger or smaller based on their relative mass. I am a bit surprised that the system as a whole seems to drift slowly. I would expect the system to have a center that stays fixed in space. Mode 11 makes it very clear that I need to get that oscillator mod done. I'll try that this weekend. If you never hear from me again, you know what happened. Cheers, Ruben/Epsilon. Epsilon CMM2 projects |
||||
| yock1960 Senior Member Joined: 18/08/2020 Location: United StatesPosts: 167 |
Thanks Ruben! There is a number at upper right, which is the current x-scale in meters, but I could add a 1x, 2x, etc. down by the other info. As for the drift, this is to be expected, the speed of the drift depending on the masses and velocities involved. Currently, I believe all of the data sets contain a central massive body...star...at rest...but it could be given an initial velocity....stars are in orbit too! I have improved the 're-center' command to move the trails (if they are enabled)...you can get some nice 'spiro-graph' type effects...try data set 'test2.dat. I'm getting ready to add display/editing of data...which I don't think should take too long and will make experimentation much easier. As to making the sprite size related to the mass...I will give it some thought. It would probably need to be adjusted, based on the scale, since as you zoom out, everything bunches up. I think I would need to add a value to the data file to allow the system scale to be set by the user and make appropriate changes to the program. As programmed, zoomed out all the way, only gets to about the orbit of Saturn...so...pretty limited. My biggest challenge at this point, is being able to understand the math involved to put something in orbit, based on the central mass...versus trial and error...which is rather tedious! Thanks for the input! Plenty to do yet! Steve |
||||
| NPHighview Senior Member Joined: 02/09/2020 Location: United StatesPosts: 213 |
Ah, gravity and orbits! I'm looking forward to examining your code. Aeons ago, while a physics student, I did something very much like this on an HP-98xx-series desktop computer. The computer had a display that only showed x, y, z, and t registers (this is a reverse-Polish "RPN" calculator like later models such as the HP-35 and HP-41), but also had a plotter. I had just read Larry Niven's "Ringworld" where an alien species had engineered five stars (and their accompanying solar systems) to orbit each other in a Klemperer Rosette and I wanted to see if it would actually work. It did, but just like yours, drifted. Here's someone else's web-based version. My professor and I examined my code, and decided it was OK. He then slyly suggested floating-point round-off error as the cause, and sent me on a wild excursion of investigating the IEEE floating-point standard, ways to implement multiple-precision arithmetic in RPN, etc. This eventually led me to a very useful book by one of the mathematicians for the U.S. space program, "Math Toolkit for Realtime Programming" by Jack Crenshaw (ISBN 978-1929629091), which still holds a place of honor in my collection, next to "Mathematical Methods That (Almost Always) Work", where "(Almost Always)" is embossed, but not colored in, on the book's cover :-) Edited 2021-03-28 11:49 by NPHighview Live in the Future. It's Just Starting Now! |
||||
| cdeagle Senior Member Joined: 22/06/2014 Location: United StatesPosts: 266 |
A document is attached that talks about the circular-restricted three-body problem that may be of interest. For these types of problems round-off can be a problem which requires the use of a very good integrator. crtbp.pdf |
||||
| yock1960 Senior Member Joined: 18/08/2020 Location: United StatesPosts: 167 |
Ringworld...Niven...the golden age of Sci-fi...sigh! As I continue with this and if...IF....get a better understanding of celestial mechanics...I may be able to simulate the Rosette. As far as the 'working bits' of this code, it's straight from the paper, with the exception of a change I made to deal with the orbits going increasingly eccentric, when the time increment is increased in order to speed things up. This seems to reign things in pretty well...based on some of the reading I have done, increasing time increments do lead to inaccuracies and apparently there is some threshold, since I only apply this on factors over 1x and subsequent increases 2x up to 64x, seem to remain stable with this one adjustment. Sometime in the next day or so I will post an update that allows display, editing and saving data and possibly allowing selective enabling/disabling display of orbits...they will still be calculated of course. Steve |
||||
| yock1960 Senior Member Joined: 18/08/2020 Location: United StatesPosts: 167 |
Thanks...but what I really need is Celestial Mechanics for Dummies! Steve |
||||
| yock1960 Senior Member Joined: 18/08/2020 Location: United StatesPosts: 167 |
Here is an update that makes this program pretty complete. You can now edit data inside the program and you can disable the display of individual bodies. I also added another level of zoom in, to even up the in/out level at .125x to 8x. Currently the number of bodies is limited to 10. While there is plenty of memory to expand this, I haven't even looked at what the practical limit would be at the current simulation speed limit of 64x using plain BASIC, with a large number of bodies. A CSUB would be helpful here obviously, I'm not sure I could write it, but might be fun to try. As far as relative sprite sizes for bodies of different mass...that's still a todo...maybe. Steve NBody_Simulator.zip |
||||
| yock1960 Senior Member Joined: 18/08/2020 Location: United StatesPosts: 167 |
Okay, I think this is pretty much finished....famous last words... Changes are: 'N' command key to save data as a new file. There is a problem here, sometimes it won't let you save, saying the file exists....and sometimes it works okay... 'R' command key to re-center the objects. This happens automatically if the central object moves off screen. 'D' command key to create a .bmp of the current screen. Uses current base filename, but with .bmp extension. Overwrites existing file. 'A' command key to toggle auto disable mode, which when active, will automatically disable display of objects that are less than 9 pixels from the central object. This needs to be off, if objects have been manually disabled and zoom in or out is used (they will be re-enabled if auto-disable is on). Simulation time is now saved. Edit screen now shows what color the different bodies are displayed in. Steve NBody_Simulator.zip |
||||
| phil99 Guru Joined: 11/02/2018 Location: AustraliaPosts: 2828 |
The need for infinitely precise calculations to achieve stability may be sidestepped by cheating. Turn the Celestial Bodies into spacecraft. They travel mostly by celestial mechanics with occasional input from thrusters. Measure the discrepancy between what is happening and what you want to happen, if it gets too big correct it. |
||||
| The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |