I am not sure about "conservation is encoded" part, but I can believe it. Either way, in practice the simulations will encounter issues along these lines if they are not careful. For example, I left your simulation running for what amounted to ~120 yrs and saturn lost all her moons. This is the best pic I could get, sorry (hopefully it is reproducible): https://i.imgur.com/C7emd28.png
Since you do not report anything about conservation of energy/momentum, how do we know that isn't the problem?
Thanks! heh, it is rather complex there are all sorts of things... most likely the new gravity function set for that model messed up, which can apply attraction between groups of objects if they are distant and weak enough.
But honestly I am certain that it is something in particular and not something mysterious about conservation of energy/momentum which i have not come across yet, because there is no formula in that gravity simulation which should be able to destroy momentum. In the other models, there are quasi-physical friction and pressure functions which do destroy momentum and do have some rough adjustments to compensate for that somewhat, but accuracy is lost whether things are compensated for or not. Tracking energy and momentum can be a good way for tracking accuracy of a model, but if you do any adjustments to correct it, that is a kind of fudge not based in true physics. It is poignant that you expressed scepticism of climate models because of a perceived lack of such adjustments, while the opposite is actually true. Climate models have to include a lot of calibrated adjustment and quasi-physics, because the whole system is too complex to represent at all relevant scales. This should not condemn the work of computer scientists specialised in climate modelling to undue scepticism.
It's a well established fact that numerical integration methods either gain or lose energy (in particular, the Runge-Kutta family is known to lose energy over time). For celestial mechanics simulations, a special class of numerical integration methods called "symplectic integrators" are used and their purpose is to conserve energy and angular momentum.
> but if you do any adjustments to correct it, that is a kind of fudge not based in true physics.
When you are numerically integrating differential equations that model physical phenomena, you're not doing "true physics" but an approximation thereof.
And an approximation that makes Earth drift 70 km per year or Saturn's moons drift out of orbit in a few hundred years is a very bad approximation by scientific standards.
The methods used for celestial mechanics calculations need to be precise over thousands to millions of years. And the way they work is to "fudge" with the numerical methods to preserve energy and angular momentum. It's a much better approximation of "true physics" than your toy simulation.
Your assumption that the issues are due to floating point errors is incorrect. 64 bit double precision is millimeter accurate to the orbit of Neptune. That's good enough for scientific applications.
If you're interested in this, you could take a look at this scientific grade N-body simulator and the methods it uses: https://github.com/hannorein/rebound
Its not as easy as declaring the resolution of absolute position. If you really want to spend the time on figuring it out, then examine the difference in scale between the bodies positions, velocities, accelerations given different model timestep values, what happens during the squaring summing and rooting, multiplying by G of those values and also even (because i have looked into this before) the subdivided timestep values involved in tempering this models data, so it becomes a perfectly stable quantised version of its anologe values (with no need for the kind of corrections Runge-Kutta is notable for)
That link is very intresting to me thankyou. You can notice that it includes some quite simple integration schemes as 'symplectic' (basically means stable without need for gross correction)
It's a good point of order though, I got this mixed up last time I looked at issues in that system. I got fed up trying to explain, that the integration scheme used there is "symplectic" - it doesn't require gross adjustments, so the many bugs that have and will spring up shouldnt be patched with gross adjustments. If the model is gaining or loosing energy, i cant blame it on the integrator or on missing physics.
So regardless of that, thanks for the correction, i had got it in my head 53bit mantissa was somewhat less than mm resolution at Neptune. Im still wary that the resolution could easily cause problems, but accept there is a fair chance these could be avoided with careful calculations.
Thanks for the good discussion. I'm still unconvinced that asking for climate models to report on conservation of energy is "undue speculation", but I really don't know how big a deal it is. Anyway, I looked at my old code and here is some R to get the JPL data and convert to state vectors, hopefully you can use/translate it to easier test your sim:
dlHorizons <- function(ObjName = "Apophis",
sd = "2000-Jan-01", st = "00:00:00",
ed = "2000-Jan-02", et = "00:00:00",
stepSize = "1", stepUnit = "d"){
root = "http://ssd.jpl.nasa.gov/horizons_batch.cgi?batch=1&"
start = paste0("START_TIME%20=%20%27", sd, "%20", st, "%27&")
end = paste0("STOP_TIME%20=%20%27", ed, "%20", et, "%27&")
tble = "TABLE_TYPE%20=%20%27Vector%27&"
RefPlne = "REF_PLANE%20=%20%27Ecliptic%27&"
RefCntr = "CENTER%20=%20%27@000%27&"
VecTab = "VECT_TABLE=%20%272%27&"
step = paste0("STEP_SIZE= %27", stepSize, "%20", stepUnit, "%27&")
Cmd = paste0("COMMAND=%20%27",ObjName, "%27")
res = scan(paste0(root, start, end, tble, RefPlne, RefCntr, VecTab, step, Cmd), what="")
return(res)
}
extractEphemeris <- function(input){
ends = grep("(\\$\\$SOE)|(\\$\\$EOE)", input)
input = input[ends[1]:ends[2]]
dates = input[grep("(TDB)", input) - 2]
times = input[grep("(TDB)", input) - 1]
start = grep("(TDB)", input) + 1
end = start + 5
ret = as.data.frame(matrix(nrow = length(start), ncol = 8), stringsAsFactors=F)
colnames(ret) = c("Date","Time", "px", "py", "pz", "vx", "vy", "vz")
for(i in 1:length(start)){
ret[i,3:8] = as.numeric(input[start[i]:end[i]])*1000
}
ret$Date = dates
ret$Time = times
return(ret)
}The tricky thing I ran into with the JPL NEO data was they don't seem to release the co-ordinates for them as they do the major solar system bodies. It looks like they just serve out a selection of orbital and observational measurements, which someone has figured out how to convert already, but it could take me ages.
https://ssd.jpl.nasa.gov/sbdb_query.cgi
A priority for the project is tidying and documenting code so that other people might use it. Recently facility for efficient collision processing was built, next I want to accommodate multi-point objects and types of bonds, to start more down to earth simulations which is what Im most interested in - dynamic spatial awareness for vacuum cleaners and things :)