Request for Simulink to provide link to offending block for "the model, 'xxxx', was changed after the SimState was saved"

This request refers to the three questions:

• https://uk.mathworks.com/matlabcentral/answers/1736580-cannot-find-state-n-in-the-given-variable-error-when-trying-to-start-a-simulation-using-previous?s_tid=prof_contriblnk
• https://uk.mathworks.com/matlabcentral/answers/182251-simulink-cannot-load-the-initial-simstate?s_tid=srchtitle
• https://uk.mathworks.com/matlabcentral/answers/38166-simstate-error?s_tid=srchtitle

In all these examples, users (including me) are struggling because we are trying to use the "Save Operating Point" method.

The "Save Operating Point" method is extremely powerful, and a very useful feature of Simulink that we would like to exploit to its fullest extent.

However, as users find, it is extremely easy to encounter the following error, when trying to run the simulation using the "Saved Operating Point":

"Simulink cannot load the initial SimState because the model, 'xxxx', was changed after the SimState was saved. Run the simulation again and resave the SimState.

This is problematic when the model is very large, as the search space (number of subsystems and parameters) is huge. Finding the problem block/parameter is like looking for a needle in a haystack.

Often everything is PERFECT, except for perhaps one single parameterised block that is causing the issue. For the user to find this, without a hint from Simulink about where to start looking, is very difficult.

Simulink must KNOW where the new model is different to that in the saved states, because it is detecting that place and throwing the error.

Please could Simulink then tell the user WHICH block/parameter the problem is with?

Even just the FIRST block/parameter problem would be a help, because often there may be only one.

A link could be provided to the relevant block/parameter, or even just the text listing the block pathname.

Ideally a list of the problem blocks/parameters could be provided, if there are more than one.

Please can this be included in future Simulink versions?

[Andrew Roscoe]

I see there is a related question now which has an "accepted answer".

https://uk.mathworks.com/matlabcentral/answers/2027039-why-do-i-receive-the-error-simulink-cannot-load-the-initial-operating-point

I am heartened that at the the bottom it does say "The development team is considering improving the error message to point directly to the offending change that is causing the loading of the Operating Point to fail. "

I'm not allowed to comment on the answer in that thread, which is a shame, so I enter a comment here.

The attachment example.zip (function getCheckSumDiff)) which is uploaded with the "accepted answer" has been really helpful for us.

One thing I would say is that in the example function getCheckSumDiff(), there are some parts that need to be slightly modified to work to make it work in all cases.

The most obvious and easiest is that for

        if(ischar(checksumItems1(idx).Value))
            if (~strcmp(checksumItems1(idx).Value, ...
                        checksumItems2(idx).Value))
                idxForDifferences=[idxForDifferences,idx];
            end 
        end

and

        if(ischar(checksumItems1(idx).Value))
            if (~strcmp(checksumItems1(idx).Value, ...
                        checksumItems2(idx).Value))
                idxForDifferences=[idxForDifferences,idx];
            end 
        end

You need to do the comparisons, not using strcmp and "~=", because in many cases, the values are arrays, and the result of strcmp of "~=" is then an array of boolean values, and then the if() statement on an array of boolean true/false flags only takes into account the first element.

So, getCheckSumDiff() in the example.zip doesn't find all the differences, and can sometimes report NO differences, even though the overall checksum is different.

Code that works better in this area, which checks the whole array (or sets of string) and returns a single boolean flag for the if to work on:

       elseif (ischar(item1.Value) || (isnumeric(item2.Value)))
             if (~isequal(item1.Value, item2.Value)) % Crucial here to use array comparison, not just ~=, because item1 and item2 could be scalar, or arrays, of same or different sizes.
                idxForDifferences = [idxForDifferences,idx];
             end             

There are also some other areas of the function which we have augmented, for example so that values which are cells or structures can also be checked (every element and every sub-structure/field of every value). We also check first that classes of every value are the same. Presently the attachment example.zip (function getCheckSumDiff) skips over any values which are cell arrays or structures, and so getCheckSumDiff in that example can miss differences in some cases.

[Andrew Roscoe]

We also have one set of outputs from getCheckSumDiff() that shows that in some cases WE have not changed the model at all, but that MATLAB/SImulink is deciding to change the 'CompiledBlockIndex' of blocks, outwith our control.

Specifically, in this case, there are two SimPowerSystems "Universal Bridge 3 arms" blocks in a model. We don't change them, or their parameterisation, between runs. However between two runs, their 'CompiledBlockIndex' can become transposed. Presently there doesn't seem to be any way that we can avoid this. It seems be random which is 'CompiledBlockIndex' 31 and which is 'CompiledBlockIndex' 32, so it's 50:50 whether the second run will complete or not, without the "model has changed" error.

============================================================================================================
Function: getCheckSumDiff.m
getCheckSumDiff : Contents checksums are different
getCheckSumDiff : 13 differences were identified.
type        index                                                               Handle model1                                                              Identifier model1                 Value model1                                                                       Handle model2                                                                  Identifier model2                 Value model2         
____________    ______    _____________________________________________________________________________________________________________________________    __________________________    _____________________________    _________________________________________________________________________________________________________________________________    __________________________    _____________________________

{'contents'}     20310    {'TopLevelModel/PowerSystem/IdleTurbineVariantSubsystem/DualChannelIdleTurbine/Bridge1/Universal Bridge 3 arms/Model/Constant'}    {'CompiledBlockIndex'    }    {[                       31]}    {'TopLevelModel/PowerSystem/IdleTurbineVariantSubsystem/DualChannelIdleTurbine/Bridge1/Universal Bridge 3 arms/Model/Constant'}    {'CompiledBlockIndex'    }    {[                       32]}
{'contents'}     21011    {'TopLevelModel/PowerSystem/IdleTurbineVariantSubsystem/DualChannelIdleTurbine/Bridge2/Universal Bridge 3 arms/Model/Constant'}    {'CompiledBlockIndex'    }    {[                       32]}    {'TopLevelModel/PowerSystem/IdleTurbineVariantSubsystem/DualChannelIdleTurbine/Bridge2/Universal Bridge 3 arms/Model/Constant'}    {'CompiledBlockIndex'    }    {[                       31]}
{'contents'}    450912    {'TopLevelModel/powergui/EquivalentModel1/Gates/From14'                                                                       }    {'GotoTag'               }    {'T115_11073_19937029253033'}    {'TopLevelModel/powergui/EquivalentModel1/Gates/From14'                                                                       }    {'GotoTag'               }    {'T115_11074_19933945826420'}
{'contents'}    450922    {'TopLevelModel/powergui/EquivalentModel1/Gates/From15'                                                                       }    {'GotoTag'               }    {'T115_11074_19933945826420'}    {'TopLevelModel/powergui/EquivalentModel1/Gates/From15'                                                                       }    {'GotoTag'               }    {'T115_11073_19937029253033'}
{'contents'}    451159    {'TopLevelModel/powergui/EquivalentModel1/Sources/From11'                                                                     }    {'GotoTag'               }    {'T113_10820_18051318337222'}    {'TopLevelModel/powergui/EquivalentModel1/Sources/From11'                                                                     }    {'GotoTag'               }    {'T113_10821_18048591413368'}
{'contents'}    451169    {'TopLevelModel/powergui/EquivalentModel1/Sources/From12'                                                                     }    {'GotoTag'               }    {'T113_10821_18048591413368'}    {'TopLevelModel/powergui/EquivalentModel1/Sources/From12'                                                                     }    {'GotoTag'               }    {'T113_10820_18051318337222'}
{'contents'}    451618    {'TopLevelModel/powergui/EquivalentModel1/State-Space'                                                                        }    {'NonTunableParameter(2)'}    {109x113 double             }    {'TopLevelModel/powergui/EquivalentModel1/State-Space'                                                                        }    {'NonTunableParameter(2)'}    {109x113 double             }
{'contents'}    451619    {'TopLevelModel/powergui/EquivalentModel1/State-Space'                                                                        }    {'NonTunableParameter(3)'}    {160x109 double             }    {'TopLevelModel/powergui/EquivalentModel1/State-Space'                                                                        }    {'NonTunableParameter(3)'}    {160x109 double             }
{'contents'}    451620    {'TopLevelModel/powergui/EquivalentModel1/State-Space'                                                                        }    {'NonTunableParameter(4)'}    {160x113 double             }    {'TopLevelModel/powergui/EquivalentModel1/State-Space'                                                                        }    {'NonTunableParameter(4)'}    {160x113 double             }
{'contents'}    451869    {'TopLevelModel/powergui/EquivalentModel1/Status/Goto14'                                                                      }    {'GotoTag'               }    {'T117_11308_21389186079188'}    {'TopLevelModel/powergui/EquivalentModel1/Status/Goto14'                                                                      }    {'GotoTag'               }    {'T117_11309_21385806051823'}
{'contents'}    451877    {'TopLevelModel/powergui/EquivalentModel1/Status/Goto15'                                                                      }    {'GotoTag'               }    {'T117_11309_21385806051823'}    {'TopLevelModel/powergui/EquivalentModel1/Status/Goto15'                                                                      }    {'GotoTag'               }    {'T117_11308_21389186079188'}
{'contents'}    452654    {'TopLevelModel/powergui/EquivalentModel1/Yout/Goto14'                                                                        }    {'GotoTag'               }    {'T118_11407_21667749800884'}    {'TopLevelModel/powergui/EquivalentModel1/Yout/Goto14'                                                                        }    {'GotoTag'               }    {'T118_11408_21664272314881'}
{'contents'}    452662    {'TopLevelModel/powergui/EquivalentModel1/Yout/Goto15'                                                                        }    {'GotoTag'               }    {'T118_11408_21664272314881'}    {'TopLevelModel/powergui/EquivalentModel1/Yout/Goto15'                                                                        }    {'GotoTag'               }    {'T118_11407_21667749800884'}

getCheckSumDiff : Interface checksums are the same
============================================================================================================

[Andrew Roscoe]

Further comment, as we (myself and colleagues, not MATLAB employees) continue to invest a lot of time and effort into this.

It turns out that it is ALSO possible to have substantial differences in the checksum detail entries between models, and NOT encounter the "model was changed" error. For example, it seems possible to adjust the logging (or not) of some signals between two simulations that are linked by the savedOperatingPoint process, but ONLY if the addition or removal of signal logging does not affect any block code that is (or is not) then required or reduced through block reduction optimisation. It's not always obvious to a user when this occurs. When you successfully manage to change logging between two such linked simulations, without encountering the "model has changed" error, the checksum details change quite a lot, but Simulink somehow assesses the checksums and decides that the differences are allowable.

So now we spend a lot of time making further adjustments to the code example at https://uk.mathworks.com/help/simulink/slref/determining-why-simulink-accelerator-is-regenerating-code.html to allow SOME types of differences in the checksums, but still be able to highlight other types of checksum differences that actually will cause the "model was changed" error. This is the only way that we can try and deal with these errors in a large model.

Its still annoying because deep inside Simulink there must be an algorithm that assesses the checksum differences and makes the assessment of "model changed" or "model not changed" in terms of savedOperatingPoint compatibity. If only MATLAB/Simulink would open up this algorithm or some debug output from it, life would be much easier for anyone using the savedOperatingPoint process. In the meantime, we continue to have to attempt to second-guess and reverse-engineer the process for analysing the checksum details, and trying to highlight to a user what (if anything) has changed in their model that causes the "model has changed" error, so that they can deal with it.