As you can see from the screenshots, Strategy Monitor created a limit sell order of $11.05 (for CAMT), which the exchange never filled on the Orders window today because the high only reached $10.80; that's expected. The problem is the WLP 6.9.20.7 Chart window sold the same position for the opening price of $10.73. Can someone explain why this happens? Some comments:

1) This occurs extremely rarely, and I don't know how to reproduce it.
2) If I close WLP and reopen it, it stills shows the sale at $10.73 for 10/31 and Strategy Monitor still shows a 10/30 Alert limit order to be placed today (10/31) for $11.05. So the WL program isn't trying to hide its tracks when it is restarted.
3) It looks like the Alert generated by SM is not corresponding to what the Chart window is trying to do. I'm not sure how that's possible. (Perhaps the Chart window mistakes it for a Market order when SM knows it's really a Limit order. How could I test that?)

Is this something unique to my strategy, or is this something internal to the WL program?

Apparently what the chart window does is sell next bar (10/31) at market which coincides with the open price. However, without seeing the actual code and ensuring that the strategy's settings (incl. preferred values) are identical between SM/chart window it'd be pretty difficult to tell.

As you say this occurs rarely, was it ever the case before build .20?

QUOTE:
ensuring that the strategy's settings (incl. preferred values) are identical between SM/chart window it'd be pretty difficult to tell.

There are no changes to the strategy preferred value parameters. I only re-optimize on weekends. This change occurs from the time SM runs (just before market opening) and the market closes such that the Chart window shows the results for that trading day.

One thing I did try was to go into preferences and uncheck the checkbox for Turn off stop/limit order rounding entirely, then restart WL. But that doesn't change what the Chart window shows. However, the question remains would this change what SM does? I don't know. SM simply shows what it caches in XML before the restart, which wouldn't be affected.

What I can say is, if this was a general coding error, then it would affect all limit orders--and it doesn't. So this has to be a rounding error difference between SM and the Chart window--that's my conclusion. Can you comment on how price rounding is handled differently between SM and the Chart window?

QUOTE:
... was it ever the case before build .20?

I don't know. This came up while investigating why some stock trades fall out of sync with WL and the actual portfolio. It happens rarely, but it has always happened. My conclusion is that SM somehow rounds differently than the Chart window, but that's hard to prove at my end. Do you have a way of proving this? Is there something I can do?

QUOTE:
Can you comment on how price rounding is handled differently between SM and the Chart window?

Not only that would make little sense, the execution on the open suggests there's more to it than a rounding difference. A peeking condition, unstable indicator or something else in the Strategy code. Cannot really comment without being able to reproduce.

QUOTE:
A peeking condition, unstable indicator or something else in the Strategy code.

There's no peeking condition in any of the code. ATR (which is unstable) is involved in some exit branches, but not this one. At any rate, the Data Range is over 800 bars, so if ATR were involved (which it isn't in this exit), it would have to be in the 0th bar of 800 bars, which is unlikely.

For the exit conditions (not this one) that do involve the ATR, I can tell you ATR is stable to at least 2 decimal places. But what happens after that I don't know. I'm going to include the log10 of the exit-condition residual in the "Signal msg" for those exits to see how many decimals places the exit condition begins to fail (differ). If it's failing in the 14th decimal place, it shouldn't be an issue. But if it's failing in the 4th (maybe 5th) decimal place, that's more of a concern. But the cause of this case (shown in the screenshot) does not involve the ATR.

How can I test the rounding behavior of SM relative to the Turn-off-stop/limit-order-rounding-entirely condition? I'm wondering if that condition only affects the Chart window, but not SM.

So in a Data Range of 800 daily bars, is the only difference between what SM sees and the Chart windows sees in the 0th bar of 800, and the new 799th bar of 800? Everything else--ideally--should be the same, right? If so, I'm not even sure how peeking would even play a role here unless the strategy could peek off the Chart (which it can't). There's has to be another explanation for the SM verses Chart differences.

The 14-period ATR (if it would be like that) is unstable up to bar 50-60 so unless you're using a 200-period ATR let's discard this idea.

Stop/Limit rounding isn't recommended for live trading (good that you disabled it) but it may result in rejected orders if it's identical to the High/Low of the bar value. Your order isn't rejected - just the opposite.

What happens here is the conversion of a limit sell order into a market sell order. Wealth-Lab can do it when respective option is activated in Quotes window but this preference doesn't apply to Strategy Monitor. Neither Chart window nor Strategy Monitor support this functionality of Quotes windows altogether so it cannot and does not affect them.

Therefore I wonder if your (unknown) strategy code may be issuing a market order on some condition for whatever reason.

QUOTE:
I wonder if your ... strategy code may be issuing a market order on some condition for whatever reason.

Bingo, you are correct. The Chart window took the QBSell branch (Qik Bearish Sell, Market exit); whereas, SM took the QWSell branch (Qik Weakening Sell, Limit exit).

CODE:
Please log in to see this code.

Moreover, the ATR is involved in this branch decision (see code above) and has been suspect in other branch decision disagreements between SM and the Chart window. Let's call it an ATR problem for now. I'm going to include the log10(residual error) in the branch condition Signal msg to see how many decimal places SM and the Chart trading are off. I'll get back to this with an answer in about a week. This has been an ongoing problem, but at another branch site.

If this is an ATR problem, the next question is how to fix it? What I need is a substitute robust metric for volatility.

By the way, the highest ATR period I ever use is 22 daily bars. And I only simulate against daily bars.

It's not ATR problem. This code logic has an unrealistic order of exits and peeks into the future:

CODE:
Please log in to see this code.

1. To stay realistic, AtMarket order should precede AtLimit/AtStop. Please find more on this in the WealthScript Programming Guide > Order of Trading Signals > Programming Trading Strategies > Peeking

2. If today's Close does not exceed a Chandelier exit price you sell at market today (at bar rather than bar+1). Wait a moment. Isn't it a bit too late to sell today at open when the Close price is already known?

This circumstance fully explains the discrepancy in order type. I'd refactor the snippet like:

CODE:
Please log in to see this code.

Oops, I just notice a major problem. The SellAtMarket order above is using "bar" instead of "bar+1". Hmmm. But that mistake would apply to both SM and the Chart window, so they would still be trading the same mistaken way. Right? This doesn't explain the total problem.

UPDATE: I just read your post above. You're saying the SellAtMarket-bar (instead of bar+1) error is switching the effective execution sequence of the Limit and Market order so they're out of sync. Let me fix that mistake a see what happens. Interesting.

As you can see in the User Guide: Orders > Portfolio Synch > Theoretical vs. Actual, it's possible to get out-of-synch with your account when trading with AtLimit orders.

P.S. You run Strategies in SM in Raw Profit mode, don't you?

QUOTE:
You run Strategies in SM in Raw Profit mode, don't you?

That's true. (I wonder how you knew that?)

I think Portfolio Simulation mode and PosSizers are a good idea, but they add another monkey to the wrench. I like to keep my simulations as simple as possible for now (without all the extra monkeys). Once my strategy is more refined, I may add more monkeys to it. But not yet. And the present strategy makes money now, so I can't complain.

Thanks for pointing out the SellAtMarket vs SellAtLimit out-of-sequence bug.

Glad to help.

I didn't know but asked about RP mode because Port.Sim. mode should not be employed in SM. That might lead to more discrepancies (User Guide > Strategy Monitor > Characteristics of the Strategy Monitor: Operational difference between the Strategy Monitor and Backtester).