3 ms·

>"Conservation of energy, momentum, information is hardcoded into all known laws of Physics. It is our integration algorithms which do not all ensure conservati

• strainer 10y ago
  >For example, I left your simulation running for what amounted to ~120 yrs and saturn lost all her moons. 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.
  • exDM69 10y ago
    > 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 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 https://github.com/hannorein/rebound
    • strainer 10y ago
      > Your assumption that the issues are due to floating point errors is incorrect. 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)
  • nonbel 10y ago
    >"Quite precise data for thousands of NEOs is available, but its needs converted to position and movement vectors to use in this simulation." https://github.com/strainer/fancy https://github.com/strainer/fancy 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) }
    • strainer 10y ago
      Thankyou for bearing with me - Ive been under the weather and have trouble explaining myself at the best of times. 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 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 :)