DOE Exascale Computing Program

PathForward Request for Proposals


All proposals are due on or before July 18, 2016 at 3 p.m. PDT.

Interested Offerors are advised to monitor this website for potential PathForward RFP amendments and other PathForward RFP information updates. LLNS may notify interested Offerors (who have previously contacted LLNS and expressed an interest in the PathForward RFP) of updated PathForward RFP information via e-mail; however, LLNS is under no obligation to do so. It is the responsibility of all interested Offerors to monitor this website for current PathForward RFP information.

Interested Offerors must submit all communication (questions, comments, etc.) about the PathForward RFPs to the Contract Administrator.

PathForward seeks solutions that will improve application performance and developer productivity while maximizing energy efficiency and reliability of an exascale system. PathForward responses should describe R&D that will:

  1. Substantially improve the competitiveness of the HPC exascale system proposals in 2019, where application performance figures of merit will be the most important criteria.
  2. Improve the Offeror's confidence in the value and feasibility of aggressive advanced technology options that they are willing to propose for the HPC exascale system acquisitions.
  3. Identify the most promising technology options that would be included in 2019 proposals for the HPC exascale systems.

RFP Questions and Answers

Q1:  How will PathForward proposers be made aware of other ECP activities?
A1:  ECP will define integration and collaboration opportunities but not prior to the due date for PathForward proposals.

Q2: Are PathForward RFPs for all or nothing awards?
A2:  The DOE Laboratories reserve the right to negotiate with any vendor and to allocate funding for a proposal to some or all of the proposed work packages.

Q3:  Is the ECP using LINPACK as a performance metric?
A3:  No. LINPACK is not a relevant performance metric for ECP's goal of Capable Exascale Computing. The primary ECP performance goal is application performance. For the purposes of PathForward a capable exascale system is defined as a supercomputer that can solve science problems 50X faster (or more complex) than on the 20PF systems (Titan, Sequoia) of today in a power envelope of 20-30 MW and is sufficiently resilient that user intervention due to hardware or system faults is on the order of a week on average.

Q4:  The ECP FOM includes a 50x performance improvement over baseline performance on Sequoia and Trinity. How will Proposers establish baseline performance estimates and FOMs?
A4: The baseline performance and relevant codes to establish the baselines and project improvements to FOMs can be found at and at

Q5:  Do you have guidance for us on the granularity of work-packages, e.g. pages, data, and dollar value?
A5:  We do not want to specify page limits or costs for work packages. We recognize the size of a work package may not be correlated with the cost (and vice versa).

Q6:  Can the prior investment made to create background IP that is directly relevant to our PathForward advanced architecture design be counted towards the 40% cost share?
A6:  No. The cost share requirement must be for current and future activities that can be demonstrated to align with and to match the U.S. Government funding for the PathForward contract.

Q7:  What software development activities are in scope for PathForward?
A7:  Software development activities may only be proposed as described on pages 5-6 of the Draft Technical Requirements. PathForward has a hardware focus, so software should be the minimum necessary to facilitate demonstration of new hardware features. Software-only work packages are out of scope.

Q8:  What is the interest in PathForward for storage R&D?
A8:  We identify memory and storage as a technical challenge but storage R&D will only be in scope to the extent that the proposal improves the FOMs as described in the Draft Technical Requirements.

Q9:  What motivates the ECP Resilience target of one week MTBI/MTBF? Is it realistic?
A9:  We are not asking for one week MTBI/MTBF with hardware alone. Our target requirement is that human intervention due to hardware or system faults is on the order of a week on average. Hardware failure rates can be more frequent so long as software or hardware recovery mechanisms are employed and don't require human intervention.

Q10: If an offeror wishes to work with multiple partners in the same technology area, such as multiple system integrators proposing more than one system design, would that require the submission of more than one proposal?
A10: Yes. A Proposer may submit separate proposals for distinct conceptual system designs.

Q11: What level of detail are you looking for in the exascale conceptual system design and node designs (e.g., projected power consumption, memory/network latency and bandwidth, compute capabilities or a higher-level description of the system and node with their benefits)?
A11: We are looking for the level of detail that is necessary to justify the importance and value of your work packages. Conceptual system designs serve as a basis to understand how a successful PathForward project will lead to an Exascale Systems RFP response.

Q12: What would be suitable deliverables for the work packages that demonstrate key exascale features? Are reports or presentations on what was done and the benefits acceptable deliverables?
A12: Deliverables must convince us that the work packages will improve potential system bids in response to the 2019 Exascale System RFP.

Q13: Should work on software and application co-design be budgeted as part of PathForward work packages?
A13: Costs for co-design should be included in your budget.

Q14: Should hardware demonstrators for a particular technology be bid as separate work packages?
A14: It doesn't matter so long as pricing for hardware demonstrator is identified separately.

Q15: The Technical Requirements Document has the word "Draft" in the title. Is this the final version?
A15: The document is called a "Draft" because it will be changed into a final SOW when the subcontracts are awarded.

Q16: Is it necessary to include analysis of both sets of benchmarks for PathForward system performance FOMs or is either one alone sufficient, or is one preferred over the other?
A16: There is no requirement for a benchmark analysis, but it is up to the Offeror to demonstrate that their proposed work will substantially improve application performance.

Q17: Will co-design affect how the benchmarks should be run or analyzed for PathForward system performance FOM demonstrations as compared to how they were run and analyzed for Coral(1) and APEX?
A17: As the PathForward program progresses, co-design may lead to changes to the DOE's approach for analyzing system performance. However, at this time it is premature to know with certainty what, if anything would change.

Q18: Who is (are) the point(s) of contact within the DOE who will be working with the Offerors on code port strategies?
A18: This information will be made available to the PathForward participants after contract award.

Q19: Will any DOE Lab resources be actively participating in code ports to specific Offerors ISAs and other computational engines such as GPUs?
A19: ECP intends to assign Laboratory personnel to participate in co-design activities in support of PathForward. Hackathons and code porting are expected to be key activities within co-design. However, Offerors should not count on such laboratory-supplied labor in their response. The Offeror should create a project plan that budgets for the full cost of the software porting effort necessary for the success of their work package.

Q20: [Reference: Under the Target Requirements Section 6.5.1 (TR-1); Work Package the last sentence paragraph 1 states: "A schedule for periodic technical review by the DOE laboratories shall also be provided."] Is the periodic technical review required for each work package and to be priced with the milestones or can it be done at a higher level with a statement that reads: A periodic technical review will be held and scheduled and may address multiple work packages within the same review?
A20: A periodic technical review will be scheduled where multiple work packages will be addressed within the same review. You do not need to separately price the periodic technical review with each milestone.

Q21: [Reference: Under the Target Requirements Section 6.5.1 (TR-1); For each work package, describe the following - under Cost and Schedule it states: "Please provide quarterly milestones, dependencies on other work packages or technologies, completion criteria, and cost for this R&D package (only put this into the price proposal)."] It is expected that for each work package the Subcontractor will propose a quarterly milestone for the entire program or may the milestones be tasked based and proposed in the quarter it is to be completed? In other words some quarters may not have a milestone proposed.
A21: Milestones should be task based and should correspond to completion of logical activities of work packages. Timelines should fit with your schedule and expected completion of those activities. Activities should be specified such that they will be completed throughout the period of performance; while a specific workpackage may not have any milestones that are completed within a given quarter, DOE anticipates that some milestones over the full set of workpackages will be completed each quarter, but not necessarily in the last month of the quarter. The invoices and payments are based on completed and accepted milestones?

Q22: If the Offeror includes a Compliance Matrix in its proposal to assist the evaluators, and to demonstrate its proposal meets the evaluation factors, please confirm that it will not be counted in the 50 page count limit of the technical volume along with the cover letter, cover page, table of contents, references and staff curricula vitae.
A22: It is too late in the proposal process for us to create new categories of items that should or should not be included within the page count. The proposal page requirements must be adhered to as currently written.