Alpha affects linkForce differently than the other forces about d3-force

[asktree]

I don't know if GitHub has a special request assignment feature, but I am working on fixing this.

[mbostock]

All of the forces are scaled by the simulation’s current alpha; that’s the intentional cooling of the forces. In link.js:

l = (l - distances[i]) / l * alpha * strengths[i];

In x.js (and similarly y.js):

node = nodes[i], node.vx += (xz[i] - node.x) * strengths[i] * alpha;

In manyBody.js:

w = strengths[quad.data.index] * alpha / l;

If you instantaneously set the alpha to 1 when it goes below 0.02, I’d totally expect to see some pulsation. If you don’t want the simulation to stop permanently, maybe try setting alphaTarget to a non-zero value?

[asktree]

Sorry, I should be more clear. The issue I'm reporting on is not the slowdown or about any strange behaviors regarding instantly setting alpha to 1. Rather, what I'm referring to is that the forces are not equally scaled by the simulation's current alpha. In my first demo, the graph expands as alpha decays, which is what I was trying to show. I just set it to repeatedly jump back to alpha = 1 in order to repeatedly demonstrate that motion. All the forces are cooling down, but linkForce seems to be cooling down more.

For these examples I set alphaDecay to 0 and just set them each on a different alpha, and let them run for a while just to be sure they'd reached equilibrium. I also made the links more powerful to make it more pronounced, but the effect is there with any parameters (including defaults).

[mbostock]

I understand, but it’s also expected that as the simulation cools that the balance of forces changes. However, if you tinker with it and think you’ve found a way to improve the behavior, please let me know!

[asktree]

I ended up getting rid of this behavior by removing the velocity terms when calculating the positions of nodes. I tested it pretty darn thoroughly. Basically, these terms end up getting more accurate as alpha is lower, so the force isn't as extreme because it doesn't over or under estimate (depending on the order you instantiate the forces) as much.

An alternative "fix" would be, instead of deleting the velocity terms, dividing them by alpha. I tried this and it also worked. However, I figured this way was pretty wonky and that it was better to just make links work like the other similar forces.

I realize this was probably a pretty low-on-the-priorities "fix", but my project is trying to display graphs with up to ~6000 links and it ends up being quite noticeable, all of the clusters in the graph shrink when you wake the simulation to drag stuff around and then start slowly ballooning back out again. I really like the alphaDecay feature so this bugged me a lot.

I can see the merits of "preempting" nodes by checking where they're going to be, but in my opinion this behavior is more relevant when you're working with rigid forces like collision. Perhaps a forceRigidLink should be made, which simply prevents a node from ever moving more than a given distance away from a given point.

The other thing about preempting is that, without it, simulations really flip out when velocityDecay is 0. So with my change, this is true of forceLink; it's already true of manyBody and the positional force. It seemed pointless to prioritize support for velocityDecay(0) when the other forces already break with it. Using the alternative fix I described does not have this issue, though. Perhaps in the future they should all be changed in some way or another.

I initially thought that the problem was due to the fact that the old link.force did not factor in velocityDecay when preempting position. However, this doesn't seem to be the case because the behavior still existed when I just set velocityDecay to 0. Still seems like something to keep an eye out for in the future. Note that forceCollide also exhibits the alpha-inconsistency I tried to get rid of here, I just didn't try messing with it.

I went ahead and made a fork for your convenience and for the sake of my potentially being able to say I contributed to d3 :P