Description

PhysX3D is a highly efficient numerical computer simulation which can calculate the gravitational n-body-problem. The n-body-problem is about predicting the complex movement of many particles based on the interactions between each pair of two particles. Every particle does affect every other particle. In the gravitational n-body-problem only the force of gravity is being considered.
The numeric simulation is linked to the most efficient CPU-based 3D graphics engine ever written in Java, which I developed myself completely from scratch. It can display the flight paths, osculating Keplerian orbits, particle groupings, particle velocities, the dynamic gravitational potential and the dynamic warping of space as well as several other graphical extensions like the day-night-cycles of planets in multiple star systems. The graphics engine also supports stereoscopic 3D for 3D monitors or head-mounted displays.

Features


Paths

Velocities

Groups

Calculation Features:

 - 
Velocity Verlet integrator with adaptive timestepping
 - 
64 bit double precision calculation
 - 
CPU multithreading
 - 
GPU acceleration for higher particle number problems
 - 
simulation data and configuration (settings, units, graphics) is being read from a file system (.txt)
 - 
adjustable simulation speed
 - 
time and date tracking
 - 
collision detection

Display Features:

 - 
free camera mode, follow camera mode, automatic counterrotation of camera
 - 
stereoscopic 3D rendering for 3D monitors or head-mounted displays
 - 
paths
 - 
velocities
 - 
groups
 - 
osculating Keplerian orbits
 - 
grid(): dynamic gravity potential visualization with filter for gravity waves
 - 
cube(): dynamic visualization of warped space
 - 
dynamic visualization of the 3D Barnes-Hut Tree (not used for force calculation)
 - 
blooming effect
 - 
polygon graphics with dynamic lighting by multiple moving light sources
 - 
body rotation about an arbitrary axis

Performance   -   Java vs. C++

Initially I developed PhysX3D in Java, including my leightweight 3D graphics engine. However, in late 2017 I traslated the major source code parts into C++, starting with Line3D. I wanted to know which programming language is faster and which additional optimizations could be made in C++. It turned out that Java is extremely well optimized, but in C++ extensions like SSE2 or AVX2 could make the algorithm twice as fast (basically the CPU can calculate several operations as one vector operation). Another big difference is memory management. Java completely lacks the ability to free allocated memory. This means that while the Java version requires up to 500MB RAM, the C++ version only needs a maximum of 135MB, usually about 10MB. Furthermore, OpenCL in C++ provides some extra optimizations like vector data types and explicit memory transfer over the PCIe bus. This way, in the C++ version the GPU kernel runs 30% faster.
The overall numeric performance is indicated by the amount of possible integration steps per second plotted in the diagram below (Setup: Lenovo Y50-70 Laptop).


In the diagram you can spot the differences between Java and C++: Firstly, the CPU part runs about twice as fast in C++ due to vectorization. Java cannot make use of this. The second difference is that GPU acceleration runs faster in C++ because of vector data types and explicit memory transfer over the PCIe bus. The aparapi library for Java lacks these features.
C++
Java
Pros + more functionality + simple to learn
+ explicit memory management + very well optimized
+ better support for extensions like OpenCL + exactly as fast as C++ in non-vectorizable loops
+ more opotions for optimization (for example AVX2) + much better compatibility across multiple operating systems
+ no additional software required + displaying simple graphics is extremely fast
+ console is always available and easy to use for debugging
Cons - just opening a window takes more than 100 lines of code - no explicit memory management, slow garbage collector
- pointers are not easy to learn - much higher RAM usage
- bad compatibility across different operating systems - arrays are always allocated on the heap
- methods have to be written in the right order or in an extra header file - requires Java Runtime Environment
- no default console when programming a graphic interface
To my surprise however, the graphics part runs faster in Java. I've built my Line3D library directly on Windows Graphics Device Interface (GDI) with WDDM 2.0 drivers (GDI+ is slow AF). Later I exchanged GDI with the faster Direct2D, which is still slower than the Java implementation. In Java I used the libraries java.awt and javax.swing. Drawing primitive figures Java seems to be about 40% faster.
Java 100%
C++ GDI+     1%
C++ GDI   33%
C++ Direct2D   58%

Implementation Strategy and Parallelization

Since version 16.2, the integration is implemented using Velocity Verlet, since it enables the usage of variable time steps and does maintain the total energy and angular momentum. In order to maintain constant simulation speed and to use all the available computational power, the time intervals for the integration vary by size depending on the processors speed. A very effective algorithm (similar to prediction models for next-day energy consumption of large companies) is used for predicting the size of the next time step based on the time the last computation took as well as the last time step. Since I used double variables in Java, the round-off error of 2⋅10-16 makes the error in total energy stay below 10-7. Velocity Verlet itself is a second order integrator and thus produces a global O(t2) error.
The n-body-problem represents a workload which can be parallelized, meaning it can be splitted upon all available processing cores except for one, which is reserved for the graphical output. Thus, running on an 8-core processor the n-body computation can make use of seven cores. Whereas a small number of bodies requires very fast clock speeds and cannot be splitted into more threads than there are bodies, a large number of bodies is a highly parallelizable workload and multi-core processors can be utilized. Parallel threads have to be synchronized at multiple points within each calculation step, so at small body numbers the performance of multithreading is inferior to singlethreading. At large body numbers multithreading becomes superior to singlethreading by a factor of 3.8 on an Intel Core i7-4720HQ. Multi-core processors will benefit even more from multithreading.
Since version 15.3 GPU acceleration has been successfully implemented via aparapi. aparapi is a Java extension which translates the compiled Java bytecode into OpenCL which is then executed on the GPU. In GPU mode the double orbital state vectors are converted into float arrays which can then be accessed in the Kernel provided by aparapi. Only the part impacting performance with n2 is being executed on the GPU and the newly calculated orbital state vectors are returned back to the CPU. At high body numbers the performance is increased by a factor of 113 running on the Nvidia GeForce GTX 960M (1.71Tflops, 640 shader units @1.336GHz) compared to CPU multithreading on the Intel Core i7-4720HQ (0.33Tflops, 8 threads @2.56GHz).
The Nvidia GeForce GTX 960M can handle 54 Billion force calculations per second at 5000 bodies or more. This means that one single force calculation does require roughly 44 floating point operations. In the source code, a single force calculation requires about 33 floating point operations, not taking into account array transfers to the VRAM and back as well as memory latencies. This proves that my implementations in Java and C++ have reached the optimization limit.

Compatibility

PhysX3D is completely written in Java, so it is compatible with any system that supports Java. It has been successfully examined on a variety of different computers ranging from a Raspberry Pi 2 over several laptops to a Linux Cluster with four 16-core AMD Opteron processors offering 0.59Tflops. In all tests it was able to utilize the entire computational power provided by the systems. The Nvidia GeForce GTX 960M as well as the Intel HD Graphics 4600 have been successfully tested for GPU acceleration. Also tests on a ZOTAC GeForce GTX 1080 AMP Extreme (9.78Tflops, 2560 shader units @1.911GHz) have been conducted. Any GPU with OpenCL support will be compatible.
Just for fun I also benchmarked PhysX3D on the Nvidia GeForce GTX Titan Xp (14.48Tflops, 3840 shader units @1.404-1.885GHz), which is currently the second fastest consumer GPU in the world. This graphics card can handle 340 Billion force calculations per second.

Which integrator is most efficient?

Mathematical problems like the n-body-problem cannot be solved analytically and thus require a numerical method in order to be approximated. So, what is an integrator?
An integrator is an algorithm that, at a discrete time step, gets the positions, velocities and acclelerations of all particles as input and calculates the positions and velocities of all particles one time step later as ouput.

x(t), v(t), a(x(t))   ⟶   x(t+∆t), v(t+∆t)

This is the most important part of the entire program. There are many ways to do it, so I tested all major types of (explicit) integrators in order to find the most efficient one.

Integrator Description Algorithm Order Evals Performance
Euler Initially, PhysX3D started with the straightforward Euler method, which is easy to implement, but compared to other integration methods it is not competitive at all and moreover results in instability very fast.
x(t+∆t) = x(t) + v(t) ∆t + ½ a(x(t)) ∆t²
v(t+∆t) = v(t) + a(x(t)) ∆t
O(t1) 1 1x
RK4
(Type RK)
In version 13.0 I implemented Runge-Kutta 4th order to replace Euler. RK4 is much more stable than Euler and furthermore it can handle large integration steps while still keeping the overall error low. One "disadvantage" of RK4 is that it requires four evaluations of the acceleration function (the acceleration between every pair of two bodies has to be computed four times) making a single calculation step take the quadruple calculation time of one Euler step. Despite that, the superior accuracy of RK4 makes its performance better than Euler by a factor of about 300.
kx1 = v(t)				kv1 = a(x(t))
kx2 = v(t) + ½ kv1 ∆t		kv2 = a(x(t) + ½ kx1 ∆t)
kx3 = v(t) + ½ kv2 ∆t		kv3 = a(x(t) + ½ kx2 ∆t)
kx4 = v(t) + kv3 ∆t		kv4 = a(x(t) + kx3 ∆t)
x(t+∆t) = x(t) + ⅙ (kx1+2⋅kx2+2⋅kx3+kx4) ∆t
v(t+∆t) = v(t) + ⅙ (kv1+2⋅kv2+2⋅kv3+kv4) ∆t
O(t4) 4 303x
RKN4(5)
(Type RKN)
In version 15.8 I experimented with Runge-Kutta-Nyström 4(5)th order. RKN4(5) solves the second-order ordinary differential equation of gravity as one instead of splitting it into two first-order ordinary differential equations and then solving them alternating like RK4 does. RKN4(5) requires at least five evaluations of the acceleration function to work and a sixth evaluation for estimating the local error which can then be used for stepsize-control. Stepsize-control is an algorithm which automatically calculates the optimal stepsize for the minimum local error based on the dynamically changing system. For example, it drastically decreases the simulation speed in case of close encounters to maintain accuracy and it increases the speed when all bodies are far apart. This means that with stepsize-control enabled the simulation speed cannot be maintained as constant. Surprisingly, when the stepsize is chosen above the ideal stepsize, RKN4(5) with the original integration coefficients presented by Fehlberg is inferior to RK4 by a factor of 2 in terms of the global energy error.
In version 15.9 I tried another variant of Runge-Kutta-Nyström 4(5)th order with a different set of coefficients (D. G. Bettis). This turned out to be 3 times as accurate as RK4 when only using five evaluations of the acceleration function. It is also twice as stable at large stepsizes than RK4. With this variant of RKN4(5) it is even possible to do stepsize-control with only five evaluations, even though a little different as described in the paper since their claim of f5 of the previous step to be equal to f0 of the next step turned out to be wrong thru my investigations. So for stepsize-control I am using the truncation error in position which does not require the sixth evaluation. The optimal stepsize can be used as a dynamic limit for the maximum stepsize and thus the simulation speed.
Constants ακ, γκλ, Cκ, Ċκ
f0 = a(x(t))
f1 = a(x(t) + ∆t α1 v(t) + ∆t² γ10f0)
f2 = a(x(t) + ∆t α2 v(t) + ∆t² (γ20f021f1))
f3 = a(x(t) + ∆t α3 v(t) + ∆t² (γ30f031f132f2))
f4 = a(x(t) + ∆t α4 v(t) + ∆t² (γ40f041f142f243f3))
x(t+∆t) = x(t) + v(t) ∆t + (C0f0+C1f1+C2f2+C3f3+C4f4) ∆t²
v(t+∆t) = v(t) + (Ċ0f01f12f23f34f4) ∆t
O(t5) 5 922x
Verlet In version 16.2 I tested the Velocity Verlet (also called Störmer-Verlet) integrator in its one-step formulation. Verlet is much easier to implement than RKN4(5). Symplectic integrators like Verlet are the holy grail for gravity simulations. Velocity Verlet is a second order integrator and thus requires two function evaluations per step, but the first evaluation is the same as the last one from the previous step, so it can be implemented using only one evaluation per step, just like Euler. But what makes Verlet so special? The Verlet integration does conserve both the total energy and the total angular momentum, apart from the round-off error. This makes it more stable than even RKN4(5) by a factor of about 1000 and also the total energy error will not increase over time (besides round-off error which settles in the order of 10-7 for the total energy). On top of that, since Velocity Verlet only requires one single evaluation of the acceleration function per step, it is ideal for simulations with large particle numbers, because the body positions can be updated five times as often as with RKN4(5). However, Verlet does not provide a method for stepsize control directly, so a geometric approach could be used in the future.
x(t+∆t) = x(t) + v(t) ∆t + ½ a(x(t)) ∆t²
v(t+∆t) = v(t) + ½ (a(x(t))+a(x(t+∆t))) ∆t
O(t2) 1 940000x
FR
(Type CM)
Version 16.3 was used to test the Forest-Ruth 4th order symplectic integrator. Like Verlet it is symplectic, so the total energy of the system should in theory be conserved, but in reality there is energy loss at large time steps. Also FR only requires three evaluations of the acceleration function due to the constant c1 being chosen to be zero. Unfortunately, it does not provide better performance than Velocity Verlet at large time steps.
Constants ci, di
v1 = v(t)				x1 = x(t)
v2 = v1					x2 = x1 + d1 v2 ∆t
v3 = v2 + c2 a(x2) ∆t		x3 = x2 + d2 v3 ∆t
v4 = v3 + c3 a(x3) ∆t		x4 = x3 + d3 v4 ∆t
v5 = v4 + c4 a(x4) ∆t		x5 = x4 + d4 v5 ∆t
x(t+∆t) = x5
v(t+∆t) = v5
O(t4) 3 123x
RKN3NEW
(Type RKN)
Version 16.5 was used to test the RKN3NEW integrator, which is a symplectified version of the standard Runge-Kutta-Nyström 3rd order integrator. It is described to have minimal phase-lag (the constants define those properties). At large time steps however the total energy is not being preserved as well as with Verlet.
Constants ακ, γκλ, Cκ, Ċκ
f0 = a(x(t))
f1 = a(x(t) + ∆t α1 v(t) + ∆t² γ10f0)
f2 = a(x(t) + ∆t α2 v(t) + ∆t² (γ20f021f1))
x(t+∆t) = x(t) + v(t) ∆t + (C0f0+C1f1+C2f2) ∆t²
v(t+∆t) = v(t) + (Ċ0f01f12f2) ∆t
O(t3) 3 303x


The plot above shows the error propagation with simulation time. Note that on the x-axis not the integration steps are plottet, but the simulated years which are directly proportional to the compute time. Benchmark was the program 'solar system benchmark' which contains 219 bodies, the simulated years are 2016-3016, simulation speed was set to 1.9E10% (about 10 years per second of compute time). It was executed in CPU multithreading mode on seven threads on an Intel Core i7-4720HQ. This benchmark takes about five minutes, independently of the integrator. This means that per simulated year the number of integration steps varies for every integrator, since the different integrators require different numbers of function evaluations. (Integration steps per year: Euler: 842, FR: 260, RKN3NEW: 245, RK4: 213, RKN4(5): 149, Verlet: 862).
As you can see, Verlet stands out from all the other integrators tested. Its error stays below 10-6 independently of the simulation time whilst the errors of all the other integrators increase over time, which makes it the ideal integrator for long-time-simulations. That's the symplecticity of Verlet.
For short periods of time on the other hand, the error of integrators like RKN4(5) stays below machine precision.


Version Logfile

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------
date          |	version name  |	code  |	improvements in physics					      |	gain  |	improvements in graphics
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------

12.04.2014							-------------------- project launched --------------------

22.04.2014	Gravity		194	implementation of simple Euler method in 2D				primitive text-based graphical output

01.05.2014	PhysX2D		307										2D graphics

06.06.2014	Barnes-Hut-Sim.	729	addition of the third spatial dimension					orthogonal 3D graphics with mouse rotation and zoom
					failed attemt of implementing the Barnes-Hut algorithm			flight paths as dots

18.10.2014	PhysX3D v0.0	520	improvement in efficiency by avoiding to pause the calculation	+10000%	coordinate system
					relativistic mass							flight paths as lines

07.08.2015	PhysX3D v1.0	2211	sphere space restriction						velocity vectors, groupings
					retarded gravitational potential					perspective 3D-graphics with adjustable field of view
					seperated calculation and graphics threads				keyboard interaction
					adjustable simulation speed						camera switching between bodies
					possibility to print data output					visibility and occultation
					collision detection							grid() and cube() methods for visualising gravity
					more demo programs							relativistic grid() with filter for gravitational waves
														autorotation
														velocity-distance-diagram
														addition of class Launcher for primitive GUI

15.11.2015	PhysX3D v2.0	2337	multithreading in n-body-calculation				+150%

29.12.2015	PhysX3D v3.0	2329	automatic decision between single- and multithreading
					shortened code due to finishCalc()
					more demo programs

18.01.2016	PhysX3D v4.0	2333										frame buffer for more fluid graphics

21.02.2016	PhysX3D v5.0	2811	configuration methods configurePhys() und configureOut()		improved coordinate transformation in convert()
					solar system from JPL database						dynamic osculating Keplerian orbit calculation

27.03.2016	PhysX3D v6.0	3212	substential error fixes in relativistic calculation			improved coordinate transformation in convert()
					linear interpolation in relativistic calculation			free camera and improved keyboard interaction
					extended JPL solar system						addition of blooming-effect
														automatic counterrotation

31.03.2016	PhysX3D v7.0	3260	code outsourcing into relCalc() for more efficiency		+20%	improved filter for gravitational waves
					improvement of sphere() for more efficiency			+10%

03.04.2016	PhysX3D v8.0	3246	error fixes								improved mouse interaction
					time dilation

12.05.2016	PhysX3D	v9.0	3264	change of grid() method from force to potential				more efficiant graphics
														polygon graphics with dynamic lighting

12.05.2016	PhysX3D	v9.1	3296	failed attemt to improve efficiency by using "actio=reactio"	-10%

26.08.2016	PhysX3D	v10.0	3552	addition of date and time tracking					stereoscopic side-by-side graphics for VR
		(from v9.0)

31.08.2016	PhysX3D	v11.0	3621	rotation data of planets and moons in JPL solar system			full-screen-mode and fixed offset problem
					extended insert() method of PhysX class					rotation of bodies around an arbitrary axis
														graphical visualisation of planetary rings
														possibility of many light sources
														improved efficiency in drawing single pixels
														improved nomenclature of demo programs and user manual
														simplification and improvement of the GUI

06.09.2016	PhysX3D	v12.0	3638	complete separation of physics and graphics			+20%	improved mouse interaction
					adjustment of initial-guess the size of a time step			improvement of Launchers
					automatic detection of the amount of CPU cores				fixing an error regarding exported .jar file

06.09.2016	PhysX3D	v12.1	3637	failed attemt to improve efficiency by avoiding subtractions	-30%

12.09.2016	PhysX3D	v13.0	3722	replacement of Euler method by Runge-Kutta 4th order		+2000%
		(from v12.0)		improvement of sphere() for more efficiency			+5%
					error fixing in collision detection
					substantial improvement in efficiency due to micro optimisation	+130%

16.09.2016	PhysX3D	v14.0	3714	improvement in multithreading					+15%	addition of CPU and RAM usage monitor
					RAM limitation to 500MB using System.gc()				small improvement of convert()
														improvement of user manual

13.09.2016	PhysX3D	v14.1	3731	failed attemt to improve RK4					-20%

02.10.2016	PhysX3D v14.2	3723	improved garbage collection due to variable recycling		+10%	improvement of osculating orbit calculation
		(from v14.0)		english designation of solar system bodies				improved blooming effect
					improved configuration of PhysX and Window class
					extended spacecraft catalogue in the JPL solar system
					more possibilities for simulating parts of the solar system
					supplement of planetary rotation data

16.11.2016	PhysX3D v14.3	3749	avoidance of unnecessary memory access					improvement of synchronized output data
					option to pause and resume the n-body-calculation			locked camera position when not in free mode

02.10.2016	PhysX3D v15.0-2		experimental implementations of GPU computation via aparapi

25.11.2016	PhysX3D v15.3	4021	successful implementation of GPU computation via aparapi	+700%
		(from v14.3)		method for generating galaxies

22.10.2016	PhysX3D v15.4		experimental model for gravity in toroidal space

02.12.2016	PhysX3D v15.5	4007	faster square root from aparapi Kernel				+720%	improvement in drawing shapes via subtype polymorphism
		(from v15.3)		removal of GPU FP64 requirement						improvement in blooming effect memory management

11.02.2017	PhysX3D v15.6	4018	huge improvement in startup time and memory usage			improvement of convert() by combined rotation matrix
					micro optimisation in orbit calculation					parallel sorting algorithm for visibility / occultation
					method for calculating the error of total energy			improved movement and rotation of free camera
														70% faster orbit plotting with combined rotation matrix
														faster sphere rendering with combined rotation matrix
														avoidance of re-calculating output data when paused
														improved VR perspective in free camera mode
														improved memory usage of VR mode
														option to change line thickness
20.03.2017	PhysX3D v15.7	4618	bug fixes								zoom adjustment for free camera mode
					better simulation time tracking						simplification and memory improvement of convert()
					faster StrictMath.sin/cos/tan functions					40% faster blooming effect
					extended spacecraft catalogue in the JPL solar system			i,O,w instead of euler angles for osculating orbits
					extended asteroid catalogue in the JPL solar system			calculation and visualization of eccentric anomaly

30.03.2017	PhysX3D v15.8	4367	tests of RKN4(5) with adaptive stepsize
					read simple programs from .txt files without hardcoding

09.04.2017	PhysX3D v15.9	4271	tests of RKN4(5) with coefficients from D. G. Bettis

15.04.2017	PhysX3D v16.0	3218	replacement of RK4 by RKN4(5) (D. G. Bettis)			+200%	automatic initial zoom
					limit of speed at close encounters via stepsize-control			smoothed fps for on screen display
					removal of tidal friction and relativistic calculation			continuous zoom
					export of configuration and programs to editable file system
					improved internal configuration methods

16.04.2017	PhysX3D v16.1	3584	experimental implementation of Barnes-Hut algorithm in 3D		visualization of 3D Barnes-Hut tree

30.07.2017	PhysX3D v16.2	3296	replacement of RKN4(5) by Velocity Verlet integrator		+102000%
					added galaxy supercluster simulation
					more accurate date and time tracking

30.04.2017	PhysX3D v16.3	3324	experimental implementation of FR 4th order integrator		-99.98%

08.06.2017	PhysX3D v16.4	3374	test of Richardson extrapolation on Velocity Verlet		-99.97%
		(from v16.2)

31.05.2017	PhysX3D v16.5	3333	experimental implementation of RKN3NEW integrator		-99.96%
		(from v16.2)

05.06.2017	PhysX3D v16.6	3267	failed attempt to improve multithreading
		(from v16.2)

09.07.2017	PhysX3D v16.7	3347										failed attempt to implement motion blur
		(from v16.2)

30.07.2017	PhysX3D v16.8	3273	failed attempt to improve multithreading
		(from v16.2)

03.08.2017	PhysX3D v16.9	3666	version for benchmarking all different integrators of previous versions
		(from v16.2)

06.09.2017	PhysX3D v17.0	3297	failed test of aparapi 1.4.0
		(from v16.2)

25.11.2017	PhysX3D v17.1	3314	much faster GPU kernel (shared memory optimization)		+92%	more compact code with inner classes
		(from v16.2)											removal of CPU usage monitor (up to 50% faster graphics)
														lower memory usage
														fixed off center rendering in vr mode
														lines and polygons in screen corners are now rendered

04.11.2017	PhysX3D v17.2	3317										experimental version for frame time analysis for v17.1
		(from v16.2)

05.11.2017							-------------------- transition to C++ --------------------

05.11.2017	PhysX3D v17.1	2410	cloning of PhysX3D to C++

24.06.2018	PhysX3D v18.0	2401	CPU vectorization in C++					+115%

26.08.2018	PhysX3D v18.1	2428	slightly faster GPU kernel (improved memory coalescence)	+8%
					better detection of the fastest available GPU

18.04.2018	PhysX3D v18.2	2432	minor bug fix								improved mouse rotation

Template for the File System

# Configuration ############################################################################################################################################################################################################################################################################################################### 
# Every line starting with a "#" is a comment. When the first character in the file name is a "#", the file will be ignored.
# The first 3 lines not starting with a "#" are reserved for configuration and cannot be removed. Every additional line will be read as a new body.
# Every line must contain the proper amount of "," to seperate the values. There is no "," after the last cell of the line. Empty cells will be filled with the default values automatically.
# All set values must be in the right format indicated by the default values. (boolean: true/false, integer: 0/+0, double: 0/0.0/+0.0E+0). The color rgb values must be within the interval [0, 255].
# The number of spaces and tabs as well as the position of the "," does not matter. Line breaks to seperate complete lines with the proper amount of "," will be ignored.

# Basic Settings ###################################################################################################################### 
# enable GPU acceleration       error tolerance monitor fps     coordinate system size  path length     grid resolution cube resolution 
# default:                true,           1E-3,             60,                  500.0,              3,             30,             10  
# ''''''''''''''''''''''''''''| ''''''''''''''| ''''''''''''''| ''''''''''''''''''''''| ''''''''''''''| ''''''''''''''| ''''''''''''''| 
                              ,               ,               ,                       ,               ,               ,                 

# Units ############################################################################################################################### 
# time [s]              mass [kg]               length [m]              size [m] (scale radius) gravitational constant [m^3/kg*s^2]	
# default:         1.0,                    1.0,                    1.0,                    1.0,                                   50.0  
# ''''''''''''''''''''| ''''''''''''''''''''''| ''''''''''''''''''''''| ''''''''''''''''''''''| ''''''''''''''''''''''''''''''''''''''| 
                      ,                       ,                       ,                       ,                                         

# Initial Time and Date ############################################################################################################### 
# year                  month                   day                     hour            minute          second          millisecond	
# default:           0,                      1,                      1,              0,              0,              0,              0  
# ''''''''''''''''''''| ''''''''''''''''''''''| ''''''''''''''''''''''| ''''''''''''''| ''''''''''''''| ''''''''''''''| ''''''''''''''| 
                      ,                       ,                       ,               ,               ,               ,                 

# Initial State of Bodies ##################################################################################################################################################################################################################################################################################################### 
# name                  color (r,g,b)   radius                  star?   ring?   mass                    x position              y position              z position              x velocity              y velocity              z velocity              axis inclination        axis right ascension    rotation period         
# default:           -,  255, 255, 255,                    1.0,  false,  false,                    1.0,                    0.0,                    0.0,                    0.0,                    0.0,                    0.0,                    0.0,                    0.0,                    0.0,               infinity  
# ''''''''''''''''''''| ''''''''''''''| ''''''''''''''''''''''| ''''''| ''''''| ''''''''''''''''''''''| ''''''''''''''''''''''| ''''''''''''''''''''''| ''''''''''''''''''''''| ''''''''''''''''''''''| ''''''''''''''''''''''| ''''''''''''''''''''''| ''''''''''''''''''''''| ''''''''''''''''''''''| ''''''''''''''''''''''| 

Details

Java version C++ version
Code Lines: 3314 2432
Integration Method: Velocity Verlet Velocity Verlet
Latest Version: 17.1 (25.11.2017) 18.2 (18.04.2018)

System Requirements

Java version C++ version
CPU: 2 GHz Dual-Core 2 GHz Dual-Core
RAM: 500 MB 135 MB
GPU: optional, OpenCL support required optional, OpenCL support required
Software: Java Runtime Environment Windows 10 64-bit

Download

PhysX3D v17.1 Java.rar (just unzip the folder, no installation required)
PhysX3D v18.2 C++.rar (just unzip the folder, no installation required)

Demo


References

 - 
T.J. Stuchi. (2002). Symplectic Integrators Revisited
 - 
N. Senu, M. Suleiman, F. Ismail, M. Othman. (2010). A Zero-Dissipative Runge-Kutta-Nyström Method with Minimal Phase-Lag
 - 
E. Forest, R.D.Ruth. (1989). Fourth-Order Symplectic Integration
 - 
Wikipedia. Velocity Verlet
 - 
D. G. Bettis. (1972). A Runge-Kutta Nyström Algorithm
 - 
Erwin Fehlberg. (1987). Neue Runge-Kutta-Nyström Formelpaare 3(4)-ter und 4(5)-ter Ordnung
 - 
C.J. Voesenek. (2008). Implementing a Fourth Order Runge-Kutta Method for Orbit Simulation
 - 
René Schwarz. (2014). Cartesian State Vectors to Keplerian Orbit Elements (Memorandum #2)
 - 
Larry Bogan. (2004). Relationships of the Geometry, Conservation of Energy and Momentum
 - 
NASA Jet Propulsion Laboratory. HORIZONS Web-Interface
 - 
Wikipedia. List of Solar System objects by size
 - 
Wikipedia. Axial tilt of Solar System bodies
 - 
René Schwarz. (2014). Astrodynamical Constants (Memorandum #5)
 - 
Wikipedia. Schrittweitensteuerung
www.000webhost.com