Market Orders used during Backtesting

[BraisedInBlue]

It appears that trying to submit an order against a BarsInIndex that you are not currently in I.E EnterLong(1, 1, "signalName") while currently residing within BarsInProgress == 0 is what is causing the assertion failure. But it only happens when using a 1m bar. The assertion failure doesn't occur in longer bars.

[NinjaTrader_ChelseaB]

Hello BraisedInBlue,

Below is a link to a reference sample where you can test that theory. This will place orders to BarsInProgress 1. Add the sample to a 1 minute chart.

https://ninjatrader.com/fr/support/helpGuides/nt8/backtesting_ninjascript_strate.htm

Does this also have an error?

[BraisedInBlue]

It does not appear to have the same issue. I am sure there is a reasonable explanation for why it is occurring in my custom code (its likely my fault), but its low on my priority to debug since I can prevent it by ensuring the entry orders can only occur on the secondary series. Thank you for the help!

[NinjaTrader_ChelseaB]

Hello BraisedInBlue,

If you have a legitimate error you can isolate, I would want to know about it.

Strategies should be able to place orders to any series without error.

[BraisedInBlue]

Chelsea,

I am in the middle of refactoring a good portion of my support code, also found some minor issues/bugs in some of my operational understanding of the event processing. But I will revisit this scenario after I get done getting re-baselined, to see if I can reproduce the issue and give you a stubbed unit test.

[BraisedInBlue]

o while some of my issues have been resolved that I was seeing, (fixed some issues in my code). But now I am seeing behavior that I thought shouldn't be occurring.

This is related to when the market order is executing.

The strategy is running Calculate.OnPriceChange, and the logic is tied to OnBarUpdate. OnBarUpdate() is called for each price change (Tick replay enabled) as desired, and the entry condition is detected properly to trigger the order. But the order is filling at the price of the bar's open. I only have a primary time-series, no secondary tick-series. I am running in market replay with tick-replay enabled.

A picture is worth a thousand words in this case. So I can confirm that the entry conditions are met, but when the market order is submitted, it is filling as if we are at the open of the current bar. Is this because OBU still considers us in the previous closed bar, thus "submitting to the next open bar" is actually the current bar when OBU is processing intra-bar data?

[BraisedInBlue]

The behavior looks better if I use a secondary tick series, but there is still some delay. Is this to be expected? Also, it seems there is some issues because order is filled against the tick series, and shows the buy at two different prices (1 order), so I am not sure what to make of that.

[NinjaTrader_ChelseaB]

Hello BraisedInBlue,

May I confirm that State is State.Realtime when this occurs and is not State.Historical?

Was Calculate changed in State.SetDefaults or State.Configure, or manually in the strategy settings?
Has the instance of the script been removed and re-added for defaults to be pulled?

What is the exact playback time the condition is true order is submitted?
Print(string.Format("condition true at: {0}", Cbi.Connection.PlaybackConnection.Now));
(This is so we can confirm the order is placed before the bar is closed)

Please also enable TraceOrders to get information about the order submission.

With delay, this depends on what you mean. You are seeing a delay between the time the print appears for the submission and the time the market order fills?

[BraisedInBlue]

Ill go through your questions and see what I come back with. I was loading into the same paused point in market replay. I will need to go back and verify if I was in the market replay data or historical data. Calculate is being set in State.Configure but should align with the Calculate from strategy settings.

[NinjaTrader_ChelseaB]

Hello BraisedInBlue,

Where you have mentioned:
" but should align with the Calculate from strategy settings."
This is not necessarily true.

If Calculate is set in State.Configure this will superceed what is selected in the Strategy window in the strategy parameters.

If you select Calculate.OnPriceChange in the strategy parameters in the Strategy window, and you have Calculate.OnBarClose set in State.Configure, the Calculate will be OnBarClose and will not match what was chosen in the Strategy window in the strategy parameters.


The defaults are only pulled once when adding a new instance of the script. This means if code is set in State.SetDefaults, the strategy instance must be removed and a new instance added so the new defaults are pulled.


To avoid confusion, print it to the output window in OnBarUpdate.

https://ninjatrader.com/support/forum/forum/ninjatrader-7/strategy-development-aa/99209-date-conditions-not-working?p=791121#post791121

[BraisedInBlue]

I meant to say that the code is set to OnPriceChange, and have the strategy template also set to use OnPriceChange. Unfortunately, I am having a little trouble recreating the exact scenario I have screen captured above, but I am still seeing some off order behavior, so I will add the debug info you asked for and try to capture another scenario.

[BraisedInBlue]

So after reviewing this setup, it appears that the incorrect entry is only occurring in historical mode (its worse when there is only the primary bar series as the order triggers at the open of that bar vs using a small secondary series for submitting the order). Tracing orders and the PlaybackConnection.Now member aren't valid during historical strategy testing. (Now will report what the current play back time is vs. the historical time stamp).

To recap, Calculate mode is consistently set to OnPriceChange via the Strategy initialization, and the strategy enabling menu for the chart. The order issues I see occur when using a singular data series (1 minute) with onPriceChange, TickReplay enabled, and leveraging OnMarketData() to process trade entries and exits. (Trade entry occurs at the open of the bar in which the condition triggered it).

Now, as an attempt to alleviate the problem, I can add a secondary series of a finer granularity (Smaller time or a small tick based bar). When using Ticks the order is firing on a later bar, (its not always on the bar following the bar the condition was triggered, and seems to vary some), when using smaller time bars, order entry still occurs at the open of the bar in which the condition was met.

However! My original setup, with only the primary series works fairly well in real-time. So what I am trying to achieve is similar entries between real-time and historical (because this is how back-testing will function).

[NinjaTrader_ChelseaB]

Hello BraisedInBlue,

Do you have TraceOrders and Prints and a specific bar time that shows the issue?

May we also see the output from the TraceOrders and Prints?

What is the bar time and date we should focus on?

[BraisedInBlue]

So here is a screen cap capturing the additional debug info. The "**** Entering" line is printed when the condition is met and the order submitted via EnterLong/EnterShort. Now again this is in the historical data section of a playback, and thus the PlaybackConnection.Now is simply printing the time I am paused at when reloading the strategy. This order submission misalignment is identical in backtesting via the strategy analyzer. The detection is occurring intra-bar (due to using Calculate.OnPriceChange, OnMarketData, and TickReplay) but when you submit the order against the sole-primary bar series, it is market filling as if it triggered at the open of that bar.

This order submission behavior basically makes historical/back-testing invalid as it gives significantly better fills fairly consistently (It makes losers, lose less, and winners, win more consistently). However, this implementation works reasonably well in real-time operation (in terms of when orders execute).



There is a little bit chopped off in the log window so here a copy of the relevant order.

***** Entering Short Trade: @3691.75 at bar: 2150 time: 1/5/2021 7:36:22 AM

1/5/2021 7:07:00 AM Strategy 'Prediction Engine/221444164': Entered internal SubmitOrderManaged() method at 1/5/2021 7:07:00 AM: BarsInProgress=0 Action=SellShort OrderType=Market Quantity=1 LimitPrice=0 StopPrice=0 SignalName='testSell' FromEntrySignal=''

1/5/2021 7:07:00 AM Strategy 'Prediction Engine/221444164': Entered internal SetStopTarget() method: Type=Stop FromEntrySignal='testSell' Mode=Currency Value=275 IsSimulatedStop=False IsMarketIfTouched=False


****** EPIPHANY *********

As I was filling out my response here, I had an epiphany (work around). The submission of market orders on time-series bars in State.Historical doesnt fire until the bar is closed (Which is why it should be seen on the open of the bar after the condition is triggered). I tried circumventing this by leveraging OnMarketData and TickReplay to give me intra-bar granularity without all the extra overhead and processing changes that come from using multiple time-series.

But this just causes the order to be submitted as if we are in the previous closed bar (hence why it always occurs at the open of the bar in which the condition triggered the order), By switching to Limit orders for entry during State.Historical, I can achieve the entry I desired (more or less).

However, then I need to deal with the exits, as the same problem occurs on market exits (exits occur on the bar open price for which the condition triggered). Unfortunately, there is no functional work around for exits, as Stops/StopLimits will just throw the error saying the order is invalid, and MIT/limit orders will allow submission but will never trigger (Not entirely sure why this is the case). Here is a screen cap of the fixed entry, but the problematic exit.



Here is the order trace for the corresponding exit order.


***** Exiting Short Trade: @3688 at bar: 2168 time: 1/5/2021 7:43:22 AM

1/5/2021 7:25:00 AM Strategy 'Prediction Engine/221444164': Entered internal SubmitOrderManaged() method at 1/5/2021 7:25:00 AM: BarsInProgress=0 Action=BuyToCover OrderType=Market Quantity=0 LimitPrice=0 StopPrice=0 SignalName='' FromEntrySignal='testSell'

1/5/2021 7:25:00 AM Strategy 'Prediction Engine/221444164: Cancelled pending exit order, since associated position is closed, orderId='NT-00128-435' account='Playback101' name='Stop loss' orderState=Working instrument='ES 03-21' orderAction=BuyToCover orderType='Stop Market' limitPrice=0 stopPrice=3697.25 quantity=1 tif=Gtc oco='NT-00086-435' filled=0 averageFillPrice=0 onBehalfOf='' id=-1 time='2021-01-05 07:07:00' gtd='2099-12-01' statementDate='2021-01-14'


So I am sure that the "Answer" here is that I absolutely have to use a secondary time series in order for the intra-bar granularity to work, but the API is exposing a 60% solution that doesn't require a secondary time-series (Meaning everything but the order submission components can work in this way).

[NinjaTrader_ChelseaB]

Hello BraisedInBlue,

Is this still an inquiry about an error received from an order placed to BarsInProgress 1 that is not filling with the data from that series?

Do you have a saved output text file you would like assistance analyzing?