March 2006 - gridrpc-wg - lists.ogf.org

Re: saga update... (iii)
by Andre Merzky 23 Mar '06

23 Mar '06

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

3 4

Fwd (pbellens@ac.upc.edu): Re: [Fwd: [saga-rg] Re: saga update... (iii)]
by Andre Merzky 22 Mar '06

22 Mar '06

Hi all, I got following forward from Rosa Badia, as an answer to the saga-rpc proposal. Pieter makes some interesting points... Cheers, Andre. ----- Forwarded message from pbellens(a)ac.upc.edu ----- > Date: Mon, 20 Mar 2006 10:47:18 +0100 > From: pbellens(a)ac.upc.edu > To: rosa.m.badia(a)bsc.es > Subject: Re: [Fwd: [saga-rg] Re: saga update... (iii)] > > #include <saga.hpp> > > string func_name = "pi/pi_trial"; > string config_file = "file:///client.conf"; > > int main (int argc, char *argv[]) > { > .. > 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); > > --> In Ninf-G, one creates an object handle that specifies a host and a module > name, where a module can contain anywhere from 1 to many functions. That comes > in really handy, since you can access a lot of functions with a single object > handle creation call. For the case above, you would need 100 handles to access > 100 functions. Unless you start wrapping those functions, but that s a lot of > work, and pretty ugly. The object handle/Ninf-G case is not part of the > official GRPC standard though, whereas the SAGA handle initialization does > follow the standard. Personally, i prefer Ninf-G's approach here. > > > > // perform async call > saga::task t = handle.call <saga::async> (i, times, &count[i]); > > --> Because the handles are treated different, the GRP call itself differs as > well. I don t see how they pass a callback function, though. In Ninf-G, each > asynchronous GRP call contains a callback function as an argument. > > > > // wait tasks (for ever, for all) > tc.wait (-1.0, saga::task::All); > > --> Here you wait on a function container, in Ninf-G one waits for individual > function calls. Although you can wait for several functions, by using logical > AND or OR functionality. This is an interesting feature of SAGA, although we > don t need it. > > > .. > 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. > > --> This makes sense. However, it would make sense to gather all configuration > files into one single file, and use that single file at runtime initialization > time, just as Ninf-G does. > > kind regards, > > pieter -- "So much time, so little to do..." -- Garfield

1 0

CFP: Grid 2006
by Hidemoto Nakada 22 Mar '06

22 Mar '06

All, here is a CFP for Grid2006 that will be held in Barcelona, co-located with the 2006 Cluster Conference. -hidemoto -------------------------------------------------------------------------a GRID 2006 Preliminar Call for Papers ==================================== GRID 2006 the 7th IEEE International Conference on Grid Computing Barcelona, 28-29 September www.grid2006.org The Grid conference series is an anual international meeting that brings together a community of researchers, developers, practitioners, and users involved with Grid technology. The objective of the meeting is to serve as both the premier conference presenting best Grid research and a forum where new concepts can be introduced and explored. The previous events in this series were: Grid 2000, Bangalore, India; Grid 2001, Denver; Grid 2002, Baltimore; Grid 2003, Phoenix; Grid 2004, Pittsburgh; and the sixth event, Grid 2005 in Seattle. All of these events have been successful in attracting high quality papers and a wide international participation. Last year's event attracted about 400 registered participants. >From the second event through the sixth, we have been known as the Grid Workshop affiliated with the Supercomputing SC conference series. For this, our seventh event, we will convene our first meeting as a conference and this year we will be co-located with the 2006 Cluster conference. The proceedings of the first three workshops were published by Springer-Verlag, and the proceedings of the three most recent workshops were published by the IEEE Computer Society Press. We expect this year's proceedings will join those of the last three years in the IEEE Computer Society's Digital Library. Grid 2006 has been labeled CoreGRID event. SCOPE ===== Grid 2006 topics of interest (in no particular order) include, but are not limited to: * Internet-based Computing Models * Applications, including eScience and eBusiness Applications * Distributed and Large-Scale Data Access and Management * Middleware and Toolkits * Monitoring, Management and Organization Tools * Resource Management and Scheduling * Networking * Virtual Instrumentation * Metadata, Ontologies, and Provenance * Creation and Management of Virtual Enterprises and Organizations * Architectures and Fabrics * Information Services * Security Issues * Programming Models, Tools, and Environments * Grid Economy * Autonomic and Utility Computing on Global Grids * Performance Evaluation and Modeling * Cluster and Grid Integration Issues * Scientific, Industrial and Social Implications Technical Papers ================ Grid 2006 invites authors to submit original and unpublished work (also not submitted elsewhere for review) reporting solid and innovative results in any aspect of grid computing and its applications. Papers should not exceed 8 single-spaced pages of text using 10-point size type on 8.5 x 11 inch paper (see IEEE author instructions, a LaTeX style sheet and Word format is available, too). All bibliographical references, tables, and figures must be included in these 8 pages. Submissions that exceed the 8-page limit will not be reviewed. Authors should submit a PDF file that will print on a PostScript printer. Submission implies the willingness of at least one of the authors to register and present the paper. Proceedings: All papers selected for this conference are peer-reviewed and will be published as a separate proceedings. After the event, the papers will also be published in the IEEE Xplore and the CS digital library. For author instructions see http://www.computer.org/cspress/instruct.htm Special Issue: The best 6 to 8 papers from the conference will be selected for journal length extension and their publication in a special issue of the Future Generation Computing Systems (FGCS). Important Dates =============== 1 March 2006 Paper submission site open 7 April 2006 Full paper submission due 14 April 2006 Last date for paper updates before review process 9 June 2006 Acceptance notification 1 July 2006 Camera-ready copy due 28-29 Sept 2006 Conference Conference Organization ======================= General co-Chairs Andrew Grimshaw, University of Virginia, USA Rosa M. Badia, Barcelona Supercomputing Center, Spain Program Chair Dennis Gannon, Indiana University, USA Program Vice Chairs Applications: Satoshi Matsuoka, Tokyo Institute of Technology, Japan Data Management: Beth Plale, Indiana University, USA Networking/Security/Infrastructure: Olle Mulmo, Center for Parallel Computers, KTH Sweeden Scheduling/Resource management: Jarek Nabrzyski, Poznan Supercomputing Center, Poland Tools/Software/Middleware: Ian Taylor, Cardiff University, UK Publicity Chair: Julita Corbalan, Universitat Politecnica de Catalunya, Spain Proceedings Chair: Rajkumar Buyya, University of Melbourne, Australia Finance Chair: Craig Lee, The Aerospace Corporation, USA Local arrangements chair: Toni Cortes, Barcelona Supercomputing Center, Spain Tutorial Chair: Salim Hariri, University of Arizona, USA Steering Committee ================== Chair: Craig Lee, Aerospace Corp., USA Mark Baker, University of Portsmouth, UK Rajkumar Buyya, University of Melbourne, Australia Wolfgang Gentzsch, D-Grid, Germany Daniel S. Katz, JPL/Caltech, USA Manish Parashar, Rutgers University, USA Heinz Stockinger, University of Vienna, Austria

1 0

Re: saga update (ii)
by Andre Merzky 18 Mar '06

18 Mar '06

Hi folx, lets do another, more complete example translation from gridrpc to saga. Todays example is the pi_client_sync.c from the NinfG documentation. The original code (changed formating) is attached as pi_client_sync.c. The SAGA version is included below. I ommited the C version this time, for brevity - please let me know if you would like the direct comparison with C, and I'll try to come up with that. ---------------------------------------------------------- /* This is sample program for Ninf-G, calculate PI on one server */ #include <saga.h> std::string func_name = "pi/pi_trial"; std::string config_file = "client.conf"; int port = 0; int main (int argc, char *argv[]) { if ( argc != 3 ) { std::cerr << "\n\tUSAGE: " << argv[0] << " <times> <hostname>\n\n"; exit (2); } long times = atol (argv[1]); string host = argv[2]; try { /* Initialize Function handle */ saga::rpc handle (host, func_name); /* Synchronous call */ long answer; handle.call (0, times, &answer); /* Compute and display pi. */ std::cout << "PI = " << 4.0 * ((double) answer / times)) << std::endl; } catch ( const saga::exception & e ) { std::cerr << "Catched saga error: " << e.what () << std::endl; exit (2); } return (0); } ---------------------------------------------------------- Don't let yourself be fooled by the shortness of the programm - that is mainly due to C++, not due to saga (although again the session initialization/destroy is done behind the scenes by default). The semantics should be exactly the same as in GridRPC. Well, thats for now, the next example should tackle a async call I guess. Again, I would be more than happy to see more realistic code examples posted by you guys :-) Cheers, Andre. -- "So much time, so little to do..." -- Garfield

1 0

Re: GGF17 sessions...
by Andre Merzky 15 Mar '06

15 Mar '06

--- please excuse the cross posting --- Hi Group_S_, we scheduled 4 sessions (one 45min, 3 90min) for GGF17 in Tokyo. Given that GGF17 is only 3 days, and that we also plan to hold a application workshop which will be somewhat SAGA centtric, you are save to assume that GGF17 will be pretty busy for us... Below are the details for the scheduled sessions. We are free to shuffle them around, and to change agenda etc. for the next 4 weeks or so (before the program gets printed). So please send us feedback/corrections/suggestions etc. Best regards, Andre + Chairs session 1 - RG - 45 min - administrativa - SAGA overview for the crowd, announce other sessions etc - sync with RPC and CPR, finalize on design teams session 2 - RG - 90 min - plan for real req. document for these design teams - work on SAGA-RPC draft - work on SAGA-CPR draft (if available) - synchronize with (and plan for future) new specs in GGF (GFS, BES, JSDL, ...) (we should READ them before GGF) - if time: start with SAGA-WG issue list session 3 - WG - 90 min - finalize req document, last comments, and submit to editor immediately (if not done before GGF) - update on issue list, close last remaining items session 4 - WG - 90 min - finish issue discussion - check API for remaining open parts - define timeline/responsibilities for finalization - define editors for cook-book - define editors and format for language bindings - update on implementations - discuss bulk optimizations (see DRMAA use case) - discuss parts of API which should be moved into the RG look-&-feel document (object, task, ...) -- "So much time, so little to do..." -- Garfield

1 0