Trapping Rain Water Explained: Tracing [0,1,0,2,1,0,1,3,2,1,2,1]

Imagine looking at a cross-section of a rugged landscape after a heavy storm. Rain has fallen, and water has pooled in the depressions between uneven hills and ridges. Given the elevation map height = [0, 1, 0, 2, 1, 0, 1, 3, 2, 1, 2, 1], how many total units of water remain trapped between those vertical barriers instead of spilling off the edges?

If you inspect bar by bar, water does not depend merely on how tall the immediate neighbors are. A single drop of water at index 2 (with height 0) is bounded by the tall wall at index 1 (height

Without a systematic mental model, calculating this feels overwhelming: you might try scanning left and right infinitely from every single index, or getting tripped up by valleys nested inside larger valleys. We need a way to look at height constraints globally without re-scanning the entire array at every single step.

height = [0, 1, 0, 2, 1, 0, 1, 3, 2, 1, 2, 1]
# Think about why index 2 (height 0) can trap water, 
# while index 0 (height 0) cannot.

To understand how water gets trapped in our elevation map height = [0, 1, 0, 2, 1, 0, 1, 3, 2, 1, 2, 1], we have to stop looking at single bars and start looking at boundaries. Imagine pouring water over this entire terrain: any individual bar at index $i$ can only hold water if there is a taller bar somewhere to its left and another taller bar somewhere to its right.

Water does not care about the immediate neighbor alone; it cares about the absolute tallest peaks flanking it on either side. Specifically, the water level sitting directly on top of bar $i$ is strictly limited by the height of the shorter of those two bounding peaks. If we define $\text{leftMax}[i]$ as the maximum height from the start up to index $i$, and $\text{rightMax}[i]$ as the maximum height from index $i$ to the end, the trapped water at any single position is given by:

Looking at our elevation map, index 2 has a height of 0. Its highest obstacle to the left is 1, and its highest obstacle to the right is 3. The limiting boundary is $\min (1,3)=1$, meaning index 2 can pool water up to height 1. Subtracting its own height of 0 leaves 1 unit of trapped water.

Let us trace the two-pointer algorithm step by step on our elevation map height = [0, 1, 0, 2, 1, 0, 1, 3, 2, 1, 2, 1]. We maintain left pointer $L=0$, right pointer $R=11$, leftMax = 0, rightMax = 0, and ans = 0.

Try this: Trace steps:

Now that you have seen how the two-pointer sweep maintains running maximums and accumulates water across [0, 1, 0, 2, 1, 0, 1, 3, 2, 1, 2, 1], it is time to apply the exact same mechanical trace to a slight variation of the array.

Take the original elevation map and alter its center valley by raising the lowest interior bars. Consider the modified elevation map height array: [0, 1, 0, 2, 1, 2, 1, 3, 2, 1, 2, 1]. Notice that the bar at index 5, which was previously 0, is now 2.

Work through the two-pointer initialization: set left pointer L = 0, right pointer R = 11, leftMax = 0, rightMax = 0, and ans = 0. As L and R step inward, compare how the new height of 2 at index 5 alters the boundary conditions compared to the original trace.

height = [0, 1, 0, 2, 1, 2, 1, 3, 2, 1, 2, 1]
# Trace L=0, R=11, leftMax=0, rightMax=0, ans=0
# What is the final value of ans?

The two-pointer elevation sweep we used to solve the array $[0,1,0,2,1,0,1,3,2,1,2,1]$ is not just an isolated algorithmic trick—it is a blueprint for any problem where a local resource is constrained by the minimum of two global extremes. Recall that at every step of our trace, the water height above column $i$ was strictly decided by $\min (\text{leftMax},\text{rightMax})-\text{height}[i]$. This exact boundary-governed pattern reappears in geometry, skyline layout, and financial reservoir simulations where capacity is limited by the lowest threshold of surrounding walls.

To see this transfer in action, consider a 2D container wall optimization task: given a set of vertical panels of varying heights, you must find two panels that, together with the x-axis, form a container holding the maximum possible water volume (the classic Container With Most Water problem). While that problem uses a greedy two-pointer reduction moving inward from the absolute edges based on height comparison, the underlying mental model remains identical to our rain water trace. You are constantly letting the shorter boundary dictate the active constraint, sacrificing the limiting side in hopes of finding a taller bottleneck.

When encountering a new spatial capacity puzzle, do not immediately jump to brute-force nested loops that check every pair of boundaries. Instead, ask three diagnostic questions:
1. Is the capacity at position $i$ determined by the nearest enclosing peaks, or by the absolute highest peaks to the left and right?

By mapping these questions back to our elevation map trace, you can safely port the two-pointer sweep to higher-dimensional or modified architectural layouts without rewriting your core logic.

def max_container_area(height: list[int]) -> int:
    # Apply the two-pointer boundary-sweep pattern
    # to find the maximum rectangular container area.
    left, right = 0, len(height) - 1
    max_area = 0
    while left < right:
        # TODO: compute area and advance the limiting pointer
        pass
    return max_area