Comments on: Groovy Gravity Processing https://www.barneyb.com/barneyblog/2010/05/28/groovy-gravity-processing/ Thoughts, rants, and even some code from the mind of Barney Boisvert. Thu, 11 Sep 2014 09:58:12 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Peter Teuben https://www.barneyb.com/barneyblog/2010/05/28/groovy-gravity-processing/comment-page-1/#comment-213293 Peter Teuben Sat, 05 Jun 2010 03:17:38 +0000 http://www.barneyb.com/barneyblog/?p=1534#comment-213293 A 4th order will just delay execution. Just try a simple 2body problem with a highly eccentric orbit as test case. You might be able to do better with an RK45 variable timestep, I've never tried that but remember learning about this adaptive technique in college. But in practice the Aarseth technique seems to have worked well. Might be fun to try that RK45 one in the nbody0 code. A 4th order will just delay execution. Just try a simple 2body problem with a highly eccentric orbit as test case. You might be able to do better with an RK45 variable timestep, I've never tried that but remember learning about this adaptive technique in college. But in practice the Aarseth technique seems to have worked well. Might be fun to try that RK45 one in the nbody0 code.

]]> By: barneyb https://www.barneyb.com/barneyblog/2010/05/28/groovy-gravity-processing/comment-page-1/#comment-213279 barneyb Fri, 04 Jun 2010 17:52:35 +0000 http://www.barneyb.com/barneyblog/?p=1534#comment-213279 Peter, That's exactly the conclusion I'd come to as well. ;) I tightened up the slicing which helps, and I'm currently changing the way I do the integration over the slices with a more accurate method (RK4). Depending on how that works out I'll consider adaptive slicing as well. I'll definitely check out Aarseth's stuff though. I've been doing a bit of research of optimizing N-body, but I need to invest some time in building a 3D viewer (which is simple) and the corresponding navigation controls (which is harder), along with some better status tracking, before I go crazy with the back end. Peter,

That's exactly the conclusion I'd come to as well. ;) I tightened up the slicing which helps, and I'm currently changing the way I do the integration over the slices with a more accurate method (RK4). Depending on how that works out I'll consider adaptive slicing as well. I'll definitely check out Aarseth's stuff though. I've been doing a bit of research of optimizing N-body, but I need to invest some time in building a 3D viewer (which is simple) and the corresponding navigation controls (which is harder), along with some better status tracking, before I go crazy with the back end.

]]> By: Peter Teuben https://www.barneyb.com/barneyblog/2010/05/28/groovy-gravity-processing/comment-page-1/#comment-213248 Peter Teuben Fri, 04 Jun 2010 01:46:27 +0000 http://www.barneyb.com/barneyblog/?p=1534#comment-213248 I would check energy conservation, gravity close encounters are notoriously hard to deal with, and if you timesteps are not adaptive (sort of smaller steps when accellerations are larger), you will not keep the energy conserved very well and you can get slingshots very easily. A neat way to do adaptive timestepping was proposed by Sverre Aarseth back in 1963. His codes are freely available. I have copies in fortran and C. I would check energy conservation, gravity close encounters are notoriously hard to deal with, and if you timesteps are not adaptive (sort of smaller steps when accellerations are larger), you will not keep the energy conserved very well and you can get slingshots very easily.
A neat way to do adaptive timestepping was proposed by Sverre Aarseth back in 1963. His codes are freely available. I have copies in fortran and C.

]]>