Ok, lets do the async call, again with an example taken from the NinfG tutorial (pi_client_multi.c, attached with changed indentation). The SAGA version, again in C++, is below: ----------------------------------------------------------- #include <saga.hpp> string func_name = "pi/pi_trial"; string config_file = "file:///client.conf"; int main (int argc, char *argv[]) { if ( argc < 3 ) { std::cout << "\n\t"; std::cout << "USAGE: " << argv[0] << " TIMES HOSTNAME\n"; std::cout << "USAGE: " << argv[0] << " TIMES HOSTNAME1 HOSTANME2...\n\n"; exit (2); } // initialize vars from CL arguments int n = argc - 2; long times = atol (argv[1]) / n; std::vector <std::string> hosts; for ( int i = 0; i < n; i++ ) { hosts[i] = (argv[i+2]); } try { std::vector <long> count; saga::task_container tc; for ( int i = 0; i < n; i++ ) { // create rpc handle saga::rpc handle (hosts[i], func_name, config_file); // perform async call saga::task t = handle.call <saga::async> (i, times, &count[i]); // add task to task container tc.add (t); } // wait tasks (for ever, for all) tc.wait (-1.0, saga::task::All); // Compute and display pi. int sum = 0; for ( i = 0; i < n; i++ ) { sum += count[i]; } std::cout << "PI = " << 4.0 * (sum / ((double) times * n))) << std::endl; } catch ( const saga::exception & e ) { std::cerr << "Found saga error: " << e.what () << std::endl; exit (2); } return (0); } ----------------------------------------------------------- I realised that I forgot the config_file argument to the handle creation in the last (synchroneous) example - it should look like above. That actually _is_ a difference to GridRPC: as the session in SAGA is not RPC specific, it makes no sense to have a RPC specific config file for a session. Hence, the config file would need to be attached to the handle creation. The example code above lives from the task container: that allows to collect multiple asynchroneous calls to be handled together. Best regards, Andre. PS.: as a side note, we do have the above form of RPC included in our saga reference implementation. However, it does not yet forward the calls to a NinfG or GridSolve adaptor. If anyone in this group has interest in connecting the reference implementation to a real GridRPC backend, please let us know :-) -- "So much time, so little to do..." -- Garfield
Andre,
I realised that I forgot the config_file argument to the handle creation in the last (synchroneous) example - it should look like above. That actually _is_ a difference to GridRPC: as the session in SAGA is not RPC specific, it makes no sense to have a RPC specific config file for a session. Hence, the config file would need to be attached to the handle creation.
Please note that the GridRPC config file is not per session, but per whole client program. the config file should be passed to the saga::rpc class, like saga::rpc.init(config_file); where 'init' is a class method of the rpc class.
PS.: as a side note, we do have the above form of RPC included in our saga reference implementation. However, it does not yet forward the calls to a NinfG or GridSolve adaptor. If anyone in this group has interest in connecting the reference implementation to a real GridRPC backend, please let us know :-)
We do have an java implementation for Ninf-G client. if your SAGA reference implementation is Globus-based and written in Java, it will be relatively easy to make it Ninf-G aware.
Quoting [Hidemoto Nakada] (Mar 23 2006):
Andre,
I realised that I forgot the config_file argument to the handle creation in the last (synchroneous) example - it should look like above. That actually _is_ a difference to GridRPC: as the session in SAGA is not RPC specific, it makes no sense to have a RPC specific config file for a session. Hence, the config file would need to be attached to the handle creation.
Please note that the GridRPC config file is not per session, but per whole client program.
the config file should be passed to the saga::rpc class, like
saga::rpc.init(config_file);
where 'init' is a class method of the rpc class.
Hi Hidemote, I'd like to understand the purpose of the config file better, so I have a couple of questions. I found the config-file section in the Ninf-G user manual. What is the general idea of the config file? To me it sounds like it configures the (client side) backend, not the API - would that not better be hidden in some ~/.ninfgrc or so? Are there many values which are intended to change from one application run to the next? The GridSolve user guide is silent about the config file structure - is it the same as in Ninf-G? If not, how does GridSolve handle the client side configuration?
PS.: as a side note, we do have the above form of RPC included in our saga reference implementation. However, it does not yet forward the calls to a NinfG or GridSolve adaptor. If anyone in this group has interest in connecting the reference implementation to a real GridRPC backend, please let us know :-)
We do have an java implementation for Ninf-G client. if your SAGA reference implementation is Globus-based and written in Java, it will be relatively easy to make it Ninf-G aware.
We write the reference implementation in C++ - so its even simplier I think :-) Cheers, Andre. -- "So much time, so little to do..." -- Garfield
Andre,
I'd like to understand the purpose of the config file better, so I have a couple of questions. I found the config-file section in the Ninf-G user manual.
What is the general idea of the config file? To me it sounds like it configures the (client side) backend, not the API - would that not better be hidden in some ~/.ninfgrc or so?
Are there many values which are intended to change from one application run to the next?
yes. the configuration file cannot be shared by all the applications. we found that configuration files are really handy. It could be hidden like $(PWD)/.ninfgrc .
The GridSolve user guide is silent about the config file structure - is it the same as in Ninf-G?
No. it is totally implementation dependent.
If not, how does GridSolve handle the client side configuration?
I have no idea. my colleague Yusuke might know the answer for your question. # He was working for Jack for one year.
PS.: as a side note, we do have the above form of RPC included in our saga reference implementation. However, it does not yet forward the calls to a NinfG or GridSolve adaptor. If anyone in this group has interest in connecting the reference implementation to a real GridRPC backend, please let us know :-) We do have an java implementation for Ninf-G client. if your SAGA reference implementation is Globus-based and written in Java, it will be relatively easy to make it Ninf-G aware.
We write the reference implementation in C++ - so its even simplier I think :-)
Hi, all,
The GridSolve user guide is silent about the config file structure - is it the same as in Ninf-G?
No. it is totally implementation dependent.
If not, how does GridSolve handle the client side configuration?
I have no idea. my colleague Yusuke might know the answer for your question.
If GridSolve people read this discussion, of course, it is the best for them to answer the question, or correct my comments if I said wrong. The client configuration is almost nothing in GridSolve and NetSolve. Only $NETSOLVE_AGENT (or $GRIDSOLVE_AGENT) and $NETSOLVE_AGENT_PORT can be specified with the environment variables. The client can get the information of remote servers form the agent, because the server is registered to the agent when it starts. On the other hand, GridSolve and NetSolve have the server configuration file. A file will be prepared for each server by a remote site administrator (or a user after he/she login the remote). This configuration filename will not be appeared in the client-side API. regards, Yusuke
participants (3)
-
Andre Merzky -
Hidemoto Nakada -
Yusuke Tanimura