Well, I finally got back to debugging the iliac code.  I had thought that because the system is able to go in any old crazy direction that it needed a lot of complicated selection criteria to prevent it from spitting out crazy results, and so I spent quite a bit of time writing and debugging that code.  After hours of frustration, I decided to use the single simplest rule that I could think of; i.e. the path that gets the furthest distally in the scan is the most likely to represent the true optimal path.  In most cases there are multiple sets of parameters that achieve an approximation of the correct result.  This of course relates back to the entire premise of the code which is that there exists an underlying stable instability which allows for the sensitive dependence on initial conditions while maintaining a coherent large scale structure in terms of tracking of the lumen.
Once I simplified the selection down to the bare minimum criteria, the code seems to be performing reasonably well.  The next step is the have the system be able to isolate when one or both of the iliac trackings have failed.  It turns out that it is very uncommon for it to fail bilaterally and that typically the issue is unilateral and related to extreme asymmetric iliac size, severe stenosis, or high bifurcation.  I think the easiest way to go about this will be to compare the two sides in terms of how far they have tracked and use that as an internal consistency check.  I have noticed that there are a couple of studies where the scan acquisition outruns the contrast bolus and so in those situations there is typically symmetric decreased flow bilaterally.
At any rate, since we are talking about around 4% of the the total runs that it doesn't complete, there needs to be some kind of salvage algorithm.  Well, that is an issue that I can address once I figure out how to accurately gauge failure.  which reminds me, I still have to go back and write the salvage algorithm for the initial aortic tracking.