Abstract of Research Proposed

The text below is designed to facilitate the process of preparing initial trial applications for TeraGrid accounts via the DAC process. UITS is encouraging this because we believe that use of the TeraGrid will enable IU scientists to perform new, cutting edge research.

Researchers who are just beginning to investigate the TeraGrid may use this as boilerplate for writing their DAC application. DAC applications are submitted via the process outlined at http://rac.uits.iu.edu/hpc/tg-application-abstract.shtml

The proposal will most likely be well-received if you provide a concise and clear explanation of the scientific goals to be accomplished.

• Follow the given instructions and review all guidelines carefully.
• The justification section of the proposal is very important.
• Proposals should not focus on science and are generally not heavily judged on science; focus more attention on methods, justification, and a plan for your allocation.
• Be sure to include proper performance, timing, and scaling data, otherwise the Allocations Committee has no way to gauge if your requested allocation is reasonable. It's best to obtain this data on the architecture you are requesting.
• If requesting a particular resource, be sure to include why you need that resource.
• Page limits may not be enforced, but it is highly recommended to following the page limit guidelines. (They will probably be enforced with rejections in the near future!) If the page limit is a problem for your proposal, attach data as appendices and make references in the proposal body. These appendices are not required reading for the reviewers but will help them gain more information if needed.
• It's helpful to the reviewers for you to attach recent papers regarding the proposed research.
• Be sure to include your funding sources, especially sources relevant to the proposed research.
• You should have all code development done before requesting a large allocation to use that code.

Larger grants [MRACs and LRACs] require a significantly more detailed proposal. NCSA has provided sample proposals for these larger allocations.

Here is a list of topics others have proposed. It is by no means exclusive!

• Parameter sweep interfaces: managing many executions with different parameters
• Tools and support for developing end-user application portals
• End-user application and community portal (focused on particular communities)
• Collaborative viz environments (e.g. interactive viz -> AccessGrid or multiple displayers)
• Visualization-based steering tools and environments
• Global, synchronized file space
• Combined resource queue and broker: one place to submit for architecture-insensitive jobs
• Client-side (laptop, user workstation) tools for launching/interacting with applications
• Workflow/dependency tools for managing jobs on multiple resources
• Directory services / resource discovery to publish/query
• Differentiated pricing (pay more to run sooner, pay less to run as scavenger/cycle stealer)
• Meta/Co scheduling (mechanisms to schedule and simultaneously use multiple resources)
• Middleware for message passing *between* different resources
• Advanced reservations
• Non-CPU resource pricing (Instrument data stream, disk, database access, network)
• Fast-path parallel data movement between resources
• Tools for access to remote instrument data streams
• Remote batch & interactive visualization/rendering services
• Remote data (e.g. WAN GPFS/GridFTP/SRB) read/write
• Remote database (e.g. mySQL/Oracle/Sybase) access
• Single sign-on / remote job delegation and data access: Authenticate once, interact with multiple resources or launch jobs using cached credentials (e.g. MyProxy)
• Unified accounting currency and single help desk
• User portal for managing development teams, accounts, job submission