Multi timeframe strategy - Order of BarUpdates

[NinjaTrader_PatrickH]

Hello Shansen,

Thank you again for your patience.

As far as the Trading Hours template; Playback cannot start for each instrument in a multi-time frame indicator or strategy until a tick is received for each. This means that a tick a is forced to the series that utilizes the "smaller" Trading Hours template when the tick is received for the "larger" Trading Hours template.

For the BarsArray[1] having an update timestamp for the tick received when BarsArray[0] receives the same tick this actually matches the Multi-Time Frame & Instruments.

In your's and my own examples the primary series is 5 minute bar and the secondary series is a 15 minute bar. This means the documentation for Multi-Time Frame & Instruments still matches up, you just need to think of the top displayed bars in the image as the secondary bar series or the bottom displayed bars.

The image displays the 14:59:00:480 timestamp on the Tick bars and shows that the bars 2 and 3 for the primary series in the image also show the secondary series receiving the tick at the same time. Which is what we see when we call the first tick of a bar and check the BarsInProgress == 0 and call the Times[1][0] showing that it is in fact already updated but has not called OnBarUpdate yet.

Please let me know if you have any questions.

[Shansen]

Regarding Trading Hours, if my understanding is correct, your response does not explain the behaviour.

1. You state "Playback cannot start for each instrument in a multi-time frame indicator or strategy until a tick is received for each". This is a single-instrument Strategy, all BAs are on the same Instrument (i.e. 6B 03-18), the first tick is received for each BA at the same time (noting the consecutive processing for each BA).
   Where your statement implies the output would start with the start of the "smaller" Trading Hours template "US Equities RTH" 9:30am - 4:00pm ET (UTC-5) which equates to Melbourne 1:30am - 8:00am AEDT (UTC+11). The first output line would be for the bar ended 1:35am AEDT. However, in each scenario (i.e. #1.AddDataSeries, #2.AddDataSeries with TrHrs, and #3.AddDataSeries with TrHrs & Default 24x7), the output starts at 4:05pm.
   
2. You state "a tick is forced to the series that utilizes the 'smaller' Trading Hours template when the tick is received for the 'larger' Trading Hours template". If I understand your statement correctly, where the DataSeries using the 'smaller' Trading Hours template (i.e. US Equities RTH) is output, the output for this series would start with the start of the Trading Hours template (i.e. 1:35am AEDT). This is in line with my understanding. However, this DataSeries (i.e. BA[3]) is not output as part of StratC. StratC only outputs BA[0], BA[1], & BA[2].

As I see it, under scenario #2 AddDataSeries with TrHrs (middle table), IsFirstTickOfBar for BA[0] 5min and BA[1] 15min incorrectly align with IsFirstTickOfBar for BA[2] 60min. Under scenario #3 AddDataSeries with TrHrs & Default 24x7 (right-hand table), records broadly align with the expected scenario #1 (left-hand table). In the attached picture (originally from post#14) contrast the red circled records in each table.
However, scenario #3 is missing BarUpdate events for BA[0][11], [16], & [29]. In the attached picture, marked with purple lines.
Please advise how scenario #3 is missing BarUpdate events.


Regarding update of secondary DataSeries, you state, at the first tick of a bar under BarsInProgress == 0, Times[1][0] shows it is updated but has not called OnBarUpdate yet (AKA processed yet). So we have confirmed there is a "disconnect" between update and processing of secondary DataSeries. That is, where BA[1] is updated but not processed, an Indicator value at BA[1][0] will point to null(?) as it is yet to process, an Indicator value at BA[1][1] will point to BA[1][0] as it is yet to process. Once BA[1] is processed, an Indicator behaves as expected, the value at BA[1][0] points to BA[1][0], the value at BA[1][1] points to BA[1][1]. So, depending where we are in the evolution of processing Indicator values are not as expected.

Is there a way to determine whether a BA has processed? While StratC presents a workaround, it is only a workaround. The logic required is convoluted.
Can NT8 core logic be changed to align the update and processing of secondary DataSeries, such that an Indicator will always behave as expected regardless of where we are in the evolution of processing (i.e. the value at BA[1][0] always points to BA[1][0])?

[NinjaTrader_PatrickH]

Hello Shansen,

Thank you for your response.

OnBarUpdate() will be called for each update to the BarsArray but in the sequence of the added series.

I cannot reproduce the output you have with my own indicator. Can you review my code and test it and advise if you can still produce the same behavior with my code or what is differing in your code from mine?

I look forward to your response.

[Shansen]

Please find attached your code, TestMultiTimeFrame, slightly revised. I've added two mock Indicator Properties: ProxyIndValueBip0 and ProxyIndValueBip1 and output them after the Times[x][x] values.

The output shows:

• At BIP0 FirstTickOfBar, ProxyIndValueBip1 is null (1/01/0001 12:00:00 AM) (BIP1 has not yet processed)
• At BIP1 FirstTickOfBar, ProxyIndValueBip1 is processed (10/01/2018 6:10:00 AM)

So, depending on the evolution of processing, BIP 1 currt close (10/01/2018 6:10:00) has different values for ProxyIndValueBip1.
* Note: BIP1 prior close is always null. As part of this demo script, this can be ignored as the Series ProxyIndValueBip1 is aligned to the primary BarsArray.

UPDATE - BIP 0
BIP 0 prior close: 10/01/2018 6:00:00 AM - 10/01/2018 6:00:00 AM
BIP 0 currt close: 10/01/2018 6:05:00 AM - 10/01/2018 6:05:00 AM
BIP 1 prior close: 10/01/2018 6:00:00 AM - 1/01/0001 12:00:00 AM
BIP 1 currt close: [B]10/01/2018 6:10:00 AM - 1/01/0001 12:00:00 AM[/B]
The tick updating: 10/01/2018 6:00:34 AM

UPDATE - BIP 1
BIP 0 prior close: 10/01/2018 6:00:00 AM - 10/01/2018 6:00:00 AM
BIP 0 currt close: 10/01/2018 6:05:00 AM - 10/01/2018 6:05:00 AM
BIP 1 prior close: 10/01/2018 6:00:00 AM - 1/01/0001 12:00:00 AM
BIP 1 currt close: [B]10/01/2018 6:10:00 AM - 10/01/2018 6:10:00 AM[/B]
The tick updating: 10/01/2018 6:00:34 AM

Please find attached a Strategy, TestMultiTimeFrameStrat. Where the Indicator, TestMultiTimeFrame2, has been culled to one DataSeries.

The output shows:

• At BIP0 FirstTickOfBar, BIP1.ProxyIndValue is processed (9/01/2018 6:10:00 PM)
• At BIP1 FirstTickOfBar, BIP1.ProxyIndValue is already processed.

UPDATE - BIP 0
BIP 0 prior close: 10/01/2018 6:00:00 AM - 10/01/2018 6:00:00 AM
BIP 0 currt close: 10/01/2018 6:05:00 AM - 10/01/2018 6:05:00 AM
BIP 1 prior close: 10/01/2018 6:00:00 AM - 10/01/2018 6:00:00 AM
BIP 1 currt close: [B]10/01/2018 6:10:00 AM - 10/01/2018 6:10:00 AM[/B]
The tick updating: 10/01/2018 6:00:34 AM

UPDATE - BIP 1
BIP 0 prior close: 10/01/2018 6:00:00 AM - 10/01/2018 6:00:00 AM
BIP 0 currt close: 10/01/2018 6:05:00 AM - 10/01/2018 6:05:00 AM
BIP 1 prior close: 10/01/2018 6:00:00 AM - 10/01/2018 6:00:00 AM
BIP 1 currt close: [B]10/01/2018 6:10:00 AM - 10/01/2018 6:10:00 AM[/B]
The tick updating: 10/01/2018 6:00:34 AM

My understanding has been incorrect. For a multi time-frame Strategy, Indicators are updated as they are called regardless of the BIP. As above, when called an Indicator based on BIP1 is processed and returned in BIP0.

[NinjaTrader_PatrickH]

Hello Shansen,

Thank you for your patience.

This is the correct behavior. The called indicators run on their BarsArray where a Series must first be updated in it's script on the desired BarsInProgress call to OnBarUpdate().

Please let me know if you have any questions.

[Shansen]

Patrick,

Thank you for persisting.

Please find attached a reworked Strategy, StratA, which hosts an Indicator BarProgress. Where BarProgress only serves to access IsFirstTickOfBar for each BarsArray (a workaround for the NT post : Multi timeframe strategy - IsFirstTickOfBar of non-processing BarsArray)

Please find attached the output which shows a very close match between Test 1 (AddDataSeries) and Test 2 (AddDataSeries with TrHrs & Default). As shown, sporadic differences occur.

How can these differences occur?

[NinjaTrader_PatrickH]

Hello Shansen,

Thank you for your response.

While you are using the correct idea in the strategy, the use of the indicator in the strategy could be the reason for the discrepancy.

Please try calling .Update() on the indicator array at the beginning of the OnBarUpdate():

		protected override void OnBarUpdate()
		{
            if (!IsFirstTickOfBar) return;
			
			_barProgress[BarsInProgress].Update();

If the behavior continues please consider assigning specific indicator instances to each individual BarsArray without the use of the array.

Please let me know the results of this.

[Shansen]

Any excellent idea... to no avail.

This makes sense. As highlighted in the attached picture, while inconsistent, the issue occurs in BarsArrays (BAs) that are about to be "updated". As _barProgress[BarsInProgress].Update() will only impact the current BA, the problem BAs remain untouched.

While it is helpful to know how this is occurring, does it matter? In each instance the Times[x][barsAgo] is yielding the correct answer.

Any insight is welcome.

[NinjaTrader_PatrickH]

Hello Shansen,

Thank you for your response.

IsFirstTickOfBar would not be set for the BarsArray until it called OnBarUpdate. Even forcing the Update() of the indicator does not force it to call a BarsArray out of sequence.

So each BarsArray must see it's OnBarUpdate() before it can set it's IsFirstTickOfBar.

Please let me know if you have any questions.

[Shansen]

If I understand your statement correctly, it does not fit the evidence (the attached picture in post #23).

I agree, forcing Update() of the Indicator will not force it to call a BarsArray out of sequence:

_barProgress[BarsInProgress].Update();

However, calling the Indicator property IsFirstTick[0] from the Strategy (as is currently done) does trigger the Indicator's OnBarUpdate:

_barsAgos[array] = _barProgress[array].IsFirstTick[0] ? 1 : 0;

As highlighted in post #23, the issue is this does not appear to be done consistently. In the picture, every cell not shaded orange shows .IsFirstTick[0] has successfully updated, every cell shaded orange shows it has not updated. Hence, it appears to work inconsistently.

[NinjaTrader_PatrickH]

Hello Shansen,

Thank you for your response.

We should only be checking or assigning the IsFirstTickofBar to a variable when the BarsArray has called OnBarUpdate() via BarsInProgress.

If you implement this into the strategy do you continue to see the discrepancies?

I look forward to your response.