xsede_Successful_Proposal_Guide

advertisement
April 13, 2015
Writing a Successful XSEDE Proposal
Ken Hackworth
XSEDE Allocations Coordinator
Outline
• References & Terms
• Main Document and guidelines for XSEDE Research (XRAC)
Request
I.
Research Objectives
II.
Computational Methodology (and Applications/Codes
to be used)
III. Application Efficiencies
IV. Computational Research Plan
V.
Justification for SUs (TB) requested
VI. Additional considerations
Outline continued:
•
•
•
•
•
•
Other Documents (*Progress Report and Publications for Renewals)
Review Criteria
Overview of Proposal (Request) Types and Actions
XSEDE Awards (Allocations)
XSEDE Systems (Resources)
Procedures for submitting Allocation request
The Lingo
Allocation Request Types
• Startup Development/testing/
porting/benchmarking
• Education Classroom, Training
• Research Program (usually funded)
•
•
•
•
PI
POPS
XRAC
SU
3 Types of
XSEDE
Projects
Principal Investigator
Partnerships Online Proposal System
XSEDE Resource Allocations Committee
Service Unit = 1 Core-hour
“Traditional” v. Community
• XRAC proposals are accepted in four general
categories of research activities
–
–
–
–
Single Principal Investigator
Large research Collaborations (e.g., MILC consortium)
Community Consortiums (e.g., NEES)
Community Services (e.g., XSEDE Gateways)
• The general requirements for proposals of all four
types remain largely the same.
– Whether requesting compute, storage, visualization,
or advanced support or some combination
General Proposal Outline
I.
II.
III.
IV.
V.
VI.
Research Objectives
Computational methodology (Applications/Codes)
Application efficiencies
Computational Research Plan
Justification for SUs(TB) requested
Additional considerations
Note: Sections III and IV are often integrated.
I. Research Objectives
• Traditional proposals
– Describe the research activities to be pursued
• Community proposals
– Describe the classes of research activities that the proposed effort will
support.
• Keep it short: You only need enough detail to support the
methods and computational plan being proposed.
• TIP—Reviewers don’t want to read the proposal you
submitted to NSF/NIH/etc., but they need to see if you have
merit-reviewed (grant) funding.
II. Computational Methods (and
Applications/Codes used)
• Very similar between traditional and community proposals.
• For compute requests
– Describe the Applications and components you will use.
– Describe the methods/algorithms employed in your computational
research
– Describe code development/features/advances ‘home-grown’ codes.
• For storage requests
– Provide description of data to be stored (organization, formats,
collection mechanisms, permissions granted or received)
– Describe the amount and expected growth of data to be stored.
III. Application Efficiencies
• Very similar between traditional and community proposals.
• For compute requests
– Explain why you chose specific resources for your applications.
– Provide performance and scaling details on problems and test cases
similar to those being pursued. (What is the appropriate scale for your
problem?)
– Ideally, provide performance and scaling data collected by you for the
specific resource(s) you are requesting.
• For storage requests
– Explain the efficiency of your storage algorithms and protocols.
– Describe and estimate the expected costs of scaling to larger data sets
and a larger number of clients.
IV. Computational Research Plan
• Traditional proposals
– Explicitly describe the problem cases you will examine
• BAD: “…a dozen or so important proteins under various conditions…”
• GOOD: “…7 proteins [listed here; include scientific importance of these
selections somewhere, too]. Each protein will require [X] number of runs,
varying [x] parameters [listed here] [in very specific and scientifically
meaningful ways]…”
• Science Gateway proposals
– Explicitly describe the typical use-case(s) that the gateway supports
and the type of runs that you expect users to make
– Describe how you will help ensure that the community will make
scientifically meaningful runs (if applicable)
• BAD: “…the gateway lets users run NAMD on XSEDE resources…”
• BETTER: “…users will run NAMD jobs on [biological systems like this]…”
• BETTER STILL: “…the gateway allows users to run NAMD jobs on up to 128
processors on problem sizes limited [in some fashion]…”
V. Justification of SUs, TBs
• Traditional, Research proposals
– If you’ve done sections II, III and IV well, this section
should be a straightforward math problem
– For each research problem, calculate the SUs required
based on runs (base units) defined in IV and the timings in
section III, broken out appropriately by resource
• Reasonable scaling estimates from test-case timing runs to fullscale production runs are acceptable.
– Clear presentation here will allow reviewers to award time
or storage in a rational fashion
– Analogous calculations should apply for storage requests
V. Justification of SUs, TBs
• Community (gateway-type) proposals
– The first big trick: Calculating SUs when you don’t know the precise
runs to be made a priori.
– renewIn Year 2 and beyond
• Start with an estimate of total usage based on prior year’s usage patterns
and estimate for coming year’s usage patterns.
• From this information, along with data from sections IV and III, you can
come up with a tabulation of SU estimates.
– Year 1 requires bootstrapping
• Pick conservative values (and justify them) for the size of the community
and runs to be made, and calculate SUs.
• TIP—Start modestly. If you have ~0 users, don’t expect the reviewers to
believe that you will get thousands (or even hundreds) next year.
– Analogous calculations for TBs of storage needed
VI. Additional Review Considerations
 Ability to complete the work plan described
(more significant for larger requests)
– Sufficient merit-reviewed funding
– Staff, both number and experience
 Local computing environment
 Special Needs
 Other access to HPC resources
– (e.g., Campus centers, DOE centers, etc.)
VI. Additional Considerations
Community (gateway) proposals
these components can provide key details:
– Community Support and Management Plan
• Describe the gateway interface — in terms of how it helps
community burn SUs or access TBs.
• Describe plans for growing the user community, “graduating”
users to Research allocation awards, regulating “gateway hogs”
– Progress report
• The actual user community and usage patterns
• Manuscripts thanking this service, or list articles referencing
XSEDE.
– Local computing environment
– Other HPC resources
Renewals require a Progress Report
• For Research Project Renewal and Supplement
Requests
– Summary of Scientific Discoveries
– Accomplishments of Computation Plan
• Usage
• Achievements of the Computations (more detail than summary).
– Specify the number of publications, conferences, reports
that result from XSEDE support.
– Contributions to other research efforts.
(experimental/computational/instrumental, etc.).
Other Documents:
Required:
• CVs for PIs and Co-PIs (2 pages)
• List of Publications resulting from the XSEDE allocation
Optional:
– Code Performance & Scaling (If it won’t fit in Main Doc.)
– Special Requirements
– References (If they won’t fit in Main Doc.)
– Other
Proposal Review Criteria
•
Methodology
For compute requests, the choice of applications, methods, algorithms and techniques to be
employed to accomplish the stated objectives should be reasonably justified. While the
accomplishment of the stated objectives in support of the science is important, it is incumbent on
proposers to consider the methods available to them and to use that which is best suited.
(For storage requests, the data usage, access methods, algorithms and techniques to be employed to
accomplish the stated research objectives should be reasonably justified. For shared collections,
proposers must describe the public or community access methods to be provided.)
•
State Appropriateness of Computations for Scientific Simulations
The computations must provide a precise representation of the physical phenomena to be
investigated. They must also employ the correct methodologies and simulation parameters (step size,
time scale, etc.) to obtain accurate and meaningful results.
•
Describe the Efficiency in Usage of Resources
The resources selected must be used as efficiently as is reasonably possible. To meet this criterion for
compute resources, performance and parallel scaling data should be provided for all applications to be
used along with a discussion of optimization and/or parallelization work to be done to improve the
applications.
(For storage resources, information on required performance and expected access patterns should be
provided for all data and collections to be stored and used along with a discussion of work done or
planned to improve the efficiency of the data use.)
•
Computational Research Plan
Explain computational steps to accomplish science. Give details of computational costs. (Justification)
XSEDE Projects
An XSEDE Project is like a bank account for allocations.
– It is permanent, only one per PI.
– It holds a year’s worth of allocation (on 1 or more systems)
– PI’s request an allocation renewal each year thereafter.
– An Allocation awarded to a New Request creates an XSEDE
Project.
A PI’s Computational Projects evolve over the years.
– Computational Projects begin, end and extend.
– In subsequent years successful Renewal Requests provide
allocations for new Computational Projects under the same
XSEDE Project. Your XSEDE Project remains the same.
– A Renewal Requests is just like New Request, but must
contain a Progress Report of last year’s Computational
Projects and list of publications from past year’s allocation.
Eligibility
• Principal investigator (PI) must be a researcher or educator
at a U.S.-based institution, including federal research labs or
commercial organizations, (Commercial requests must guarantee that
their results are publically available, and work must be in collaboration with an
open science organization.)
• A postdoctoral researcher is eligible to be a PI.
• A qualified advisor may apply for an allocation for his or her
class; but a high school, undergraduate or graduate student
may not be a PI.
Overview: Research Request
portal.xsede.org AllocationsSubmit/Review Request **
•
•
•
•
•
Web forms: Investigator, Grants, Resource Request,…
Requires Main Doc. = “proposal” (pdf upload) & CV
Reviewed by experts in same Field of Science
2.5 months from deadline to award availability
Details:
– Allocation Size: Unlimited
– Reviewed: Quarterly
– Deadlines: 15th of October, January, April, July
– Awards Begin: 1st of January, April, July, October
Overview: Startup/Education Requests
portal.xsede.org AllocationsSubmit/Review Request **
•
•
•
•
•
Web forms: Investigator, Resource Request,…
Requires only an abstract and CV
Reviewed by a XSEDE Staff (Startup Allocations Committee)
2 weeks from submission to award availability
For code devel / performance eval / small-scaling computations /
classroom & training instruction
• Details:
–
–
–
–
Request limit: 200,000 SUs total or combination of all resources requested
Reviewed: within 2 weeks of submission
Deadlines: None
Awards Begin: within 2 weeks of submission
Proposal Document(s)
https://www.xsede.org/web/xup/allocation-policies**
• CV (s) required for all requests.
• Abstract for startup/education request
(in forms, or as a PDF document)
• Proposal “Main Document” for Research request
(renewals/supplements)
Key to a successful review:
• Adhere to page limits!
• “Justify” allocation request.
Page Limit
Proposal Document
3
Progress report
10
New or Renewal
15
Over 10 Million SUs
Pg. limit: DOES INCLUDE FIGURES & TABLES.
The Award = Allocation
• One per PI (generally)
• 1-year duration
• Unused SUs are forfeited at the
end of an award period
• Progress report required for
renewal requests.
• Add users to a grant via XSEDE
User Portal
4 quarters = 1 yr allocation period
Advance
Submission Review Award
Time to renew
The Resources: Compute
https://www.xsede.org/resources/overview
HPC Systems: (Kraken, Ranger, Lonestar, Steele, Trestles,
Blacklight, Keeneland, Quarry, Gordon)
Advanced VIS Systems: (Longhorn, Nautilus, Spur)
HTC Systems: (Condor and OSG)
Storage Systems: (local resource storage)
The Resources: Extended Collaborative Support(ECS)
https://www.xsede.org/ecss
• Dedicated, but limited, XSEDE staff assistance (request FTE
months)
• 5 Questions which are part of resource request section of
application
• Reviewers rate need for ECS (0-3)
The Process: Steps
•
•
•
•
•
•
•
•
•
Assess Systems: https://www.xsede.org/resources/overview
Determine Type of Project
Login: portal.xsede.org AllocationsSubmit/Review Request **
(“Create portal login” if first time.)
Select Action (New, Renewal, Suppl/Just/Prog/Ext/Trans/Adv)
Select project Type (Research; Startup/Edu < 200K SUs)
Fill in forms: PI/Co-PI Info, Proposal Info, Supporting
Grants, Resource Request (alloc. request/machine).
Upload proposal document(s): (Main Doc., CVs, etc.).
Update at anytime and “Save to date”
Click “Final Submission” when finished (but can still
change)
Login at portal.xsede.org
Example Form: New Project
Example Form: PI entry page
Example Form: PI entry page, populating with
Portal information
Clicking on this box
will auto-populate
this page with your
portal information
Example proposal submission: Title,
Abstract, FOS and Keywords
Example proposal submission: Supporting
grants
Example proposal submission: Resource
request page
Example proposal submission: Resources
request page (continued)
Example proposal submission: Document
upload page
Example proposal submission: Document
upload (continued)
Check mark confirms
I have uploaded CV
Example proposal submission: Saving and
Final Submission
Example proposal submission: Saving and
Final Submission
Example proposal submission: Successful
submission
Pending Request
Approved Request
Interesting Facts
•
•
•
•
~600 research requests per year
~800 other requests
~3.5B SUs requested(3.2B are research requests)
~1.8B SUs awarded(1.6B are research awards)
Questions?
• Asking for Help
help@xsede.org
Download