According to representative S/AAAs and PIs, the protocol for accomplishing this is currently somewhat informal, based on email exchanges at the levels of PI-to-PI (to find another project willing to swap), PI-to-S/AAA, and S/AAA-to-S/AAA. Although in some cases the PI need only approach his/her S/AAA, the following appears to be a frequent process for accomplishing exchanges: 

1.   The PI locates another PI having unused allocation on the desired machine, and is willing to trade; 
2.   The two PIs approach the appropriate S/AAA(s) for approval; 
3.   The S/AAA(s) approve or reject the exchange; 
4.   The S/AAA(s) responds to the PI(s); and 
5.   The request is passed - on paper - to the database administrator(s) associated with each of the machines, who then make(s) changes in the database to reflect the trade. 

Much of the process can be automated or assisted, reducing both effort and error. We propose to develop web-based forms whereby a PI can indicate whether he/she needs additional time and/or is willing give up allocations, and on what machines. If a matching "offer" is found, the forms will initiate queries to extract information from the resource accounting database to validate the requests (e.g., are both PI's associated with the projects swapping time, and do the projects have the time to trade?). After validation, the requests can be forwarded electronically to the S/AAAs for their approval, with automatic copies to the PIs so that they are aware of the status of the request. Additional forms requiring S/AAA status could carry out the approval process and electronically request the database manager to take the corresponding adction. 

Clearly, this project would be most useful if allocations could be exchanged across MSRC boundaries. If approved, we plan to submit this as a cross-MSRC effort. This would, of course, depend upon the adoption of compatible resource allocation database systems at the interested MSRCs (both ASC and ARL have expressed interest in adopting some or all of our current Year 3 project to develop a resource allocation accounting database for NAVO). 

Project Deliverables:
The major deliverables for this project will be: 

1.   A database to manage information on resource trades currently in process. This would provide a central repository for any trade not yet completed; i.e., proposed trades and trades which have not yet had approval of the appropriate S/AAA(s). 
2.   A suite of cgi programs to create and handle web interfaces for offering and approving resource trades. These programs would be the primary means of managing the database described above. They would interface to the resource accounting database to obtain information on available resources, and would send mail to those parties who had requested notification of changes in the status of a trade. 
3.   Web-based documentation of tool, for users.
4.   Web-based documentation of tool, for S/AAAs and database administrators.
5.   Technical documents describing installation and maintenance requirements and procedures. 

The major milestones for each quarter are as follows: 

• Q1. Requirements, usability analysis, and specification: Work with PIs, S/AAAs, and system administrators at NAVO to: clarify the processes involved in resource reallocation; identify security requirements with regard to resource allocation data; establish basic interface requirements; identify special issues involved in spanning multiple MSRCs; and develop specification for the reallocation database and the user interfaces. 
• Q2. Develop prototype of tool at our local site, using our local installation of the resource allocation database developed as part of the Year 3 project, and a database of simulated resource trades. Develop interface and corresponding tool documentation. 
• Q3. Deploy tool at NAVO. Perform system and integration testing. Make additional changes to both software and documentation based on user feedback. Finalize technical documentation. 
• Q4. (If approved) Deploy tool at other MSRCs. 

Project Benefits:
This intent of this project is to streamline processes that have been clumsy for both PIs and S/AAAs. The concept is based directly on information obtained from S/AAAs in discussing a Year 3 project, the Resource Allocation Accounting Database. 
The primary benefits are primarily to the PIs, who currently have to initiate informal queries to locate another project willing to swap time - or approach the S/AAA to do it on their behalf. The automatic tracking when requests and approvals are forwarded electronically will also make it possible for PIs to know where their requests are in the system. Finally, the availability of this tool would eliminate some basic paperwork that is not really essential given the nature of the activity. 
 

Collaboration:
This clearly would be most beneficial as a cross-MSRC project. Because this is still in the proposal stage, we have not yet approached other groups formally, but we anticipate that ARL and possibly ASC would be willing to collaborate (based on statements they have made in the recent past). 

Budget Justification:
To complete the proposed deliverables within the 12-month project period, the following resources must be allocated: 

• Personnel: NACSE's team-based approach will be used, so personnel effort is described in terms of person-months of particular expertise required to complete the project. Full-time professional staff (not students) will be used for all but software testing and some documentation tasks. 

 

 

The project will require 2 months of system programmer time, approximately 1.5 months of usability engineering, .5 months by a Web-database integration specialist, 1 month of interface designer effort, and 1 month each of staff in software testing and documentation. In addition, project management and support staff will be required, totally approximately 1 month for the project period. 
 

• Travel: The only travel needed for this project will be 1-2 trips to Stennis (1-2 persons each) for project review and/or deployment of the deliverables. (Note that it is assumed that multiple projects will be funded, and that it will be possible to combine trips for multiple projects. Thus, we anticipate making at least two trips during the course of this project, but only one has been factored into the budget.) 

• Other Expenses: There will also be minimal expenses for basic supplies, such as xeroxing, documentation and printing costs, mailing costs, etc. 

 

 

No equipment will be purchased for this project, nor will any profit be recouped. 

The indirect cost rate is set by the federal government, and covers all basic operating expenses (facilities, maintenance, utilities, library resources, etc.) It also offsets the costs incurred by Oregon State University and the Northwest Alliance for Computational Science and Engineering in providing high-performance workstations, file servers, Web servers, database servers, and other machines required to support this project, plus high-speed network connectivity.