Maximum point number in point distribution example

[DaniBas]

Which is the maximum number of points to manage with the distribution
example. i am working on this definition but i need to manage 2000
points aprox (u:16 v:120). is there any path to accelerate the
resolution? when i try to run simulation with this amount of points it
crashes. can i just solve without visualizing simulation?

any idea?

dani.

[David Stasiuk]

You could perhaps reduce the timer refresh rate, be sure to minimize the GH window before unlocking all timers, and hide all the geometry.

[daniel piker]

Hi Dani,

I think 2000 points will be a bit of a struggle with this definition as it is at the moment, (but maybe possible with some patience).

This is particularly because its complexity is O(N^2) - because all particles have to interact with each other, so you have around 4 million force calculations per iteration.

The cutoffs help a little (because above this distance it avoids calculating a costly square root), but it still has to check all of them.

If there was some way you could start with a somewhat reasonably distributed point arrangement, and optimize that using only force connections between points and their immediate neighbours it would be much lighter. Maybe you could distribute a smaller number of points, and then use them as the basis for the starting arrangement of the larger number through some sort of subdivision.

Another thing that is sometimes very helpful when dealing with very large heavy simulations in kangaroo is to not use the timer at all, but just set a high value for Subiterations. this calculates intermediate iterations without drawing them to screen, so can be significantly quicker.

There are computational techniques for improving this sort of thing (like Barnes-Hut), which I may some day have a go at tackling but probably not soon. Another thing that could help a lot would be if we can thread or multi-thread the code, which is definitely something I'm hoping to to do.

Daniel

[DaniBas]

hi,

starting with a distributed point geometry on surface helps a lot.

still improving definition. i will report any goals, jj.

thanks v m.

On Jan 5, 8:26 pm, daniel piker <danielpi...@gmail.com> wrote:
> Hi Dani,
>
> I think 2000 points will be a bit of a struggle with this definition as it
> is at the moment, (but maybe possible with some patience).
>
> This is particularly because its complexity is O(N^2) - because all
> particles have to interact with each other, so you have around 4 million
> force calculations per iteration.
> The cutoffs help a little (because above this distance it avoids calculating
> a costly square root), but it still has to check all of them.
>
> If there was some way you could start with a somewhat reasonably distributed
> point arrangement, and optimize that using only force connections between

> points and their immediate neighbours it would be *much* lighter. Maybe you

> could distribute a smaller number of points, and then use them as the basis
> for the starting arrangement of the larger number through some sort of
> subdivision.
>
> Another thing that is sometimes very helpful when dealing with very large
> heavy simulations in kangaroo is to not use the timer at all, but just set a
> high value for Subiterations. this calculates intermediate iterations
> without drawing them to screen, so can be significantly quicker.
>
> There are computational techniques for improving this sort of thing (like
> Barnes-Hut), which I may some day have a go at tackling but probably not
> soon. Another thing that could help a lot would be if we can thread or
> multi-thread the code, which is definitely something I'm hoping to to do.
>
> Daniel
>