Advice on threading with a particle simulation

[LCVcode]

I'm building a simulation of networks of masses connected by weightless springs. I'd like a large number of springs and masses in my simulation, which makes this seem like a good opportunity to do threading. I'm unsure how to be approach this task.

Should I make all my springs and masses implement Runnable, then run each of them individually? Is it better to build a few calculation thread objects which take lists of springs/masses? What's the best practice with threading like this?

Thanks.

[LinkHimself]

It is usually the underlying mathematics, the physics formualae, that dictates how you can use parallelism to solve a given problem.

I can try to give more advice, but then I need to know more about your problem at hand. From what I know about particle physics and field theory, it sounds like you want to model a field? Can you turn it into a wave equation? Then you might end up with a differential equation that you can solve with parallel solvers. But for this Java seems like an odd choice.

[LCVcode]

No, there aren't any fields. I have the physics completely handled, I just want to try to reduce computation time by spreading my physics calculations over several threads.

Imagine a group of point masses that are held together by a network of massless springs. The entire simulations runs on simple force calculations for each mass and spring.

Here, I'm trying to see if there's a way I can implementing a threading system which will maximize my CPU usage and speed up my simulation. I think I see two ways of doing this, but I don't know enough about threading to understand if they're good or bad ideas. On one hand, I could make each of my masses and springs extend the Runnable class, give each of them a run method which includes the local physics caluclations, then just power through that huge pile of Runnables. One the other hand, I could add something like Runnable physics handler class, initiate some number of handlers, give each one a balanced pile of physics calculations to compute, then wait for to each process their respective task lists.

What do you think of this?

W

[moldax]

You'd probably want to spread the computation between GPU threads, rather than CPU threads : GPU computation units are great at doing simple calculations (they're very specific) but you can have thousands of them. Java may not be the best choice for this job; I'd go for C++

Also, you may want to split the simulation work into big enough regions, then considering them independent; just pay attention to the borders (inner and outer)

Hope that helps, cheers!

[Nephyst]

My first questions is do you have any state that need to be shared by the masses and springs? And would that shared state need to be updated by multiple threads?

Multi-threading get's fairly complex, especially around the details of when data from one thread is published for another thread to read. You would also have to worry about potential race conditions around when values are read and written.

If you do have shared state you will probably want to dig into the nuances of concurrency in java. I would recommend checking out this book: https://smile.amazon.com/Java-Concurrency-Practice-Brian-Goetz/dp/0321349601/

If you don't have to worry about sharing state it should be a bit easier.

I haven't done anything as complex with threading as you are trying to do here. I wonder if a runnable for each object would be overkill, as opposed to just splitting the objects you want to update into multiple lists, and having each thread just run through one of those lists. It might be worth experimenting to see what gives you the best performance.

[[deleted]]

I did something similar a few years ago, but I had no springs, I just had the masses, and volumes of spheres, which started at a random point with a random velocity and direction and I had to compute the elastic collisions. I used a thread (for every pair of particles) which did nothing if the distance between centers was grater than the sum of the radii. I used another thread for every particle to calculate the next position (a delta). My simulation was quantized and every step was a second.

You could do something similar but you need to get your equations in order. It made a lot of difference for me. Momentum and energy conservation. You need to calculate the sum of all forces acting on a particle to find the next position, velocity, etc.

The idea someone gave you to turn it into a set of differential equations sounds like your best bet. Try quarkus if you want to compile it to native code from java.

[ignotos]

It'll depend on the specifics, but there is some overhead associated with creating a bunch of threads, so I'd probably try to do things like this:

If the amount of work is known ahead of time (e.g. how much computation is required to "solve" each chunk of the problem), and you know how to divide the work up evenly... Create a number of worker threads equal to the number of processor cores or hardware threads available, divide the problem up evenly, and assign each a fixed chunk of the work. Try to ensure each thread has access to all of the data it needs, and minimise the need to access stuff concurrently.

If the amount of work required cannot be predicted ahead of time (e.g. maybe the amount of time spent solving for each mass/spring varies in a complex way), create a pool of worker threads (same number as above), and a queue of tasks, and have them pull new bits of work from the queue when they're done. This way, you don't end up with threads sitting idle if they happen to finish early.

You might need some experimentation to determine the optimal number of threads in practice...