Regarding the recent post in p.b.o-t about RK methods and n-body simulations,
here's what happens if you use the tree method.  See p.b.a. for animation.  The
simulation itself only took a couple hours up to this point with 30000
particles.

Again, it's not actually correct, but there's a threshold parameter that
determines when calculating forces whether the ratio of the potential size of a
node relative to the distance to that node is large enough that you need to look
at the children more closely.  If the threshold is zero then you look at the
whole tree ( O(n^2) ); if it's too big you overlook a lot of detail ( O(n log
n) ).  Somewhere in the middle is apparently a good enough compromise to within
a few percent.  The  force calculation is expensive enough that building the
tree at each RK sub-time-step is very little overhead.

There's a c program with an OpenGL interface if anyone's interested although
I'll have to make a couple parameters more obvious before posting.  Thanks for
the fun idea!

 - Ricky

Post a reply to this message

Attachments:
Download 'nbody.jpg' (121 KB)

Preview of image 'nbody.jpg'

I dont suppose there is any chance you might post the code for this, please?

DaSilvor


"triple_r" <nomail@nomail> wrote in message 
news:web.4895f19fe5f40d6fef2b9ba40@news.povray.org...
> Regarding the recent post in p.b.o-t about RK methods and n-body 
> simulations,
> here's what happens if you use the tree method.  See p.b.a. for animation. 
> The
> simulation itself only took a couple hours up to this point with 30000
> particles.
>
> Again, it's not actually correct, but there's a threshold parameter that
> determines when calculating forces whether the ratio of the potential size 
> of a
> node relative to the distance to that node is large enough that you need 
> to look
> at the children more closely.  If the threshold is zero then you look at 
> the
> whole tree ( O(n^2) ); if it's too big you overlook a lot of detail ( O(n 
> log
> n) ).  Somewhere in the middle is apparently a good enough compromise to 
> within
> a few percent.  The  force calculation is expensive enough that building 
> the
> tree at each RK sub-time-step is very little overhead.
>
> There's a c program with an OpenGL interface if anyone's interested 
> although
> I'll have to make a couple parameters more obvious before posting.  Thanks 
> for
> the fun idea!
>
> - Ricky
>

Post a reply to this message

"DaSilvor" <das### [at] rariuscouk> wrote:
> I dont suppose there is any chance you might post the code for this, please?


No problem.  Just wasn't sure it was that interesting, but here it is, complete
with RK 2, 4, and 8 (ouch!) and plenty of octree visualization with OpenGL.

It should compile with very minimal effort on Mac OS X or Unix/Linux.  (On Mac
OS X you need the funny flag that's commented out in the Makefile for some
bugfix.)  Windows?  It should work in theory, but I'm not sure how to make it
compile with GLUT.  If it doesn't work you can comment out the OpenGL stuff in
main.c and copy the integration from gldisplay.c over to main.c.

No warranty of course, but I hope someone can get something out of it.  It's all
there, just DON'T BE AFRAID TO READ THE SOURCE AND THE README FILES!

http://rsreusser.googlepages.com/barnes_hut.tar.gz

 - Ricky

Post a reply to this message

"triple_r" <nomail@nomail> wrote:


> If it doesn't work you can comment out the OpenGL stuff in
> main.c and copy the integration from gldisplay.c over to main.c.


I've simplified this so now there's just an OPENGL flag in common.h that should
turn on/off the OpenGL stuff.  Just comment it out and recompile to turn off
OpenGL entirely.

 - Ricky

Post a reply to this message

Ah, yes, right.

I was expecting a pov file.
No worries

Dave





"triple_r" <nomail@nomail> wrote in message 
news:web.489bb23e27c5a961ca4884450@news.povray.org...
> "triple_r" <nomail@nomail> wrote:
>
>
>> If it doesn't work you can comment out the OpenGL stuff in
>> main.c and copy the integration from gldisplay.c over to main.c.
>
>
> I've simplified this so now there's just an OPENGL flag in common.h that 
> should
> turn on/off the OpenGL stuff.  Just comment it out and recompile to turn 
> off
> OpenGL entirely.
>
> - Ricky
>

Post a reply to this message

"DaSilvor" <das### [at] rariuscouk> wrote:
> Ah, yes, right.
>
> I was expecting a pov file.
> No worries

Ah.  Sorry.  Perhaps I should have been more clear that the simulation itself
was in C.  Once you figure out the compiling, the jump from POV-Ray to C isn't
that bad, so if this sort of thing is interesting to you it might be worth
figuring out.  There's a reason (speed!) things like ClothRay or MechSim are
patched into POV-Ray rather than written in POV-Ray, but POV-Ray certainly has
its place, too.

 - Ricky

Post a reply to this message