Default vs NinjaScript Category in Log

[samish18]

I am running a strategy live and it entered a trade in between bars (I am using onBarClose) and this trade did not occur in the backtest, when looking at the execution of this trade in the log, it is categorized as "Default" with message "Ninjascript strategy EMACrossOver submitting order". I noticed that for other entries that occurred correctly (same execution appears live and in backtest) the message is the same, but it is categorized as "Ninjascript" in the log. Why is this?

[NinjaTrader_Gaby]

Hello samish18,

Thank you for your post.

Generally, "Default" would be from the core and "NinjaScript" would be something specific about a NinjaScript. In my testing I am seeing that the very first submission after enabling is categorized as Default and the rest are labeled as NinjaScript - this would be incorrect. If you would like I can submit a report on this.

Regarding a difference between your live performance, as has been discussed on your previous posts, live orders are filled on an exchange with a trading partner on an agreed upon price based on market dynamics. Backtest orders are not using these market dynamics. Instead these are filled based on logical rules from processing historical data.

• When in historical data, only the Open, High, Low, and Close will be available and there will be no intra-bar data.
  • This means actions cannot happen intra-bar, fills cannot happen intra-bar. All prices and actions come from and occur when the bar closes as this is all the information that is known
  • Because of this, OnBarUpdate will only update 'On bar close' as it does not have the intra-bar information necessary for 'On price change' or 'On each tick' and the script will not have the intra-bar information to accurately fill an order at the exact price and time.

Intra-bar granularity adds a second data series such as a 1 tick series using AddDataSeries() so that the strategy or indicator has the individual ticks in the historical data in between the High and Low of the primary series. Are you using the BarsInProgress index of the added 1 tick series for the order method calls? For example,

EnterLong(int barsInProgressIndex, int quantity, string signalName)

What is the BarsInProgress index you are supplying to the order methods?
During what BarsInProgress is the order submitted?

If you have implemented intrabar granularity and are still seeing a discrepancy, please provide the output from debugging to understand what is causing the differences.

Write the price data and condition values to a text file, write the order.ToString() and execution.ToString() in a text file.
Run the strategy again in real-time and backtest.

Below is a link to a support article that provides instructions and an example script with sample code.

https://support.ninjatrader.com/s/article/Developer-Guide-Comparing-Strategy-Results

[samish18]

Yes, please submit a report on it. I am running the strategy using onBarClose, and am never entering intrabar. I noticed with other strategies, the first submission is still categorized as "NinjaScript", it is only the erroneous order that happened intrabar and on a day when the strategy took no other in backtest that was cateogorized as "Default". This leads me to believe that the submission under the "Default" category was faulty and I would like to avoid this

[NinjaTrader_Gaby]

Hello samish18,

I will submit a report on the Log message displaying as "Default" when it should be "NinjaScript".

However, I cannot claim in the report that the orders labeled "Default" are erroneous without evidence. We would need output from debugging that illustrates this.

Regarding intrabar granularity, this is not for entering intrabar. This is for accurate order fills, and is still necessary when using OnBarClose.

[samish18]

How may I avoid this erroneous entry under the "Default" category so that my strategies only enter correctly when it is "Ninjascript"

[NinjaTrader_Gaby]

Hello samish18,

Thus far you haven't provided any evidence that suggests that the incorrect labeling is also an erroneous entry (an entry your strategy wasn't supposed to take).

While I can see that the first submission is labeled as "Default" in the Log, from my testing there is nothing to suggest that this is tied to the strategy's logic / the strategy wouldn't have taken this order.

If you're suggesting the label bug and this order submission are related, you would need to provide debugging output showing clearly showing that the conditions in your script shouldn't have allowed for this entry to be taken. Otherwise, the only thing I can note in the report is that the label is simply wrong (not that the entries are wrong).

[samish18]

The categorization implies that the order is not from the script and as I previously said, both the chart data, backtest and prints suggest that no order should have been taken.

[samish18]

I have also only noticed this issue when running a strategy live and it has never occurred in sim

[NinjaTrader_Gaby]

Hello,

The categorization implies that the order is not from the script and as I previously said, both the chart data, backtest and prints suggest that no order should have been taken.

The categorization does not explicitly imply this - if you have done the debugging please provide this as supporting evidence, along with a reduced sample script to reproduce.

I have also only noticed this issue when running a strategy live and it has never occurred in sim

As discussed in your various posts about the topic, a strategy running real-time (live brokerage account, live market simulation, Playback connection etc...) will produce different results than the performance results generated during a backtest. Intrabar granularity needs to be properly implemented in order to have accurate results.

Have you implemented 1-tick intrabar granularity?

Are you using the BarsInProgress index of the added 1 tick series for the order method calls? For example,

EnterLong(int barsInProgressIndex, int quantity, string signalName)

What is the BarsInProgress index you are supplying to the order methods?

During what BarsInProgress is the order submitted?

[samish18]

I have implemented 1-tick granularity, am using barsinprogress of added series. Your above statement address the issues between backtest and live, but not between live and sim. I don't know if there is an issue, just stating I have not had this issue in live simulation

[NinjaTrader_Gaby]

Hello samish18,

I don't know if there is an issue, just stating I have not had this issue in live simulation

I see, thank you for clarifying. I am seeing the mislabeling occurring with the Sim101 account on live data, however, from my testing the mislabeling does not also suggest that the mislabeled Default entry should not have occurred. I'm testing with the SampleMACrossover.

I look forward to receiving the output and reduced sample script that demonstrates that the mislabeled entry should not have occurred. Once again, to be clear, without the reduced sample and output to back this up, the only thing I can note in the report is that the Log message is mislabeled (not that the entries are wrong).

[samish18]

Just to clarify, when testing this, how often do you see it? I've seen it about 1-2 times a week when running 20+ strategies a day. It seems to only occur sometime when a strategy is taking it's first order since activation. Is this consistent with your experimentation?

[NinjaTrader_Gaby]

Hello samish18,

Yes, I am seeing the same thing. Only for the first order after enabling the strategy.

[samish18]

How often are you seeing it? Also when you run multiple strategies do you only see it for a single strategy?