Efficient algorithm to find overlapping circles of various sizes I have a collection of N circles in the plane with various position and radius. Circles move around according to one force and become bound to each other once they overlap. 
I need a fast way to determine if a circle is overlapped/overlaps another, to determine the circle's equations of motion during a time step. 
Once circles have overlapped, they are bound, so it's easy to remember that relationship. 
The problem is to evaluate when circles overlap for the first time. 
Think of cheerios floating on milk. 

Obviously I have thought of using a KDTree or a Delaunay Triangulation, but these only take into account the circle centers, not their radius, so the closest circle in a DT Trianle isn't necessarily overlapping, while another might be.

I've read somewhere that a MWVD might work, but I don't understand how that would work. 
D Eppstein has a couple of papers out on Mobius Transformations, and that too is over my head, but it looks like it's related. 
Can anyone point me in the right direction ?

Thanks.
A modified Bentley-Ottmann sweep algorithm (here, for example) will find all line segment intersections in $O((n+k)\log n + k)$ time, where $k$ is the number of intersections.  It's fairly straightforward to extend the algorithm to handle circles. A good walkthrough is here under "finding intersections".

$k$ can be $\Omega(n^2)$ in theory (in which case pairwise checking is faster), but it seems difficult to avoid the $k$ term, and in any case you seem to say $k$ will be small in your question.

Granted, this recomputes the intersections from scratch each time you run the algorithm, which may be inefficient for your purposes.  You may be able to get around this a bit by maintaining the list of circles sorted by $x$ coordinate, and modifying this list online as the circles move.  This won't help your asymptotic running time, but it avoids sorting each circle every time.  If the circles stay relatively sparse (few cross the same vertical line), the binary search tree on the $y$-coordinates will be cheap to maintain.

The other issue is that knowing two circles intersect already does not improve the running time at all.  Once two circles attach to each other, you will calculate their intersection every single time, which is a waste.