Participants
- no one from ARC until 16:00 - 16:15
- Etienne
- Luigi
- Mark
- Tim / Steve
- Morris
- Johannes
- Emmanouil
- Oxana


Proposed agenda:

(a)
Debrief notes from the last meeting

Reminder for use case/requirements presenters at OGF30!



(b)
Status: PGI Use Cases Document - Debrief Comments and Editor submission

+ new use case request SAGA via GIN

+ new use case request DGSI 


(A)
Integrate now - one week more
- deadline harsh - use case must be provided to either me or PGI  on Monday and Tuesday to be integrated.


(B)
1 Document, 2 new use cases
Integreate after pc (30days) + 10 days integration + (30 days)


(C)
We have reviewed the use cases already several weeks - there is no further addition in the version 1 of the document



### AGREEMENT --> OPTION C
- because we can have another round of use case documents
- time consuming internal review process already
- but it is necessary to go on to keep our focus for the first iteration
- SAGA, DGSI, probably an OSG use case - first documents, raising awareness


comment Etienne:
- PGI use cases- workflow is out of scope, but functional submission to one node might be interest

- committment and never show up
- better a smaller group than ask everybody who might be interested
- clearly production grids 

Mark: OGF Policy... if only minor (minor additions), if changes are substantial (new sections)
- use cases new sections
- through the public period again...
- new use case drives new use case requirements...

TBD: Morris: Reject the requests now & discuss how to integrate later


(c)
Discussions on job descriptions based on use cases

Preparation and prioritization for specification & OGF30 presentations.

TBD: Collecting the job description requirements and prioritize based on multiple use cases requiring them

TBD: If it is not working then we prioritize whole use cases

TBD: Address Etienne EMail shortly




###
# Emmanouuil: use case mappings to requirements
###

Use Case: Virtual Physiological Human (VPH)
- use of SAGA to submit jobs to Globus 5
- minor data-change

[OK]
101 - The Job Description document specification MUST permit the Client to request automatic data stage-in and stage-out
 	
( GIN 	 Job Description, Activity Management 	   	 Agreed YES 	 2010-04-28)

# understandable

[OK]
103 - The Job Description document specification MUST permit the Client to request that at specified Activity states, 
the Execution service sets the Activity on 'Hold' 
Overall yes agreement

# Where is hold? workflow orchestration, spawn processes and wait data to be staged, therefore they need that

[OK]
105 - Job Description supports:
1) Service-directed data-staging (i.e. specify data-stagings),
2) Client-initiated data-staging (i.e. specify data-staging but service will do nothing, only control whether files 
existing)
3) Manual data-staging (i.e. no specification of data-staging elements)
Agreed yes

# Why client-initiated data-staging is needed? (not manual) - We need more flexibility in data-staging (SAGA client is 
initiating this)
# Oxana: All together a tough requirement - technical might be different realized


[OK]
108 	 Job Description comes with support for requesting multi-processor Activities 
(for example: threads/node, network topology, task/core mappings, multi-threading and such like) 	 
Strawman functionality 	 Job Description 	  	 Agreed YES

# Why is that required? When the use case is using MPI you would like to get efficiency, NAMD (molecular dynamics)



###
# Etienne: use case mappings to requirements
###

use case: Marshal activities
- service grid via bridge accessible desktop grids

[OK]
100 - The Job Description document MUST reference all grid entities in conformance to the GLUE specification
Agreed yes

# Why? The only method to permit the execution service to understand user requirements and match the system...