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

2 visualizzazioni (ultimi 30 giorni)
This request refers to the three questions:
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?
  3 Commenti
Andrew Roscoe
Andrew Roscoe il 28 Mag 2024
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
Andrew Roscoe il 3 Gen 2025
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.

Accedi per commentare.

Risposte (0)

Categorie

Scopri di più su Simulink in Help Center e File Exchange

Prodotti


Release

R2021b

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by