Why did I get duplicate variables in my workspace after changing their names?

(I did solve this problem but I haven't been able to repeat it. I hope it's okay to ask here anyway because I am curious if anyone has an explanation. I will describe below what solved it and how I have tried to repeat it. Couldn't find any threads describing this anywhere.)

I had a few variables in my script with names starting with capital letters that I wanted to change to lowercase first letters. For example I wanted to change "Flux_th" to "flux_th". See code example below with only the relevant lines from my script.

load('dataNucGlobal_nuc.mat')
load('dataNucGlobal_reac.mat')

Flux_th = 42078172084928.6; % [neutrons/cm2/s]

I used the shift+enter function in matlab to change "Flux_th" to "flux_th" (same with the other variables).

I cleared my workspace, I ran the script (like below) and got BOTH "Flux_th" and "flux_th" in my workspace (they have the same value).

load('dataNucGlobal_nuc.mat')
load('dataNucGlobal_reac.mat')

flux_th = 42078172084928.6; % [neutrons/cm2/s]

I tried changing back to capital letters on "Flux_th" and doing the same thing again but it still gave me duplicates.

I am pretty sure that I tried manually deleting the duplicates with capital letters in the workspace and then running the script, but that also gave me duplicates.

It happened again even after restarting matlab.

What DID actually solve the problem is the following sequence:

I cleared the workspace, then I ran this separate script that creates and saves the .mat files, that script looks like this:

%% Global nuclear data

%data for reactions
dataNucGlobal_reac = table('Size',[0,3], 'VariableTypes',["double", "double", "string"],'VariableNames',["barn";"isotopefrac";"reference"]);

dataNucGlobal_reac('O16 (n,p) N16: s-f', :) = {2.026e-5, 99.76, "ENDL"};

save('dataNucGlobal_reac')


%data for nuclides
dataNucGlobal_nuc = table('Size',[0,3], 'VariableTypes',["double", "double", "string"],'VariableNames',["halflife_s"; "decayconst"; "reference"]);

dataNucGlobal_nuc('N16', :) = {7.12, log(2)/7.12, "?"};

save('dataNucGlobal_nuc')

Then I ran my original script without the load lines like this:

% load('dataNucGlobal_nuc.mat')
% load('dataNucGlobal_reac.mat')

flux_th = 42078172084928.6; % [neutrons/cm2/s]

This time I did not get any duplicates, so I cleared my workspace again and reinserted the load lines and finally ran the script like this:

load('dataNucGlobal_nuc.mat')
load('dataNucGlobal_reac.mat')

flux_th = 42078172084928.6; % [neutrons/cm2/s]

Now everything is working and I can't reproduce what happened by changing variable names from capital to lowercase letters.

I am super confused because as you can see, the .mat-files DO NOT contain any of the variables that became duplicates, so it doesn't make any sense that this would help. I have no idea what happened so that is why I am asking here.

[dpb]

Some bizarre corner/edge case in the Editor code name-change logic, probably. Not being reproducible and not a commonly observed event, it probably cannot be duplicated even by Mathworks and so will remain unexplained unless and until it happens again in an environment that can be captured.

[Fredrik]

Interesting, thanks!

[dpb]

Such kinds of errors are the dickens to try to debug because they are so rare and even if seen, as in your case, can't be reproduced nor can the exact sequence that caused it be recreated.

/GEEZER ALERT -- Many, many years ago had an online coal ash analyzer product that using MS Professional Basic under MS-DOS, . Worked flawlessly for years until a customer asked for an additional functionality; after it was added, the app began randomly crashing at or just after midnight and even the builtin error handling couldn't trap it. We ended up being forced to add a hardware watchdog timer module to the system to force a hard reset being unable to find any software cause of the problem and the changes made had had nothing whatever to do with any of the timekeeping calculations. EVENTUALLY, after many, many long nights, I finally uncovered the root cause -- the time functions internal to the app relied on returning the PC date string and parsing it; it turned out that for roughly 30 seconds after midnight the time returned 24:00:SS instead of rolling over to 00:00:SS. The internal array logic for storing hourly ash measurement data was based on the 0:23 hour; the 24th hour was out of range address. Even more bizarre behavior was that that error was trappable, what caused the randomness was that adding the additional code turned out to have bumped up the string array storage such that garbage collection error handler was what actually generated the nontrappable error. The point being, what appear unexplicable events will always have a root cause, but uncovering it may be extremely difficult and may end up leading far astray from whence one might think the symptoms indicate is the issue. \GEEZER ALERT

Answer 1

[Voss]

To me it seems most likely that at some point you saved the mat files with the Flux (capital F) variables still in your workspace.

Note that save(filename) saves ALL workspace variables to the mat file (so in this case _reac.mat contains the _reac variable and _nuc.mat contains both the _reac and _nuc variables). My guess is that some older version of at least one of those mat files contained the Flux variable (and of course whatever else was in the workspace when it was saved), and you restored all those variables when you loaded it.

You can specify which variables are saved to a mat file, e.g.:

save('file.mat','x') % save only variable x

and likewise you can specify which variables are loaded from a mat file, e.g.:

load('file.mat','x') % load only variable x
% or
S = load('file.mat');
x = S.x;
% or
S = load('file.mat','x');
x = S.x;

[Fredrik]

You are right, I managed to reproduce it now by changing a variable name, running the script that saves .mat files, changing the variable name back, clearing the workspace and then running the main script again.

I didn't know that the save function worked like this so thank you very much for the answer! I guess I should be more careful in the future and think twice about whether or not I need to read documentation about things I don't use very often. I am going to fix this now by specifying what I want to save as you described.

[Voss]

You're welcome!