Skip to main content

bugs - Definitions are not distributed to parallel kernels


Bug introduced in 10.0 and fixed in 10.0.2.



I have a small package with utilities, which looks like that:



BeginPackage["Utilities`"];
f::usage = "...";
Begin["`Private`"];
f[x_] := x;
End[];
EndPackage[];
DistributeDefinitions["Utilities`"];

When I load this package and try to use my function f with ParallelEvaluate, everything works as expected:


(* Input *)

ParallelEvaluate[{$KernelID, f[2]}]
(* Output *)
{{1, 2}, {2, 2}}

But I get into trouble when I try to use Utilities package inside another.


BeginPackage["MainPackage`", {"Utilities`"}];
g::usage = "...";
Begin["`Private`"];
g[x_] := ...;
End[];

EndPackage[];

The function g is quite big and complicated and f is called somewhere inside it.


When I call g, everything works fine. But when I try to do something like this:


ParallelEvaluate[{$KernelID, g[2]}]

I get a lot of errors. As I understood, the problem is in function f. It seems to be not defined in the context of the main package for parallel kernels.


I've added Print[Definition[f]]; into the body of g, and when I try to use ParallelEvaluate with g I get this:


Both kernels print Null.


Which means, that f isn't defined inside of g. Do you have any ideas, how I can fix it?




Update 1.


While manual distribution of definitions doesn't work, ParallelNeeds works good. I removed DistributeDefinitions from Utilities package and added ParallelNeeds to MainPackage:


ParallelNeeds["Utilities`"];
BeginPackage["MainPackage`", {"Utilities`"}];
...
EndPackage[];
DistributeDefinitions["MainPackage`"];

This work fine. But in my case Utilities package is stored in another folder. And if I do so in MainPackage:



SetDirectory["Dependencies/"]; (* Directory with Utilities package. *)

ParallelNeeds["Utilities`"];
BeginPackage["MainPackage`", {"Utilities`"}];
...
EndPackage[];
DistributeDefinitions["MainPackage`"];

ResetDirectory[];


The definition is again not distributed. It seems like changing directory "erases" distributed definitions. Can I avoid it somehow without placing Utilities near MainPackage?



Update 2.


I found a solution for the problem on my own. One need to set/reset directories not only for kernel, but also for its subkernels, like this:


SetDirectory["some_dir"];
ParallelEvaluate[SetDirectory["some_dir"]];

Update 3.


It's a bug. The answer of Wolfram support:




I could reproduce this problem on my machine and have now reported it to our developers. I hope this can be fixed in our future releases. We at Wolfram, appreciate your feedback and encourage you to let us know of any other problem you may come across while using Mathematica.




Answer



I believe this may be a bug in version 10 as in version 9.0.1 the definition does get distributed. What happens in version 10 also directly contradicts the documentation. Here's an illustration:


enter image description here


Comments

Post a Comment

Popular posts from this blog

mathematical optimization - Minimizing using indices, error: Part::pkspec1: The expression cannot be used as a part specification

I want to use Minimize where the variables to minimize are indices pointing into an array. Here a MWE that hopefully shows what my problem is. vars = u@# & /@ Range[3]; cons = Flatten@ { Table[(u[j] != #) & /@ vars[[j + 1 ;; -1]], {j, 1, 3 - 1}], 1 vec1 = {1, 2, 3}; vec2 = {1, 2, 3}; Minimize[{Total@((vec1[[#]] - vec2[[u[#]]])^2 & /@ Range[1, 3]), cons}, vars, Integers] The error I get: Part::pkspec1: The expression u[1] cannot be used as a part specification. >> Answer Ok, it seems that one can get around Mathematica trying to evaluate vec2[[u[1]]] too early by using the function Indexed[vec2,u[1]] . The working MWE would then look like the following: vars = u@# & /@ Range[3]; cons = Flatten@{ Table[(u[j] != #) & /@ vars[[j + 1 ;; -1]], {j, 1, 3 - 1}], 1 vec1 = {1, 2, 3}; vec2 = {1, 2, 3}; NMinimize[ {Total@((vec1[[#]] - Indexed[vec2, u[#]])^2 & /@ R...
Post a Comment
Read more

functions - Get leading series expansion term?

Given a function f[x] , I would like to have a function leadingSeries that returns just the leading term in the series around x=0 . For example: leadingSeries[(1/x + 2)/(4 + 1/x^2 + x)] x and leadingSeries[(1/x + 2 + (1 - 1/x^3)/4)/(4 + x)] -(1/(16 x^3)) Is there such a function in Mathematica? Or maybe one can implement it efficiently? EDIT I finally went with the following implementation, based on Carl Woll 's answer: lds[ex_,x_]:=( (ex/.x->(x+O[x]^2))/.SeriesData[U_,Z_,L_List,Mi_,Ma_,De_]:>SeriesData[U,Z,{L[[1]]},Mi,Mi+1,De]//Quiet//Normal) The advantage is, that this one also properly works with functions whose leading term is a constant: lds[Exp[x],x] 1 Answer Update 1 Updated to eliminate SeriesData and to not return additional terms Perhaps you could use: leadingSeries[expr_, x_] := Normal[expr /. x->(x+O[x]^2) /. a_List :> Take[a, 1]] Then for your examples: leadingSeries[(1/x + 2)/(4 + 1/x^2 + x), x] leadingSeries[Exp[x], x] leadingSeries[(1/x + 2 + (1 - 1/x...
Post a Comment
Read more

What is and isn't a valid variable specification for Manipulate?

I have an expression whose terms have arguments (representing subscripts), like this: myExpr = A[0] + V[1,T] I would like to put it inside a Manipulate to see its value as I move around the parameters. (The goal is eventually to plot it wrt one of the variables inside.) However, Mathematica complains when I set V[1,T] as a manipulated variable: Manipulate[Evaluate[myExpr], {A[0], 0, 1}, {V[1, T], 0, 1}] (*Manipulate::vsform: Manipulate argument {V[1,T],0,1} does not have the correct form for a variable specification. >> *) As a workaround, if I get rid of the symbol T inside the argument, it works fine: Manipulate[ Evaluate[myExpr /. T -> 15], {A[0], 0, 1}, {V[1, 15], 0, 1}] Why this behavior? Can anyone point me to the documentation that says what counts as a valid variable? And is there a way to get Manpiulate to accept an expression with a symbolic argument as a variable? Investigations I've done so far: I tried using variableQ from this answer , but it says V[1...
Post a Comment
Read more