Moving ball simulation within a donut

resolve_collisions() tests the separation of every pair of balls, so its complexity scales as O(n²).

Consider dividing the box into sub-areas, so we only have to compare the balls in each region with those in the same region and immediate neighbour regions.

Even without that redesign, we could save on the Euclidean distance calculation by pre-filtering with cheaper Manhattan distance to exclude pairs that cannot be close enough.

I don't have any advice about performance, but here are some general coding style suggestions.

DRY

This expression is used several times:

box_size/2

You can set it to a variable:

limit = box_size/2
ax.set(
       xlim = (-limit, limit),
       ylim = (-limit, limit),
       title = "moving atoms"
       )

Documentation

It's great that you added docstrings for your functions. The PEP 8 style guide also recommends adding a docstring at the top of the code summarizing its purpose:

"""
Moving ball simulation within a donut
Add more details here.
"""

Naming

In the wall_collisions function, the variables named r and v are not very descriptive. The docstring does have brief descriptions, but it would be better to describe their types as well. Also consider using type hints for the functions to make the code more self-documenting.

The docstring says this:

output: v 'velocities after ball-wall collisions'

It seems like the output is unused. Also, I don't see how v is being changed inside the function. You should be able to just delete this line:

return v

In the main code, this variable name is also vague:

dt = 0.05 #time step in s

As in the comment, time_step is more descriptive:

time_step = 0.05 # in units of seconds

Portability

I get a syntax error and the code does not run unless I comment out this line:

%matplotlib qt5

This syntax is probably specific to your IDE.

More Descriptive/Accurate Docstrings

Since you have chosen to use docstrings instead of type hints, then try to be more precise is describing what the arguments to the functions are. For example, I can deduce from your use of the zip built-in function that arguments r, v, and Mass are iterables. Then say so:

def wall_collisions(r, v, Mass, radius_out, radius_in):
    """
    This function determines when the balls collide with the outer and inner walls
    inputs:
        r: a list of the balls' positions.
        v: a list of the balls' velocities.
        Mass: a list of the balls' mass.
        radius_out: the outer radius of the donut.
        radius_in: the inner radius of the donut.

    outputs:
        a list of velocities after ball-wall collisions.
    """

But why is Mass capitalized when r and v are not? And m is the standard name used in physics for referring to an object's mass, which is different from the object's weight. So I would not use variable name weight. I also thought that radius_out was some "output" list that would be filled in. Perhaps better names would be outer_radius and inner_radius.

And what is function wall_collision really returning? You say they are the velocities after ball-wall collisions. But the actual value returned is input argument v, which does not appear to have been modified. Am I missing something? Also, the only call to wall_collision is not using any return value, which suggests your docstring is inaccurate. Better to just return None and change the docstring accordingly.

In function resolve_collisions you are returning a modified v, but the caller is not explicitly using this return value (although v is defined as a global and thus the updated global can be accessed that way). See next session.

Use of Globals

As I previously mentioned, variable v is at global scope and is being passed to various functions that claim to return v, but the return value is being ignored by the caller and instead referencing the global variable v instead. The conflict between the docstrings, what the functions return and whether the return values are actually used by the caller can cause confusion and make the code difficult to maintain.

There are various ways of resolving this. Just a couple:

1. You could modify the docstrings to state that the functions return None but that the v list being passed in as an argument is modified (although that does not seem to be the case for wall_collisions).
2. You could encapsulate all of your variables and the functions that operate on them into a class with attributes (instead of the global variables) and methods (instead of the functions). The class would be instantiated with the inputs (those iterables that describe the balls' positions, velocities and mass) and these would be saved as attributes using a leading underscore for the name if the clients of the class are not supposed to directly access these attributes (same naming convention for your "private" methods). And your docstrings would make it very clear that, for example, after method resolve_collisions is called that attribute v (or _v) is updated with new velocities.

I personally would go with option 2.

Separation of Concerns

Your code starts with descriptions of balls and runs a simulation in function animate. That suggests that the main concern of the program is to animate the stimulation. However, couldn't it be useful to generate the simulation steps in some application that does not use matplotlib specifically to animate the simulation? I would instead rename animate to something like next_simulation_step since the returned points could be displayed in numerous ways (or not displayed at all). I see that this function (or method if you take my suggestion) takes an argument i, which is not used but is an artifact of wanting to use this function with matplotlib.animation.FuncAnimation. I would instead remove this argument from next_simulation_step making it independent of matplotlib:

class BallCollisionSimulation:
    ...
    def next_simulation_step(self):
       """This method returns the next simulation step, based on Euler's method"""
        for a in range(20):
            self._r += self._v * self._dt
            self._wall_collisions()
            self._resolve_collisions()

        self._points.set_offsets()  # uses self._r

        return self._points,

You would use this as follows:

simulation = BallCollisionSimulation(various_arguments)
for _ in range(20):
    points = simulation.next_simulation_step()  # get next step's points

But method next_simulation_step has the wrong interface for use with matplotlib.animation.FuncAnimation. So we create an additional adapter function, animate:

simulation = BallCollisionSimulation(various_arguments)

def animate(i):
    return simulation.next_simulation_step()

ani = animation.FuncAnimation(fig, animate, frames = 1000, repeat = False,
                              interval = 10, blit = False)