Hacker News new | past | comments | ask | show | jobs | submit login

It says in your readme[1] though that your solar system simulation simulation is off by 70k km (regarding Earth orbit) after only 1 year relative to the JPL ephemerides, for "unknown reasons". I don't see how you can use that to justify not checking for conservation of momentum/energy.

I also do not understand your final sentence.

[1] https://github.com/strainer/fancy




Come on it doesnt say "unknown reasons" it says the "It is possible the discrepancy is due to the limitation of javascripts 64bit FP numbers rather than subtle algorithmic or physics error"

70k km / a year (on a billion km long orbit) was a lot closer than I had hoped for, considering its a 64 bit newtonian model. But this is beside the fact that having worked on the project a fair bit, I understand that any model adjustments to conserve energy or momentum are non-physical 'fudges' to correct deficiencies of the model. There are no laws of physics dedicated to adjusting energy, momentum, information in order to conserve them. They are conserved by a mathematical correctness of every physical law - a proper account of that eludes me, but it is certainly explained somewhere.


Right, you don't know how much error the floating point error accounts for. You also brought up loss of angular momentum to solar wind, etc. These are all just speculations. That may be fine for the purposes of your simulation, but not for predicting if asteroids will impact the earth or the influence of human activity on Earth's climate.

Also, I know you are supposed to use a symplectic integrator to ensure conservation of energy when doing these simulations, so it is not somehow hardcoded into the laws, eg: https://en.wikipedia.org/wiki/Leapfrog_integration


We could certainly calculate how much error was introduced by rounding, if we had the time and inclination. It is useful to understand that about numerical modelling, it should not be necessary to accept any indeterminable discrepancies.

Conservation of energy, momentum, information is hardcoded into all known laws of Physics. It is our integration algorithms which do not all ensure conservation of information - but that is carefully achievable with basic first order schemes, such as Verlet and leapfrog integration.


>"Conservation of energy, momentum, information is hardcoded into all known laws of Physics. It is our integration algorithms which do not all ensure conservation of information - but that is carefully achievable with basic first order schemes, such as Verlet and leapfrog integration."

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?


>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.


> 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


> 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)


>64 bit double precision is millimeter accurate to the orbit of Neptune.

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.


>"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

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)
  }


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

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 :)


> There are no laws of physics dedicated to adjusting energy, momentum, information in order to conserve them. They are conserved by a mathematical correctness of every physical law

The physical laws guarantee conservation, yes. But not all numerical methods for solving differential equations do.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: