ezocher / gravity-toy Goto Github PK

I was originally using the Windows.Foundation.Point class for the simulation values because I saw the the constructor signature was Point(double, double) and assumed X and Y were doubles internally. It turns out they are currently floats (see FoundationPointIssue.sln). Need to implement a (double, double) point class and change the simulation to use it.

• Add fields for controlling speed of time and verify with existing scenarios
• Hook up speed up/slow down buttons. They should effect both running and stepping.

Prereqs: complete issue #3 and issue #6 and gain some experience with them across PCs

• Use a quick benchmark at app start and the available hardware threads to automatically set the CalculationSettings for every scenario

Will leave behind numeric-investigations branch in case it's needed again.

Clean ups after creating new branch:

• Delete FoundationPointIssue folder (keep NumericTypesTests folder, it could be convenient to have it in master)
• In UWP code: Delete data dumping class and remove references to it and globals for it

Look holistically at distance minimums and acceleration limits and clean up and centralize.
Need to keep at least some minimum value for r to avoid divide by zero.

This is work to finish the fix for issue #2

Trying different values for the number of calculations per frame in the toy orbit scenario is producing unexpected results. For example, 2000 calcs/frame produces a nearly stable orbit, 5000 produces a slowly shifting orbit, and 10000 produces some unexpected "flat spots" in the orbit.

Seeing e.g. 1907 seconds is not helpful, implement auto scaling of time units, investigate D:H:M:S.ss or decimal of largest appropriate unit.

The lower the orbit is, the faster it grows.

Before clearing or modifying sim it would be nice to have a clean way to ensure that no rendering is in progress (exclusive lock?). See especially SimRenderer.ClearSim().

Fixed before opening issues. Moved here from README.md.

• Revise calculation
• Establish what big G should be for toy scenarios, fix masses, update and test
• Get real world big G working with earth orbit scenario

Talk about animating orbits along perfect paths for games or visualizations, versus making a highly accurate and stable gravity simulation.
Things learned about precision
Reference issue #31

Could also consider mouse click, hold and drag in window for scrolling

• Add looping to calculations, controlled by CalculationSettings per scenario
• Test and refine with toy orbiting scenario

Replaces final step of Issue #1

Fixed prior to opening issues. Moved here from README.md.

Suspend/Resume caused many problems including crashes that were mostly masked by Visual Studio not allowing Suspend of applications attached to the debugger.

Fix was to handle Suspending events and stop UI updates while suspended.

In numeric-investigations branch

Example requirements:

• Satellite in geosynchronous orbit: (add specifics about scales of distance, acceleration, and delta-v in a small time slice and about how double is insufficient)

Also investigate:

• Investigate existing open source astrometric or gravity-specific libraries or modelling systems

Requires new mission capability with delta-v's added at specific locations and/or times

• Create numerical-investigations branch
• Dump data to tab-delimited text files
• Create a tiny console app to investigate specific calculations
• Formatting fixes: separate X & Y of Points with tabs, print max digits of doubles (use {0:R} formatting for all doubles).
• Use this to investigate issue #2 and issue #10

Create new SimSpace using parsecs and years. Use some random varied star sizes. Make these mini-galaxies with proper rotation.

• Add and get working for 500 body toy scenario

Generalize approach from issue #18 to be able to generate rotating discs of bodies with no central body (or with one).

In UWP Windows.Foundation.Point is publicly (double, double) but is (float, float) internally.
Start with this page: https://docs.microsoft.com/en-us/dotnet/api/windows.foundation.point?view=dotnet-plat-ext-3.1 and also address the pages for the X and Y fields.

Tried a toy orbital simulation and was unable to get a body moving in a circular or near-circular orbit.

• Noticed that orbits are not as expected, having more than one perigee/apogee per orbit.
• Noticed that in the first computed step of a scenario an error is introduced when the initial velocity vector doesn't take into account that the end of the first step is not on the tangent to the starting position of the first step.
• Noticed that orbiting bodies are gradually accelerating to higher minimum and maximum velocities each orbit.

Definitely need to change to have much finer granularity calculation steps (multiple calculation steps per render step).

https://herbie.uwplse.org/

For 20000+ km/h we don't need thousandths for example. Also add commas for thousands.

Also capture complete and elapsed time captured

Low earth orbits are working in the scenario using SimSpace.LEOSpace, but medium earth orbits (GPS) and geosynchronous orbits are behaving strangely. The first geosynchronous orbit I tried in this scale traced out a polygon rather than an ellipse. Looks like numeric overflow somewhere.

In the 9 bodies scenario the central body should never move. Because of cumulative numerical errors (confirm) it eventually does.

Even when there are errors, the simulation runs should give identical results since the exact same calculations are run in the exact same order with no randomness introduced. I ran three runs of the 9 bodies scenario and got three totally different paths for the central body which diverged from 0, 0 at different iterations. WTF?

Screenshots are here: https://github.com/ezocher/Gravity-Sandbox/blob/master/Images/
NineBodies-NumericalInstability1.PNG (and 2 and 3)

Rename all versions of CheckAdditionPrecision() and make V3 the primary one

See EarthFromISS.jpg and EarthFromLunarOrbit.jpg files in Images folder for reference colors

There are many in GravitySim.cs that need cleanup

Given only an orbital altitude, pick a random angle around the primary body and then calculate the starting position and the starting velocity vector to provide a circular orbit.

Completed prior to opening issues. Moved here from README.md.

Added messaging area above control strip.

Done prior to opening issues. Moved here from README.md.
XAML modifications run async but they take time proportional to number of bodies involved.

In LoadXRandomBodies() and LoadXBodiesCircularCluster() add calls to sim.SetCalculationSettings() based on number of bodies requested. May overlap with work in issue #7

Fixed prior to opening issues. Moved here from README.md.

Bug: Had runaway explosion of number of UI threads when simulation didn't complete in per frame time and XAML was falling further and further behind. (Was formerly: Figure out the animation/memory problem that started ~2016).

Fix was to drop frames when calculations hadn't completed in time. Will also implement issue #6 for large scenarios on multi-core machines.

First create a scenario based on the issue #19 work and then get the mini-galaxy properly moving while it rotates. Next, create two of those and set them on a collision course.

Do a pencil and graph paper and spreadsheet analysis of one minute of the actual ISS orbit versus a single linear step of the current algorithm to understand the nature of the error in the approximation.

• One thing that intuitively seems problematic is that the velocity of an orbiting body at the end of each step won't be in the same direction as the tangent to the curve at that point.

Render key bodies using bitmaps with transparency. Views need to be from above the north (or south) pole of each body.