Is there a way to split MATLAB m scripts into a header file with multiple include files?

So for a little background in regards to the point-of-view/perspective that I am coming into this question from -- I used to work in FEA/CAE and for large models, we used to have a master or header file that would have the run definition and some characteristics about the run and then we would have what we called "include files" that would contain the rest of the model information.

So, given that, what I am trying to do is something similiar with MATLAB m script files.

suppose that I have a MATLAB m script files that has 10 lines of code, let's call that test.m.

What I am looking to do is to split test.m (with lines 1-10) into two files, header.m (with lines 1-5) and include1.m (with lines 6-10) so that when I run the header, it would look like or appear to MATLAB as if it was just one giant file.

Note that the contents for include1.m isn't like a separate tool or function. It's just more information.

The way that we have it now is in one giant MATLAB m script file and I am looking to split it out so that if I want to have make changes, I can change the smaller include files rather going to line x in the much bigger file.

Is there a way to do something like that in MATLAB?

Thanks.

If there are any questions or any points of clarification needed, please let me know.

Thank you.

Answer 1

[ES]

Hi,

since the original file (test.m) is a script, you can just split the file into as many segments (different files) as you want and call each one in order.

Make sure, when you split the files, you don't introduce any syntax error (like cutting in middle of an if or a for loop). That should be fine.

That is:

original file (test.m)

line 1...

line 10

New file 1(header.m)

line 1...

line 5

line 5.1 include1.m% here you are calling the second file

New file 2(include1.m)

line 6...

line 10

[Ewen Chan]

So...suppose this is what the test.m file looks like:

a = 1 + 2;
b = 3 - 4;
c = 5 * 6;
d = 7 / 8;
e = 9 + 10;
f = 11 - 12;
g = 13 * 14;
h = 15 / 16;
i = 17 + 18;
j = 19 - 20;

Would this be how I would need to split that up so that header.m becomes:

a = 1 + 2;
b = 3 - 4;
c = 5 * 6;
d = 7 / 8;
e = 9 + 10;
include1.m

and include1.m becomes:

f = 11 - 12;
g = 13 * 14;
h = 15 / 16;
i = 17 + 18;
j = 19 - 20;

I just want to make sure that I have the syntax correct.

Thank you.

[Walter Roberson]

You would not include the '.m' subscript on the word include1.m . Just

include1

[Ewen Chan]

Thank you!

Answer 2

[Steven Lord]

You can do what ES suggested and be okay some or most of the time, but this won't always work. Consider a function:

function y = function2
script1;
y = sin(alpha);

and the associated script named script1:

alpha = pi;

What happens when you try to call function2, expecting the output to be the sine of pi?

>> z = function2
Error using alpha
Too many output arguments.

Error in function2 (line 3)
y = sin(alpha);

You "poofed" a variable into function2's workspace at runtime, but when it was parsed MATLAB had already decided that the reference to alpha was a call to the alpha function since there was no indication in the function2 source code that alpha would be a variable at runtime. The alpha function doesn't return any outputs but MATLAB called it with one so it could pass that into the sin function. This type of approach has some of the same problems the eval function does.

If your "include" file's purpose is to perform some initialization (calling functions to configure your environment) without "poofing" variables into the workspace, it should probably be safe. To be extra careful, you could make it a function instead of a script so it does all of its work in its own workspace, isolated from the function that "includes" it.

If your "include" file's purpose is to define variables and/or data, I would make it a function that returns either the variables or a container (a struct, a cell, a containers.Map, a table, etc.) that stores the data. The file that includes it would then call it with an output argument. Compare a modified version of function2 named function3 (I'm just doing this for illustration purposes; you should use more descriptive names):

function y = function3
data = include3();
y = sin(data.alpha);

and the new include file:

function data = include3()
data.alpha = pi;

When you call this, you get the expected result.

>> y = function3
y =
   1.2246e-16

This has an added benefit: if you decide to add something to the container returned by include3 (to support some other function that also needs to include it) you don't need to worry about breaking function3. Your function3 function doesn't need to care what fields other than alpha the struct data includes. If data.beta now exists too (to support a function4 that also "includes" include3) that's fine, even if function3 were to call the beta function.

Alternately if you have a lot of state information to keep track of writing a class object, using the constructor for the class or default property values to initialize those properties to their initial states, and having the class methods manipulate that state is a possibility. See the documentation for classes for more information.

[Ewen Chan]

"To be extra careful, you could make it a function instead of a script so it does all of its work in its own workspace, isolated from the function that "includes" it."

I'm not sure if Simulink applications can be functions.

It's a complex modeling program which has been demarcated by the company as legacy and therefore; no further development work is put into it.

As such, to the best of my knowledge, the input file feeding information to the Simulink application doesn't have any functions contained within it, so all I'm looking to do is possibly break it up some (maybe) so that instead of reading one giant file, I am looking at the relevant pieces only, but also having the option of concatenating the input file back into one giant file if I am ever asked to do so (albeit, I might be using Linux command line tools like 'cat' to do something like that instead).

In your example where there is a call to a function, the call itself and everything associated would be what's broken off into the include file and not in the middle of the function call (if that's what you're referring to/worried about).

But, duly noted.

[Walter Roberson]

"I'm not sure if Simulink applications can be functions."

MATLAB Function Blocks can call functions.

[Ewen Chan]

""I'm not sure if Simulink applications can be functions."

MATLAB Function Blocks can call functions."

But that assumes that the Simulink model has Function Blocks, correct?

Which, I'm not sure if the model that I am running has those.

Further, again, I am not sure if the Simulink app that I am running is or can be a function unto itself, i.e. I'm not using Function Blocks to call functions, but rather that the Simulink model/app in and of itself in its entirety, is a function.

[Walter Roberson]

Simulink models can be called as functions

https://www.mathworks.com/help/simulink/slref/simulink.simulationoutput-class.html

https://www.mathworks.com/help/simulink/slref/sim.html

https://www.mathworks.com/matlabcentral/answers/65454-simulink-return-values-of-simulation

The model is an input to the sim() call, so that can be used with multiple models.

[Ewen Chan]

Thank you.