How to find current forces applied to particles

Replies to This Discussion

Permalink Reply by Daniel Piker on November 7, 2017 at 9:00am

Hi Cory,

I just put an example script here:

https://github.com/Dan-Piker/Kangaroo-examples/commit/8f0403dcb0f85...

That lets you see the vectors applied to each particle and which goals they come from as you step through the simulation

Related to how the solver works, the vectors shown here are actually the 'move' vectors, and the numbers are the weightings. To get forces, you would multiply each move by its respective weighting value.

Permalink Reply by Cory on December 1, 2017 at 8:43am

Thanks - this is useful. I wasn't able to get the main component to output anything, but rewrote it in python for my own purposes and all the calls seem to work. Using a custom iterator to drive kangaroo will definitely provide the control I've been struggling to find with custom goals. I'm now hoping to reimplement BouncySolver while leaving hooks to inspect or modify the system at each iteration. I have some questions about the API:

• GetAllMoves() is returning vectors here after a reset but without any steps applied. At what point are goals' Calculate methods being called?
• How does SimpleStep differ from Step?
• Is there a call to check for convergence, or does the GH solver module do that itself?

Permalink Reply by Daniel Piker on December 4, 2017 at 8:35am

Hi Cory,

Sorry for taking a while to get back to you on this.

-GetAllMoves is returning whatever the current move vectors of each goal are. These actually don't currently get reset when you reset the solver (since they get recalculated with each iteration when the Calculate method is called for the goal). So after a reset, but before any new iterations have been performed, the last move vectors calculated will still be there. Perhaps I should make it so the moves get reset too.

-Step is actually doing multiple iterations whenever it is called, and the number of iterations performed will vary depending on how long they take to calculate. It does 10 iterations, then checks if more than 15ms have elapsed, or the energy threshold has already been reached. If neither is true, it does another 10 iterations, and so on. I wrote it this way to try and maintain some degree of interactivity over a range of different sizes of simulation.

For a simple system, such as dragging points in a sketch with a handful of length and angle constraints, this means it might perform a few hundred iterations between each frame shown on screen, and the constraints are maintained exactly throughout the dragging motion.

For a bigger system with thousands of goals, you wouldn't want to wait for the same number of iterations to be performed, or you might only get an update every few seconds.

SimpleStep, as the name implies, is much simpler. It just performs one iteration.

Now in retrospect, I wish I had maybe named things differently, but the more complicated 'Step' function actually came first, and once people had started scripting with it, I didn't want to switch the names of methods and mess up scripts using them.

-As I mentioned, with Step, there is a check for whether the energy threshold has been reached. The standard solver component will also stop refreshing the Grasshopper solution once it has converged. You can also perform this check in a script yourself by calling GetvSum(), which returns the sum of particle velocities. Here's an example script making use of this. You could also get all the move vectors and add up their magnitudes if you wanted to base it on potential energy instead of kinetic.