Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
How to properly reset Matlab workspace between runs?
45 views
Skip to first unread message
Kate J.
Jun 13, 2012, 9:39:07 PM6/13/12
to
I have a system of files that includes a Simulink model that calls a .mexw32 file and an externally-written .lib file. To run my system, I compile my c-mex s-function code into a .mexw32 file, which is then called by one of my Simulink model blocks when the model runs.
Description of my system usage: after my c-mex s-function is compiled into the mex-file, I click the “play” button on my Simulink model; the model runs, and the system generates a set of output files. The execution of the system is partially determined by parameter values located in text files that are read by the mex-file. Once a particular run finishes, and I remove the generated output files to a separate, permanent location, I adjust the parameters in the text files, and re-click “play” in the Simulink model, to perform another system run, and generate a new set of output files.
The problem: I’ve noticed that the parameters used by my system in the *first* run, appear to determine the behavior of *all* subsequent runs. This shouldn’t be true; ideally, each time I modify the parameters, I should see unique behavior corresponding to that particular set of parameters. Instead, if e.g. the initial set of parameters performs well (i.e. generates a nice-looking set of output data), then it doesn’t matter if I use a set of (known) very poor parameters subsequently – every additional set of data that I generate *still* looks good, even though they *shouldn’t*.
I’ve tried executing “clc” , “clear all” and “clear all; close all; clc;” commands between runs; however, this doesn’t change the fact that every subsequent run still depends entirely on the parameters from the very first run. I’m really not sure which aspect(s) of my system are the culprits causing this problematic carryover behavior. But the only solution I’ve discovered, so far, is to shut down Matlab and restart it, with my new set of parameters specified for the first new run.
Has anyone experienced a similar problem? If all of the “clc” and “clear all” commands haven’t worked to reset the Matlab workspace between system runs, are there other, possibly more powerful alternatives that I could try? Or, am I doomed to having to shut down and then restart Matlab every single time I need to change parameters?
Thanks in advance for your input.
Description of my system usage: after my c-mex s-function is compiled into the mex-file, I click the “play” button on my Simulink model; the model runs, and the system generates a set of output files. The execution of the system is partially determined by parameter values located in text files that are read by the mex-file. Once a particular run finishes, and I remove the generated output files to a separate, permanent location, I adjust the parameters in the text files, and re-click “play” in the Simulink model, to perform another system run, and generate a new set of output files.
The problem: I’ve noticed that the parameters used by my system in the *first* run, appear to determine the behavior of *all* subsequent runs. This shouldn’t be true; ideally, each time I modify the parameters, I should see unique behavior corresponding to that particular set of parameters. Instead, if e.g. the initial set of parameters performs well (i.e. generates a nice-looking set of output data), then it doesn’t matter if I use a set of (known) very poor parameters subsequently – every additional set of data that I generate *still* looks good, even though they *shouldn’t*.
I’ve tried executing “clc” , “clear all” and “clear all; close all; clc;” commands between runs; however, this doesn’t change the fact that every subsequent run still depends entirely on the parameters from the very first run. I’m really not sure which aspect(s) of my system are the culprits causing this problematic carryover behavior. But the only solution I’ve discovered, so far, is to shut down Matlab and restart it, with my new set of parameters specified for the first new run.
Has anyone experienced a similar problem? If all of the “clc” and “clear all” commands haven’t worked to reset the Matlab workspace between system runs, are there other, possibly more powerful alternatives that I could try? Or, am I doomed to having to shut down and then restart Matlab every single time I need to change parameters?
Thanks in advance for your input.
Phil Goddard
Jun 13, 2012, 11:38:06 PM6/13/12
to
Are you sure that your S-Function is re-reading the file each time?
Assuming it is, then
>> clear all
should remove the mexw32 dll from memory and force it to reload each time which is effectively what closing MATLAB is doing.
Given that's not working the best you can do would be
>> clear mex
>> delete('nameofsfunction.mexw32'); % delete the mex file
>> mex nameofsfunction.c % do a recompile
But I'd put my money on the file not being re-read correctly.
Phil.
Assuming it is, then
>> clear all
should remove the mexw32 dll from memory and force it to reload each time which is effectively what closing MATLAB is doing.
Given that's not working the best you can do would be
>> clear mex
>> delete('nameofsfunction.mexw32'); % delete the mex file
>> mex nameofsfunction.c % do a recompile
But I'd put my money on the file not being re-read correctly.
Phil.
Kate J.
Jun 14, 2012, 1:43:07 PM6/14/12
to
>> Are you sure that your S-Function is re-reading the file each time?
Thanks for asking this question, Phil. Although my c-mex s-function code does read a variety of parameter files, your question prompted me to discover that the 2 parameter files that are causing problems are actually read by one of the .cpp source files from which my controller.lib and controller.dll files are generated within Visual C++ 2008 Express Edition. (And then, subsequently, I use the command "mex cmexsfcn.c controller.lib" to generate my cmexfcn.mexw32 mex-file.)
I'm going to see if I can determine if there is a way to clear these loaded parameter values / files between runs, via the C++ source code. If anyone is familiar with how to do this, suggestions are very welcome.
Kate J.
Jun 14, 2012, 3:27:10 PM6/14/12
to
update: via print statements, I was able to determine that the parameters *are* being correctly reloaded for each run, without having to clear and recompile the mex file each time. There had been a separate, red-herring issue that had been confusing me; once I recognized and eliminated that issue, I now see that the parameters between runs *are* being handled correctly.
Thanks again for your input, Phil. It was helpful to get me thinking about other issues that have led me to solve this issue.
Thanks again for your input, Phil. It was helpful to get me thinking about other issues that have led me to solve this issue.
0 new messages