During the life of a model, you will very likely need to change many configuration parameters to complete different tasks. For example, when debugging you want to enable many run time diagnostics to catch modeling errors. When the model is well tuned and you want to use it for a Monte-Carlo study, you want to disable any diagnostic that may affect performance.
These collections of configuration parameters can be stored as Configuration Sets.
Multiple Configuration Sets in One Model
Do you know it is possible to store more than one configuration in a model?
An easy way to create a second configuration is from the Model Explorer. Right-click on the configuration and select Copy:
Right-click on the model and select Paste:
Now that you have two configurations in the model, select the one to be used by right-clicking on it and selecting Activate:
Storing a Configuration Set in a File
When I create a new model, I usually change the configuration for 2 or 3 of my typical use cases:
- Physical Modeling: For models using Simscape I use a configuration with the ode23t solver and the Simscape Logging enabled.
- Code generation: For models that generate code I use a Fixed-Step Discrete solver, ert.tlc target, and I enable the code generation report.
- Debugging: When debuging, I disable most optimizations, and set many diagnostics to error.
To quickly configure a new model for those tasks, what I did is that I exported the configurations I use most often to MATLAB files:
In the example below, the exported MATLAB file, configCG, is a function that creates a configuration set object. When I create a new model, I can easily attach and activate my previously saved configurations using attachConfigSet and setActiveConfigSet:
Now it's your turn
Do you take advantage of all those ways to manage configuration sets? Let us know by leaving a comment here.
6 CommentsOldest to Newest
Thanks for the post on Configuration Sets. It is very handy to be able to store multiple configurations in the model and easily switch between them. We use this method to switch between different solvers based on stiffness considerations, which in our models depend on the values of a set of user-specified parameters.
There is some missing functionality that would significantly enhance the utility of configuration set switching. The currently available model callbacks do not provide a way to use a callback to modify configuration parameters (or variant subsystems) on a per-run basis. The first callback to execute in response to starting a simulation is the InitFcn. As far as I can tell, both the configuration set and active variants are locked prior to this callback’s execution, so any attempt to change them throws an error. The PostLoadFcn callback can change these settings, but it only executes once when the model is first loaded, so it isn’t useful for running multiple simulations on a model (without closing and reloading it).
Our application uses different configuration sets and active variants for each run, based on user-specified inputs (see my comments and Guy’s informative responses in his article on Variant Subsystems: http://blogs.mathworks.com/seth/2013/03/18/time-to-convert-to-variant-subsystems/). In most cases, we avoid these errors by using a pre-initialization function as the entry point for running simulations. Our function first selects the appropriate configuration set and active variants based on user-supplied parameters, then starts the simulation run. However, this function is bypassed if a user clicks on the Play button in the Simulink GUI, or uses any of the several command-line methods of starting a simulation. We can use the InitFcn callback to anticipate these errors and exit gracefully, but this means that the normally handy Play button is essentially useless. If there were a ‘pre-initialization’ callback (that executes prior to model compilation, locking the config set and active variants, etc.), we wouldn’t have to rely on trying to enforce the use of our entry-point function to start simulation runs.
I’d love to hear any thoughts or suggestions anybody might have on this issue.
@John B.: Thank you for the detailed description of your use case. I will come back to you shortly on this topic.
We’re using configuration sets as well for our large number of nested model references. However, they are a bit limited if you must have small variations within your tree. For example, the top model oftentimes has a specific configuration (libraries to compile with, a different “Inline Parameters” configuration and so on). Discrete sub models are often set up with a bigger sample time and so on. The only way to configure such an architecture is to create as many config sets as there are variations, limiting the advantages of the feature. A nice improvement would be to be able to “mask” the configuration parameters, for example by stacking config sets…
@Gwenole: I absolutely agree with you. Very often in a hierarchy of referenced model you have a few minor variations of a common configuration set. I will follow up soon with a post introducing techniques to help creating variants of one configuration set.
@John B: You are not the first user to report the need for a callback earlier than the “initFcn” callback. We actively looking into providing a solution for the use cases you described (switching configuration sets and variants). Hopefully it will be available soon, because in the current release the approach you implement is the only way to go.
Thanks for the info. I’ll be sure to look for this functionality in the release notes for future releases.