TeraGrid Roaming Requirements RAT

1. TeraGrid Roaming Requirements RAT

2. Project Charter Purpose(voted on September 13th 2009) • Understanding how users use roaming today • Understanding what, if anything, prevents users from taking more advantage of roaming today • Identify if roaming is effective, in its current implementation. • Document additional roaming requirements of the user community • Document requirements/constraints from RPs in supporting roaming. • Identify users that aren’t using roaming but could benefit from it • Gather requirements, document findings and suggest changes to the TG Roaming policy • Develop a coherent communications plan to communicate: the RAT’s results; the “to be” operations posture with respect to roaming; and how this posture will meet users’ needs. Additionally, develop a plan to insure that current and potential users are aware of these roaming (or roaming-like) options.

3. Agreements per the TeraGrid September 2009 Quarterly Meeting • Allow any allocated project to add, at will, a startup level allocation on any TeraGrid resource. Such additions can be handled as transfers or as Supplemental requests and, up to the local startup limits, will be approved with RP notification and without TRAC review. This process is already in place and effective. We will set a goal of 48 hours from transfer request to completed action (transfer complete, account activated, or communication back to PI and requestor if possible). • Projects wishing to explore other resources above the startup level will do so via a POP transfer request or Supplemental request. Significant transfer levels require RP confirmation; significant supplements will be reviewed by the TRAC.  • All Campus Champion allocations will receive a “Campus Champions default allocation” (or perhaps alternately called an “Explorer Pack” allocation) consisting of a startup level allocation on every TG resource, including those resource that are not now “Roaming.” The specific branding of this service may be “Campus Champion Default Allocation” or Campus Champion Explorer Pack” , or some other name. Complete consensus on this issue may not have been reached yet. • TG will develop and execute a communication plan to describe this policy, describe the change, and encourage Roaming-like usage.

4. RAT Approach • Identify the target audience of a roaming user survey • Create/execute a User Survey • Form survey results into options for additional abilities • RP Agreement on options

5. The User Survey Target Populations • People that had requested or received roaming allocations in the past 3 years • Campus Champions • Science Gateways • Anyone else we could think to ask • Total of 140 people identified

6. Executing the survey and response rates • We matched the people to be surveyed with contact people from the RAT, Campus Champions, ASTA, and User Services • The people to be surveyed were asked by their contact person to complete the survey and in some cases helped fill out the survey. • 64 responses out of 140 or 46%

7. Survey Documents The following documents can be found on the TeraGrid Roaming Requirements RAT WIKI Page (http://www.teragridforum.org/mediawiki/index.php?title=Roaming_Requirements) • User Survey Summary Report – a report from Survey Monkey of the questions and responses. This document is most useful for viewing the statistics on questions with a finite set of answers. • User Survey Detailed Report - This is a complete spreadsheet of all of the questions and responses to the survey. It has a lot of information and is best used as either the initial source for filtering out information or for going back and getting detailed info on a specific issue. • User Survey Responses to Open Questions – Since the Detailed Report has so much information, this document was created to list only the responses to the open text portions of the survey. There are four tabs, one for each of the open comment fields of the survey. This is the best place to find details on suggestions or problems.

8. Survey Results Would your research benefit from the use of multiple TeraGrid systems as opposed to a single TeraGrid system? Yes - 68%, No – 8%, Not Sure – 24% Can your code be used on multiple architectures? Yes - 86%, No – 5%, Not Sure 9% Can you predict how much time you would want on each machine? Yes – 44%, No – 37%, Fail-over if main machine is down – 7%, Other 12% (Responses in a separate document) Do you need assistance to use multiple sites? Yes 42%, No - 58% How would access to multiple resources help your work? (Multiple choice) • Flexibility - search for shortest queue (site shopping) 65% • Benchmarking code across many resources 52% • Flexibility - submit to multiple resources simultaneously (multi- site run) 35% • Exploratory work 31% • I'm a campus champion, and I want the ability to help campus users explore different resources 22% • Flexibility - co-locate computing with data location (move computing to data) 22% • Other 15% (Responses in separate document) • None of these would be of use to me. 0% Do you know which architecture best suits your application? Yes 50%, No 15%, Not Sure 35% Do you need to tune/test your application on multiple architectures? Yes 60%, No – 40%

9. Survey Results - Continued How critical is the ability to tune/test your application on multiple architectures? (1 being not very important to 10 being extremely important) 1. 0% 2. 0% 3. 3% 4. 3% 5. 23% 6. 16% 7. 29% 8. 7% 9. 7% 10. 13% Are you a current TeraGrid user? Yes 92%, No – 8% Have you requested or received a roaming allocations in the past? • Yes, I requested and received a roaming allocation 75% • No 10% • Yes, I received a roaming allocation that I had not requested 8% • Yes, I requested but did not receive a roaming allocation 6% Please explain what happened with the roaming allocation or request. 33 Responded (Responses in separate document)

10. Survey Results - Continued In what phase of the process did you know what resources your application needed? • Before the start-up allocation 46% • After the start-up allocation 32% • Before the Quarterly TRAC allocation 16% • After the Quarterly TRAC allocation 7% Do you need to share SUs across multiple resources? Yes - 66%, No – 34% Do you have any suggestions on how TeraGrid could accommodate multi-site allocations and how those allocations might be more useful to TeraGrid’s user population(s)? 26 Responded (Responses in separate document)

11. Conclusions • A significant portion of users surveyed do not know what resources they need until after their start-up allocation. However, most do know what resources they need before the TRAC allocation. • Roaming in production is not justified • Need to identify a way to help users determine the most appropriate resources before the TRAC allocation. • Make sure catalog of resources is kept up to date • User Services will work with these individuals to help them determine the resources they should request • Need to communicate the September 2009 Quarterly Meeting agreements and any changes agreed to out of this RAT

12. Conclusions (RP Agreement item 1 of 2) • We need an agreement on the time limit for the RP confirmation of part B of the Sept 2009 quarterly agreement. (24 hours?) • Part B Projects wishing to explore other resources above the startup level will do so via a POP transfer request or Supplemental request. Significant transfer levels require RP confirmation; significant supplements will be reviewed by the TRAC. 

13. Conclusions (RP Agreement item 2 of 2) TeraGrid Architecture Evaluation (TAE) Allocation • This resource allocation will offer users an opportunity, and a maximum of 30,000 SUs, to identify the best resources for their future production computational work. All RPs and all compute resources must be part of the resource pool, with exceptions only for storage systems and VM hosting systems. In effect, this will behave like TeraGrid Roaming, with the following policy modifications: • RP may restrict local allocation to 10% of SUs request, in local SUs—i.e., 3,000 local SUs max on a 30k SU TAE award. • RPs may restrict access to queues for these allocations (low-priority only, debug only, no long queues, no special/full-machine queues) • RPs may choose to restrict access to certain software applications. E.g., licensed packages like Gaussian, or common/popular applications for which scaling/performance info is readily available (e.g. from AUS). • RPs may choose to restrict access to long-term storage for these allocations. • RPs may choose to exclude a given resource from Evaluation use on a given project, if that project also has a specific allocation for the resource.

14. THE RAT TEAM(In order of attendance to meetings) • Mike Northrop (Lead) • Kim Dillman • Jim Lupo • Amitava Majumdar • David Hart • John Cobb • Bruce Loftis • Elizabeth Leake • Carol Song • Dan Katz • Jay Alameda • Patricia Kovatch • S. Kay Hunt • Scott Lathrop • Kent Milfeld • Matthew Woitaszek • Praveen Nuthulapati • Sergiu Sanielevici