1. Extreme Scale: Programming

2. Participants Mary Hall Rob Ross Christine Sweeney Ian Foster Daniel Laney Lavanya Ramakrishnan Jim Ahrens John Wright Craig Tull Tom Uram Frank Wuerthwein Pinar Alper Gagan Agrawal Jim Kowalkowski Greg Abram Berk Geveci Scott Klasky Manish Parashar Valerio Pascucci Michela Taufer Chris Carothers Thanks to Manish for taking detailed notes!

3. Changes in Architectures High concurrency More dynamic – execution of programs (more asynchronous) – behavior of system (e.g., DVFS, failures) Diversity of architectures In-system storage – And no common model for this so far Lifetime, locality, API, …

4. “Horizon” and Coordination Where does the workflow end and programming model begin? – Hierarchical representation and scheduling Might be multiple algorithms that solve the same problem: are those implemented as part of a single code, or as multiple codes Need for coordination between workflow and programming model (and runtime) – Coordination between workflow and the scheduler – Coordination with things external to the system (e.g., other workflow systems, additive manufacturing example) Need to bring communities together to enable interoperability.

5. Mapping Scientists define model of science (workflow), that is converted into an execution plan in some way – Capture what scientist wants to do rather than how they want to do it – Leads to improved portability to different architectures – How is architectural information and scientist’s intent used to pick a “good” execution plan? Domain specific language (DSL) paradigm for programming? User could specify “knobs” (options) that provide additional degree(s) of freedom (e.g., precision) Cost models needed to enable decision-making – Including during execution – E.g., relative cost of data access

6. Patterns “Poor man’s workflow” – capturing scripts, etc. that define a job and allowing for easy re-execution Coupled codes Ensembles (many jobs running at the same time) – People already do this (e.g., using swift), sampling high- dimensional spaces – Conditionals in the workflow based on results of individual runs – UQ/V&V often a piece of this Multi-physics and in situ analysis – Which pieces are done as part of the “workflow”? Need to articulate the common workflow patterns to help guide discussion.

7. Provenance Capture of runtime decisions, even if it isn’t possible to reproduce exact execution Tagging of data based on runtime analysis More than just what workflow is doing Even if teams aren’t using other workflow components, provenance capture is useful

8. Pragmatics Accessibility of the workflow description method Basic programming constructs (conditionals, loops) are needed as part of the language for describing workflows Dynamism in the workflow itself, workflow is changed at runtime (rather than trying to capture all the possible execution paths) – User driven or automated How do you get large communities to buy into tools developed under the workflow umbrella (e.g., provenance capture)? How do you help teams integrate some tools while not necessarily buying into the whole set of tools/packages? In situ analytics will be parallel, must take good advantage of architectural characteristics and coexist with simulation code(s)