Force Directed Layout Explosion

I have a GoView with about 1000 GoObjects on it, more or less evenly distributed within a circle centered in the view, but with significant overlapping.

I am writing a declutter algorithm to allow the user to hover over a congested spot, "explode" those objects under the mouse, and then be able to hover on one of the exploded objects to get a tooltip.
I am using the ForceDirectedLayout to do this.
Basically, when the mouse hovers over the view, I check to see how many objects are within a small square around the mouse (PickObjectsInRectangle). If more than one, then I move the found objects into a new layer, and use ForceDirectedLayout to rearrange them and spread them out nicely.
I have "built a fence" around the display area with a max charge of 2500. I have spent several days playing with the Electrical Charge/Field methods and have come up with a set that does a reasonably good job - except for one problem.
When there are a number of nodes involved, one or more of the objects gets shot out of the lower right of the view and given X and/or Y coordinates of 50,000+ and the view's underlying document is expanded to fit the new coords. The view's DisplayRectangle is NOT altered so it looks fine except for the blown-out objects.
I have found that if I detect this situation by looping through the objects after the layout and looking for coordinates out of range, and then manually moving each out-of-range node back to the center of the chart, and then redo the forcedirected layout, then it works fine.
I have seen in another thread that you recommended doing a TreeLayout first and then a forceDirected layout.
Is that a good idea here?
Or is there something that I can set that will prevent the ForceDirected algorithm from exploding objects out into never-never land?
Setting the Document.AllowResize = false has no effect.

The other forum topic you mention deals with how to get force-directed layout to work more quickly when all of the nodes start off at about the same location. We have greatly improved how GoLayoutForceDirected handles this case in version 3.0, so that you won’t have to use that GoLayoutTree hack.

I think what you are seeing is the occasional case where the overlapping nodes cause the repulsive force to be extremely large, resulting in a overly large displacement. We have also fixed this problem in version 3.0.

Version 3.0 is currently in beta test. I don’t know when it will be generally available. If you are a customer with a support subscription, you should have gotten e-mail about 3.0 beta last month.