Updating Shipped Multiple Prices (March 28, 2024) - Assertion Error Supplied <> Generated

[adnan-trader]

Dear PST community,

Has anyone else experienced last contract mismatches (AssertionError) with updating the supplied multiple prices as of March 28, 2024 from the development branch and updating with IB?

I have downloaded the latest multiple prices from development branch (March 28, 2024) instead of from master as it is further back (August 31, 2023) than one year lookback as of Sept 2024. I was able to run the seed_price_data_from_ib.py successfully for the list of instruments.

I am trying to update them following the steps outlined in the "Updating shipped multiple prices" section. Many of instrument codes worked, but about 30 failed--ALUMINIUM, GOLD, LEANHOG, SOYMEAL--excluding ones where current prices are missing (e.g., LME).)

Using ALUMINIUM as the example, the supplied multiple prices csv file changed the current contract on March 26, 2024 18:00:00 from contract 20240500 to 20240600 on March 26, 2024 18:00:01 (note this is 1 sec later) and continues until the end of the month.

DATETIME,CARRY,CARRY_CONTRACT,PRICE,PRICE_CONTRACT,FORWARD,FORWARD_CONTRACT
2024-03-26 18:00:00,2286.0,20240600,2277.25,20240500,2286.0,20240600
2024-03-26 18:00:01,,20240700,2286.0,20240600,,20240700
2024-03-26 23:00:00,2298.0,20240700,2286.0,20240600,2298.0,20240700
2024-03-27 13:30:00,,20240700,2270.0,20240600,,20240700
2024-03-27 14:00:00,2285.0,20240700,2273.0,20240600,2285.0,20240700
2024-03-27 15:00:00,,20240700,2273.25,20240600,,20240700
2024-03-27 16:00:00,2294.25,20240700,2285.25,20240600,2294.25,20240700
2024-03-27 17:00:00,2302.25,20240700,2291.0,20240600,2302.25,20240700
2024-03-27 23:00:00,2302.25,20240700,2291.0,20240600,2302.25,20240700
2024-03-28 13:30:00,2310.0,20240700,2300.25,20240600,2310.0,20240700
2024-03-28 14:00:00,2315.25,20240700,2307.25,20240600,2315.25,20240700
2024-03-28 15:00:00,2322.5,20240700,2310.5,20240600,2322.5,20240700
2024-03-28 16:00:00,2330.5,20240700,2320.75,20240600,2330.5,20240700
2024-03-28 17:00:00,2332.25,20240700,2323.0,20240600,2332.25,20240700
2024-03-28 18:00:00,,20240700,2320.0,20240600,,20240700
2024-03-28 20:00:00,,20240700,2310.0,20240600,,20240700
2024-03-28 23:00:00,2332.25,20240700,2310.0,20240600,2332.25,20240700

However, the generated roll calendar and multiple prices have, correctly, based on roll config, the current contract 20240500 until 2024.04.01 (see below).

Roll Config:
Instrument | HoldRollCycle | RollOffsetDays | CarryOffset | PricedRollCycle | ExpiryOffset
ALUMINIUM | FGHJKMNQUVXZ | -45 | 1 | FGHJKMNQUVXZ | 14

Generated roll calendar:
DATE_TIME,current_contract,next_contract,carry_contract
...
2024-01-02 23:00:00,20240200,20240300,20240300
2024-01-30 23:00:00,20240300,20240400,20240400
2024-03-01 23:00:00,20240400,20240500,20240500
2024-04-01 23:00:00,20240500,20240600,20240600

Generated multiple_prices:
DATETIME,PRICE,FORWARD,CARRY,PRICE_CONTRACT,FORWARD_CONTRACT,CARRY_CONTRACT
2024-03-26 23:00:00,2277.25,2286.0,2286.0,20240500,20240600,20240600
2024-03-27 23:00:00,2277.0,2291.0,2291.0,20240500,20240600,20240600
2024-03-28 23:00:00,2312.0,2310.0,2310.0,20240500,20240600,20240600
2024-04-01 23:00:00,2329.5,2348.5,2348.5,20240500,20240600,20240600
2024-04-02 23:00:00,2359.75,2359.75,2359.75,20240600,20240700,20240700

So, we have a contract mismatch on March 28, 2024 when trying to splice the data between the supplied contract 20240600 and generated current contract 20240500.

How does one correct this issue?

Do you delete the rows in the supplied multiple file, assuming the newly generated roll calendar and multiple prices are correct?

Thanks, Adnan

[tgibson11]

Please see this discussion, and in particular this comment

[adnan-trader]

Thank you for the reply @tgibson11.

As this is my first time setting up the system and updating the supplied data for backtesting first and then eventually for production.

I understand your solution for resolving by adjusting the newly generated roll calendar roll date to match the supplied multiple prices roll date.

In your experience, what are the explanations for why the instruments (with the Assertion error) were rolled earlier (by Carver based on the dates in the supplied multiple prices) than the expected roll date based on the new roll calendar based on the updated contract prices?

Wouldn't an alternative (equivalent?, better?) solution be to (as also suggested by @vishalg):

1. Delete the offending rows in the supplied multiples csv (as reason for early roll is unknown for those not in production)
2. Then, let the newly generated multiple prices be spliced (from 2024-03-26 instead 03-28) with the modified supplied multiple prices.

This seems to have the benefit of having the contract & prices staying consistent with the new calendar and contract prices until month end as expected.

Is there a reason to prefer one approach over the other (assuming the alternative is viable)?

Thanks, Adnan

[tgibson11]

what are the explanations for why the instruments (with the Assertion error) were rolled earlier (by Carver based on the dates in the supplied multiple prices) than the expected roll date based on the new roll calendar based on the updated contract prices?

As you suggest, the provided multiple prices reflect when Rob actually did his roll. Why did he do it when he did? The short answer is that he was trying to minimize his roll costs, rather than blindly sticking to a schedule.

In this example, he probably had a position in the May contract, he held it as long as he could, probably in a Passive roll state. Then either the roll finally happened passively, or he was forced to roll because of contract expiry or because IB would have force-closed his position.

Wouldn't an alternative (equivalent?, better?) solution be to (as also suggested by @vishalg):

Delete the offending rows in the supplied multiples csv (as reason for early roll is unknown for those not in production)
Then, let the newly generated multiple prices be spliced (from 2024-03-26 instead 03-28) with the modified supplied multiple prices.

Sure, you could do that if you like. The usual approach is to take the provided multiple prices as-is and extend them. But if you prefer to modify the existing prices instead, you're free to do that too.

Is it equivalent or better? Is there a reason to prefer one? It probably doesn't make much of a difference. The thing is, if you look further back in the multiple prices, you will see more examples of this sort of thing. So don't imagine that you'll have a nice orderly multiple price history that follows the roll config like clockwork.

And if you want to minimize your own roll costs, you won't be blindly following a roll schedule in your own trading either.

[vishalg]

Very good points. Trading future rolls is an entire discipline in itself. For a daily rebalancing futures strategy being super accurate about rolls is not necessary. "Bad rolls" will fall out of the price signals in a few months and the impact on estimation of vols will be very minimal.

[tgibson11]

I just realized that I misinterpreted the roll calendars from @adnan-trader. All my points above remain valid, but my explanation applies to a different scenario than the one actually presented.

So...

Rob actually rolled about a week earlier than would have been the case strictly following the roll config. Why? The short answer is still the same: to minimize roll costs.

Rob was probably looking 1-2 weeks ahead. He saw a roll was going to be coming up. He saw that he currently had no position in the instrument. He saw that the volume in the forward contract was adequate, so he rolled.

How is that minimizing costs? Well, imagine if he had waited. Then there is a chance that a position might be taken in the old contract. Now a few days later you have to sell what you just bought (or vice-versa). Better to do the roll when your system doesn't have an open position, if you can.

[adnan-trader]

Thanks again @tgibson11. As I have gone through more of the offending instruments, I see the same pattern where the contract was rolled 1-2 weeks earlier than what is suggested by the generated roll calendars. Your practical experience in live trading has provided some great insights on why the supplied multiple prices deviate from the 'theoretical' roll calendars generated. So, I better understand why it is (probably) better to treat the supplied multiple prices as given and adjust the generated roll calendars as you suggested. Also, not to think of the roll calendars as some perfectly spaced set of dates.

Now the hard work of adjusting ~30 or so calendars...

[vishalg]

In this case I am tempted to delete the offending rows rather than fix the roll calendar. That's because the new forward contract is missing prices for a few days which would seem to indicate that it was rolled too early perhaps.