Use older MATLAB save formats

I'm running a model that has a bunch of DLLs which read some .mat files.

When I use an old version of MATLAB (I think 2011a) to generate the files I get files that work okay, but when I create them with 2017a the files seem not to work with the same script.

I've used 2017 to read in the working 2011 file and then save it, and these files also don't work.

I've also tried the above with the '-vXX' settings at all available values according to the help, with no success.

Example:

clear; load('v2011file.mat'); save('v2017copy.mat', '-v6', 'var1', 'var2', 'var3');

One thing that I have notices between the two is that when they're selected in the "Current folder" browser, the preview always shows the 2017 files with the variable names in aphabetical order, regardless of the order that I saved them in, while the older 2011 file seems to maintain the order that they were saved. I can only assume that this is something related to a change in the way that files are saves - it might not be a problem but it does hint toward a change (it does this whether or not I include '-vXX' to use older formats).

It's probably worth noting that the 2011 files are created on XP, while the 2017 files are made on Windows 7.

Essentially I'm looking for anyone who might know whether it's possible for me to change the way that the file is put together by MATLAB, rather than having to change the DLLs to acceps a newer file.

[Jan]

Please mention what "the files seem not to work with the same script" exactly means.

[Lauren Dransfield]

Sorry, my wording isn't great - the files are both created woth the same script, just one is on XP and 2011a (DLLs read fine), while one is on Win7 and 2017b (DLLs can't read)

[Rik]

DLL functions were replaced by mex function extentions a long time ago (R2010a and before). It was still supported for some time (although I can't find the release support ended).

What do those functions do that would change the mat file? What code are you running exactly? It seems unlikely the save function has anything to do with it, unless you are shadowing it (which you should not do).

[Lauren Dransfield]

The DLLs are just reading the file's data after it's been created - I think it's the creation that's getting a bit mixed up. Prior to saving the scripts are generating a couple of N dimensional matrices, nothing particularly special if I'm honest.

From what I can tell the data that's in the two files is identical, it's just the order of the variables within the file that's different, hence me thinking it's the save. I've added a solution below.

[Stephen23]

The "order" of variables stored in a .mat file should not be relied upon, and code that assumes that they come in a particular order is fragile code.

Having the variables in a particular "order" implies that they have some meta-data in their names (i.e. pseudo-indices), which is a slow and inefficient way to handle meta-data: much more robust would be use use actual indexing (in which case this entire problem disappears).

[Lauren Dransfield]

I don't disagree, it's not very robust at all and isn't how I'd have done it myself (it goes so far as insiting that each matrix and vector is a specific size, which is completely inappropriate).

These are largely scripts that I've inherited and don't have time to fix before results are required, and so finding a workaround for the timebeing is better this time around.

I'll take your comments into account next time I have time to update the code to something a bit more robust, thanks.

Answer 1

[Lauren Dransfield]

It looks like I can work around the save order issue and have something that works by doing:

save('new2017file.mat', 'var1');
save('new2017file.mat', 'var3'. '-append');
save('new2017file.mat', 'var2', '-append');

Meaning I can put them in a specific order - I have to have the default save set to -v7 in preferences>general>.mat files too.

I wouldn't say no to a more elegant answer if there's one available though!

Answer 2

[Rik]

Since v7.3 is R2006b, I don't really see a reason why you would need to set the default to -v7.

Also, why don't you write a wrapper to replace the load? That way you remove the ordering requirement, without having to do a lot of work.

function S=loaddata(filename)
tmp=load(filename);
S=struct('var1',tmp.var1,'var2',tmp.var2,'var3',tmp.var3)
end

[Lauren Dransfield]

I'm not sure why I need to set it to -v7 either, I just know it worked one way and didn't the other!

[Lauren Dransfield]

Looks like it'd be a better way to have it in future, but I'm not sure the DLLs will be happy trying to read a structure when it isn't what they're expecting

[Rik]

I find it a bit strange that a dll mex function would interact with a file in the first place.