Error in using 'parpool'

Hi, I have been using parpool to run my function simultaneously. However, in my new laptop, I got the problem as follows:

      >> parpool('local', noPMrun);
      Starting parallel pool (parpool) using the 'local' profile ... 
      Error using parpool (line 103)
      Failed to start a parallel pool. (For information in addition to the causing error, validate the profile 'local' in the Cluster Profile Manager.)

      Caused by:
          Error using parallel.internal.pool.InteractiveClient>iThrowWithCause (line 665)
          Failed to start pool.
              Error using parallel.Cluster/createCommunicatingJob (line 92)
              ICU error: get canonical time zone ID, err='U_ILLEGAL_ARGUMENT_ERROR'.

Is there anyone who can help/solve this problem? Thank you

[Walter Roberson]

Is it possible that your new laptop is running macOS Sierra and your Language and Region are not English / USA, and that you did not install the patch for Sierra?

[Artem Lenskiy]

Having the same issue in Matlab 2016b, Linux, 2 Xeon setup. Help is appreciated!

[Clint]

I had this problem trying to start a local cluster in Matlab 2016b on Fedora 25 with OpenJDK 1.8.

When I run Matlab's cluster validation tool it said the error is on line 503 in the file /usr/local/MATLAB/R2016b/toolbox/matlab/timefun/@datetime/datetime.m

In Matlab the command 'timezones' will show a list of valid time zones. Mine is 'Australia/Sydney', so just above line 503 I added this new line:

tz = 'Australia/Sydney';

When I closed Matlab and tried to validate the cluster again, there was a new error at line 573! I changed that line from this:

thisData = currentTime(tz);

To this:

thisData = currentTime();

Now it works.

[Norm]

Thanks Clint!

This fix (hack?) worked for me on Centos 7.3 Seems there might be some bugs in timezone handling in matlab R2016b

[Midas Chew]

This help, Thanks!

[Peter Perkins]

Modifying the MATLAB code is probably not a great idea. My Feb 16th post suggested two work-arounds, and those have been described in this bug report.

[Maxim Ovechkin]

Amazing. Thank you, Clint!

Answer 1

[Zygmunt Szpak]

I encountered the same problem. My workaround was to set the TZ environment variable to:

export TZ='Australia/Adelaide'

You can find the correct timezone string for your location here:

https://en.wikipedia.org/wiki/List_of_tz_database_time_zones

Answer 2

[Prasad Mendu]

Does the validation of the local cluster profile succeed? For more information on how to validate, refer to the link below:

https://www.mathworks.com/help/distcomp/clusters-and-cluster-profiles.html#brrzq8d-1

Local cluster profile uses the cores on your machine to parallelize the code and it could be possible that there are validation errors with local profile on your new laptop, and it will be helpful to look at those errors to know the cause of this issue.

Answer 3

[Peter Perkins]

Norm, Clint, Artem, and Simon, what if anything is your TZ environment variable set to, and what does /etc/localtime point to? If you symlink /etc/localtime to, say, /usr/share/zoneinfo/Etc/UTC, does the problem go away?

Setting TZ should work around this problem. If you can do that, it's probably a better idea than modifying datetime.m.

Answer 4

[orlem lima dos santos]

After looking inside datetime function I realized that matlab gets the timezone from the computer. So all you need to do is fix the timezone from your computer and reopen matlab it should works after this.

It is works for me.

[Peter Perkins]

The Bug Report for this problem

https://www.mathworks.com/support/bugreports/1539123

should have been added to this thread, but somehow never was. It includes two different work-arounds, and confirms that this bug was fixed in R2017b.

[shreya]

Thanks.. This work-around helps!

Answer 5

[Daniel Melnick]

I have the same problem while trying to run the parallel toolbox on a Mac Pro running High Sierra. Please help

[Peter Perkins]

Daniel, High Sierra changed the organization of the system time zone files, resulting in symptoms that look like the ones described for Linux in the bug report I posted above, but for a completely different reason.

R2017b and earlier suffer from this, but there is a bug report with a work-around that will work for those versions of MATLAB.