i'm struggling with the following.

I use ParallelTable and it works transparently as it automatically distributes the needed definitions.

However, I run into problems if inside ParallelTable I call a package with Get["code/example.m"]. For example, the value of const which was set in the master kernel is not propagated in the evaluation of Get["code/example.m"].

  • 1
    $\begingroup$ Could you please provide a more complete example of what you are doing, and a short explanation of why you are doing it? $\endgroup$ – Mr.Wizard Feb 21 '12 at 15:07
  • $\begingroup$ I have to sample an expensive function f[x] over a range of x. And in order to calculate f[x] I have to Get the *.m package. $\endgroup$ – Valerio Feb 21 '12 at 15:35
  • $\begingroup$ It looks like the problem gets fixed if I put DistributeDefinitions["Global"]` just before the `ParallelTable'. $\endgroup$ – Valerio Feb 21 '12 at 16:21

Don't ever call functions like Get inside ParallelTable because it will be difficult to control side effects. Get should be evaluated only once per kernel to load definitions: to achieve this, use either ParallelEvaluate[Get[...]] or ParallelNeeds (for proper packages).

It is good practice to only place definitions inside .m files, and not code that computes results. If .m files contain calculations instead of definitions, they are bound to use global variables. Handling these from parallel evaluations will be difficult and error prone.

  • $\begingroup$ I need to call Get inside ParallelTable as the package I'm calling does things like NDSolve $\endgroup$ – Valerio Feb 21 '12 at 15:32
  • $\begingroup$ So the .m file is not a package (definitions), but a program that produces results? And those results depend on some global variables that you set in the kernel? From the minimal information you gave, this is how I imagine it. If you're doing this: it's bad style and can lead to mistakes. I suggest make the .m-file define functions only, and use those function in the calculation. $\endgroup$ – Szabolcs Feb 21 '12 at 15:35
  • $\begingroup$ Yes, it is like this. I like it this way as every .m file does a particular job and allows my code to be modular. I would keep it this way if possible. $\endgroup$ – Valerio Feb 21 '12 at 15:41
  • 1
    $\begingroup$ @Valerio If what the .m file does depends on global variables, then by definition the system is not modular (what it does depends on the environment). While someone might be willing to give you a workaround which will let you keep your current setup (for that you'll need to edit your question and describe in detail what you have), the root of the problem is precisely that your setup is not modular. $\endgroup$ – Szabolcs Feb 21 '12 at 15:53
  • 1
    $\begingroup$ @Valerio As I said, package up whatever your function does, and call that function, passing all the input to it. Don't try to use .m files as functions or "subroutines". It is just asking for trouble. $\endgroup$ – Szabolcs Feb 21 '12 at 16:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.