Parallel Computing Toolbox Environment Configuration Change in MATLAB

Direct answer

Yes—parallel pool initialization behavior is version-sensitive: major MATLAB releases have shifted between process-based and thread-based workers, which changes how environment variables propagate. The definitive cross-platform method is to define the variable in the environment of the component that actually spawns the workers—the OS service account for MATLAB Parallel Server, the scheduler submission environment for Slurm/PBS/LSF, or the cluster profile where supported—then confirm the value inside the worker with getenv, not only in the MATLAB client.

Confirmed behavior vs. likely cause

Confirmed: a local parpool starts workers as child processes of the MATLAB client on the same machine, so a variable set with setenv in that MATLAB session is normally visible to those workers via getenv. setenv is process-local and volatile: it does not survive a MATLAB restart, does not cross machines, and does not alter the environment of an already-running cluster service.

Likely explanation for cross-platform inconsistency: remote workers under MATLAB Parallel Server are launched by a scheduler or service account (a Windows service or Linux daemon) that reads the system/service environment, not your interactive login shell. A variable exported in your shell or set with setenv in the client therefore never reaches those workers, and the gap appears on one OS but not another depending on how that OS resolves service-account environments.

Steps for this case

1. Identify the spawner. Local parpool inherits from the MATLAB process; cluster jobs inherit from the scheduler or service. Do not assume a login-shell export reaches a system service.
2. Set the variable where workers are born. For local pools, call setenv('VAR','value') before parpool. For Parallel Server or Slurm/PBS/LSF, configure the systemd unit, Windows service properties, scheduler submission script, or cluster profile environment instead.
3. Pin the release. Record the MATLAB release and pool type, and check that release's notes for process- vs thread-based worker changes, since thread-based workers may observe the process environment differently.
4. Verify inside the worker. Compare client and worker values rather than assuming inheritance.

% Client-side check
setenv('MY_VAR','expected');
disp(getenv('MY_VAR'));

p = parpool;  % local pool
spmd
    fprintf('Lab %d sees MY_VAR=%s\n', labindex, getenv('MY_VAR'));
end
delete(p);

On a cluster, submit a minimal task through the same profile that returns getenv('MY_VAR') plus worker hostname and OS details, and compare with the client.

One diagnostic detail needed

Which execution target shows the mismatch—a local parpool on a specific OS, or a MATLAB Parallel Server cluster profile? The fix differs: local pools need client-side setenv before pool creation, while cluster workers need the variable in the service or scheduler account environment.