Turnover on the Quantopian platform is defined as

capital traded  /  portfolio_value

The capital that will be traded by a set of orders (eg by using order_optimal_portfolio) can be thought of as the difference between the current portfolio holdings and the target portfolio holdings. Dividing those values by portfolio_value one get's the portfolio weights. So, another way to get turnover is

sum of abs(current portfolio weights - target portfolio weights)

One doesn't need to fetch order object information to get turnover. Simply get the current portfolio weights and subtract the optimized portfolio weights. This will give the 'change in portfolio weights'. Take the absolute values of these weights and sum them up. That will be the daily turnover. Something like this

# First get the optimized calculated weights but not actually order  
opt_weights = opt.calculate_optimal_portfolio(objective=target_weights, constraints=constraints)

# Get the current portfolio weights.  
# Turnover is the difference between the current weights and the optimized weights  
current_weights = context.portfolio.current_portfolio_weights  
difference = opt_weights.subtract(current_weights, fill_value=0.0)  
turnover = difference.abs().sum()  

Note, one can't simply subtract the current and optimized weights like this

difference = opt_weights - current_weights

If a security is in one weighting and not the other, the result will be nan. Not what we want. The pandas method subtract to the rescue. This method allows for 'filling' any values in one series and not the other with a value (eg 0). See https://pandas.pydata.org/pandas-docs/version/0.18/generated/pandas.Series.subtract.html.

Also note this is the daily turnover. The contest constraint is for the mean daily turnover to be between 5%-65% measured over a 63-trading-day rolling window. To get the 63 day mean value, one would need to store this daily value then find the mean of the last 63 values.

The attached example simply logs the turnover. However, one could conceivably modify the optimized weights or do other logic if turnover is too high.

Thanks for your in-depth response/example algo, Dan. That cleared up a lot of my confusion.

Just want to confirm one nuance - are you saying that Quantopian evaluates turnover based on orders actually filled or merely placed by order_optimal_portfolio? I had assumed the former but I am gathering the latter is the actual methodology. Or is it technically the former, but not a big enough difference in practice to warrant providing infrastructure for an orders-style object?

I only occasionally see warnings about unfilled orders - but I thought it might be of theoretical interest to have access to fill information, regardless. I guess I could just save a snapshot of context.portfolio.positions at close and extrapolate unfilled orders from that? (Sorry if I'm answering my own question...though on second thought this might not work if trades are executed end of day...or maybe it would...I'll look into this myself :))

P.S. I know the QTradableStocksUS includes filters for liquidity, but no filter is perfect. In fact, I would prefer to have a universe that included illiquid assets precisely to implement a strategy based on actual vs projected turnover. (I guess the only thing stopping me from straying from ol' QTrad are contest rules; maybe I'll dig a little deeper, wean myself off of backtests and do some actual research.) But there's gotta be somebody out there with a similar vision who's ventured into this territory already...

Cheers and happy holidays

@Christopher Sorry for not being more clear. You asked "Just want to confirm one nuance - are you saying that Quantopian evaluates turnover based on orders actually filled or merely placed by order_optimal_portfolio? " Quantopian bases turnover on the actual executed and filled trades.

The approach above was intended as a way to estimate the impact of placing orders using the order_optimal_portfolio method. By knowing this estimate, one could modify the orders to potentially stay within the turnover limits. This is a good estimate (typically most orders fill) but isn't the actual turnover. If one is only trading once per day, the actual turnover can be found using a similar method.

# Turnover is the difference between the current weights and the previous weights  
current_weights = context.portfolio.current_portfolio_weights  
difference = context.previous_weights.subtract(current_weights, fill_value=0.0)  
turnover = difference.abs().sum() 

# Save the current days portfolio weights to compare tomorrow  
context.previous_weights = current_weights  

The portfolio weights will reflect the actual traded securities and therefore the actual turnover. However, if one trades more than once during the day, the intra-day trades may not be captured using this approach and actual turnover could be higher. Unfortunately, there isn't a simple way to find the actual dollars traded if trading intra-day. While one can save the order objects, the orders only contain the quantity of shares filled and not the actual fill price. The price is needed to calculate turnover.

Hope that clears up my initial response?