Hi, We had a discussion on the last phone meeting about the ExecutionHost in the ComputeUsageBlock (section 5.5 in http://redmine.ogf.org/dmsf_files/12990?download= ). At the beginning of writing up the UR-2.0 draft we decided that we should go for a flat structure of elements in the various usage blocks. While this has been a good approach for most of the elements, it has turned a bit tricky for the ExecutionHost. Constraints: - The ExecutionHost needs to support accounting for parallel jobs. - Parallel jobs means multiple hostnames. - Parallel jobs on multicore hosts means multiple process IDs per host - Multiple hosts means multiple benchmarks. - The process IDs and benchmarks are associated with specific hosts. - In XML you cannot have the same attribute multiple times in the same element. As far as I can see, there are two viable ways to meet these constraints. 1) What is already in the draft. ExecutionHost is a container for HostName, ProcessID and Benhmark. You can have multiple ExecutionBlocks per ComputeUsageBlock. You can have multiple ProcessIDs per ExecutionHost, and one HostName and one Benchmark. This meets all the constraints but means that the ComputeUsageBlock is not flat. 2) ExecutionHost is a string containing the hostname, and there are separate elements for ProcessID and Benchmark. You can have multiple ComputeUsageBlocks, one per host. There can only be one ExecutionHost per ComputeUsageBlock, but multiple ProcessIDs (all corresponding to the one ExecutionHost). The ComputeUsageBlocks can be identified (if identification is needed) as belonging to the same job e.g. by them having the same start time and, time wall time and cpu time. The Node element will always be 1 and should be removed. The number of processors used by the job can be found by summing the Processor elements in each of the This meets all the constraints and gives a flat structure in the ComputeUsageBlocks but means more work for parsers (and more room for mistakes) when accounting for parallel jobs. What do you think? Any opinions? cheers, Jon