1. Background .............................................................................................................................. 1 2. Summary of Recommendations ............................................................................................... 1 3. xRAC Committee and Meeting Procedures ............................................................................. 2 4. Lowering Barriers to Entry ...................................................................................................... 4 5. Resources and Resource Providers .......................................................................................... 7 6. Communications .................................................................................................................... 10 1. Background The policies and procedures for allocating NSF’s cyberinfrastructure resources have evolved over more than 20 years of serving the national user community under the original centers program, the PACI partnerships, and now the TeraGrid. A TeraGrid Requirements Analysis Team (RAT) was formed in March 2008 to review and update the current policies based on community feedback, an increasing diversity of resources, and the impact of NSF’s Track 2 and Track 1 systems. One challenge is how best to apply the merit-review xRAC process to maximize scientific impact in a range of environments where resources are either over-requested or under-requested. The objectives are to optimize the allocations process to adapt to resource availability and to ensure we fully capitalize on emerging opportunities as additional resources become available. This may include efforts within TeraGrid to facilitate increased access to the resources (while maintaining proposal standards and scientific impact), changes in the evaluation process by the xRAC, and changes in how TeraGrid sites implement recommendations from the xRAC. There should emerge a consistent competitive review process that can adapt to a full range of allocation environments. While the focus is on compute systems, the recommendations should also address novel resource classes. In addition, a set of issues have emerged that require policy-level decisions and TeraGrid consensus, both to adapt policies to the current environment and to permit TeraGrid to move forward with such activities as the Core Services 2 efforts, which in part implements these allocation policies. The RAT is producing two documents to capture its recommendations. A new version of the “Grant Proposal Guide” for TeraGrid allocations will be published; this is a public document that describes the allocations policies and process for users, reviewers and funding agencies. The second deliverable is this document, an internal TeraGrid team document, which focuses on recommended actions for TeraGrid team members. 2. Summary of Recommendations The results of the RAT discussions can be categorized into four sets of recommendations addressing aspects of the allocations process. The specific recommendations include changes to policy, changes to implementation of the procedures, and TeraGrid-wide planning and communications. Formalize, adjust, and document the xRAC processes and procedures. With a growing user base, increasing numbers of proposals and resource providers, some aspects of the xRAC process need to be formalized and made more transparent to the TeraGrid and the user community. While an overhaul is not recommended, some modifications are important to maintaining the integrity of and confidence in the process by xRAC members, the user community, and TeraGrid Resource Providers (RPs). Take steps to reduce the real and perceived barriers to entry for the xRAC process. The current process is based on the premise of resource scarcity. Policies need to be adjusted so that the process can adapt to situations of significant resource availability. Implementation of the proposal submission process must also be streamlined to lower perceived barriers, reduce confusion, and minimize complexity. The burdens here should be borne by the TeraGrid, not placed on current and potential users. Resolve and clarify various policies related to the integration and presentation of TeraGrid resources. TeraGrid RPs have a great deal of latitude in choosing which resources to make available to the allocations process—and how to make them available. Some limits and policies need to be defined to balance RP flexibility with the equally important goals of simplifying the system for the user community and working within the limits of the underlying TeraGrid infrastructure. Improve communications about resources and allocations. A number of opportunities exist to better communicate with the current and potential user community about the availability of resources and about the process itself. Communications can help increase demand for resources and lower perceived barriers to entry. In general, we are also supportive of the implementation recommendations detailed in the Core Services 2.0 vision document, where they do not explicitly contradict the RAT recommendations, as changes that will improve procedures for users and contribute to lowering the real or perceived barriers to entering the TeraGrid user community. The remainder of this document is organized according to these broad categories, with numerous specific recommendations detailed in each section. 3. xRAC Committee and Meeting Procedures In large part, the xRAC process has served the NSF and the NSF-supported cyberinfrastructure RPs well for nearly 20 years, and we see no need to significantly change the process. However, because of the expanding user community, the growing number of RPs and resources, and the evolution of the TeraGrid, there are some changes needed to formalize the process. In addition to the specific changes below, we recommend that policies and procedures for the xRAC committee selection and meetings be documented and posted on the TeraGrid Web site. 1) xRAC procedures when resources are under-requested or under-allocated No substantive changes to xRAC procedures are policies are required for under-request or underallocated resources. We do recommend that the xRAC Coordinator begin each xRAC meeting with a summary of resource availability and request levels, identifying resources that have been either significantly over-requested and under-requested, as well as the level of total requests to the total available SUs. The xRAC can use this information as context for their deliberations. We expect that the xRAC will reduce awards less significantly and consistently across all proposals when total available SUs exceed or meet total requests and will apply stricter standards consistently across all proposals when total requested SUs exceeds those available. Recommendations for dealing with under-allocated resources are described in the Resource section (for discretionary allocations) and in the Communications section. 2) Broaden the membership selection process and clarify term limits We recommend that the xRAC remain autonomous so as to preserve independent merit-review of TeraGrid allocations proposals. Given the breadth of disciplines permissible for allocations proposals, the current number of ~40 members seems to be an appropriate size to cover the domains yet have meaningful discussions. To ensure sufficient experience and to make the recruitment process manageable, the term limit of an xRAC member is three years. Members may have their terms extended up to six months if deemed necessary by the Allocations Coordinator. Previous members can rejoin after a minimum 2-year hiatus. The Allocations Coordinator should solicit nominations for members from the following groups: NSF OCI program officers; program areas in NSF domain directorates or other agencies (requests for nominations made via OCI); the TeraGrid Science Advisory Board; departing xRAC members; and the TeraGrid Forum. These reminders should include information about the domains for which there is the most urgent need. Nominees should be recognized for and/or actively engaged in computationally oriented research in a discipline. Candidates need not be xRAC awardees or even eligible to apply for an xRAC award (e.g. FFRDC staff). Candidates must be able to spend substantial time reviewing proposals in a timely way and participating in quarterly meetings. In addition to domain coverage, it is desirable to maintain breadth of geographical and institutional participation, as well as diversity considerations within the committee. The TG Allocations Coordinator will manage the process by which candidates are recruited to serve on the committee within the Allocations Working Group. 3) Adopt formal conflict-of-interest policy for reviewers We recommend that TeraGrid adopt the attached conflict-of-interest policy for reviewers. In addition, we recommend changing the proposal format to permit PIs to name individuals who should not review their proposal. This policy should be provided to all prospective candidate reviewers and should be incorporated by reference in the Allocations “Grant Proposal Guide.” 4) Method to select a chair of the xRAC meetings The chair’s duties are to facilitate the committee’s open discussion, ensure that the committee’s recommendations for each proposal are clearly summarized, and maintain a schedule to complete the committee’s work in a timely way. There are no special decision-making privileges of the chair, and there are no duties beyond the meeting itself. We recommend that, when possible, an NSF OCI program officer chair the xRAC meetings. When this is not possible, the Allocations Coordinator will open each meeting with a request for nominations (up to 3), and the members will elect their own chair. (Nominees should have attended at least two previous xRAC meetings.) 5) Caucus procedures Historically, in the evening prior to each LRAC and MRAC meeting, a “caucus” session is held in which reviewers assigned to each proposal discuss their independent reviews and seek to either obtain a consensus recommendation or identify the areas of disagreement for discussion with the full committee the following day. This is intended to facilitate the meeting workload—especially important as the number of proposals is approaching 100 per day. However, there have been concerns that this semi-private caucus procedure diminishes the open peer-review process and makes it difficult to enforce conflict-of-interest policies. We recommend that the caucus session be maintained, because it expedites the workload and does not need to diminish the openness of the peer-review process. We recommend that the purpose of the caucus be clearly explained to new members when they are recruited, and that it be made clear that there should be no pressure to reach consensus and that significant differences of opinion should be carried over to open debate with the full group the following day. In addition, to preserve conflict-of-interest rules, proposals in which an xRAC reviewer in attendance is a PI or co-PI will not be discussed at the caucus session; discussion will be deferred until the formal meeting. These guidelines should also be stated to the full group at the beginning of each caucus session. 6) Role of RP observers in xRAC meetings TeraGrid RPs are permitted to send, at their own expense, a single representative (“allocation officer”) to observe the xRAC meetings, provide information when requested by the xRAC during deliberations, and participate in post-meeting processes. Conflict-of-interest rules for these observers are detailed in the xRAC COI policy document. In addition to the RP representatives, the following persons are required to ensure the smooth functioning of the xRAC meetings: the xRAC Coordinator, the person responsible for meeting logistics, a TeraGrid GIG representative, and a TeraGrid allocations staff member. The conflictof-interest rules apply to the xRAC Coordinator and the TeraGrid GIG representative. 7) Improve the transparency and documentation of decisions made by the TeraGrid allocation officers to balance oversubscribed resources. If any resources are oversubscribed at the conclusion of the xRAC allocation recommendations, the xRAC Coordinator will convene all of the attending RP allocation officers and GIG participants to quickly assess whether alternate resources are available to satisfy the total allocations. If so, the xRAC will be adjourned, and the allocations officers will make reallocations with preference given to, in priority order, (a) (b) (c) (d) assigning allocations to alternate resources specified by the user in their proposal, re-assigning allocations to alternate resources with similar system architectures, retaining current users rather than assigning new users to over-subscribed resources, and allocating to sites where the user has the most previous experience. Users assigned to resources they did not request will be informed that this was done because the resource they requested was oversubscribed. If it is obvious that further cuts must be made or unclear to the allocations officers whether reallocations can satisfy the spirit of the xRAC recommendations, the xRAC will reconvene after the allocations officers make a best effort at re-allocations. The xRAC will be asked to identify the least meritorious proposals overall whose awards received a disproportionate level of SUs, with a charge of reducing such allocations until the total recommended awards can be satisfied by available SUs. The Allocations Coordinator will ensure that all changes are documented and available to the RPs. Specifically, formal copies of the allocations spreadsheet should be kept prior to and after the re-allocations process, and made available to NSF and TeraGrid team members upon request. 4. Lowering Barriers to Entry Some potential users who do not use TeraGrid resources perceive that it is difficult to enter the system for various reasons—e.g., the time from “idea-to-account” is too long, the proposal process subjects them to double jeopardy for accomplishing their scientific objectives, the proposal submission requirements are too complex, and so on. Particularly in times of resource availability, it is important to examine possible barriers to entry and recommend improvements to lower those barriers where appropriate and to better communicate the actual processes that exist and their rationale. 8) Enable more timely entry into the allocations process A common complaint amongst non-users of TeraGrid is that it takes too long to enter the allocations system, and we wish to address this issue while maintaining an equitable and effective allocations process. At the same time, we believe that the quarterly MRAC and semi-annual LRAC schedule serves the TeraGrid and the national community well and should be maintained. It is necessary to aggregate requests in order to set priorities and make zero-sum decisions. Six months seems reasonable for the large requests, with quarterly MRAC meetings providing a more frequent entry point for new users entering the system or for smaller users. In addition, more frequent meetings may place an undue burden on the volunteers who serve on the review committee. There are three recommendations to enable more timely entry. 1. Larger start-up awards should be provided, particularly when resources are available (see below). 2. The Core Services 2.0 efforts should work to shorten the timeframe between proposal submission and the creation of allocations. This would help minimize perceived timeliness issues and permit renewal proposals and progress reports to be submitted closer to the end of an allocation period. 3. Policy should be changed such that, upon submission of a proposal for the next appropriate MRAC or LRAC review cycle (at least a month prior to the stated deadline for that cycle), a new PI is eligible to request a Pre-Award allocation equal to the size of his/her request times the fraction of a year remaining until the start of the next allocation period. For example, a potential LRAC PI who prepares a proposal in July (for allocations to begin Oct. 1) with a request of 1 million SUs annually would be eligible to receive a pre-award allocation of up to 250,000 SUs (25% of the request, since there are 3 months until the Oct. 1 start date), subject to internal TeraGrid review. Depending on the circumstances (see below), the Allocations Coordinator may decide to grant the PreAward or ask xRAC members to review it off-cycle as a supplemental proposal. (As is true for other PIs, the “early submittal” PI is still permitted to modify his/her proposal up until the posted xRAC submission deadline.) [Can we expand this to cover the LRAC PI who has a proposal ready in April (prior to the June MRAC?) This is the biggest possible gap in the current process for new PIs.] The Pre-Award allocation depends on the availability of SUs on the resources requested (e.g. it would not be granted on a fully allocated system, crowding out previously allocated users). The Pre-Award allocation is subject to the same rules as other allocations; in particular, unused SUs are forfeited at the end of the allocation period. Since they are dependent on submission of an xRAC proposal, Pre-Award allocations cannot have Extensions. Pre-Award allocations are different from Advances in that the usage on a Pre-Award allocation is not deducted from the subsequent “New” allocation. 9) Increase available resources granted to new “startup” awards, and rename “DAC” accounts to “Startup Allocations” Given the increase in scale of the new Track 2 and Track 1 systems, we recommend that the size of the startup allocations granted by internal TeraGrid review to new users be increased for compute resources from the current 30K SUs to 100K SUs. With this change, the thresholds for DAC/MRAC/LRAC allocations would now be 100K and 500K SUs. We recommend that the MRAC/LRAC threshold be revisited after the September 2008 LRAC meeting based on analysis of the distribution of requests. RPs should, however, have the ability to limit the size of a start-up allocation for resources where 100k SUs would represent a prohibitively large fraction of the resource. The “startup” limit will be posted in the TeraGrid Resource Catalog for each resource, compute or otherwise. The TeraGrid reviewers and allocations staff will enforce these limits until Core Services 2.0 provides some implementation support. We also recommend that the DAC name be changed to “Startup Allocation” to better communicate its availability and intent. 10) Reduce confusion related to classification of proposals and proposal formats With resources ranging in size from several hundred processors to tens of thousands of cores, non-compute and compute resources that may not be allocated in SUs, and a complex set of allocations policies, the current entry into the proposal submission process confuses many users. Minimally, using fixed limits of SUs to categorize proposals is becoming less and less satisfactory. In the short term, we recommend that the initial entry screens for the POPS system be revised in light of the TeraGrid’s dynamic resource situation to better guide submitters to the appropriate meeting and to eliminate options that lead to dead ends. Because the submitter must identify a proposal’s category, the categorization should be based on a formula that is simple to understand and simple to calculate. In the longer term, it would be possible to hide a more complex formula from a proposal submitter and have POPS automatically categorize a request. For example, the category could be derived by a sum of the requests, each inversely scaled by a system’s total available SUs. At that point, the initial category selection (Start-up, Medium/Large) may only be important in terms of proposal requirements; namely, a start-up request does not require a formal proposal document, while larger requests would. As an alternatively, the allocations officers could apply subjective evaluations to distinguish start-up from MRAC/LRAC requests and even to define “medium” and “large” proposals on the fly to balance proposal traffic and xRAC workload. 11) Improve, clarify and simplify the POPS interface and proposal formats With respect to implementation, we recommend that the Core Services 2.0 activity make improvements to the POPS interface to reduce perceived barriers within the actual proposal submission process. In particular, we recommend that POPS no longer include the “resource attributes” that force users to answer a short Q&A about their proposed resource use. In practice, these attributes do not play a significant role in the xRAC deliberations, do not have enough consistency across resources to permit any quantitative analysis, and unduly complicate the user interface, especially with more than two dozen resources listed. Instead, we recommend that POPS provide easier access to resource descriptions and recommended use guidelines. Post examples of “excellent” proposals for each resource of class and clearly document within POPS the availability of these examples and the importance of addressing all requested information and evaluation criteria. We note that exemplary proposals are already available in POPS, but we encourage the Allocations WG to improve the POPS documentation pointing to these examples, expand the set to include newer resource classes, and to continuously update these examples as appropriate (e.g. for very large-scale requests in the Track 2 era). We also recommend that the xRAC process adopt a more formal proposal document(s) structure than that currently used to allow more consistent application of proposal length policies, clarify for users what is expected in proposals, and permit explicit collection of information needed by reviewers and by TeraGrid. Proposals should include the following required and optional documents, and POPS should restrict the different submission types to the appropriate documents: Main Proposal (required, page length varies depending on request size). This document should have the scientific background and objectives and the justification of the resource request. Within the main document, some flexibility can be permitted. However, a recommended sample template can be provided and/or recommended sections outlined. The focus of reviewers will be on this document. Progress Report (required for renewals and supplements, 5-page limit). Report on progress made during prior (current) allocation award period. This is the Main document for Progress Reports within Multi-Year Awards. Reviewers will consider this document for rating the successful use of prior allocation awards.) Publications Citing TeraGrid Support (required for renewals/progress reports of all kinds, including renewed “startups,” no page limit; N/A for new submissions). A list of bibliographic citations for publications in preparation, submitted, accepted, or published that benefitted from access to TeraGrid resources. Where implementation allows, bibliographic document formats (such as EndNote or BibTeX) could be supported for this attachment. This document is separated for TeraGrid metrics purposes. Special Requests (optional, 1-page limit). For Advanced Support Program justification and other special requests. Performance and Scaling of Codes (optional, 5-page limit). Information related to code performance and scaling, if the information cannot be fit within the main proposal document. This document should be used only to support claims made and used in the Main Proposal regarding the performance of relevant codes. Reviewers should not be required to closely scrutinize this document to evaluate the computational justification. References and Figures (optional, no limit). CVs (required for most submissions, perhaps optional for supplements and justifications). A single attachment that includes all submitted CVs. No other appendices will be permitted. This set of information corresponds to what is currently requested by xRAC reviewers, and largely what is provided in current submissions, but it does expand the total posted page count permissible for many types of submissions. However, the actual page counts for many current submissions far exceed the posted limits by use of the policy loophole that permits unlimited appendices. Posted guidance for each section should clearly state that many (smaller) projects are not expected to use the full page-limit in some sections— progress report and code scaling, in particular. With this clarified structure for submissions, we further recommend that submissions that exceed the posted page limits be returned to the submitters for revision or re-submission at a later date. By changing the structure, the xRAC Coordinator can quickly examine submissions for compliance. The page limits for the various sections can be determined without the need for examining the content. The non-compliance policy should be clearly posted with the submission guidelines. 5. Resources and Resource Providers As a coordination activity and resource federation, the TeraGrid offers many advantages to its users and a great deal of flexibility to RPs as far as the management of their resources. RP flexibility must be balanced against the potential for user confusion and the implementation of the coordination/federation capabilities. This section lists several recommendations to clarify this balance. In additions, RPs are encouraged to create incentive programs that facilitate scaling and more productive large-scale usage, to streamline the selection process (e.g., combining with other similar architectures as with the TeraGrid Clusters or Abe/Queen Bee), and to self-eliminate resources for which demand remains low. Because of the diversity of situations, we do not recommend a general TeraGrid-wide program or policy, but RPs could offer incentives to facilitate scaling studies and code improvements which would result in increased code efficiency and more productive large-scale usage. For example, LBNL has had a program whereby users are partially reimbursed for computer time spent in scaling studies and large-scale debugging and code improvements. 12) Simplify the access to Startup Allocations across TeraGrid RPs The following changes to the DAC process can be implemented almost immediately with little or no development effort from the Core Services team. We further recommend that the TeraGrid documentation be improved so that startup instructions aren’t buried—the ‘QuickStart’ guide to getting a Startup Allocation should be clearly and prominently identified for first-time users. The current DAC allocation “meetings” exist largely for historical reasons and because prior policies did not permit sufficient RP flexibility. Site-specific DACs do not serve user needs, force arbitrary decisions upon users, and create unnecessary proliferation of projects. We recommend that site-specific DACs be replaced with a set of four startup allocation types: 1. Roaming (Select this for access to most TeraGrid compute resources) The Roaming start-up option would give requesters only the option of asking for TeraGrid Roaming (and perhaps multi-site GPFS-WAN). 2. Specific Resources (Select this to request particular compute or storage resource(s)) The Specific Resources option would include the menu of all allocable resources. 3. Storage Only (Select this if you need only storage resources) Storage-only startups are OPTIONAL if storage-providing RPs feel the need for this option since there is no storage equivalent to TeraGrid Roaming. 4. Training (Select this for class instruction or training activities) Training start-up requests would present requesters only with the option of TG Roaming, or potentially, as proposed, a smaller subset of TG resources forming a “Training Grid.” As long as Training Grid allocations only appeared on training start-up projects and not in conjunction with Roaming or specific allocations, the current accounting system can support this option without modification. Review processes would need to be defined for the Specific and (if presented) Storage Only startup requests, although the current model for reviewing TeraGrid DACs could be applied to any or all of these sets of requests, with default reviewers on overlapping terms assigned to each proposal. The EOT area will appoint reviewers for Training startups. 13) The allocations policies must adapt to novel resource classes, including but not limited to storage and ASTA to improve adoption by the user community. No new general policies can be defined for arbitrary resources. However, RP or TeraGrid decision to introduce new resource classes must be required to include a discussion of (a) new proposal requirements, (b) new proposal evaluation criteria related to the new classes, and (c) the communication plan to inform users. (a) Defining new proposal requirements should involve representatives of the Core Services group in order to identify implementation mechanisms and the effort involved. (b) When new review criteria and associated policy changes are approved, the posted allocation “grants proposal guide” for users must be updated. (c) The communication plan should include an analysis of TeraGrid documentation updates required and the entity responsible (GIG or RP) for announcing the new resource class and associated proposal changes. To this end, we recommend a review of the recent policy documents for ASP and storage allocations, with respect to these three areas. The ASP policies did describe new proposal requirements and, to a degree, the evaluation criteria for this new resource class. A review of the Long-term Storage allocation policy needs to be reviewed in this light. 14) TeraGrid Roaming policies should be reviewed, adapted and made explicit in light of the changes to the TeraGrid resource environment. The current concept of TeraGrid Roaming (http://www.teragridforum.org/mediawiki/index.php?title=TeraGrid_Roaming) serves several purposes that benefit a large crosssection of users: 1. It can simplify allocation requests for projects that use applications that can run on a range of TeraGrid resources. Users can then optimize and self-regulate to find the resource with the shortest wait time, for example. 2. It simplifies allocation requests for projects that plan multi-site, multi-resource runs. 3. It can help provide new users with access to a variety of resources so they can evaluate the full range of TeraGrid capabilities. Similarly, it provides an easy way to “move” xRAC awards to alternate, but non-specific architectures. Users have a hassle-free access to many resources. At the same time, TeraGrid Roaming has several significant flaws: 1. In the current implementation, a roaming allocation causes user logins to be created on all TeraGrid resources, even though past experience has shown that most will never be used. This represents significant extra work and represents a chronic security concern. 2. Since actual usage cannot be assigned to a resource a priori, Roaming makes it difficult for RPs to plan resource availability for specific allocations. Because of the potential benefits of Roaming, we recommend that Roaming continue to be offered as described in the current de facto policies (including the requirement that all compute resources be offered), with the following modifications. We support the implementation changes described in the Core Services 2.0 Vision document in which Roaming allocations require an extra step by PIs to identify those resources upon which they plan to run. This step should be simple, automatic and changeable over time as the user gains experience. This step will help reduce the most significant concerns about security with Roaming accounts. To ameliorate the challenges in resource planning around Roaming allocations, TeraGrid Roaming allocations should be limited to the following three situations: (1) Startup allocations, in which the user does not know where best to run and may need to evaluate several architectures; (2) xRAC recommendations and awards made to encourage users to migrate to new or alternate platforms, especially in the case of overallocated resources; and (3) xRAC requests in which the proposal describes how the project will use roaming to minimize job waits by finding the least-busy resource or how the project will conduct multi-site runs using unique grid capabilities. Failing this, the allocation should be made to the most appropriate resource(s), based on xRAC recommendation. RPs should be permitted (but not required) to include storage resources as valid Roaming resources. The RP must provide a means for users to understand and calculate how storage charges, if any, will be applied against a roaming allocation. Permissible Exceptions: (a) Resources for which Services Units cannot be converted to Normalized Units via some agreed-upon conversion factor, for example, storage resources. (b) Resources that are not allocated according to some variation of core- or node-hour. The best current example would be the Indiana Quarry cluster, which is dedicated to science gateways and for which the allocated entity is a dedicated virtual host, rather than a share of compute cycles. Similarly, an interactive visualization resource such as TACC’s Maverick may also be excluded. 15) RPs will distribute access to under-allocated resources via Director’s Discretionary awards. TeraGrid should centrally support the ability of RPs to initiate and monitor such discretionary projects and allocations via POPS and Core Services. If a resource remains substantially under-allocated after the xRAC procedures, the Director of the RP is encouraged to make discretionary allocations to other projects until the next LRAC or MRAC cycle, to bring the total allocation up to the threshold designated for substantial allocation. A Resource will be deemed to be “substantially under-allocated” when less than 80% of what the RP declared available at the meeting was allocated. This level improves turnaround for the allocated projects and retains flexibility for potential new users and opportunities. The temporary discretionary allocations provided under this policy, and awarded for other reasons, will be recorded as such in TGCDB, and included in any accounting of allocations and usage. Within the current Core Services infrastructure, it is possible to create discretionary projects and allocations, by contacting the central allocations staff at NCSA. Such discretionary awards can be of arbitrary duration. However, it is not now possible to “convert” such awards into allocated awards; when an xRAC-initiated award is made, such users will receive new grant numbers. The primary limitation on this capability is staffing resources. Priority must be given to completing requests from allocated users. In addition, the current infrastructure does not support such awards during “friendly user” (i.e., pre-production) periods of resource operation. The vision for Core Services 2.0 recognizes that such capabilities are desired and must be supported. We support the plan for Core Services 2.0 to enable site-initiated discretionary allocations and to enable monitoring of allocations and users during pre-production phases. In the current system, sites have the ability to coordinate discretionary projects, if desired. For example, if PSC and TACC both want to grant discretionary time to the same PI, a joint request can be submitted and awarded. The implementation of Core Services 2.0 will explore the possibilities of permitting RPs to manage such coordinated discretionary projects. 6. Communications Better and more regular communications can serve to improve the level of allocation requests and to reduce perceived barriers to entry. In addition, RPs should consider mechanisms for communicating the availability of new and under-requested resources to potential users. 16) Distribute regular press releases and user news on the new allocations ‘portfolio’ after xRAC meetings, as DOE INCITE does. We recommend that the TeraGrid External Relations group formalize a schedule of press releases and user news postings associated with xRAC proposal deadlines and award announcements. Under the current LRAC/MRAC quarterly rotation schedule, it is recommended that the press releases after each MRAC meeting focus on the upcoming deadline for LRAC/MRAC proposals, the types and approximate quantities of resources available, the new resources coming online, and how to get information about applying. The press releases after each LRAC/MRAC meeting would focus on the overall resources allocated, the science associated with those allocation and the scope of the user community; a lesser objective would be to announce the deadline and process for upcoming MRAC allocations. To expedite this effort, TeraGrid Forum should be given opportunity to comment and contribute input, but the ER group will have the authority to issue releases and news postings upon the declared schedule. (Note: NSF may have primary responsibility for the press releases, working in conjunction with the ER group.) In addition, after each xRAC event, the xRAC Coordinator will post to User News a summary of the recent meeting, identifying whether there are or are not resources available for supplementary requests and the approximate levels (if any) for the various resources. 17) Broadly announce and conduct “proposal” training classes early in each proposal cycle. The Allocations and User Support working groups should host a 1-2 hour videoconference training session for all prospective proposers early in each proposal cycle. This should include information about the resources available, proposal requirements, tips for writing good proposals, and info about start-up accounts for scaling studies in support of proposals. 18) Pay special attention to communicating the availability of resources and associated training to new users, communities and institutions Many standard communication methods (e.g. User News) tend to reach existing users and those already familiar with TeraGrid. It is critical to pay attention to methods which reach out to new users, communities and institutions. The Allocations WG should work closely with the EOT WG to ensure that TeraGrid continues to engage potential new users and bring them into the allocations process. This includes communications at large conferences (e.g. TG’08, SC’08), domain-specific conferences (e.g. professional societies, particularly for non-traditional HPC domains), non-traditional community meetings (e.g. Tapia, Grace Hopper, HASATCC, CHASS, NSTA), collaborations with MSI-CIEC and with EPSCoR, and campus champions. 19) Ensure that ongoing changes within the TeraGrid are routinely reflected in the current allocations policies document posted for users at http://www.teragrid.org/userinfo/access/allocationspolicy.php. Within the TeraGrid organizational structure, the ultimate responsibility for maintaining a current allocations policy document falls to the Area Director for User Facing Projects. In practice, the AD for UFP and the xRAC Allocations Coordinator will monitor TeraGrid policy discussions and decisions and will accept suggestions and comments from NSF, the Science Advisory Board, the TeraGrid Forum, GIG management, and TeraGrid users regarding updates and clarifications needed in this document. The xRAC Allocations Coordinator will suggest edits as needed and solicit feedback from the Allocations Working Group. Minor edits will be made upon consensus of the working group. Significant modifications will be reported to the TeraGrid Forum and feedback accepted. The presumption is that policies have been approved and that this step is an editing and updating process; edits will be posted for users’ benefit while feedback continues. Communicating policy changes to users via regular updates to and review of this document must be performed in a timely fashion. Perhaps include a matrix listing the recommendations and those Working Groups/roles charged with implementing them.
© Copyright 2019