December 2009 - saga-rg - lists.ogf.org

Some more comments on the SAGA specs.
by Ceriel Jacobs 17 Feb '10

17 Feb '10

Hi, I have some more remarks/questions about the new Saga specifications, this time about the task package. Here they are, in random order: Bugs: task.wait() in the details does not specify a default value for the timeout. PreCond on task.cancel(): sais that task is in 'Running' state, but the Notes say that it can also be in a final state, in which case the cancel has no effect. Why does task_container.remove() return the removed task? It is already specified as parameter. PostCond on task_container.run(): sais that all tasks in the container are in 'Running' state, but I guess the only thing you can be sure of is that the state is not 'New', like with task.run(). PostCond on task_container.cancel(): sais that if no timeout occurs all tasks in the container are in 'Canceled' state. But the tasks can be in another final state as well. Debatable issues: task_container: what is the difference between list_tasks() and get_tasks()? list_tasks() originally returned the cookies. Should it now return a list of object ids? Or should the method just be removed alltogether? I am not sure that it is a good idea to have get_result() call rethrow(). How do I now make a distinction between an exception coming from the get_result() call itself and an exception from the task? I guess that in the exception handler I can check the state of the task, but that does not give you a definite answer: if the state is "FAILED", the exception can still come from get_result() itself, can it not? Why not leave it to the user to call rethrow() if he/she wants, and as it was before? Cheers, Ceriel

2 2

just a couple of glitches in the Saga specs
by Ceriel Jacobs 18 Dec '09

18 Dec '09

Hi Andre, just a couple of minor glitches this time, and nothing debatable, I think. The context class description still refers to the set_defaults method, which no longer exists: "(see documentation to the set_defaults() method." (at the bottom of page 81). Notes at remove_context talk about "parameter values", that should be "attribute values". Cheers, Ceriel

1 0

Some comments on the SAGA specs.
by Ceriel Jacobs 16 Dec '09

16 Dec '09

Hi, I am currently in the process of modifying the Java language bindings for SAGA, following the changes in the SAGA specification, using the version marked as "Version 1.1 Revised November 19, 2009", and came across a couple of issues, written down below, in random order: CONSTRUCTOR specification of URL: should have "url", not "buffer", as out parameter type. Also, the specification does not provide a default value for the in-parameter, whereas the details do (and the latter is correct, I think). Version 1.0 of the SAGA specs had this error as well. DESTRUCTOR specification of URL: should have "url", not "buffer", as in-parameter type. Version 1.0 of the SAGA specs had this error as well. URL set_port specification: default value for port = "" ??? That cannot be right, a port is an integer, so I guess the default value is -1. This is wrong in the details as well. Version 1.0 of the SAGA specs had this error as well. stream.close() still can throw IncorrectState. This is fine, but contradicts the Errate in Appendix B, which say that close() now is not throwing IncorrectState anymore. This remark only holds for the namespace/file/logicalfile close, the rpc close, and the stream_server close. These errata also don't mention any of the changes to the streams package, and there are several, such as the added "connect" method in the stream_server class, and the name change of the stream_server class (which used to be stream_service). These errata also don't mention a couple of signature changes in the task package, and there are several: task_container add(), remove(), list_tasks(), get_task(). Moreover, these changes all break backwards compatibility. Also, the task_container.state metric has changed type, again a change that breaks backwards compatibility. Appendix B sais in its first paragraph that the version number of the document has not changed, and remains 1.0. However, the first page of the document clearly states: "Version: 1.1 Revised November 19,2009". task_container.add(): the notes specify that it throws AlreadyExists if the task is already in the container, but AlreadyExists is not in the Throws list. Question: why can the context constructor still throw IncorrectState? Or any other exception, for that matter? It doe not call set_default() anymore. Should these exceptions now be thrown by the add_context method of session? But that one currently cannot throw IncorrectState. That's it for now. Cheers, Ceriel

1 0

Saga Python bindings LSU-VU diff
by Manuel Franceschini 15 Dec '09

15 Dec '09

Hi all, first, sorry for the delay but I was extremely busy with classes the last weeks. Please find attached the first attempt of a diff between LSU (1.4) and VU bindings. Please note that the VU bindings are a little bit outdated, as we just removed the buffer module from the spec but didn't have time yet to do the same for our LSU bindings wrapper. Furthermore I couldn't find the 'stream' and 'rpc' module in the LSU bindings. This is the first attempt to craft a somewhat clear layout to compare the two. I wrote a small script to build it, so I can tweak it relatively easily to change structure (in case somebody has a suggestion for better layout). Best, -- /Manuel

1 0

Re: [SAGA-RG] quick poll: SPMD attributes
by Andre Merzky 12 Dec '09

12 Dec '09

hi Andre, Quoting [Andre Luckow] (Dec 11 2009): > > Hi, > > Quoting [Ole Christian Weidner] (Dec 10 2009): > >> > >>> Some of the concerns may get addressed by resource discovery and > >>> reservation, but not all. So, we would like to propose the > >>> following replacement list for these attributes: > >>> > >>> SPMDVariation > >>> NumberOfProcesses > >>> ProcessesPerMachine > >>> ProcessesPerSlot > >>> ProcessesPerCore > >>> > >>> (Slot and Machine are the DRMAA terms for CPU and Host). > >> > >> Let's go with CPU and host then. Especially slot is IMHO a rather weird term - cpu is so much easier to understand. > > > > Peter corrected me: its socket, not slot. Anyway, I am by no means > > sold to those terms, but rather want to nail down concept and > > hierarchy. Machine and CPU would be fine with me, as would be > > > > node > > host > > machine > > > > and > > > > cpu > > socket > > processor > > I agree in the point that the above attributes are better than the existing SAGA one. However, I > believe the way these attributes can be used can become quite complicated. It requires detailed advanced knowledge > of the Grid resources that will be used. Further, the user can make contradicting specifications, e.g. > if the ProcessesPerMachine attribute does not fit to the ProcessesPerSockets attribute. Correct. For knowledge: that system would only make sense (or at least make more sense) if combined with a resource discovery and description. Contradiction: well, that is often the case anyway, like you specify an interactive job AND IO/redirection into files, or specify 4 processes but no SPMDVariation. Not sure what to do about that... > On a space sharing system a user usually cannot influence the number of cpus/cores he gets > per node. E.g. on LONI you must use 8 cores per node on QB and 4 cores per node on all other machines. > Thus, the most common usage mode will probably be: > > NumberOfProcesses = x > ProcessesPerMachine == number_of_cores_per_cpu * number_of_sockets > ProcessesPerSockets == number_of_cores_per_sockets > ProcessesPerCore = 1 > > The question is: How can this 80% case be efficiently supported without loosing the flexibility > in the other cases? Does it make sense to declare default values for the ProcessesXXX attributes > and to declare them optional? Agree, they absolutely should be optional, and default to ProcessesPerMachine = unspecified ProcessesPerSockets = unspecified ProcessesPerCore = 1 And right, you can't enforce number of cpus/cores, but you can set upper bounds, to make either sure you are not getting on a core where xxx processes are already running, or, on the other end, allow the DRM to use a core for multiple process instances. Makes sense? > >>> The NumberOfProcesses is to be interpreted as exact number by the > >>> backend. The ProcessesPerXYZ are to be interpreted as upper bounds > >>> by the backend. > >>> > >>> So, for example, one could specify a 16 process MPICH job as > >>> > >>> SPMDVariation = MPICH > >>> NumberOfProcesses = 16 > >>> ProcessesPerCore = 2 > >> > >> Ok, but what if the backend doesn't understand these things, (RSL > >> for example only understands number of nodes and number of > >> processes). In this case the adaptor itself would have to (a) > >> figure out the number of cores per cpu (b) the number of cpus per > >> node and (c) make a reservation for > >> (16/2/#cores_per_cpu/#cores_per_node) nodes. The globus GRAM > >> adaptor already does something similar to this due to the > >> shortcomings of RSL. Not pretty. > > > > Right - but it is even worse if the user has to do it on application > > space. So, I guess it is like with all other JD attributes: if it > > is specified, it must be honored - which may effectively limit the > > number of available backends... > > Even worse, different Globus installations differently interpret > the "count" RSL attribute. Just try to use Abe, Ranger and QB with > the same RSL file you will see a different behavior. It's just too > easy to "hack" the JobManager Perl script of Globus. :-( Can't do nothin about that I guess... Thanks! Andre. > Regards, Andre -- Nothing is ever easy.

2 2

Re: [SAGA-RG] quick poll: SPMD attributes
by Andre Merzky 12 Dec '09

12 Dec '09

Quoting [Andre Luckow] (Dec 12 2009): > > Agree, they absolutely should be optional, and default to > > > > ProcessesPerMachine = unspecified > > ProcessesPerSockets = unspecified > > ProcessesPerCore = 1 > > > > And right, you can't enforce number of cpus/cores, but you can set > > upper bounds, to make either sure you are not getting on a core > > where xxx processes are already running, or, on the other end, allow > > the DRM to use a core for multiple process instances. > > > > Makes sense? > It does make sense. But now the next question is: What is the semantics of those attributes? > - exactly > - upper bound > - lower bound > > or do you want to specify a range (which complicates things even more). IMHO they should be upper bound. Less processors per XYZ should give better performance, so it should be ok for the user? I could live with exact, too - but lower bound does not make sense I think - I don't want to end up wioth 1000 procs per core just because its allowed by the default job description ;-) Cheers, Andre. -- Nothing is ever easy.

1 0

quick poll: SPMD attributes
by Andre Merzky 10 Dec '09

10 Dec '09

Hi all, we had a very productive meeting with the DRMAA guys today, and will continue tomorrow. We'll send around notes next week I think, but for now I'd love to have some quick feedback on a very specific topic. At the moment, SAGA has the following job description attributes to specify job mnultiplicity, which are derived from the JSDL core and JSDL SPMD extension: - SPMDVariation - MPI type etc. - TotalCPUCount - total number of CPUs required by the job - NumberOfProcesses - number of instances of the Executable that the consuming system MUST start - ProcessesPerHost - number of instances of the Executable that the consuming system MUST start per host. - ThreadsPerProcess - number of threads per process (i.e., per instance of the Executable There is not much discussion about SPMDVariation (anymore), but the others are appearently somewhat inconsistent: - processes can be started by the backend, threads can't, so why specify ThreadsPerProcess? - hosts can have multiple CPUs - this is not reflected - CPUs can have multiple cores - this is not reflected - in general, the attributes seem somewhat inconsistent, and its hard to specify the values for specific use cases. Some of the concerns may get addressed by resource discovery and reservation, but not all. So, we would like to propose the following replacement list for these attributes: SPMDVariation NumberOfProcesses ProcessesPerMachine ProcessesPerSlot ProcessesPerCore (Slot and Machine are the DRMAA terms for CPU and Host). The NumberOfProcesses is to be interpreted as exact number by the backend. The ProcessesPerXYZ are to be interpreted as upper bounds by the backend. So, for example, one could specify a 16 process MPICH job as SPMDVariation = MPICH NumberOfProcesses = 16 ProcessesPerCore = 2 That would allow on to run on a 2-way QuadCore host, placing two processes on each of the 8 cores. It would also allow to run on two 4-way SingleCore hosts, placing one process on each core. Well, try to specify that with the current attributes - very difficult! So, the questions we have is - does the above proposal indeed capture the SAGA MPI use cases? - if not, which use cases are not covered? How can they be addressed? To be clear: this is not intented to be an errata to the current SAGA spec, but rather a consideration for the next SAGA Version... Thanks, Andre. -- Nothing is ever easy.

2 2

Re: [SAGA-RG] quick poll: SPMD attributes
by Andre Merzky 10 Dec '09

10 Dec '09

Quoting [Peter Tr?ger] (Dec 10 2009): > > > > SPMDVariation > > NumberOfProcesses > > ProcessesPerMachine > > ProcessesPerSlot > > ProcessesPerCore > > > >(Slot and Machine are the DRMAA terms for CPU and Host). > > Small correction: DRMAAv2 has the concept machine, socket (not slot), > and core. Socket is the new term for CPU in most of the multi-core > publications. So, a 2-way SMP system with 2 Intel QuadCore processors > has: Argh, sorry for the mixup! Andre. > machineSockets = 2 > machineCoresPerSocket = 4 > > The example is still correct then: > > >So, for example, one could specify a 16 process MPICH job as > > > > SPMDVariation = MPICH > > NumberOfProcesses = 16 > > ProcessesPerCore = 2 > > > >That would allow on to run on a 2-way QuadCore host, placing two > >processes on each of the 8 cores. > > Best, > Peter. > -- Nothing is ever easy.

1 0

Re: [SAGA-RG] Python SAGA language bindings: how to express explicit object destruction?
by Thilo Kielmann 09 Dec '09

09 Dec '09

(Added the SAGA mailing list to this thread.) My two cents are: looks like in languages wirth garbage collection (Java and also Python), we need to have a close() method to achieve a side effect on the remote middleware. If it is the right thing for Java, then it is also the right thing for Python. Thilo On Dec 9, 2009, at 3:53 PM, Mathijs den Burger wrote: > Hi all, > > We may have overlooked something in the Python SAGA language bindings: > how to express explicit object destruction. > > The root problem is that many backends have to be stopped > explicitly. An > example is the XtreemOS job submission system, but many others exist > as > well. > > For cleanup, SAGA defines destructors. However, this does not work in > languages that do not support explicit object destruction (e.g. Java). > The Java language bindings therefore added the method session.close(), > which explicitly closes all running middleware that uses that session. > > Python contains a 'del' statement. However, that is not the same as a > 'delete' in C++. The 'del' in Python only decreases a refcount. > Relying > on Python's destructors (e.g. the __del__ methods in an object) can > therefore be tricky [1], and makes it not very well suited to shutdown > middleware. > > So: should we add a session.close() method to the Python language > bindings as well? > > best, > -Mathijs > > > [1] > http://www.electricmonk.nl/log/2008/07/07/python-destructor-and-garbage-col… > > > -- Thilo Kielmann http://www.cs.vu.nl/~kielmann/

2 1

Face-to-Face Meeting
by Andre Merzky 09 Dec '09

09 Dec '09

[ sorry for cross-posting ] Hi DRMAA group, Hi SAGA group, at OGF27, we discussed a joined 2-day face-to-face meeting between the SAGA and DRMAA groups, with focus on the upcoming DRMAA.v2 specification. We expect a SAGA DRMAA extension to be specified in lockstep -- thus the cross-group participation. At the moment, we plan to have that F2F meeting in Berlin (thanks to Alexander for agreeing to host!). We created a doodle form to poll for possible dates - so for all those who intent to participate in the F2F, please add your availability at: http://www.doodle.com/m4z7fy888yndp7f7 The F2F is open of course, but we may have some space constraints - so please *do* fill the doodle soon, so that we can have a reasonable estimate about participation. Cheers, Andre -- Nothing is ever easy.

2 4