adapter should mkdir working_directory?
Hello, I'm Yutaka Kawai @KEK, woriking for SAGA adapter implementation for NAREGI and PBS. I have a question about adapter behavior for working_directory. If a user specify a working_directory in the job description but the directory does not exist, what is the suitable adapter's behavior? Should the adapter throw "DoesNotExist"? or mkdir the directory for the job? In the case of the current NAREGI, it mkdir the working directory in constructing its WFML. On the other hand, PBS does not. I want to decide whether adapters absorb the difference or not. Could you tell me the case of LFC also? Regards, Yutaka -- Yutaka Kawai 河井 裕 High Energy Accelerator Research Organization (KEK) Computing Research Center Tel: +81-(0)29-864-5200 (Ext: 4503) Fax: +81-(0)29-864-4402 E-Mail : yutaka.kawai@kek.jp
I'm Yutaka Kawai @KEK, woriking for SAGA adapter implementation for NAREGI and PBS.
I have a question about adapter behavior for working_directory. If a user specify a working_directory in the job description but the directory does not exist, what is the suitable adapter's behavior? Should the adapter throw "DoesNotExist"? or mkdir the directory for the job? In the case of the current NAREGI, it mkdir the working directory in constructing its WFML. On the other hand, PBS does not. I want to decide whether adapters absorb the difference or not. Could you tell me the case of LFC also?
I'm not aware of any rule implemented by all existing job adaptors, but I think creating the directory is a viable solution as it improves the users experience and makes SAGA easier to use. Regards Hartmut
Quoting [Hartmut Kaiser] (Jul 10 2009):
I'm Yutaka Kawai @KEK, woriking for SAGA adapter implementation for NAREGI and PBS.
I have a question about adapter behavior for working_directory. If a user specify a working_directory in the job description but the directory does not exist, what is the suitable adapter's behavior? Should the adapter throw "DoesNotExist"? or mkdir the directory for the job? In the case of the current NAREGI, it mkdir the working directory in constructing its WFML. On the other hand, PBS does not. I want to decide whether adapters absorb the difference or not. Could you tell me the case of LFC also?
I'm not aware of any rule implemented by all existing job adaptors, but I think creating the directory is a viable solution as it improves the users experience and makes SAGA easier to use.
+1 Cheers, Andre. -- Nothing is ever easy.
This sounds like reasonable behavior. However, it MUST be documented. And I wonder if this is something that could be implementation-specific or better not? Do we have to add a gazillion of "what happens if" in the SAGA spec??? If not, will SAGA applications ever be portable across implementations??? Thilo On Fri, Jul 10, 2009 at 06:39:18AM +0200, Andre Merzky wrote:
From: Andre Merzky <andre@merzky.net> To: Hartmut Kaiser <hkaiser@cct.lsu.edu> Cc: 'SAGA RG' <saga-rg@ogf.org> Subject: Re: [SAGA-RG] adapter should mkdir working_directory?
Quoting [Hartmut Kaiser] (Jul 10 2009):
I'm Yutaka Kawai @KEK, woriking for SAGA adapter implementation for NAREGI and PBS.
I have a question about adapter behavior for working_directory. If a user specify a working_directory in the job description but the directory does not exist, what is the suitable adapter's behavior? Should the adapter throw "DoesNotExist"? or mkdir the directory for the job? In the case of the current NAREGI, it mkdir the working directory in constructing its WFML. On the other hand, PBS does not. I want to decide whether adapters absorb the difference or not. Could you tell me the case of LFC also?
I'm not aware of any rule implemented by all existing job adaptors, but I think creating the directory is a viable solution as it improves the users experience and makes SAGA easier to use.
+1
Cheers, Andre.
-- Nothing is ever easy. -- saga-rg mailing list saga-rg@ogf.org http://www.ogf.org/mailman/listinfo/saga-rg
-- Thilo Kielmann http://www.cs.vu.nl/~kielmann/
Quoting [Thilo Kielmann] (Jul 10 2009):
This sounds like reasonable behavior.
However, it MUST be documented. And I wonder if this is something that could be implementation-specific or better not? Do we have to add a gazillion of "what happens if" in the SAGA spec??? If not, will SAGA applications ever be portable across implementations???
The strategy so far has been to pinpoint semantics as tightly as possible, when there is agreement about the desired behaviour, and then require implementations to motivate and document when they deviate from that semantics. Seems reasonable in that case, too, I'd say? That strategy would make this an errata item. Best, Andre.
Thilo
On Fri, Jul 10, 2009 at 06:39:18AM +0200, Andre Merzky wrote:
From: Andre Merzky <andre@merzky.net> To: Hartmut Kaiser <hkaiser@cct.lsu.edu> Cc: 'SAGA RG' <saga-rg@ogf.org> Subject: Re: [SAGA-RG] adapter should mkdir working_directory?
Quoting [Hartmut Kaiser] (Jul 10 2009):
I'm Yutaka Kawai @KEK, woriking for SAGA adapter implementation for NAREGI and PBS.
I have a question about adapter behavior for working_directory. If a user specify a working_directory in the job description but the directory does not exist, what is the suitable adapter's behavior? Should the adapter throw "DoesNotExist"? or mkdir the directory for the job? In the case of the current NAREGI, it mkdir the working directory in constructing its WFML. On the other hand, PBS does not. I want to decide whether adapters absorb the difference or not. Could you tell me the case of LFC also?
I'm not aware of any rule implemented by all existing job adaptors, but I think creating the directory is a viable solution as it improves the users experience and makes SAGA easier to use.
+1
Cheers, Andre.
-- Nothing is ever easy. -- saga-rg mailing list saga-rg@ogf.org http://www.ogf.org/mailman/listinfo/saga-rg -- Nothing is ever easy.
Thank you for your comments. Then, I will try to implement the mkdir woriking dir behavior for PBS adapter also and keep memo for its document according to SAGA spec. Regards, Yutaka Yutaka Kawai ?? ? High Energy Accelerator Research Organization (KEK) Computing Research Center Tel: +81-(0)29-864-5200 (Ext: 4503) Fax: +81-(0)29-864-4402 E-Mail : yutaka.kawai@kek.jp Andre Merzky wrote:
Quoting [Thilo Kielmann] (Jul 10 2009):
This sounds like reasonable behavior.
However, it MUST be documented. And I wonder if this is something that could be implementation-specific or better not? Do we have to add a gazillion of "what happens if" in the SAGA spec??? If not, will SAGA applications ever be portable across implementations???
The strategy so far has been to pinpoint semantics as tightly as possible, when there is agreement about the desired behaviour, and then require implementations to motivate and document when they deviate from that semantics. Seems reasonable in that case, too, I'd say? That strategy would make this an errata item.
Best, Andre.
Thilo
On Fri, Jul 10, 2009 at 06:39:18AM +0200, Andre Merzky wrote:
From: Andre Merzky <andre@merzky.net> To: Hartmut Kaiser <hkaiser@cct.lsu.edu> Cc: 'SAGA RG' <saga-rg@ogf.org> Subject: Re: [SAGA-RG] adapter should mkdir working_directory?
Quoting [Hartmut Kaiser] (Jul 10 2009):
I'm Yutaka Kawai @KEK, woriking for SAGA adapter implementation for NAREGI and PBS.
I have a question about adapter behavior for working_directory. If a user specify a working_directory in the job description but the directory does not exist, what is the suitable adapter's behavior? Should the adapter throw "DoesNotExist"? or mkdir the directory for the job? In the case of the current NAREGI, it mkdir the working directory in constructing its WFML. On the other hand, PBS does not. I want to decide whether adapters absorb the difference or not. Could you tell me the case of LFC also?
I'm not aware of any rule implemented by all existing job adaptors, but I think creating the directory is a viable solution as it improves the users experience and makes SAGA easier to use.
+1
Cheers, Andre.
-- Nothing is ever easy. -- saga-rg mailing list saga-rg@ogf.org http://www.ogf.org/mailman/listinfo/saga-rg
Hello, SAGA C++ API has saga::job::job::get_stdout() and get_stderr(). However, the SAGA Python API Documentation (http://saga.cct.lsu.edu/python/apidoc/) seems that Python API does not have those methods. Could you tell me why you do not implement them for Python? If you know some alternative ways to get such standard output/error stream by Python, please tell me. Regards, Yutaka Yutaka Kawai 河井 裕 High Energy Accelerator Research Organization (KEK) Computing Research Center Tel: +81-(0)29-864-5200 (Ext: 4503) Fax: +81-(0)29-864-4402 E-Mail : yutaka.kawai@kek.jp
SAGA C++ API has saga::job::job::get_stdout() and get_stderr(). However, the SAGA Python API Documentation (http://saga.cct.lsu.edu/python/apidoc/) seems that Python API does not have those methods. Could you tell me why you do not implement them for Python? If you know some alternative ways to get such standard output/error stream by Python, please tell me.
These are just not implemented yet. And as the docs are generated directly from the code the functions are not documented either. That's for no particular reason other than the Python bindings are still in beta status. I opened a ticket reminding us to implement those. Thanks! Regards Hartmut
Dear Hartmut, Thank you for your action. I'm looking forward to the implementation. Best regards, Yutaka Yutaka Kawai ?? ? High Energy Accelerator Research Organization (KEK) Computing Research Center Tel: +81-(0)29-864-5200 (Ext: 4503) Fax: +81-(0)29-864-4402 E-Mail : yutaka.kawai@kek.jp Hartmut Kaiser wrote:
SAGA C++ API has saga::job::job::get_stdout() and get_stderr(). However, the SAGA Python API Documentation (http://saga.cct.lsu.edu/python/apidoc/) seems that Python API does not have those methods. Could you tell me why you do not implement them for Python? If you know some alternative ways to get such standard output/error stream by Python, please tell me.
These are just not implemented yet. And as the docs are generated directly from the code the functions are not documented either. That's for no particular reason other than the Python bindings are still in beta status. I opened a ticket reminding us to implement those.
Thanks! Regards Hartmut
participants (4)
-
Andre Merzky -
Hartmut Kaiser -
Thilo Kielmann -
Yutaka Kawai