Discussion Forum - QuantConnect.com

Kbsaravana INVESTOR

| Reward Discussion

Hi,

as I'm still not familiar with unvierse/alpha. I'm manually addOption for all the sp 500 tickers. if I run back test for 3 month it is taking very long time. also many times getting different crash errors. I noticed backtesting Options are so slow compared with equity. I'm not sure, performance will improve if I move to QC 500 universe with alpha? please help me on this. any workaround to improve performance?
I plan to test a strategy for 5 years.



//Initialize

SetStartDate(2019, 01, 14);

SetEndDate(2019, 2, 27);

SetCash(1000000);



//SP 500.

string tickersString = "<all 500 tickers as comma separated>";



string[] tickers = tickersString.Split(new string[1] { "," }, StringSplitOptions.RemoveEmptyEntries);



foreach (string ticker in tickers)

{

	var equity = AddEquity(ticker, Resolution.Minute);

	Stock stock = new Stock(ticker);

	stock.EMA10 = EMA(stock.Symbol, 60, Resolution.Hour);

	stock.NATR = NATR(stock.Symbol, 10, Resolution.Daily);

	selectedStocks.Add(stock);

	

	var option = AddOption(ticker, Resolution.Minute);

	option.SetFilter(x => x.IncludeWeeklys().Strikes(0, 150).Expiration(TimeSpan.FromDays(45), TimeSpan.FromDays(120)));

}

Update Backtest

Kbsaravana

Accepted Answer

Update Backtest

Notebook

The material on this website is provided for informational purposes only and does not constitute an offer to sell, a solicitation to buy, or a recommendation or endorsement for any security or strategy, nor does it constitute an offer to provide investment advisory services by QuantConnect. In addition, the material offers no opinion with respect to the suitability of any security or specific investment. QuantConnect makes no guarantees as to the accuracy or completeness of the views expressed in the website. The views are subject to change, and may have become unreliable for various reasons, including changes in market conditions or economic circumstances. All investments involve risk, including loss of principal. You should consult with an investment professional before making any investment decisions.

Kbsaravana

1.1k Pro ,

got this error:

Rahul Chowdhury

39.9k Pro ,

Hi Saravana,

You're subscribing a massive amount of data. When you subscribe to an option chain for a symbol, it represents subscribing to data for possibly hundreds of contracts. Doing this for 500 symbols means that you are subscribed to an enormous amount of data. Instead, when using many underlying symbols, you should use the OptionChainProvider with AddOptionContract to subscribe to specific contracts for that symbol, instead of the entire chain.

Kbsaravana

1.1k Pro ,

Thanks Rahul Chowdhury.. performance is so better by using OptionChainProvider. Thanks a lot.

Kbsaravana

1.1k Pro ,

Hi Rahul,

In order to improve performance, I used OptionChainProvider as below. but I need to use Implied Volatility in my filter condition, which seems available in OptionChain but not in OptionChainProvider. Could you help me on this?

var contracts = OptionChainProvider.GetOptionContractList(stock.Symbol, Time);



var contract = contracts

	.Where(x => x.ID.OptionRight == OptionRight.Put &&

			x.ID.StrikePrice >= Securities[stock.Symbol].Price

			&& (x.ID.Date - Time).TotalDays < 20

			&& (x.ID.Date - Time).TotalDays > 3)

	.OrderBy(x => Math.Abs(x.ID.StrikePrice - Securities[stock.Symbol].Price))

	.ThenBy(x => (x.ID.Date - Time).TotalDays).FirstOrDefault();

Rahul Chowdhury

39.9k Pro ,

Hey Saravana,

The implied volatility isn't available because the contract hasn't been added yet and so there isn't any data for that contract yet. We can work around this by breaking our filtering into two parts. First, we filter for right, strike, and expiry, and we add those contracts to our algorithm using AddOptionContract . Once we have the data for our contracts, we can access them from the options chain, add them to a list and then filter by IV. Here's an example.

Best
Rahul

Ernest Shaggleford

1.8k Pro ,

Hi Rahul,
May I ask if you could please clarify the source of the contract IV attribute?
Is it from the pricing model or is it from the options data source?
As an experiment I changed the code to use a different pricing model but the IV output is identical, so it seems that it's from the data source.
Also is it the case that when using the AddOptionContract() method that the pricing model option Greeks are not available in the options contracts from the subsequent Slice OptionChain?
When I log the option contract Greek values from the option chain they are not set, even after modifying the algorithm to run for another 2 weeks.
Thanks,
ES.

Derek Melchin

STAFF Pro ,

Hi Ernest,

The IV is provided by the pricing model. The reason it remains the same after switching the pricing model is because all the models use the same volatility estimator. View the source code here.

The pricing models need to be warmed up to compute the Greeks. However, as can be seen in the attached backtest, the BlackScholes model returns 0 for all the Greek values regardless of the warm-up period. We utilize the QuantLib library to gather greek values, so this may be an issue with the external library. We are currently looking into this issue and trying to understand its root cause. Track our progress here.

Best,
Derek Melchin

Ernest Shaggleford

1.8k Pro ,

Hi Derek,
thanks for the clarification on the IV that all the pricing models use the same volatility estimator.
From what I can determine, the volatility estimator is using the underlying volatility model StandardDeviationOfReturnsVolatilityModel with a 30 day rolling window.
This looks to be the 30d historical volatility and not Implied Volatility.
Is this correct?

Thanks,
ES.

Derek Melchin

STAFF Pro ,

Hi Ernest,

That is correct. The historical volatility is modeled with the StandardDeviationOfReturnsVolatilityModel by default. IV is calculated using a stochastic process (BlackScholesMertonProcess) that uses this historical underlying volatility as input. View the source code here.

Best,
Derek Melchin

Ernest Shaggleford

1.8k Pro ,

Hi Derek,
based on the following code in the QC QLOptionPriceModel.Evaluate method

var underlyingVolValue = new SimpleQuote(_underlyingVolEstimator.Estimate(security, slice, contract));

var underlyingVol = new Handle<BlackVolTermStructure>(new BlackConstantVol(0, calendar, new Handle<Quote>(underlyingVolValue), dayCounter));

this is using the QL BlackConstantVol class, which is a calculation of "Constant Black volatility, no time-strike dependence". From reviewing this QL class (ql/termstructures/volatility/equityfx/blackconstantvol.hpp) , from what I can determine it's using the input volatility, which is the 30 day HV as mentioned in the last post, as the forward volatility, as the Black Constant Volatility calculation is implementing a constant volatility model, where HV is used for the IV.
And in ql/processes/blackscholesprocess.cpp, GeneralizedBlackScholesProcess::localVolatility(), if the volatility model is BlackConstantVol, which it is in this QC implementation, then the "local vol" is also constant, and so is using the HV.
So in the case of the IV, this isn't a stochastic process.
Is my understanding correct?

Unfortunately, in the real-world, as you know, volatility is not constant, and so this model is not useable, and will not reflect the actual real-time IV.

As the QC options data doesn't include IV, nor the Greeks, for back testing purposes the IV and Greeks have to be modelled, as there is no choice for this.
But for Live trading, the Interactive Brokers TWS API provides the IV and Greeks in real-time, but I've found that LEAN ignores this data. I've previously raised a query on why this is about a week ago, but I've had no response so far.
I'd suggest that for Live trading, to resolve the issues around using modelled constant IV and estimated Greeks, that the IB provided real-time IV and Greeks should be used by LEAN.
This will also support being able to trade options on multiple underlyings while keeping within the allocated data lines allowance.

Thanks,
ES.

Jared Broad

STAFF Pro ,

Hi there Ernest, sorry do not have plans to offer this functionality at this time.

All greeks and volatility models are calculated at runtime. This was a design decision from LEAN to give the developers flexibility into the model they choose to build those greeks.

The feature to source these from an external data source could be done. So I understand why -- why do you think IB would supply anything better than we can calculate in a model locally based on the live feed?

Ernest Shaggleford

1.8k Pro ,

Hi Jared,
If my understanding is correct, if real-time actual IV and Greeks are required for contract selection and trade management, which is typically how options are traded, then there are multiple issues that make it very difficult to impossible for the Live trading of options with the current LEAN implementation.
1. Real-time IV, that would be provided by a broker (market maker (MM) algo per instrument), is based on a multitude of factors, including underlying vol, option supply and demand, and indirectly (possibly directly) real-world known future events such as dividends, earnings releases, and so on, and is quite dynamic, and so is very different to HV. IV dictates the real-time options skew which can shift between positive and negative skew, based on many factors. Currently the QC LEAN implementation for modelling IV is using a constant vol model, BlackConstantVol, which in effect is just using the HV. This will not reflect the actual real-time IV provided by the broker/MM algo.
2. As the IV is a critical factor in the calculation of the option Greeks, using a modelled constant volatility for the IV, will not reflect the actual real-time Greek values provided by the broker/MM algo.
3. The warmup period requirement for the LEAN option pricing model calculation of the Greeks means that a specific option universe for an underlying has to be set up at algo initialisation. This is fine if only trading options on one underlying, as the universe filter can be used to ensure that the actual subscribed set of contracts is within the broker's data lines allowance. But if trading options on multiple underlyings, this requires an option universe per underlying to be present, and even with the universe filters, this will result in the total subscribed set of contracts exceeding the data lines allowance, thereby making it impossible to trade. There may be a way to dynamically change the current applied universe filters to not exceed the data lines allowance, but this may not be practical, as it would require continually switching between 'normal' filters and 'minimised' filters depending on the stage of the trade.

I'd suggest all of the above could be resolved for Live trading if LEAN used the actual real-time IV and Greek values provided by the broker/MM algo.
- Issues #1 and #2 are resolved as real-time IV and Greeks are available for contract selection and trade management
- Issue #3 is resolved as the option universe method for contract filtering and subscription is not needed. Instead, the option chain provider method for obtaining the option chain would be used, and then the real-time IV and Greeks would be made available in the option chain contract attributes for contract selection, perhaps with some coarse filtering to keep within the data lines allowance prior to actual subscription. Options on multiple underlyings could be selected, subscribed to and traded/managed using this approach, while keeping within the data lines allowance.

re: "The feature to source these from an external data source could be done. So I understand why -- why do you think IB would supply anything better than we can calculate in a model locally based on the live feed?"
Please see my reasons in issues #1 and #2 above.
There may possibly be a way to improve the LEAN implementation to better reflect real-time IV and the Greeks, by at least not using a constant vol model. But from my limited understanding of this area, as I'm not an expert by any means, I believe that the broker/MM algos are closely guarded IP, and as such trying to replicate these would be a big challenge. I'd suggest it would be easier to just use the values provided by the broker/MM algos.

Also, out of curiousity, is it possible to source historical options data that includes the snapshot of the actual live IV and Greek values ?

Many Thanks,
ES.

Derek Melchin

STAFF Pro ,

Hi Ernest,

In regards to your question, there is no built-in way to gather historical IV or Greeks for options, but we are working on it. Track our progress here.

Best,
Derek Melchin

Manoj Kandlikar

805 Pro ,

Any progress on this?

Varad Kabade

31.1k Pro ,

Hi Manoj,
Please subscribe to the following GH issue mentioned by Derek for updates:
https://github.com/QuantConnect/Lean/issues/3083
Best,
Varad Kabade

Kbsaravana INVESTOR

Update Backtest

Notebook

To unlock posting to the community forums please complete at least 30% of Boot Camp.
You can continue your Boot Camp training progress from the terminal. We hope to see you in the community soon!

Platform

QuantConnect Community

Alpha League Competition: $1,000 Weekly Prize Pool

Filter Discussion by Tags

239900 Quants.

Online Now

Stay Connected

Back testing option strategy for sp 500 is taking very long time

Started By:

Join QuantConnect for Free Sign Up

Platform

SIGN IN

QuantConnect Community

Alpha League Competition: $1,000 Weekly Prize Pool

Filter Discussion by Tags

239900 Quants.

Online Now

Stay Connected

Back testing option strategy for sp 500 is taking very long time

Started By:

Join QuantConnect for Free Sign Up