On Apr 20, Andreas Savva loaded a tape reading: ...
CPUcount is defined as the number of CPUs you want the resource to have. So it is the latter one.
Unfortunately, this answer does not clarify (for me) the point Chris is asking. I would think we want to express the number of CPUs allocated from a resource and a far secondary concern would be the total number of CPUs in the resource (including the ones not allocated to us). By saying "the latter", you are saying it is this total CPUs including unallocated ones. Do you really mean that? I think I can agree with Chris's statement that this is a sufficient set of terms (spelled out to be unambiguous): 1. number of CPUs allocated per resource (a range value) 2. number of allocated resources (a range value) 3. total number of CPUs allocated to job (a range value) given that draft 17 shows a multiplicity 0-1 for Resource, I think all three of these should be given here and left out of the Application section. I also think tileSize is redundant with these three, as Chris suggested. If we want the fourth: 4. total number of CPUs in allocated resource including unallocated CPUs (idle or allocated to other jobs) Then we should be blatantly obvious about the difference, e.g. jsdl:PerResourceAllocatedCPUs jsdl:PerResourceInstalledCPUs jsdl:TotalJobAllocatedCPUs or something like that! If we were in fact going to allow multiple Resource elements (to express heterogeneous resource mixes), it would be awkward to put the total number of CPUs allocated within a Resource element. It would be better to keep that somewhere else which obviously has "global" scope within the job definition. In fact, this applies to all "global metrics" like total RAM, etc. karl -- Karl Czajkowski karlcz@univa.com