Calling netsolve_nb()

The obvious drawback of the function netsolve() is that while the computation is being performed remotely, the user must wait to regain control of the prompt. To address this drawback, we provide a nonblocking function, netsolve_nb(). The user can then do work in parallel and check for the completion of the request later. He can even send multiple requests to NetSolve. Thanks to the load-balancing strategy implemented in NetSolve agent, all these requests will be solved on different machines if possible, achieving some NetSolve-parallelism. Let us describe this function with the eig example.

As in the previous section, the user creates a 300 x 300 matrix and calls NetSolve:
octave>> a = rand(300);
octave>> [r] = netsolve_nb('send','eig',a)
Obviously, the calling sequence to netsolve_nb() is a little different from the one to netsolve(). The left-hand side always contains one single argument. Upon completion of this call, it will contain a NetSolve request handler. The right-hand side is composed of two parts: the action to perform and the arguments that would be passed to netsolve(). In this example, the action to perform is 'send', which means that we send a request to NetSolve. Through out this section, we will encounter all of the possible actions, and they will be summarized in chapter 22.

Let us resume our example and see what NetSolve answers to the first call to netsolve_nb():
octave>> [r] = netsolve_nb('send','eig',a)
  rd->request_id = 0

  r =  
  
  0
netsolve_nb() returns a request handler: 0. This request handler will be used in the subsequent calls to the function. The request is being processed on cupid, and the result will eventually return. The user can obtain this result in one of two ways. The first one is to call netsolve_nb() with the 'probe' action:

octave>> [status] = netsolve_nb('probe',r)
netsolve_nb() returns the status of a pending request. The right-hand side contains the action, as is required for netsolve_nb(), and the request handler. This call returns immediately, and prints a message. Here are the two possible scenarios:
octave>> [status] = netsolve_nb('probe',r)
  Not ready yet
  status = -1
  ...
octave>> [status] = netsolve_nb('probe',r)
  Result Available
  status = 0

To obtain the result of the computation one must call netsolve_nb() with the 'wait' action:
octave>> [x y] = netsolve_nb('wait',r)
  x =           y =
  
  10.1204            0
  -0.9801       0.8991
  -0.9801      -0.8991
  -1.0195            0
  -0.6416       0.6511
    ...          ...
    ...          ...

As with the netsolve() function, one can merge the real part and the imaginary part into a single complex vector. The typical scenario is to call netsolve_nb() with the action 'send', then make repeated calls with the action 'probe' until there is nothing more to do than wait for the result. The user then calls netsolve_nb() with the action 'wait'. It is of course possible to call netsolve_nb() with the action 'wait' before making any call with the action 'probe'. One last action can be passed to netsolve_nb() as shown here:
octave>> netsolve_nb('status')
This command will return a description of all the pending requests. Let us see how it works on this last complete example:
octave>> a = rand(100); b = rand(150);
octave>> [r1] = netsolve_nb('send','eig',a)
  rd->request_id = 0

  r1 =
 

      0

octave>> [r2] = netsolve_nb('send','eig',b)
  rd->request_id = 1

  r2 =


      1
Now let us see what 'status' does:
octave>> netsolve_nb('status')
  --- NetSolve: pending requests ---
  Requests #0: 'eig', submit-
  ted to torc3.cs.utk.edu (128.169.93.74)
          was started 41 seconds ago.
  netsolveProbeRequest returned: 1, ns_errno = 0
          Completed
  Requests #1: 'eig', submit-
  ted to torc3.cs.utk.edu (128.169.93.74)
          was started 23 seconds ago.
  netsolveProbeRequest returned: 1, ns_errno = 0
          Completed
The user can check what request he has sent so far and obtain an estimation of the completion times. By using the 'status' action, the user can also determine whether a request is still running or has been completed. By sending multiple non-blocking requests to NetSolve and relying on the agent for load balancing, the user can achieve parallelism.