Take the 2-minute tour ×
Mathematica Stack Exchange is a question and answer site for users of Mathematica. It's 100% free, no registration required.

I have two notebooks, each with a different kernel. Is there a way to grab the value of a variable in KernelA from KernelB?

share|improve this question
    
You could try assigning the variable to a tagging rule and accessing via CurrentValue[$FrontEndSession,{TaggingRules, ...}] –  Mike Honeychurch Nov 5 '12 at 21:58
2  
You could use a file. –  Sjoerd C. de Vries Nov 5 '12 at 21:59
    
@MikeHoneychurch interesting approach, an you give all the code for your example as a solution? –  M.R. Nov 5 '12 at 22:06
1  
IMO probably the best way is using MathLink (Mike's suggestion of course uses it indirectly). I showed how you can link up two kernels here--you may be interested in the linked MathGroup posting too. An updated version of that code is here. –  Oleksandr R. Nov 5 '12 at 22:12
    
@OleksandrR. Could you update your answer with the latest version of the code? (you can perhaps use belisarius' notebook-in-image palette to upload it if it is long) –  rm -rf Nov 5 '12 at 22:28

2 Answers 2

up vote 10 down vote accepted

Try this out:

Lets say you have a variable called kernelA in one notebook using Kernel A. Then:

CurrentValue[$FrontEndSession, {TaggingRules, "KernelA"}] = kernelA

In your other notebook, running Kernel B just evaluate

variableFromOthernotebook = CurrentValue[$FrontEndSession, {TaggingRules, "KernelA"}]

Edit

An alternative that might be faster (almost certainly would be if a lot of TaggingRules are used).

SetOptions[$FrontEndSession, TaggingRules -> {"KernelA" -> kernelA}]

than in the other notebook:

variableFromOthernotebook = "KernelA" /. 
(TaggingRules /. Options[$FrontEndSession, TaggingRules])
share|improve this answer
    
There is significant lag in this example :( –  M.R. Nov 6 '12 at 1:06
    
@M.R. can you explain what you mean? A lag setting the value? A lag obtaining the value? –  Mike Honeychurch Nov 6 '12 at 5:34
    
@MikeH. I find your method surprisingly performant, with no obvious lag, as well as ingenious in its simplicity. A lot of optimization must go in to the front-end link, as its bandwidth for large transfers is actually higher than the approach I demonstrate (although it has a marginally higher latency). As usual, though, older versions win out in the performance stakes: using my example, Mathematica 5.2 is about twice as fast as version 8 for basic MathLink transfers... –  Oleksandr R. Nov 6 '12 at 5:46
    
@OleksandrR. In the past I have found that if you have to set a large number of rules (from memory 30-50), TaggingRules can slow down quite a bit but for a small number I have found it to be fairly efficient. Why is V5.2 faster than V8 for MathLink transfers? –  Mike Honeychurch Nov 6 '12 at 6:34
    
@MikeH. I don't really know why, but it seems with each new version, along with many new features, more overhead gets added to the fundamental operations. In this case it's probably a question of MathLink interface version 2 vs. 3, the latter being slower for some reason. Basic manipulation of DownValues is also about a third faster in 5.2 than 8. –  Oleksandr R. Nov 6 '12 at 13:20

Here is a very simple example of how to use MathLink for this sort of communication. I will use normal code blocks for kernel A and quoted code blocks for kernel B. You must evaluate these in the order shown.

link = LinkCreate["a uniquely named link"];
link = LinkConnect["a uniquely named link"];
LinkActivate[link];
MathLink`AddSharingLink[link];
LinkActivate[link];
SetAttributes[remoteEvaluate, HoldAllComplete];
remoteEvaluate[expr_] := (
  LinkWrite[link, Unevaluated@EvaluatePacket[expr]]; LinkFlush[link];
  First@Cases[
    While[Sow[#, Head[#]] &[LinkRead[link]]; LinkReadyQ[link]] ~Reap~ ReturnPacket,
    ReturnPacket[result_] :> result, {3}
   ]
 );

The idea is that the result of evaluating expr on kernel B comes back to kernel A as the body of a ReturnPacket. Other types of packets may also be produced (for example, ExpressionPackets are generated when something is Printed), but we ignore these for present purposes.

Now:

var = Range[5];
var
(* -> var *)

remoteEvaluate[var]
(* -> {1, 2, 3, 4, 5} *)

If we care to check, we will also find that var did not suffer the indignity of unpacking and was quite unmolested in general by this process.

One important point to note is that it is not legal to call MathLink`AddSharingLink on the same link from two different kernels, as this causes a deadlock. Therefore, if you want to share data in a symmetric fasion, you will have to set up a link from A to B and another link from B to A. Although links are in fact bidirectional, this sort of communication requires matching reads and writes to be placed on the link in the appropriate sequence. Unless A and B are both being controlled by C, it will be easier in many cases to defer to the main loop as shown above, because although it renders each link effectively unidirectional, it also enables single-ended communication.

share|improve this answer
1  
I didn't manage to get this working in 9, take a look here –  Szabolcs May 15 '13 at 15:11

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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