6069 2008-05-08 09:22 JDD documentation issues 2012-09-05 13:44:48 1 1 1 Unclassified GRAM Doc 4.0.7 All All RESOLVED WONTFIX http://www.globus.org/toolkit/docs/4.0/execution/wsgram/schemas/gram_job_description.html P3 normal --- 1 swhite@aip.de feller@mcs.anl.gov cristina@isi.edu feller@mcs.anl.gov smartin@mcs.anl.gov swhite@aip.de 2008-05-08 09:22:35 Hi, While much of your documentation is quite helpful, I noticed that the entries for several of the JDD Elements are incomplete or misleading. I am aware that you meant to move to JSDL, but you should check that the corresponding entries for JSDL are clear as well. argument ======== "A command line argument for the executable. Each argument is a separate element within the job description. Spaces and quotes within an argument will preserved literally." This only tells part of the story. It needs to be stressed that one argument section per executable argument token must be. An example is in order. To execute a shell script, one needs <executable>/bin/sh</executable> <argument>-c</argument> <argument>echo "Ran script!"</argument> minMemory ========= "Explicitly set the minimum amount of memory for a single execution of the executable. The units is in Megabytes. The value will go through an atoi() conversion in order to get an integer. If the GRAM scheduler cannot set minMemory, then an error will be returned." The phrase "for a single execution of the executable" perhaps would be better said as "per executable process". The last statement appears to be false. I never saw it fail, after setting minMemory to various values. Maybe it should say "might return an error, then again, maybe not" Obvious question: when submitting to a non-shared-memory host with multiple compute cores per node, will this setting alter the number of processes per node to obtain the requested memory? (evidently not) maxMemory ========= "Explicitly set the maximum amount of memory for a single execution of the executable. The units is in Megabytes. The value will go through an atoi() conversion in order to get an integer. If the GRAM scheduler cannot set maxMemory, then an error will be returned." This wording is bewildering, when compared with that of minMemory. I think one of them is meant to be a contract with a job management system to aid in efficient allocation (like maxWallTime), and the other was originally meant as a means of adjusting the amount of memory actually allocated to each process. But I can't verify that they are really implemented this way. Generally, it would be good to make a notation about the function of the elements: which elements constitute such contracts with a job manager, and which actually alter something in the run environment. maxWalltime maxTime =========== distinction bewildering. The former says "walltime", while the latter only says "walltime or cputime", but since cputime is always going to be less than walltime... don't the do both do the same thing? feller@mcs.anl.gov 2008-05-16 11:33:07 Updated the documentation for the argument element, and replaced "for a single execution of the executable" by "per executable process" in 4.0 and 4.2 docs. The other items seem to need some more care. smartin@mcs.anl.gov 2012-09-05 13:44:48 Doing some bugzilla cleanup... Resolving old GRAM3 and GRAM4 issues that are no longer relevant since we've moved on to GRAM5. Also, we're now tracking issue in jira. Any new issues should be added here: http://jira.globus.org/secure/VersionBoard.jspa?selectedProjectId=10363