Fix ForceAtlas2 speed factor in prevent_overlapping mode

[MathisHammel]

Following up on #5260, it turns out our proposed implementation of prevent_overlapping is missing a small detail that degrades the quality of the result.

Indeed, the notes in the ForceAtlas2 paper mention "we also implemented a diminishing factor on the local speed (dividing it by 10)" when the feature is enabled, which is not present in our previous PR. Without this factor, overlapping nodes tend to be ejected very fast and the algorithm does not converge properly.

The implementation of this PR matches the corresponding function in Gephi, slightly different than explained in the paper.

The render below was performed with cuGraph before and after applying the modification, which shows a significant improvement in the quality of overlap prevention:

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[BradReesWork]

@MathisHammel Thanks for the PR and the great qork.

I need to update the PR to point to branch-25.12

[BradReesWork]

/okay to test 526de3c

[eriknw]

LGTM, thanks @MathisHammel!

[ChuckHastings]

/ok to test bf37157

[ChuckHastings]

@MathisHammel - Looks like your PR is failing one of the python tests. The AI analysis of your failure:

The failure occurred in test_force_atlas2_noverlap[500-graph_file3-10.0-1100] with the assertion assert 4041 < 1100. This means the test expected fewer than 1100 overlapping vertex pairs, but 4041 were found.
 * The test in python/cugraph/cugraph/tests/layout/test_force_atlas2.py expects that, after running Force Atlas 2 with prevent_overlapping enabled, the number of overlapping vertex pairs should be "very low" (see the threshold max_overlaps).
 * For the netscience graph (graph_file3), the test failed because the overlap count was much higher than expected.
 * This could be due to changes in the layout algorithm, differences in graph structure, or insufficiently strict parameters.

I suspect your change results in a different expectation from the code.

[MathisHammel]

Yup, I was investigating that just now. The thresholds for this family of tests were determined from 500 runs of the algorithm in its previous (incorrect) version, I'll need to recompute parameters properly because I suspect the 0.1x speed factor requires more iterations to converge.

I can do that after next week, feel free to set this PR as draft/closed in the meantime

[ChuckHastings]

I can do that after next week, feel free to set this PR as draft/closed in the meantime

No need. The PR doesn't consume any CI resources unless we manually trigger things to rerun. We'll know it needs work because discussed it and it's logged here in the PR.

[ChuckHastings]

/ok to test d1e7df7

[ChuckHastings]

/ok to test d1e7df7