March 2006 - saga-rg - lists.ogf.org

Requirement Document - Group feedback needed...
by Andre Merzky 22 Jun '06

22 Jun '06

Hi Group, the SAGA Requirement document is, finally, getting close to publication. Attached is the current version, which we intent to submit to GGF Office on Friday night. This is the 'last call' for the group to provide feedback on the draft, or (preferrably ;-) to give us a 'go ahead'. Two notable points might change before submission: the author list might get extended (please speak up if you feel left out, or have suggestions!); and the Java-CoG sections needs revision - we are waiting for input from Gregor on that. Please provide feedback as early as possible, to allow us to keep our Friday submission deadline. Comments after (local) businness hours are very likely to be ignored (for this version). Best regards, Shantenu and Andre. -- "So much time, so little to do..." -- Garfield

3 3

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 (andre@merzky.net): Re: saga update... (iii)]]
by Andre Merzky 22 Mar '06

22 Mar '06

FYI, below the CFP for Grid-2006. Cheers, Andre. ----- Forwarded message Rosa M. Badia ---- > 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 labelled a 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 > > -------------------------------------------------------------- -- "So much time, so little to do..." -- Garfield

1 0

Non-member submission from [Rob van Nieuwpoort <rob@cs.vu.nl>] (fwd)
by Shantenu Jha 21 Mar '06

21 Mar '06

Date: Tue, 21 Mar 2006 12:27:07 +0100 From: Rob van Nieuwpoort <rob(a)cs.vu.nl> To: gat-devel(a)gridlab.org Cc: saga-rg(a)ggf.org Subject: Re: [Gat-devel] SAGA an Java GAT? > 3) SAGA is planned ot be a standard, what is then with Java-GAT? Hi all, We have funding within the VL-e project to maintain the JavaGAT. VL-e runs until the end of 2008, so we will at least maintain JavaGAT until that time. Cheers, Rob

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

SAGA an Java GAT?
by alexander.beck-ratzka 14 Mar '06

14 Mar '06

Hi Folks, we just have had a discussion on SAGA or GAT (including Java GAT) and its usage in D-Grid. In these discussion some questions arised: 1) Will it give a Java SAGA in near future? 2) If there is no plan to build a Java SAGA, how can it be assured that Java GAT and SAGA remain two language bindings of the same problem? We fear that they disperse from each other. 3) SAGA is planned ot be a standard, what is then with Java-GAT? Many answers are welcome!! Cheers Alexander

2 1

Comments on the job API (revision 1.4)
by Graeme Pound 08 Mar '06

08 Mar '06

Hi, I have some comments on the job section of the Strawman API (revision 1.4). Thanks Graeme -3.37 I do not understand the purpose of job_service.get_self() which returns a Job object. -3.38 I like the removal of the JobInfo and JobExitStatus objects from the API, and adding this information as attributes to Job. This streamlines the API, the concept of read only attributes also makes sense [to me] within the context of the Job object. -3.39 I like the simplification of the job_state enumeration. NB This is called 'state' in the SIDL and should be corrected to 'job_state'. -3.41 The separation of the JobService.submitJob() method into two methods JobService.createJob() [create the job object] and Job.run() [start the job] has not been seamless and there are several of conceptual and practical problems. This needs to be fine-tuned further. On many [all?] resource managers there is no separation between submitting a job to the resource manager and manually starting the job, this raises the following problem: - Job objects are identified via the job_id which is described as the "job identifier as returned by the resource manager". Unfortunately since this information will only be available upon submission of the job (via Job.run()) this breaks the methods JobService.list() and JobService.getJob(). It is now impossible to manage an index of Job objects within JobService based upon the job ID. - What is the conceptual relationship between the JobService and the resource manager? At present this is a little confused in a couple of ways. #1 Should there be a one to one relationship between JobService instances and resource managers; i.e. should the resource manager endpoint be specified in the JobService constructor (or otherwise as an argument to JobService.createJob())? #2 The term JobService implies a close relationship to the resource manager. Previously JobService.submitJob() corresponded to communication with the resource manager. Now JobService.createJob() corresponds to the creation of instances of the Job class the JobService is acting as a factory. It may beneficial to rename JobService to JobFactory to clarify the relationship. -3.42 Should Job objects created by runJob() be added to the index managed by the JobService? Or in other terms, should JobService.runJob() be a Java 'static' method?

4 10

JobService.submitJob() query
by Graeme Pound 07 Mar '06

07 Mar '06

Hi, Can anybody clear up this issue for me? I may be missing something in the spec. Thanks, Graeme -3.31 How is the resource manager endpoint for JobService.submitJob() specified? The endpoint is specified by an argument of JobService.runJob(), but is not _obvious_ for submitJob(). Is the endpoint a property of the instance of JobService (with runJob() a 'static' method of the class), or is the endpoint specified as an attribute of JobDefinition? I assume that the contents of the JobDefinition attribute 'SAGA_HostList' is intended to be passed to the resource manager (rather than specify the resource manager itself); for example mapping to the 'CandidateHosts' element of a JSDL document. Is an additional attribute within JobDefinition required to specify the endpoint?

4 17

open_flag and open_dir_flags
by Graeme Pound 07 Mar '06

07 Mar '06

Hi, The relationship between the enumerations open_flag and open_dir_flags in the various packages of the API is a little problematic. Graeme -3.35 How should interfaces inheriting from ns_directory and ns_entry inherit/override the enumerations open_flag and open_dir_flags? The methods of ns_directory open_dir() and open() will require the enumerations defined in the name_space package (or sub-classes of these enumerations). With Java enumerations it would be possible to extend the original enumerations by sub-classing, but it is not possible to not remove fields. Unfortunately saga.logical_file.open_flags removes fields from saga.name_space.open_flags.

2 3