Cost distance produces unexpected results

[danashney]

Hello,
I am running cost distance on a 100x100 elevation dataset in 9.3. This is an area with pretty high relief and I am essentially running this to approximate overland time of travel for storm runoff. The problem is that the result is completely unexpected as compared to the cost raster and does not reflect the topography. It is almost like I am getting a Euclidean result in that the result radiates from the source and does not seem to reflect the cost raster.
I have included jpeg examples of the input (cost_surface) and result (cost_distance) with the source point for reference. Note the main channel running west to east in the center which should have "flow" directed to it before heading to the source as it is the least cost way to get downhill.
Any thoughts would be appreciated. I've used this tool before with good result but not so much this time.
Cheers!

[Anonymous User]

Original User: whuber

The result looks correct to me, Dan, insofar as one can discern any details in this rendering.  (Hillshading the result can be extremely helpful.)  This is definitely not a Euclidean pattern, which would be a series of circles concentric with the destination point shown.  What's happening, though, is that CostDistance is perfectly willing--and able--to take shortcuts around ridges when those can reduce the total cost of travel.  To verify that this is what's going on, compute the backlink grid and use that to track least-cost paths from several characteristic points within the region.

The possibility of a least-cost path completely ignoring flow channels shows the CostDistance approach to this problem is fundamentally flawed.  To track storm runoff you need either to use a flow accumulation calculation or a path distance calculation.