Simulink Parameter Estimation error: Brace indexing

Hello, I am running a simulink design optimization experiment which seeks to optimize a portion of a 2d lookup table. The experiment is close to a standard example where the objective is to minimize the sum squared error between real-world measured data and the output of the simulink model.

The results are promising so far, but consistently after the 3rd or 4th iteration, the estimation terminates with the following error:

Brace indexing is not supported for variables of this type.

I have read some answers from WR, Jan, et al that suggest in other circumstances this could be caused by a variable which was once populated becoming empty, but I can't find anything obvious in the model, the output data, or the lookup table under scrutiny.

• The estimator is bound to using values within +/- 5% of the original lookup table
• Method and algorithm are default (nonlinear least squares / TRR)
• Parameter tolerance for terminating subsequent iterations is set to about 1% (5) of the max value (500) within the original table
• Function tolerance for the same is set to 0.1
• Iteration period is steady around 70 seconds

One small thing I've noticed is that as the experiment updates the lookup table with the newest values from each iteration, they are of a very high precision (~14dp). The original lookup table is a simple double data type array with no more than 2dp precision.

I will continue to play with restricting certain data types and / or options, but this is my first go with optimizing a 2d lookup, so I thought I'd defer to the experts. Normally when I read an answer here, I end up learning more than I intended anyway.

Answer 1

[Rob Miller]

I've solved this. I believe the root cause is a small bug in the Parameter Estimation GUI.

However, what's more important to note is that I had originally overlooked a very powerful feature of the tool - the capability to generate a baseline script to execute the same cost configuration as the GUI.

https://uk.mathworks.com/help/sldo/ug/generate-matlab-code-for-parameter-estimation-problems-gui.html

I suppose I should've expected no less of a capability...

When executed from the command line, I can see that the same experiment actually terminates without errors and produces a feasible solution. For whatever reason the GUI bugs when all these particular planets align and the optimality tolerance is violated, and it just chooses to restart the simulation and throw the error.

In summary, if you're exploring sdo or parameter estimation for the first time, don't overlook the aforementioned hyperlinked capability.