Question about muti-instrument indicator

[ETFVoyageur]

To keep things simple, this example has both the chart and all added DataSeries using 1-day bars. No multi-time issues are involved. CalculateOnBarClose is false, so no issues about the final data. Running on historical data, if that matters (it's Sunday).

The examples I see, including in the NT documentation (Multi-Time Frame & Instruments) all seem to suggest that at any entry to OnBarUpdate all DataSeries willl apply to the same date. Some may not yet be valid, which can be discovered by noting that the series' CurrentBar property is -1.

Here is the tail end of a Print() statement I put at the beginning of OnBarUpdate, so all series have valid data. The comma-separated number pairs are CurrentBar,Count for that DataSeries.

DEBUG: OnBarUpdate(): CurrentBar=2641,2643  BarsInProgress=1  BarsArray length=3  BarsArray[0] null=False,114,117  BarsArray[1] null=False,2641,2643  BarsArray[2] null=False,1305,1308
DEBUG: OnBarUpdate(): CurrentBar=115 ,117   BarsInProgress=0  BarsArray length=3  BarsArray[0] null=False,115,117  BarsArray[1] null=False,2641,2643  BarsArray[2] null=False,1306,1308
DEBUG: OnBarUpdate(): CurrentBar=1306,1308  BarsInProgress=2  BarsArray length=3  BarsArray[0] null=False,115,117  BarsArray[1] null=False,2641,2643  BarsArray[2] null=False,1306,1308
DEBUG: OnBarUpdate(): CurrentBar=2642,2643  BarsInProgress=1  BarsArray length=3  BarsArray[0] null=False,115,117  BarsArray[1] null=False,2642,2643  BarsArray[2] null=False,1306,1308
DEBUG: OnBarUpdate(): CurrentBar=116 ,117   BarsInProgress=0  BarsArray length=3  BarsArray[0] null=False,116,117  BarsArray[1] null=False,2642,2643  BarsArray[2] null=False,1307,1308
DEBUG: OnBarUpdate(): CurrentBar=1307,1308  BarsInProgress=2  BarsArray length=3  BarsArray[0] null=False,116,117  BarsArray[1] null=False,2642,2643  BarsArray[2] null=False,1307,1308

The thing that is puzzling me is that the date is not the same for all of them. I would expect that, for any given line, (BarsArray[n].Count - BarsArray[n].CurrentBar) would be the same value for all n. That is sometimes, but not always, true.

For example, consider the last line for BarsInProgress=1. BarsArray[1] is on its final bar, while the other two DataSeries are on the bar before their final bar.

Could someone please help me understand what I am missing here?

Thanks,
EV

[NinjaTrader_PatrickH]

Hello EV,

Thank you for your post.

CalculateOnBarClose would have no effect when processing historical data as all bars have closed and are thus CalculateOnBarClose = true regardless of what you have set it to.

It is possible for the the CurrentBar to be less than Count by more than 1 due to the multi-threaded architecture of NinjaTrader. Couple this with multiple bar series closing at various times and historical processing of the data, we can see different bar counts for each of the series in the multi-series script.

[ETFVoyageur]

Hello EV,

Thank you for your post.

CalculateOnBarClose would have no effect when processing historical data as all bars have closed and are thus CalculateOnBarClose = true regardless of what you have set it to.

It is possible for the the CurrentBar to be less than Count by more than 1 due to the multi-threaded architecture of NinjaTrader. Couple this with multiple bar series closing at various times and historical processing of the data, we can see different bar counts for each of the series in the multi-series script.

I'm sorry but one of us is not communicating successfully. I do not see the answer to my question here.

--EV

[ETFVoyageur]

Hello EV,

Thank you for your post.

CalculateOnBarClose would have no effect when processing historical data as all bars have closed and are thus CalculateOnBarClose = true regardless of what you have set it to.

That is not true. If COBC is not false, then OnBarUpdate() does not get called for the last bar. I just went and empirically verified that -- I set COBC true for a moving average, and that MA now stops one bar short of the end.

It is possible for the the CurrentBar to be less than Count by more than 1 due to the multi-threaded architecture of NinjaTrader. Couple this with multiple bar series closing at various times and historical processing of the data, we can see different bar counts for each of the series in the multi-series script.

<required characters>
--EV

[NinjaTrader_PatrickH]

Hello EV,

Thank you for your response.

What items do you need clarifying on here?

For historical data CalculateOnBarClose is always True, this is a constant fact. Are you running this in Market Replay or real-time data?

[ETFVoyageur]

I am running it in a chart. If you set an indicator to have COBC true, it will never get called for the last bar. That is well-known, documented behavior.

--EV

[ETFVoyageur]

Hello EV,

What items do you need clarifying on here?

I was of the impression that -- assuming all data series are the same time frame (e.g. all are1-day bars) -- whenever OnBarUpdate() is called <DataSeries>[0] would refer to the same date for each of the indicator's multiple data series. Some of the series may not have started yet, but that is easy to tell -- their CurrentBar property is -1. But when you get close to the latest bar all should be valid and all should be synchronized.

• That has to be true or else some of the examples in the NT documentation are wrong
• My debug prints, however, show that is false -- as I demonstrated in the original message in this thread

OK -- there is an obvious conflict. Please tell me exactly what a programmer can expect for state whenever OnBarUpdate() is entered, and how that relates to each of the two bullet points above. Knowing that is crucial for making an indicator based on the relationship of two data series (ratio, difference, etc).

--EV

[ETFVoyageur]

I am looking at a chart where the prices start after the other data series are available. In that case, examining the trace output, it looks to me as if the situation is:

• Whenever OnBarUpdate() is called, all data series other than BarsArray[0] are in synch
• BarsArray[0] is also in synch only when (BarsInProgress==0) has occurred, and thereafter until the next cycle starts

That makes it look to me as if the simplest / safest way to handle this is:

• When (BarsInProgress != 0), just return
• When (BarsInProgress == 0), do your calculations, using the correct indexing.

Is this consistent with others' experience? Am I missing something? Why is (BarsInProgress != 0) even interesting other than the unadorned properties, such as CurrentBar, being set to that data series (and they are just a convenience -- accessible anyway with indexing)?


--EV

[NinjaTrader_PatrickH]

Hello EV,

Thank you for your patience.

I appreciate the items you bring up here and will ensure I provide the most informative answers here. I will need to investigate this further on my end as well.

May I ask what Session Template is used? And what are the Instruments used?

[ETFVoyageur]

Hello EV,

Thank you for your patience.

I appreciate the items you bring up here and will ensure I provide the most informative answers here. I will need to investigate this further on my end as well.

May I ask what Session Template is used? And what are the Instruments used?

Thanks, Patrick. Instruments -- I was charting JDST, just to have one that I knew did not go back very far. The added instruments were those in the Default instrument list and those in the DOW 30 instrument list. (BTW: one of those in the DOW 30 instrument list did not make a Data series -- index #24, but I've been too busy to even look and see which one that is.)

Not sure what you want to know about Session Template -- I just add my indicator to a chart and look at the trace printing.

The way to check synchronization is at the entrance to OnBarUpdate see whether or not all of the issues have the same value for their (Count - CurrentBar). That will match for the synchronized ones. It does not matter for the ones whose CurrentBar is -1 --- they have not yet started. All other mismatches are the issue I was talking about.


--EV

[koganam]

... Why is (BarsInProgress != 0) even interesting other than the unadorned properties, such as CurrentBar, being set to that data series (and they are just a convenience -- accessible anyway with indexing)?
--EV

One might want to execute on a timeframe other than the chart's time frame. e.g., one may want to execute intraday on a daily chart.

[ETFVoyageur]

One might want to execute on a timeframe other than the chart's time frame. e.g., one may want to execute intraday on a daily chart.

Granted -- I was too narrowly focused. In my specific case of all series being the same time frame, though, I think my observation has merit. Am I missing something in that case?

--EV

[koganam]

Granted -- I was too narrowly focused. In my specific case of all series being the same time frame, though, I think my observation has merit. Am I missing something in that case?

--EV

Nope: your observation is spot-on. If all my instruments are on the same time frame, I always execute on BarsInProgress == 0. It makes the most sense, as it is directly synched to the chart.

[NinjaTrader_PatrickH]

Hello EV,

Thank you for your additional details on this item. And thanks to Koganam for their assistance here.

EV, do you have a sample script that reproduces the same behavior you were seeing in your original post that I may test on my end?

[ETFVoyageur]

Patrick,

I'll try to get to creating a little demo for you if you like. Just be aware that will not address my question. Any demo will be just one case. My experience is that the observed facts vary with such things as what the primary instrument is. Other things may also have an effect, such as data series with varying starting times -- I just do not know. For example, I get different results when the primary instrument is very new (and so starts after the other data series do).

This is not about any programming problem I am having. It is about getting the answer to one very simple question: "What is guaranteed about the synchronization of the multiple data series on entry to OnBarUpdate()?" I have shown that they are not always all synchronized. Under what conditions are they guaranteed to be synchronized?

Code needs to now this if it is to operate on more than one of the series, such as taking a ratio or a difference. Such operations only make sense on synchronized data series.

--EV