ࡱ>  PRGHIJKLMNOa Sjbjbtt *L;  n#r#z#(8.l(0{:v$zzzzzzz,4Rzn#ĢĢĢz4n#n#z444Ģn#n#z4#R&!n#n#Ģz44^ N.n#n#r . WXR7_r{00{%a 4 r4r#((DqR((RLos Alamos Computer Science Institute FY 2006 Proposal The principal goal of the Los Alamos Computer Science Institute (LACSI) is to conduct basic research in computer and computational science that has relevance to the mission of Los Alamos National Laboratory. The funding is not intended to support advanced development efforts, although some such efforts may be spun out to produce software and tools that will be directly useful to end users. Secondary goals of the Institute are to increase the national and international stature of LANL computer science and to engage the high-performance computing research community in problems of importance to the LANL. This proposal is the product of a year-long planning effort that began in Spring 2004 with the annual LACSI Priorities and Strategies Meeting, in which plans for FY05 activities were developed. As a result of discussions at that meeting, we resolved to take two actions: We would move to a process that included an annual review of activities by an independent review committee that included members from within DOE as well as industry and academia. The first such review was convened in November 2004. Based on the review and the annual planning meeting, LACSI would submit a new proposal for research funding each year. The proposal would cover three years of activity, even though the funding would be provided one year at a time. The review and planning process should include mechanisms for phasing out projects and initiating new starts. This proposal is the first produced by the new process. For reference, we have attached the report of the review committee from November 2004. For FY06, LACSI activities would cover a broad spectrum of areas of research, including strategies for measuring, analyzing, and improving application and system performance; components and component integration systems; computer systems and networking; and computational science. These research areas are covered in four subsequent sections of the proposal. Every section includes two subsections, each describing a coherent, coordinated research activity, along with the budget, a set of tasks to be carried out, and a discussion of the relevance of the proposed work to the Weapons Program. In addition to the research, there is an additional section that covers management and community interaction. The management section includes a detailed discussion of the new management and planning cycle for LACSI. Community interactions include the enormously successful LACSI Annual Symposium and several other outreach programs carried out by the Institute. Finally, there is a section summarizing the budget Taken together, the proposed LACSI activities represent a broad and deep collection of projects that can have an enormous positive impact on high performance computing and communications within the DOE Weapons Program. Application and System Performance Integrated Performance and Reliability of Extreme-scale Systems Supported Personnel: Project Leads: John Mellor-Crummey, Rice, HYPERLINK "mailto:johnmc@cs.rice.edu"johnmc@cs.rice.edu; Jack Dongarra, UTK,  HYPERLINK "mailto:dongarra@cs.utk.edu" dongarra@cs.utk.edu; Daniel Reed, UNC,  HYPERLINK "mailto:Dan_Reed@unc.edu" Dan_Reed@unc.edu, Patrick Bridges, UNM,  HYPERLINK "mailto:bridges@cs.unm.edu" bridges@cs.unm.edu Other Supported Personnel: Rice: Rob Fowler LANL Point of Contact: Adolfy Hoisie,  HYPERLINK "mailto:hoisie@lanl.gov" hoisie@lanl.gov Vision and Motivation Building scientific applications that can exploit extreme-scale parallel systems effectively is difficult. The goal of research on performance and reliability of large-scale systems is to develop tools and technologies that help application scientists harness the power of extreme-scale parallel systems for solving computation-intensive problems. The level of parallelism in extreme-scale systems and the need to exploit parallelism on multiple levels poses a formidable challenge to achieving scalable performance. Furthermore, the architectural complexity of extreme-scale systems makes it hard to write programs that can fully exploit their capabilities. Todays extreme-scale systems include complex processors, deep memory hierarchies and complex heterogeneous interconnects. A broad spectrum of issues affects application performance, including operating system activity, load imbalance, serialization, underutilization of processor functional units, data copying, poor temporal and spatial locality of data accesses, exposed communication latency, high communication frequency, large communication bandwidth requirements and ineffective network utilization. To achieve a significant fraction of a systems potential performance requires careful scheduling of an applications operations, data accesses, and communication. On extreme-scale systems, performance and reliability are inseparable. The large number of components in extreme-scale parallel systems makes component failure inevitable; therefore, long-running computation-intensive applications must be resilient to transient and permanent hardware faults or risk being unable to run to completion. The most popular parallel programming paradigm, MPI, has little support for reliability. When a node fails, all MPI processes are killed and the user loses all computation performed since the last application-initiated checkpoint. Many challenging problems must be solved to understand how to implement scientific applications so that they can achieve scalable high performance and are resilient to failure on extreme-scale parallel systems. We propose a program of research that aims to develop technologies that support measuring, analyzing, modeling, and improving the performance and reliability of applications on current and future generations of extreme-scale parallel architectures. The principal aims of this research effort are to understand application and system performance and failure modes on present-day extreme-scale architectures through the development and application of technologies for measurement and analysis of program and system behavior, model the behavior of applications to understand factors affecting their performance and reliability on current and future generations of computer systems, devise software strategies to ameliorate application performance bottlenecks and failure susceptibility on todays architectures, and explore technologies to support fault tolerance, including capabilities for monitoring the health of system components, predicting impending faults, and proactively avoiding faults. This work will address aspects of performance and reliability spanning both applications and underlying hardware. Research Plan To address the problem of developing applications for extreme-scale systems that deliver high performance and are resilient to failure, we propose research in the areas of measuring performance and component health, analyzing performance and reliability, modeling application and system performance and reliability, exploring techniques for constructing failure-resilient programs, and evaluating alternative architectures that can yield increased performance and greater reliability. Measuring Performance and Reliability Extreme-scale systems require monitoring for a variety of purposes. Performance monitoring is needed to evaluate program behavior and resource utilization to understand why and where applications are inefficient. Health monitoring of status information such as temperature and power consumption is necessary on extreme-scale systems to anticipate or detect failures, which are inevitable on such systems because of their scale. For measurement tools to be useful for monitoring production programs on extreme-scale systems, they must have low overhead that does not distort application performance or system behavior, work with multi-lingual, parallel, optimized code without modification, analyze not only user programs but their interplay with binary-only libraries, the operating system kernel and system processes, support programs with large-scale, possibly heterogeneous parallelism, record data of only modest size, and scale to tens of thousands of nodes. In general, performance problems on extreme-scale systems are varied and complex. To understand the performance of parallel applications, one must capture detailed information about their behavior, including the interplay of computation, consumption of and contention for resources (e.g., network and I/O), communication, synchronization, and serialization. The key research challenge is to devise effective strategies for integrated measurement of such aspects of program behavior. These measurements must be sufficient to provide insights into the interplay between these different aspects of program behavior and yet introduce only low monitoring overhead so they can be used on production runs. For performance measurements to be most useful to application developers, it must be possible to correlate them with the applications source code. The appropriate strategy for collecting performance measurements depends upon the aspect of program behavior under study and the intended uses of the performance data. Performance data for an application may be collected for off-line analysis or it may be collected to enable an application to evaluate its own efficiency and adapt its behavior in response to its findings. Key strategies for gathering performance data include statistical sampling of events (sampling may be either system wide or within individual application processes), using instrumented communication libraries, and inserting instrumentation into programs via source code transformations, or by rewriting application and library binaries at link time, program launch, or during execution. Measuring and Attributing Node Performance For modern modular programs, knowing the context in which costs were incurred is vital to understanding how to address performance problems. For instance, rather than knowing that a program spends time in a particular solver, it is much more informative to know that when the solver is called with preconditioned matrices, it is fast; otherwise, it is much slower. Similarly, for parallel programs that invoke communication operations in many places, knowing that the program spends a lot of time waiting for communication is not particularly helpful for pinpointing the problem. In contrast, knowing that most waiting time is associated with a particular communication event is the first step to determining whether load imbalance, serialization or communication frequency is to blame. To attribute costs precisely to execution contexts within programs, we propose to design, build, evaluate, and disseminate open-source compiler and runtime mechanisms for efficiently collecting calling context for both synchronous and asynchronous events. Synchronous events include memory allocation and communication. Asynchronous events include hardware performance counter overflows and timer expiration. We need to collect information about both classes of events during the execution of optimized code. Rather than instrumenting each function to log its entry and exit so that calling context information is always available (as gprof does), we collect calling context on demand by stack unwinding. Collecting calling context efficiently for optimized code is tricky. In particular, for asynchronous events, monitoring code must be able to unwind the call stack from any point in the program execution, even procedure prologues or epilogues. For this case, compiler support or binary analysis is needed to determine exactly where in the machine state the return address of the caller resides. This work will build on prior work at Rice on AlphaServer platforms, which lacked sufficient compiler support to fully realize this vision, and ongoing work on Opteron platforms for which we are prototyping necessary compiler support in the gcc compiler infrastructure. To date, our research on measuring application node performance has focused on static parallelism of threads and processes. Programming models and architectures under development as part of DARPAs HPCS project heavily rely on dynamic parallelism. We propose to explore strategies for understanding system performance for applications and systems making use of dynamic parallelism. Measuring Performance Beyond Processors The PAPI library has standardized access to hardware event counters available on most modern microprocessors by providing standard routines and a standard set of performance metrics. Counters on processors measure events such as cycle and operation counts, functional unit status, cache and memory accesses, and branch behavior. Other components besides the processor, such as memory chips, network interface cards, and network switches, also have counters that monitor various events related to system performance and reliability. Unlike on-processor counters, off-processor counters usually measure events system wide rather than for a process or thread-specific context. However, when an application has exclusive use of a machine partition, it may be possible to interpret such counts in the context of the application. It may also be possible to correlate process-specific events counts with system-wide counts using a data mining approach based on multivariate statistical analysis. The current situation with off-processor counters is similar to the situation that existed with on-processor counters before PAPI. There are many platform-specific interfaces, some of which are undocumented. We propose to develop standard routines for accessing off-processor counters on a range of platforms and networks. We have begun working on an interface to counters available on Myricom network switches. The Infiniband standard also has definitions of measurement hooks. The Cray X1 has E-chip and M-chip counters. The challenge will be to try to develop as portable an interface as possible while still providing access to information that is necessarily somewhat platform-specific. In addition to routines to control and access counters, we plan to provide query routines that will provide information about what counters and events are available, including both standardized and platform-specific events. Measuring Communication To understand the performance of parallel applications on extreme-scale systems, one must understand the end-to-end costs of communication and delays that result from load imbalance or serialization. For this purpose, we have begun to explore a message-centric monitoring approach that involves gathering and propagating information as messages traverse the system. Using this approach, each message is augmented with a monitoring summary that compactly encodes information related to the message, e.g., how much time was spent generating the data contained in the message. Message-centric monitoring trades the centralized global view of trace-based systems for a decentralized, weakly consistent view of system behavior to approach the low overheads and online availability provided by statistical monitoring techniques. Making this monitoring approach efficient will require developing low-overhead representations of performance and reliability data, and controlling monitoring overhead by a combination of sampling and adaptive monitoring. Thus far, we have separately explored two strategies for message-centric monitoring: vertical monitoring of message costs on a single node, and horizontal monitoring that combines monitoring summaries from multiple incoming messages, creates a new monitoring summary from this data, and attaches it to outgoing messages. Our current prototypes show that we can gather vertical monitoring information on Linux cluster nodes using a modified version of the Linux Trace Toolkit with 3% overhead for the NAS parallel benchmarks, and that we can efficiently propagate horizontal monitoring information about LA-MPI runtime performance with similar overheads. We now need to integrate these prototypes, developed at UNM, into a single system for monitoring all operating system and message passing costs for a large-scale parallel scientific application, integrate them will the application-level monitoring tools developed at Rice, and evaluate their accuracy and overhead on large-scale machines with the ASCI Purple benchmarks. We propose to explore a sample-based approach to message-centric monitoring to enable tunable control of measurement accuracy and instrumentation overhead. This would enable message-centric monitoring to be used on production applications and system software. If message-centric monitoring is available for production applications, it can be used to audit them to verify that their behavior matches the characteristics of previously gathered performance profiles. Such audits could be used to detect performance anomalies caused by new data sets or system software changes. In addition, online availability of message-centric monitoring could also be used to optimize application load-balancing decisions and to drive MPI protocol adaptations to improve application performance. Measuring Node and System Health and Reliability Component failure is inevitable on extreme-scale systems. Long-running jobs must expect to encounter faults and take appropriate action to enable systems and applications to continue operating even when some components fail. Without the ability to anticipate or notice and tolerate component failure, the mean time to failure (MTBF) of systems with tens of thousands of commodity components, even when operated as quasi-independent partitions, will continue to decline and will severely limit the ability to solve complex problems. To anticipate component failures, we propose to develop an extended health monitoring infrastructure and support for assessing the thermal environment of extreme-scale systems. During the past year, Reeds team at UNC has developed a health monitoring system library and a Health Application Programming Interface (HAPI) for discovery and use of health-related diagnostic information on Linux clusters. HAPI acquires fault indicator data via (a) vendor provided Self-Monitoring Analysis and Reporting Technology (SMART) for disk warnings such as seek and read/write retries; (b) Advanced Configuration and Power Interface (ACPI) for temperatures and CPU throttle rates and (c) low-level hardware sensors for motherboard temperatures and power supply voltages. By operating as a uniform software layer that sits above low-level health measurement tools, HAPI hides the idiosyncrasies of measurement and allows fault detection, prediction and recovery techniques to access data via standard mechanisms. HAPI supports both standard Linux clusters and the LANL Clustermatic toolkit. To enable effective monitoring of systems containing thousands or tens of thousands of nodes, fault tolerance data collection must be scalable and integrated with low overhead performance measurement systems. We propose to develop statistical sampling schemes for this purpose. These sampling schemes will be adaptive, enabling configuration of sampling frequencies and sample sizes based on historical failure probabilities and user experiences. Measuring Environmental Health and Impacts Thermal stresses are also a major cause of component failures. An enterprise machine room contains a complex hierarchy of micro-climates, ranging from within a single microprocessor, a motherboard and node, and a set of racks through raised floors, cooling ducts and ambient room temperatures. Often, physical configuration and placement can lead to unexpected and unknown (at least until failures occur) thermal stresses. Building on the UNC HAPI infrastructure, we propose to develop a distributed measurement toolkit that exploits mobile environmental sensors that can be placed in machines, racks and air ducts. This toolkit will capture time varying temperature, humidity and vibration, enabling construction of machine room micro-climate maps and displays. This toolkit will be integrated with the health monitoring infrastructure and provide the raw data needed for constructing more accurate hardware failure models. In addition, it will enable more intelligent management of machine rooms by tracking the effects of hardware changes on the surrounding systems; often placement of new equipment can create thermal hotspots where none were expected. Analyzing and Modeling Performance and Reliability The data collected for a parallel application on an extreme-scale system can be overwhelming. Analysis and presentation techniques must support top-down analysis to cope with the complexity of programs containing millions of source lines running on thousands or tens of thousands of processors. To understand executions and reliability on such systems, it is not practical to inspect processors and tasks individually. Instead, improved analysis techniques are needed that can identify and correlate data from key subsets. Analyzing Performance with Compile Time Information Understanding the performance of programs with thousands of moving parts requires understanding the relationship of interactions between processes to the context in which these interactions occur. Resource contention (e.g. for access to I/O), serialization, and load imbalance are three problems that are difficult to understand. Serialization needs to be attributed to synchronization points. Resource utilization and contention must be attributed back to resource requests in context. Even understanding computation costs in modular programs can be difficult when multiple instantiations of code are present because of inlining and templates. In each case, the first step to understanding behavior is assessing the context in which it occurs. We propose to use calling context information collected with call stack unwinding as the basis for attributing costs to contexts. For programs with inlining or template instantiation, it is important to identify and attribute performance metrics correctly to inlined abstractions as well as the contexts into which they are inlined. To address this problem, we propose to extend capabilities in Rice HPCToolkit for binary analysis of executables to identify and accurately attribute performance for inlined code. Comparing profiles based on different events, computing derived metrics (e.g., event ratios), and correlating profile data with routines, loops and statements in application code can provide application developers with insight into performance problems. However, on an extreme-scale system, an application developer cannot inspect data from every application or system component. To help users cope with the overwhelming volume of information about application behavior on extreme-scale systems, more sophisticated analysis strategies are needed for automatically identifying and isolating key phenomena of interest, distilling and presenting application performance data in ways that provide insight into performance bottlenecks, and providing application developers with guidance about where and how their programs can be improved. Better statistical techniques are needed for analyzing performance data and for understanding the causes and effects of differences among process performance. We have begun investigating bi-clustering techniques for identifying key differences between groups of processes. A second technique for coping with the number of components and the amount of performance data that can be collected on extreme-scale systems is to select a statistically valid subset of the components and model the members of that subset in detail. Properties of the subset can be used as a basis for estimates of the entire system. Our preliminary research in this area, so far, has explored using statistical techniques for analyzing system availability. The main objective of this research will be to evaluate how well application performance can be characterized and understood without exhaustive examination of performance data by developers. An analysis challenge using message-centric monitoring is to account for indirect second-order performance effects without complete global information. Trace-based systems are able to find such indirect performance effects by paying the cost associated with keeping a global record of system activities across all nodes. Systems based purely on statistical monitoring cannot normally find such problems because there is no causal data and no cross-node data available. Unlike current statistical approaches, message-centric monitoring should be able to account for some of these effects because performance data follows the potential paths of indirect performance interaction. The grand challenge for analysis of performance data to fuse data from processors, other hardware resources, software components, and communication into a form that provides insight into the full range of performance problems in parallel applications. A particular challenge is to achieve the insight possible with space-time diagrams from message traces without exhaustive tracing (which is expensive) or diagrams too large to be rendered. Modeling Application and System Performance and Reliability The modeling of high performance software and hardware systems is highly complex and requires a deep understanding of the interplay of architecture and software at a variety of scales. The PAL team at LANL has focused on manual techniques for macroscopic modeling of parallel programs to gain insight into their expected performance on a range of parallel systems. A major thrust of modeling efforts so far at Rice has been to construct semi-automatically models of application performance at a fine-grain level to understand the interplay of the applications instructions with a microprocessor core and memory subsystem. The resulting performance models can be used for analyzing node performance on both existing and proposed future architectures. In software development, these models can be used to pinpoint particular interactions between hardware and software features that are causing performance loss. Accurate models are a unique tool for architecture design. We propose to develop performance models of programs representative of ASC codes to understand their key performance characteristics and to understand how alternative architectures could improve application performance. A focus of ongoing work is to assess the potential performance benefits and bottlenecks associated with emerging multi-core processors. Key issues of importance include understanding the impact of shared memory hierarchy components. Analysis of application models for multi-core processors should yield insight into what new compiler strategies will be needed to boost efficiency of multi-core chips. This problem may be complicated by active power management of multi-core chips improving the compiler to generate tighter code for multi-core chips may ultimately hurt performance if this causes the core to be clocked slower because of high power dissipation. Modeling Communication Performance We intend to predict the performance of a parallel application as a function of its single node performance and its communication cost. This work will build on Rices infrastructure for constructing models of single node performance. To understand the cost of communication, we must model the communication patterns of the application. We plan to extend our current binary analysis and instrumentation infrastructure to measure the volume of communication at each synchronization point. A synchronization point is defined by a call to a communication function. The user can specify the set of communication functions to be monitored at instrumentation time. For each process of a parallel application, we propose to collect a trace of synchronization events interleaved with the histogram of basic blocks that were executed in each synchronization interval. At each synchronization point, we will collect the size of messages exchanged with each communication partner. We will aggregate the collected data per computation interval, where a computation interval is uniquely determined by the addresses of the call instructions at its two endpoints. For each such interval, we will know the communication functions invoked at its starting point and its ending point, the number of times the interval executed, the distribution of message sizes sent and received at its starting point (stored as a histogram), and the histogram of basic blocks and edges executed during the interval. For each synchronization interval we plan to model the distribution and structure of the histogram of message sizes exchanged at its starting point as a function of node problem size, or/and as a function of the number of processes. This problem is similar to modeling the distribution of memory reuse distances seen by a memory reference, and we plan to use a similar modeling approach. Like reuse distance, communication volume is a machine independent application characteristic. Thus, the models of communication patterns constructed in this fashion are portable across architectures, and for predictable applications, we expect the models of communication histograms will be highly accurate. To compute computation cost between synchronization points, we will need to modify our instruction scheduler to reconstruct executed paths in partial control flow graphs. To determine the overlap between communication and computation, the user must specify for each communication function if it is synchronous or asynchronous. For synchronous synchronization points, there is no overlap between communication and computation, and the execution cost of an interval is the sum of its aggregated communication cost and its aggregated computation cost. For asynchronous synchronization points, a simple model for the execution time is to consider the maximum between the communication and computation costs, plus an eventual communication start-up cost. However, such a model is likely to under-predict the execution time because for each synchronization interval we have a distribution of exchanged message sizes, and an aggregation of basic blocks executed during all traversals of current interval. This information is not enough to match the communication cost and computation cost of each traversal. It may happen that for some executions of the interval the cost of communication is larger than the computation cost, while for other executions the computation cost is higher. In such a scenario neither aggregate cost is completely hidden. Understanding the level of overlap for arbitrary programs is a difficult problem and will require further study. Modeling Failure and Integrated Performance/Failure During the past year, the UNC team has implemented a framework where failure and performability models can be implemented and evaluated. The Failure Indicator Toolkit (FIT) is a library that supports gathering of health-related diagnostic information, developing statistical models of normal system health, and determining the probability that recent health information indicates a failure mode. FIT collects health data via the HAPI library, and it can also be stored for offline analysis and experimentation. FIT currently features a single failure predictor that makes a binary failure/no failure prediction based on a threshold applied to a single health information datum. We propose to implement sophisticated statistical models for health classification including hidden Markov models, neural networks, and Bayesian probability approaches. Each model will be automatically trained on known good health data. Once the model is trained, failure prediction takes place whenever new health data is available. The FIT framework makes comparing the predictive accuracy of different models on the same health data an easy task, allowing for quick determination of which model(s) work best with the data. As part of this work, we will develop rules-of-thumb for matching health information sources to appropriate failure predictors. Finally, we will develop and expand performability models that combine both fault-tolerance and performance for systems containing thousands of nodes. These models will include total time to solution as a function of failure modes and probabilities. Improving Performance and Reliability Raw performance and reliability data are the inputs to analysis tools. From manual, semi-automatic and automatic analysis come insights into the causes of poor performance or reliability and opportunities to address these problems. Our goal is to develop tools and approaches that can help applications achieve high performance even when system components fail or applications are subject to other system constraints. Strategies for automatic performance steering based on performance and fault models offer the potential to enable long-running programs to repeatedly adjust themselves to changes in the execution environment perhaps to opportunistically acquire more resources as they become available, to rebalance load or adapt to component failures. Moreover, measurement of environmental conditions on nodes promises to allow users and schedulers to balance checkpoint frequency and partition allocation based on failure likelihood. In addition, validated performance contracts among applications, systems, and users that combine temporal and behavioral reasoning from performance predictions, previous executions, and compile-time analyses are one promising approach. This work will explore using performance contracts to guide the monitoring of application and resource behavior; contracts will include dynamic performance signatures and techniques for locally (per process) and globally (per application and per system) evaluating observed behavior relative to that expected. Improving Reliability through Fault Tolerant Algorithms Coping with the failure of system and application components is difficult. We propose to create a framework, which we call FT-LAP, that will simplify the development and implementation of fault tolerant software libraries by providing support for detection process faults, and recovery of data in the presence of multiple process failures and high failure rates. The FT-LAP framework will exploit diskless checkpointing, which offers unique advantages for resiliency and performance in the massively parallel environments that we are targeting, build on fault tolerant MPI (FT-MPI)a state of the art implementation of the MPI standard constructed by a team led by Dongarra that has extended failure semantics and corresponding mechanisms to enable applications to detect and recover from faults at levels of functionality previously unattainable, and take an algorithm-centered approach to fault tolerance that maximizes programmer opportunities to utilize application specific knowledge to achieve the kind of unprecedented efficiency and performance that future high end computing environments will demand. To survive multiple process failures by using as small processor redundancy as possible, we propose to use error-correcting techniques to encode the local checkpoint data and store the encoded data into some dedicated checkpoint processes. Diskless checkpointing requires that each process maintain a local copy of the checkpoint data in the local memory of each process, so that a consistent state can be reconstructed during recovery. Diskless checkpointing approach is especially appropriate for iterative methods. In most iterative methods, the application will synchronize on each iteration and modify only a small amount of its state between iterations. This implies that only a very small amount of data needs to be checkpointed and hence a very low fault tolerance overhead is possible. If a smaller amount of extra memory is available in each process, then we propose to use a reverse computation-based technique combined with error correction coding. To enable a seamless computing environment offering interchangeability of compute resources and scalability from the desktop to thousands of (heterogeneous) processors including coarse grained multiprocessor supercomputers, we will develop a framework for the development and implementation of fault tolerant software libraries for the core linear algebra area that will enable easy diskless checkpoint, detection process faults, and recovery of data in the presence of multiply process failures We propose to incorporate into libraries the techniques runtime support for adaptive strategies to allow diskless checkpointing during the course of execution, produce a design for extensions to provide recovery and process initiation in the presents of faults, exploit both loss-less and lossy approaches in recovery from faults in the execution of the libraries, and produce a set of "recovery libraries" for use in application studies, and evaluate their use in practical settings. Improving Application Reliability via Adaptivity and Recovery To support applications on large-scale systems, more active techniques are needed that enable systems and applications to continue operating even when some components fail. Without such schemes, the mean time to failure (MTBF) of systems with tens of thousands of commodity components, even when operated as quasi-independent partitions, will continue to decline and will severely limit solution feasibility for complex problems. As noted earlier, health monitoring and failure prediction tools alone enable post-mortem analysis of failures. To increase the MTBF for applications and systems, online techniques are also needed that enable developers and applications to adapt program behavior. The use of tens of thousands of commodity components to increase peak performance will lead to intolerable failure rates without appropriate power management. Monitoring and analysis of power-performance profiles of scientific applications will be needed to optimize power consumption while maintaining performance. This will be particularly true for systems with multi-core chips. A second way health monitoring information can be used is to improve reliability is to let an application use it to choose hardware partitions and checkpoint frequencies based on the applications own resilience to failures and models of anticipated failures. We propose to develop batch queue selection mechanisms that will allow application developers to select batch queues based on likely failure probabilities and modes. Intuitively, applications that are more resilient to transient errors (e.g., memory word or message bit upsets) due to internal consistency checks or varying memory footprints are more likely to complete successfully on less reliable hardware. We will also develop an adaptive toolkit for application checkpointing that will choose checkpoint frequencies automatically as multiples of a user-specified threshold. For example, if an application could potentially checkpoint its state every K iterations, the adaptive toolkit would trigger a checkpoint every cK iterations, where c is determined based on acceptable overhead and probability of failure. Evaluating the Promise of Architectural Alternatives As architectural complexity rises, with multicore chips, network interface processors, complex storage hierarchies (memory and I/O), and the rise of special purpose co-processors, understanding the relative performance and reliability advantages that accrue from these alternatives is increasingly critical. We propose to develop a suite of tools that can be used to assess these tradeoffs. In particular, Los Alamos and other laboratories are evaluating alternate architectures that exploit FPGAs and graphics processors (GPUs) for high-speed computing. These systems combine FPGAs or GPUs with standard nodes, offloading computation intensive routines to the auxiliary processor. With this additional complexity comes additional failure modes, power and temperature management (GPUs are notoriously hot) and options regarding data reuse and computation overlap. We propose to explore the monitoring, adaptation and reliability issues associated with these hybrid systems, using the tools and techniques outlined in this proposal. In particular, we plan to use data gathered using message-centric monitoring to analyze application performance and to analyze architectural issues to understand performance tradeoffs among improvements in network bandwidth, computing power, and storage performance. In addition, by understanding the interplay of instructions in an applications core loops, understanding the temporal and spatial locality (or lack thereof) of memory reference patterns, one can assess whether an application can be more effectively performed with an FPGA, a GPU, a processor-in-memory or a vector unit rather than a microprocessor core. Our aim is to provide semi-automatic tools for assessing alternatives for arbitrary applications by combining static and dynamic information into detailed loop-level models of application performance. Project Tasks FY06: Develop and deploy techniques and tools for call-stack sampling based monitoring and analysis of parallel codes. Design and prototype measurement and analysis techniques for emerging architectures. Focus: multi-core processors. Design and implement software interfaces for using off-processor counters to assess application performance and reliability. Develop and validate stratified sampling for scalable monitoring of performance and system health. Evaluate message-centric monitoring of LANL-relevant applications on large-scale systems. Use message-centric monitoring to drive load-balancing decisions on dynamic applications. Integrate tools for vertical and horizontal message-centric monitoring. Evaluate statistical methods for analyzing performance data from extreme-scale systems. Develop a prototype that semi-automatically produces models of communication performance for parallel applications using a combination of static and dynamic analysis. Develop basic "micro-climate" sensor infrastructure for rack and machine room monitoring. Assess prototype failure indicator and prediction mechanisms for predicting likely component failures. Develop adaptive checkpoint schemes based on failure indicators. Assess and couple prototype batch queue selection mechanisms with failure indicator toolkit. Design and prototype diskless checkpointing in which the checkpoint processes participate in the computation and rearrange data when a failure occurs. Use p processors for the computation and have k of them hold checkpoint. Evaluate algorithms for coordinating local checkpoint/restart in which processors hold backups of neighbors. Evaluate processor/co-processor system performance based on FPGAs and GPUs. FY07: Extend and apply micro-climate senor infrastructure and integrate with health/performance monitoring toolkits. Adaptively tune online message-centric monitoring to balance accuracy and overhead. Use online monitoring information for detecting operating system-caused performance anomalies. Design, and prototype integrated analysis capabilities that provide a global view of application performance by combining information from communication analysis with node-level performance data. Develop software to determine the checkpointing interval and number of checkpoint processors from the machine characteristics using historical information. Migrate tasks if a potential problem is noticed. Coordinate and couple integrated health/performance monitoring and failure prediction with checkpointing, back queue selection and adaptation policies. Develop and extend processor/co-processor adaptability (i.e., the ability to trigger execution of adaptive libraries on processors or co-processors based on expected performance gains). FY08: Design and prototype measurement and analysis tools for emerging architectures. Focus: forthcoming HPCS architectures. Expanded evaluation of integrated adaptation and performance/reliability schemes with target applications. Evaluate processor/co-processor infrastructure with target applications. Evaluate checkpointing with "real applications" and investigate "lossy" algorithms. Generalize the prior prototypes to provide a library of routines to do the diskless checkpointing. Relevance to Weapons Program The findings from this research, as well as tools and software infrastructure developed as products of this effort, are expected to benefit all ASC application teams. The aim of this research is to provide ASC application teams with better methodology and tools for measuring application performance, resource utilization, and system health, better techniques and tools for analyzing program and system performance and reliability, insights into the interplay between applications and systems that leads to better mapping of applications onto current and emerging extreme-scale systems, strategies and mechanisms to support construction of failure-resilient programs, and insights into the nature of extreme-scale parallel architectures and applications that will help improve the design of future systems. Better tools and techniques to monitor and analyze application performance on current-generation architectures are a good investment for both the short and long term. In the short term, they help pinpoint bottlenecks in existing applications; this enables scientists tune applications for better performance. Over the long term, understanding performance bottlenecks and reliability limitations in todays applications and systems will focus research on practical software and hardware technologies that hold the most promise for improving performance and scalability of future applications on the next generation of computer systems. Budget Total Proposed Budget: $578,816 Breakdown by Site: Rice: $216,016; UNC: $233,000; UNM: $36,600; UTK: $93,200 Compiler Technology for High-Performance Computing Supported Personnel: Project Leads: John Mellor-Crummey, Rice, HYPERLINK "mailto:johnmc@cs.rice.edu"johnmc@cs.rice.edu; Ken Kennedy, Rice,  HYPERLINK "mailto:ken@cs.rice.edu" ken@cs.rice.edu, Keith Cooper, Rice,  HYPERLINK "mailto:keith@cs.rice.edu" keith@cs.rice.edu Other Supported Personnel: Rice: Tim Harvey, Guohua Jin, Robert Fowler LANL Point of Contact: Rod Oldehoeft,  HYPERLINK "mailto:rro@lanl.gov" rro@lanl.gov Vision Programming extreme-scale systems efficiently is very difficult. Difficulties exist at two levels: writing parallel programs and generating efficient code for processing elements. Writing parallel programs is hard because parallel programming models today require users to manage resources of parallel systems at a very detailed level. When using MPI the dominant programming model for writing scalable parallel programs programmers must partition application data structures and computation, add data movement and synchronization, and manage storage for non-local data. Because of the explicit nature of MPI communication, significant compiler optimization of communication is impractical. For this reason, all responsibility for optimizing communication performance falls to application developers. For high efficiency, application developers must choreograph asynchronous communication and overlap it with computation. This complicates parallel programming significantly. Higher-level programming models that simplify the construction of parallel programs are needed. However, for high-level programming models to succeed, they must meet a number of requirements. First, they must be ubiquitous; otherwise they will be unattractive to application developers. In practice, this means that in addition to being available on extreme-scale systems, they must also execute on laptops and clusters. Second, high-level programming models must be expressive and conveniently support a wide range of algorithms and programming techniques. Ideally, high-level programs should be easy to write, read, maintain, and reuse. Third, the efficiency of code generated from high-level programs must be comparable to that of the best hand-coded low-level parallel programs. Finally, to attract application developers, high-level models must have a promise of future availability and longevity. Regardless of how programs are written for extreme-scale systems, solving large-scale problems requires using processor nodes as efficiently as possible. Failure to do so would increase the time to solve problems on processor ensembles of a fixed size or require larger systems to maintain the same time to solution. The effects of efficiency gains made at the level of individual nodes are multiplicative. For this reason, compiler technology for generating efficient code for processor nodes is of critical importance. Compiler Technology for Parallel Systems Today, fragmented programming models such as MPI require application developers to explicitly manage separate address spaces for each processor as well as manage communication and data movement. High-level programming models that abstract away the details of how computation is partitioned as well as data movement and synchronization are needed if we want to increase the productivity of application developers. Whether programming for single chip multiprocessors such as Cell, or large-scale parallel systems, one should be able to use a simple programming model and compilers should take care of the details of managing data movement and synchronization without sacrificing much of the performance that could be achieved by hand coding. Global address space programming models offer the simplest abstraction for expressing parallel programs. We believe that global address space programming models are the appropriate model for programming a wide range of parallel systems from single-chip multiprocessors to emerging large-scale parallel systems such as Crays Red Storm and systems that we expect to arise out of DARPAs HPCS project. SPMD global address space programming models such as Co-array Fortran (CAF) and Unified Parallel C (UPC) offer promising near-term alternatives to MPI. Programming in these languages is simpler: one simply reads and writes shared variables. With communication and synchronization as part of the language, these languages are more amenable to compiler-directed communication optimization. This offers the potential for having compilers assist effectively in the development of high performance programs. Research into compiler optimizations for SPMD programming languages offers the potential of not only simplifying parallel programming, but also yielding superior performance because compilers are suited for performing pervasive optimizations that application programmers would not consider employing manually because of their complexity. Also, because CAF and UPC are based on a shared-memory programming paradigm, they naturally lead to implementations that avoid copies where possible; this is important on modern computer systems because copies are costly. We propose to explore the utility of SPMD global address space programming models for parallel programs of interest to the LANL. Beyond explicitly parallel SPMD programming models, data-parallel models such as High Performance Fortran and Crays Chapel language offer an even simpler programming paradigm, but require more sophisticated compilation techniques to yield high performance. Research into compiler technology to increase the performance and scalability of data-parallel programming languages as well as broaden their applicability is important if parallel programs are to be significantly simpler to write in the future. For parallel programming models to succeed, their use and appeal must extend beyond just extreme-scale machines; therefore, sophisticated compiler technology is needed for these languages to make them perform well on todays relatively loosely-coupled clusters as well as tightly-coupled petascale platforms of the future. We propose to investigate compiler technology that makes it possible to execute high-level data parallel programs efficiently on systems ranging from single-chip multiprocessors such as Cell to commodity clusters. Compiler Technology for Node Programs Achieving high levels of performance on modern computer architectures requires careful planning and execution at every level of the tool chain that translates the applications source text into executable code for the target machine. Various tools must identify large-grain parallelism and use it to occupy multiple processors. They must design appropriate strategies to pass data between the distinct threads of the computation, insert the code to implement the needed communication, and adjust the strategy to balance communication and computation. The tools must ensure that the code, as translated, has a memory reference pattern that takes appropriate advantage of the multiple levels of memory hierarchy, blocking for one or more levels of cache and for register reuse. The final steps of translation map this carefully planned behavior into the instruction set of the target machine and try to balance the needs of the computation against the processors actual resources. To achieve high performance, all of these steps must be done well. At this final level of translation, backend optimization and code generation algorithms strongly influence the final performance of an application. The major concerns at this level of translation include: 1) keeping the functional units busy, 2) hiding the latencies inherent in the processor and memory system, and 3) ensuring that the final code uses the processor effectively. The current generation of open-source compilers (and their commercial cousins) routinely produces code that obtains 5 to 10% of the processors peak performance. In part, this underperformance arises from the use of backend optimization and code generation algorithms that were developed for systems with much simpler performance characteristics. In this project, we will examine several specific backend compiler problems that appear to have an impact on the performance of ASC applications. In particular: Changing the instruction mix: In the instruction stream of a running application, the mix of operations that the processor encounters should match the set of functional units that the processor provides. A mismatch between application operations and processor capabilities leads to saturation for one set of functional units and starvation for another. We have begun an investigation into automatic techniques that use backend optimization to alter an applications instruction mix. Our initial work has focused on critical loops of Sweep3d. This example suggests that the problem will require a coordinated attack by a small suite of backend optimizations. Aggressive rematerialization: The high costs associated with accessing memory present a significant performance challenge on modern systemsone that will continue to grow as memory latencies increase and as the number of CPU cores per chip increase. Techniques that can reduce the number and frequency of memory accesses should improve application performance. Rematerialization is a code generation strategy that recomputes certain values when doing so is less expensive than accessing them from memory. Today, it is applied in register allocators to values that can be computed in a single operation and whose operands are all available a standard that misses many profitable opportunities. We will develop a standalone rematerialization algorithm (outside the allocator) that uses a tunable metric to determine profitability. The resulting technique should directly reduce memory accesses and indirectly reduce cache disturbance from scalar loads. Scheduling and register allocation: A major open challenge in code-generation algorithms lies in coordinating the behavior of instruction scheduling and register allocation. Prior work in this area has produced algorithms that coordinate their behavior but favor one process over the othereither underallocating registers to reduce constraints on the scheduler or limiting the schedulers ability to move operations when such motion increases demand for registers. Early work by Schielke shows the potential for a truly fair technique to find improvements in both scheduling and allocation reducing stalls and spills at the same time. Unfortunately, his technique relied on extensive randomization and hundreds of trials, making it impractical for routine use. We will explore algorithms that solve these problems together, working in the context of the Callahan-Koblenz register allocator that we have built for LLVM. All of these explorations will be conducted in the code context of one of the two open-source compiler systems, Open64 or LLVM, that we believe are viable candidates for future development. We will work with external collaborators on LLVM and Open64 to help ensure that there are viable open source compilers for directly transferring compiler research to the ASC program. In each investigation, we expect to apply the lessons that we have learned in designing adaptive techniques as part of the LACSI Autotuning effort. We will test the algorithms on ASC-related codes. Proposed Milestones FY06: Report intermediate results of ongoing work on techniques to change the instruction mix in performance critical loops. (Quarter 1) Perform experiments with additional codes for instruction-mix modification (Quarters 24) and develop a strategy to deliver this technology. (Quarter 4) Develop an initial aggressive scheduler for LLVM. (Quarters 1 and 2) Refine parallel compiler analysis and code generation techniques for dense matrix codes to efficiently support programs with strided alignments. Design and prototype data-parallel compiler technology to map application codes to single-chip multiprocessors with explicitly-managed memory (such as Cell). FY07: Design and implement a tunable rematerialization pass for LLVM (Quarter 2), followed by experimental evaluation and report (Quarter 4) Initial version of algorithm for combined scheduling and allocation (Quarter 2) Design and implement prototype compiler and run time support for general block distributions. Design and implement a prototype compiler that uses data-parallel compiler technology to map application codes to ensembles of single-chip multiprocessors with explicitly-managed memory (such as Cell). FY08: Refine a combined scheduler and allocator (Quarters 1 and 2); distribute as part of the LLVM compiler (Quarter 4) Distribute aggressive rematerialization pass for LLVM (Quarter 2) Develop prototype compiler and run time support for user-defined block distributions in high-level models for parallel programming. Relevance to Weapons Program One aim of this research is to produce efficient high-level programming models suitable for future ASC applications. A second aim of this research is to develop compiler technology that will make it possible to use compute nodes in extreme-scale systems efficiently. The findings from this research and software infrastructure, developed as products of this effort, are expected to benefit all ASC application teams. Budget Total Proposed Budget: $346,925 Breakdown by Site: Rice: $346,925 Components Component Architectures for High Performance Computing Supported Personnel: Subproject Leads: Ken Kennedy, Rice,  HYPERLINK "mailto:ken@cs.rice.edu" ken@cs.rice.edu; Jack Dongarra, UTK,  HYPERLINK "mailto:dongarra@cs.utk.edu" dongarra@cs.utk.edu, Lennart Johnsson, UH,  HYPERLINK "mailto:johnsson@cs.uh.edu" johnsson@cs.uh.edu Other Supported Personnel: Rice: Zoran Budimlic, Rob Fowler, Guohua Jin, Cheryl McCosh, John Mellor-Crummey, UH: Lennart Johnsson, Postdoc/Research Scientist to be hired LANL Point of Contact: Craig Rasmussen,  HYPERLINK "mailto:rasmussn@lanl.gov" rasmussn@lanl.gov Vision The goal of component architectures research is to make it easy to develop high-performance applications by using compiler-based tools to integrate components from pre-existing libraries. By providing modularity through well-defined component interfaces, component integration systems permit scientists and software developers to focus on their individual areas of expertise: scientists can concentrate on integrating applications by gluing domain-specific components together using some form of scripting language, leaving the development of those components to expert programmers. In addition, because components foster more code reuse, they provide an increased economy of scale, making it possible for resources to be shifted to areas such as performance engineering, testing, and platform adaptation; the result is improved software quality, portability, and application performance. A fundamental obstacle to this strategy is that scientific application developers, particularly those at Los Alamos National Laboratory, cannot afford to sacrifice significant amounts of performance for this clearly useful functionality. An important objective is to produce applications without sacrificing performance relative to hand-integrated codes. To address this problem, the component integration research effort is exploring integration strategies that perform context-dependent optimizations automatically as a part of the integration process. This theme defines a significant portion of the research content of the work described in the remainder of this section. In the strategy we envision, applications would be defined using high-level scripting languages such as Matlab or Python to coordinate invocation of library operations, although traditional languages such as Fortran and C++ could also serve this purpose. Because scripting languages typically treat library operations as black boxes that cannot be optimized to the contexts in which their invocations appear, these systems often fail to achieve acceptable performance levels for compute-intensive applications. One solution strategy that has been successfully employed in previous research is to translate scripts to a conventional programming language and use whole-program analysis and optimization to improve performance to acceptable levels. The main drawbacks of this approach are long script compilation times and the absence of an effective way to exploit the domain knowledge of library developers. To address these problems, this project is pursuing a new approach called telescoping languages, in which libraries that provide component operations accessible from scripts are extensively analyzed and optimized in advance. In this scheme, depicted in the figure below, language implementation consists of two phases. The offline library analysis and preparation phase digests annotations describing the semantics of library routines, combines them with its own analysis to generate specialized variants of each component in the library. In addition, it produces a library-aware optimizer that understands library entry points as language primitives. The script compilation phase can then use the generated compiler to produce an optimized base language program.  We will use this strategy to attack the problem of making component integration efficient enough to be practical for high-performance scientific codes. Of particular importance in this context is the problem of efficiently integrating data structure components (e.g., sparse matrices) with functional components (e.g., linear algebra). We will also explore the use of high-level prototyping languages, such as Matlab and Python, as the scripting languages for application definition. If this effort is to succeed, it must take into account an important reality: many components will be constructed using object-oriented languages, so techniques for optimizing such languages are critical. We plan to invest a significant effort in analysis and optimization of components written in C++, Java, and Python. Research Plan To achieve the project vision, we plan to conduct research that focuses on supporting technologies for component integration, which include: Transformation systems to eliminate overheads due to abstraction. These systems will employ high-level context information to select the right variants of components for a given calling context and employ macro-transformations that replace expensive sequences of component invocation with more efficient sequences in the given context. Component integration systems that automate specialization. We will also explore component integration frameworks that generate specialized versions of certain components for common calling context and substitute those specialized versions, statically or dynamically, in applications that employ those components. A driving problem for this research is to construct component integration frameworks that can efficiently integrate data structure components with functional components. An example would be the integration of sparse versus dense array data structures with certain types of linear algebra operations. This has been an important goal of the generic programming research area, and success will require advances in both component design and transformation-based integration frameworks. In this work we will continue our efforts to collaborate with weapons code projects at LANL. Of particular importance is the collaboration with the Marmot Project, because that project is attempting to employ modern software design and integration strategies to code development. We will continue to execute the draft collaboration plan (described below) that was developed in workshops with the Marmot team. In addition, we will develop new collaborations with the traditional code teams. As a driving problem, our work will focus on an unclassified, export-restricted test code that is representative of LANL codes that combine hydrodynamics with radiation transport. We will also explore important related codes from the Telluride and Marmot projects. With these considerations in mind, we plan to pursue research in four fundamental directions: Advanced Component Integration Systems: This effort will explore the application of telescoping languages technology to the component integration problem, with a particular emphasis on integrating components that support data structures with those that implement functionality. The effort will also consider technologies for optimizing accesses to the component interfaces emerging from LANL weapons-related code development efforts. The long-term goal of this research is to produce a component integration framework that is efficient enough to be accepted by high-performance application developers, such as those in the LANL ASC program. Some specific research challenges in this area include: Exploration of array and mesh abstraction. We will investigate the issue of separating content and layout in an array abstraction. The specific issue is whether it is possible to easily substitute different data layouts for the same abstract data structure without substantively changing the functional components that use them. This research touches on the extensive research in generic programming because it may require some coding standards for functional components to achieve maximum flexibility. However, all data-layout-specific code will be encapsulated with the data structure component. Preliminary work on this effort will be conducted in the context of Matlab (or Python), beginning with the definition of a generalized array data structure that incorporates data distribution. Specific array distributions for sparse matrices will be explored as a way of understanding the crucial performance issues. (This may contribute to work on a parallel version of Matlab, described below.) Once the Matlab array prototype has been explored, we will focus on ASC mesh data structures with the goal of demonstrating a prototype with adequate efficiency for use in production codes based on these components. The ultimate goal is to make it possible to quickly substitute different mesh data structures in a code without rewriting the functional components and vice versa. The development of new specialization strategies for components. As a specific challenge, we will explore static and dynamic approaches to reduce the time and space required to deal with specialization of multiple materials in cells. This problem arises because many codes iterate over all potential materials that might occur in a cell, even though most cells will have far fewer than the maximum number of materials. If pre-specialized code can be generated for the cells with small numbers of materials, it may be possible for the right specialized variant to be selected statically or dynamically, saving substantial space and time. The goal is to permit the developer to specify the handling of materials in the most general way possible, and let the compiler and run-time system handle the specialization. These strategies can be further enhanced by compiler-based specialization to sparse data structures and by reorganization of computation to deal with block of cells with similar properties at the same time. Demonstration of these techniques in specific applications of interest to ASC and LANL. We will continue to seek appropriate applications within the weapons program. To that end, we will use Sage and Sweep3D to represent a standard hydrodynamics and radiation transport application. We will also continue to work with the Marmot and Telluride projects to find representative applications that can be analyzed at the participating universities under export restrictions. Construction of Efficient Specialized Libraries for Component Integration: This effort will focus on the generation of component libraries that can be incorporated into high-performance applications and can be the bases for domain specific problem-solving environments. Significant issues will be flexibility and adaptability of the components to both the computations in which they are incorporated and the platforms on which they will be executed. The effort will also focus design strategies for efficient data structure components. Under this project we plan to pursue the following specific research directions Tools for Pre-optimization of Libraries: We will explore some component libraries that are used within the weapons program to identify opportunities to pre-specialize them to expected calling context. One early target for this work will be Trillinos. Mining of Traditional Applications: We will explore automatic strategies for mining traditional applications and libraries to construct component libraries that might be employed in other applications. In particular, we are interested in exploring the automated translation of older applications into script-based domain languages, in which components of the original program form the library underlying the domain language. Annotation of component libraries for efficient integration via a telescoping languages framework: This effort will develop annotation strategies, along with the associated transformation systems, that will make it easier to optimize component accesses within application and to replace sequences of calls to library components by more efficient sequences. Factoring of Components for Efficient Recombination: This work will involve research into the proper structure of libraries so that efficient variants can be synthesized from component pieces once the calling context and target platform is understood. Compilation and Optimization of Object-Oriented Languages: Object-oriented languages like C++, Java, and Python have a number of attractive features for the development of rapid prototyping tools, including full support for software objects, parallel and networking operations, relative language simplicity, type-safety, portability, and a robust commercial marketplace presence leading to a wealth of programmer productivity tools. However, these languages have significant performance problems when used for production applications. In this effort, we are studying strategies for the elimination of impediments to performance in object-oriented systems. To achieve this goal, we must develop new compilation strategies for object-oriented languages such as C++, Java, and Python. This should include interprocedural techniques such as inlining driven by global type analysis and analysis of multithreaded applications. This work would also include new programming support tools for high-performance environments. Initially, this work has focused on Java, through the use of the JaMake high-level Java transformation system developed at Rice in collaboration with the LANL CartaBlanca project. This system includes two novel whole-program optimizations, class specialization and object inlining, which can improve the performance of high-level, object-oriented, scientific Java programs by up to two orders of magnitude. In the next phase of research, we will consider how to adapt these strategies to develop tools and compilation strategies that would directly support the code development methodologies to be used in the Marmot effort. Examples include not only the application of object inlining and class specialization, but also the use of type analysis to support the elimination of dynamic dispatch of methods, a major problem for high-performance codes written in C++. We will also consider ways to apply these compilation strategies to Python used as a high-level application prototyping system. Rapid Prototyping in High-Level Scripting Languages: In this effort we will explore the use of scripting and problem-solving languages such as Matlab and Python for the development of high-performance applications. A major problem is how to implement such languages on parallel machines. We plan to pursue two interrelated strategies in this effort. The first will explore a client server architecture in which the server is a parallel cluster and the client is a desktop computer. The second is a compiler-based strategy. These are described in more detail in the following paragraphs. Matlab optimization via cluster-based computation. We focus our attention on how to provide parallel computation capabilities to such environments that would allow for seamless access to hardware and software resources for numerical linear algebra. Instead of focusing on a particular implementation, we are exploring the design space of such an interactive environment such as Matlab, Python, and Mathematica and the consequences of particular design choices. We have developed a prototype implementation of our ideas with emphasis on the performance perceived by the end user. In our design, we consider primarily a client-server architecture where the server is envisaged as a cluster and the client is a simple desktop computer. At the moment, the basic infrastructure of our design has been implemented and successfully applied to a dense matrix factorization and iterative solution method in Matlab and Python environments. Our preliminary tests show that the overhead of remote execution can be offset when problem sizes become prohibitive for a sequential environment and it is possible to reap the benefits of parallel computation. A compiler strategy for scripting languages. This sub-project will explore translation of applications from well-know rapid prototyping languages, such as Python and Matlab, to C and Fortran. The goal of this effort is to avoid the necessity for hand recoding of Matlab or Python components to achieve high performance within conventional applications. We have already developed a prototype framework for compiling Matlab that employs a powerful type analysis algorithm. We propose to expand this work in two directions. First, we will explore extending the compilation strategy to Python. Second, we will explore extending parallelism to Matlab and Python by building on the High Performance Fortran compilation technology we have already built at Rice. The result will be a Matlab variant from which efficient Fortran plus MPI can be generated. (The parallel Matlab effort is leveraged through funding from the NSF ST-HEC effort. In this project we hope to apply this work to ASC codes.) Tasks FY05 tasks under the previous LACSI funding for components: Produce a simple component integration system based on Matlab as a scripting language, which would include the Matlab-to-C compiler developed under earlier LACSI support. (Quarter 3) Design the component integration strategy for supporting the Marmot application development and produce a report on the design. (Quarter 2) Develop a preliminary implementation for distributed matrices in Matlab and possibly Python. (Quarter 4) Deliver prototype performance modeler for heterogeneous components. (Quarter 1) Design and develop preliminary tools to support object-oriented programming in high performance applications, delivering a report describing them and experiments on their effectiveness. (Quarter 4) FY06: Produce a more sophisticated prototype component integration system that would support both Matlab and C++ components. (Quarter 4) Develop a plan for component specialization, with a focus on the multiple materials effort and deliver a technical report on this strategy. (Quarter 2) Produce a report on specialization strategies for Trillinos and other libraries. (Quarter 3) Produce a definition of the first annotation language for component integration. (Quarter 2). Develop a preliminary version of the JaMake optimization system for optimization of components in C++, including object inlining. (Quarter 4). Demonstrate a more sophisticated implementation of distributed matrices in Matlab and possibly Python, supporting more than one distribution. (Quarter 4) FY07: Demonstrate advanced component integration on one ASC application. Produce a hand-coded version of the proposed multiple-materials strategy and deliver a report on how this will be automated. Develop, using a combination of hand and automatic methods, specialized versions of components from Trillinos or another suitable library and demonstrate these in a prototype application. Produce a report on potential for mining existing codes for use in modern component libraries. Develop a more sophisticated version of the JaMake optimization system for optimization of components in C++, including an advanced type analysis strategy, and produce a report on its effectiveness. Demonstrate translation of prototype parallel Matlab and Python programs to C and integration with existing ASC frameworks. FY08: Conduct experiments to explore the effectiveness of advanced component integration strategies, including optimizations based on annotations, on a variety of applications, producing reports as appropriate. Produce a prototype system for automatic specialization of programs and demonstrate it on a simplified multi-materials code. Deliver a component transformation and optimization tool for C++ based on JaMake. Conduct experiments on the efficiency of integrating prototypes written in Matlab and Python within realistic code frameworks. Relevance to Weapons Program Software quality is a critical concern for weapons codes. Component integration systems provide a widely-accepted approach to software organization, increasing both reliability and flexibility. Performance, both in terms of speed and memory requirements, remains an important concern for weapons codes. This research will explore how to increase code quality and programmer productivity without undue sacrifice of performance. Rapid prototyping is an important tool for exploring new algorithms and implementations in scientific codes. Matlab and Python are becoming widely accepted for prototyping. Automating their translation and integration into C and Fortran frameworks without loss of performance (even parallel performance) could dramatically increase productivity of weapons code developers. Budget Total Proposed Budget: $315,180 Breakdown by Site: Rice: $213,080; UH: $55,500; UTK: $46,600 Automatically Tuning and Retargeting High-Performance Components and Libraries Supported Personnel: Project Leads: Keith Cooper, Rice,  HYPERLINK "mailto:keith@rice.edu" keith@rice.edu; Jack Dongarra, UTK,  HYPERLINK "mailto:dongarra@cs.utk.edu" dongarra@cs.utk.edu; Lennart Johnsson, UH,  HYPERLINK "mailto:johnsson@cs.uh.edu" johnsson@cs.uh.edu; Ken Kennedy, Rice,  HYPERLINK "mailto:ken@cs.rice.edu" ken@cs.rice.edu Other Supported Personnel: Rice: Rob Fowler, Tim Harvey, John Mellor-Crummey LANL Point of Contact: John Thorp (acting),  HYPERLINK "mailto:thorp@lanl.gov" thorp@lanl.gov Vision For many years, retargeting of applications for new architectures has been a major headache for high performance computation. As new architectures have emerged at dizzying speed, we have moved from uniprocessors, to vector machines, symmetric multiprocessors, synchronous parallel arrays, distributed-memory parallel computers, and scalable clusters. Each new architecture, and even each new model of a given architecture, has required retargeting and retuning every application, often at the cost of many person-months or years of effort. The fundamental question addressed by this research is: Can we build components with the built-in ability to adapt with high performance to new computational platforms? One model for the kind of component tuning we envision is the Atlas system, which uses substantive amounts of computation to provide versions of a computational linear algebra kernel that are highly tuned in advance to different machines. If this approach can be extended more generally to components of all kinds, it would help avoid the enormous human costs involved in retargeting applications to different machines. To date, we have been able to extend the success of automatic tuning to a few domains such as linear algebra and fast Fourier transforms. We propose to change that by pursue a project to use advanced compilation strategies and sophisticated component designs, along with extensive amounts of computing, to accelerate the process of restructuring and tuning components for each new high-performance architecture. Research Plan One way to produce excellent code for a new platform is to expend substantive computation time to try different restructuring and compilation strategies on smaller test data sets, picking the best combination for each component on the target architecture. We proposed to pursue three general strategies that use this approach. In each of these, a common methodology is to formulate the problem as an optimization in which the running time of the component on the test data is the objective function. Because the parameter spaces are so large, strategies are needed to reduce the tuning time: these strategies include the use of heuristic search and pruning the search space using compiler models. We propose to continue the work on how to reduce the cost of empirical tuning strategies to manageable levels. Structural reorganization. Structural reorganization is typically applied to loop nests within a component. Each computation-intensive loop nest is restructured to take advantage of a variety of parameterized degrees of freedom, including amount of parallelism and cache block size. Then, based on an automatically generated set of experiments operating on small training data sets, the tuning system picks the best parameters for a given new machine. This approach has been used in the Atlas system to produce tuned versions of the LAPACK BLAS needed to port that linear algebra package to new systems. We propose to extend this work to systems that can automatically generate the tuning search space for new library components, applying standard tuning methodologies, such as loop blocking, unrolling, unroll-and-jam, loop fusion, and storage reduction. This work will build on preliminary research at Rice (LoopTool) and Tennessee (Atlas 2) that has constructed prototype systems to search through the parameter spaces for selected optimizations. To date, this work has demonstrated that a significant fraction of optimal performance can be achieved with heuristic searches that require a factor of ten less tuning time. The preliminary work, some of which was reported in the 2004 LACSI Symposium, employed only two transformations. We propose to extend these methods to the full range of transformations that can improve the performance of loop nests through source-to-source transformations. In addition, we proposed to explore ways to prune the search spaces further through static compiler models and by partitioning the individual searches for different loop nests so that the tuning can be done more efficiently. This latter strategy will build on the performance measurement and analysis tools described elsewhere in the LACSI proposal. Finally, the Rice and Tennessee efforts will collaborate on methodology and strategies and will use the results of this effort to construct at least one retargetable application of interest to DOE and the ASC program. Function decomposition. In some specialized domains, notably FFT, large computations can be decomposed into smaller specialized codelets, tuned for the target platform, which can be recomposed into excellent algorithms when the actual data sizes are known at program initiation time or run time. This strategy has been successfully employed in FFTW and UHFFT to produce excellent results. We propose to explore how this can be extended to other computational domains with well structured (de)composable operations, such multi-grid techniques, approximation schemes for various forms of discretizations, such as finite element, finite volume and finite difference discretizations, and the discretizations and operators in the methods developed by Yuri Kuznetsov and LANL collaborators. After an evaluation of the applicability of the technique in important LANL applications including the methods developed at UH by Kuznetsov, one application will be chosen as a target for applying our techniques for code adaptation. Compilation reorganization. A modern optimizing compiler consists of a series of passes that translate and improve the code. Each pass performs some specific function. The user can control some aspects of the compilers behavior; other aspects of its behavior can only be changed through source-level modification of the compiler. Variations in the applications presented to the compiler and the architectures of the machines that it must target ensure that no single setting for all of these options is best for all situations. Prior research, conducted in part with LACSI funding has shown that using adaptive search to discover the right compiler configuration can improve performance over any compiler that uses a single configuration for all programs. Specifically, this work has shown: A factor of 20 reduction in function evaluations is needed to find good solutions for the compilation sequence problem from improving the search techniques. A factor of 2 to 4 reduction in the overall running time of the search resulted from using models (rather than execution) to evaluate the impact of adaptive choices. (Note that this reduction is orthogonal to the factor of 20 from improved search.) Using adaptive techniques inside a single complex optimization, such as inline substitution, can produce significant improvements over fixed-heuristic solutions. Preliminary (unpublished) results show that simple adaptive schemes provide significant improvements over traditional heuristics such as those found in gccs inliner. The specifications found by adaptive search, either for the compilation sequence problem or the inlining problem, vary significantly from application to application. Thus, no single universal heuristic or solution works as well as the application-specific answer found by adaptive search. Other researchers have shown results consistent with ours, using a variety of compilers, environments, and optimization criteria; these papers suggest that the expected range of improvements is 20 to 30% when optimizing for performance and 10 to 20% when optimizing for code space. In this work, we will explore mechanisms for delivering adaptive tools to end users, particularly the ASC user community at LANL. We envision two approaches: Our work on automatically derived optimization sequences, requires a complete compilation system to deliver. We are working to build adaptive choice into the LLVM system, a new open source compiler developed at Illinois; our goal is to make it an attractive alternative to gcc that happens to support adaptive compilation. Our work on adaptive inlining fits nicely into a source-to-source framework. Unfortunately, we know of no suitable open-source Fortran 90 parser to serve as the base for such a system. We will build a Fortran 90 source-to-source inliner that includes a robust open-source parser for the language. This tool will let ASC developers use the adaptive inliner on their codes. We will spend the first year of this project developing infrastructure that builds toward these two goals. We will continue to work inside LLVM to improve overall code quality and to install the features needed to support adaptive compilation. We will develop a Fortran 90 parser and prettyprinter to serve as the base for the adaptive, source-to-source inliner for Fortran 90. Autotuning Workshop. To facilitate collaborations on automatic tuning strategies, we will hold a workshop at one of the LACSI sites (or at the LACSI symposium) on automatic tuning. All of the LACSI-funded efforts described in this section will participate. In addition, we will invite other nationally prominent researchers in this field. Tasks FY05 (what we promised in the current fiscal year): Feature Detector. This component collects timing data and examines it for special features. It may interpolate to fill in gaps or request additional timings to enhance complicated parts of timing curves. (Quarter 1) Investigate search space optimization and automatic search space generation; expand to heterogeneous clusters. (Quarter 2) Develop and implement UHFFT-style code generation and optimization for a limited set of multi-grid methods to be chosen in collaboration with LANL staff for maximum benefit to the ASC program within given resource constraints. (Quarter 2) Implement ATLAS-style tuning to sparse linear algebra and cluster numerical libraries. (Quarter 3) Incorporate optimizations into targeted applications; cultivate second round of applications for optimization. (Quarter 4) FY06: Develop a prototype automatic code improvement tool, based on LoopTool that includes loop and register blocking plus loop fusion and produce a report on its effectiveness. (Quarter 2) Investigate search space methods to optimize the choice of "best" implementation. Assess the benefits of UHFFT style code generation and adaptation for components in key ASC applications involving (de)composable operations; Target one type of component for implementation and evaluation of our code generation and adaptation technique. Distribute improved back-end components for LLVM. (Quarter 1) Thesis on the algorithms needed for adaptive inline substitution and preliminary experiments with optimization selection and ordering in LLVM. (Quarter 2) Develop a source-to-source front-end for Fortran 90 that can be distributed under an open-source license. (Quarter 4) Host a LACSI Workshop on Automatic Tuning. (time to be determined). FY07: Develop a more sophisticated automatic code-tuning tool, based on LoopTool, that incorporates model-based pruning and includes more optimizations; deliver a report on its effectiveness on applications representative of ASC codes. Investigate ATLAS-like optimization for collective message operations to tune for the specifics of the parallel system. Extend and assess the code-generation and adaptation techniques to a dominating range of multi-grid methods for weapons codes. Begin work on embedding adaptive behavior into another complex optimization. Build adaptive inliner for Fortran 90 using source-to-source Fortran 90 system produced in FY06 and test it on ASC codes. Experiment with adaptive optimization and selection using LLVM and ASC codes. FY08: Deliver a sophisticated automatic component tuning tool that incorporates loop and register blocking, loop fusion, array copying, scalar replacement and array restructuring; demonstrate it on at least one ASC code. Produce a production quality multi-grid adaptive library with assessment of use in at least two weapons codes. Develop and test techniques for distributing adaptive search across multiple compile steps in the code development process. Distribute adaptive inliner. Demonstrate second complex adaptive optimization on ASC codes. Relevance to Weapons Program Retargeting ASC applications to new platforms is a labor-intensive task, with most of the effort going to tuning; automating this task will provide a huge boost in programmer productivity. The Atlas experience demonstrates that automatic tuning can provide performance advantages over simple hand tuning (in situations where extensive hand optimization is impractical); hence, this approach could deliver much better performance for ASC applications on new platforms. Budget Total Proposed Budget: $290,207 Breakdown by Site: Rice: $188,107; UH: $55,500; UTK: $46,600 Systems Scalable Optimized Network Protocol Stacks Supported Personnel: Investigators: Patrick Bridges, UNM,  HYPERLINK "mailto:bridges@cs.unm.edu" bridges@cs.unm.edu; Alan Cox, Rice,  HYPERLINK "mailto:alc@cs.rice.edu" alc@cs.rice.edu; Arthur B. Maccabe, UNM, maccabe@cs.unm.edu; and Scott Rixner, Rice,  HYPERLINK "mailto:rixner@rice.edu" rixner@rice.edu LANL Point of Contact: Ronald Minnich, CCS-1, rminnich@lanl.gov Vision The number of clusters in the top 500 supercomputers has been growing since 1983. Currently 60% of the top 500 supercomputers are clusters and 35% of these clusters use commodity interconnects such as Gigabit or Fast Ethernet and run commodity system software and protocols such as Linux and TCP/IP. The low cost and easy availability of these hardware/software combinations makes them useful for the capacity computing systems that support everyday scientific development and lead to later capability computing. Despite this, commodity cluster hardware and system software is still under-optimized for the parallel computing needs of LANL application scientists, limiting the applications that run well on these systems. In addition, current commodity network software does not have optimized support emerging commodity hardware such as single chip multiprocessors (CMPs). The main objective of this research is to improve the scalability and performance of network protocol processing within the operating system to increase the performance of existing high-performance applications in commodity clusters and expand the set of applications that can viably run on current and emerging versions of these systems. To do so, research is needed on a variety of related issues, including: comparison and quantification of the performance of custom and commodity protocols on HPC applications, placement and scheduling of a single connections protocol processing functionality across network interface cards and a host processor, i.e. protocol splintering and offload, and scalability of protocol processing across multiple host processors in emerging CMP systems. Proposed Research Protocol Research Testbeds HPC systems have historically offloaded portions of protocol processing onto the network interface card (NIC), and used custom protocols for data transport. This trend continues today; Infiniband NICs, for example, are currently supported by a custom software stack comprising hundreds of thousands of lines of code. Well-tested commodity protocols such as TCP, in contrast, do not have the large development and maintenance overhead of these custom software stacks, but have typically run only on the host processor. Several groups including our own have shown benefits to both mainstream and HPC applications from offloading portions of commodity protocol processing onto dedicated processors or ASICs. While commodity protocol offload research is important and has great potential for improving the performance and cost-effectiveness of commodity clusters, there are few testbeds for continuing this research. NIC vendors have closed or are closing their on-NIC programming interfaces, and the remaining systems that do support on-NIC processing are increasingly out-of-date. The ACENIC Gigabit Ethernet card, for example, has substantially higher per-packet latencies than current Gigabit Ethernet cards such as the (non-programmable) Intel EEPRO 1000, and several times less bandwidth than modern Infiniband cards. To address this problem and facilitate further research on offloading commodity protocol processing using techniques such as splintering, checksum offload, and NIC virtualization, we propose to construct two different networking testbeds: an FPGA-based Ethernet NIC, and an Infiniband-based software/hardware testbed based on dual Opteron motherboards with bus expansion slots and Infiniscale NICs from PathScale, Inc. The FPGA-based NIC will be an appropriate platform for exploring NIC technology realizable in the near-term and the resource limitations inherent to such platforms. In contrast, the Infiniscale-based testbed will give us a platform for exploring longer-term offload and OS-restructuring issues. In addition to research protocol splintering and protocol scalability described below, which will be enhanced by the availability of this testbed, other HPC-related research will also be based on this testbed. For example, by making our device driver for the custom NIC present itself as a straightforward high-speed Ethernet device, this testbed will allow the direct comparison of the performance of Infiniband protocols with TCP/IP protocols running on the same fabric. If current TCP/IP implementations are not sufficient to compete with the Infiniband protocol stack, this testbed will also allow us to characterize what optimizations are necessary to both the operating system software and the protocol itself to achieve competitive performance while maintaining compatibility with commodity systems. Protocol Offload and Splintering Offloading protocol processing onto a NIC has been very successful both for traditional applications using TCP/IP and for HPC applications, though it has been explored primarily in the context of traditional applications. Recently, we have studied the effect of a particular offload strategy, splintering, which drastically reduces the protocol processing overhead associated with TCP/IP, freeing up CPU resources for use by HPC applications. More work is needed to precisely understand the costs and benefits of different protocol offload strategies, including splintering, traditional full-protocol offload, partial protocol offload techniques such as ack and checksum offload, and other techniques such as offloading only demultiplexing. Our first goal is to precisely quantify the benefits of protocol splintering to existing HPC application. Our previous research has shown, using models and prototype implementations, the potential benefits of splintering under the assumption that there is blocking time in most HPC applications for hiding the overheads of protocol processing. To fully understand the benefits of splintering, we need to measure existing HPC applications starting with well-known benchmarks such as the NAS and ASCI Purple benchmarks to find the extent to which protocol processing can be hidden in blocking application calls. This work will start by measuring protocol processing overheads and opportunities for protocol overhead hiding in these applications. As the networking testbeds described in the previous section become available, we will validate these measurements on the testbed and measure the achieved performance improvement of TCP/IP splintering in real HPC applications. Our second goal is to study other methods of offloading portions of individual connections besides splintering. For example, past work on early demultiplexing by the PIs and other researchers has shown benefits from using the NIC for demultiplexing packet arrivals. These benefits were primarily to resource management in network servers; in the commodity HPC world, however, effective MPI matching with early TCP demultiplexing has the potential to avoid large memory copy costs currently incurred by TCP-based MPI implementations. Longer term, we would also like to explore more dynamic methods of splintering that determine at runtime which parts protocol processing, and its associated data, should be offloaded to the NIC, which should be run on the host processor, and which should be deferred until the application blocks. Prior to conducting this research, however, we must finish characterizing existing offload systems as described previously. Protocol Processing Scalability in CMP Systems As mentioned previously, current technology trends are pushing microprocessor architectures towards single chip multiprocessor systems. In CMP systems, each processor on a node may actually have less performance than a monolithic uniprocessor, but each node will likely include tens of processors. Therefore, the scalability of network protocol processing is an important direction for research in network protocol performance optimization. Ideally, a scalable network protocol stack would improve performance for all of the servers' network connections and support a higher connection capacity as processors are added. The purpose of this research is to improve the scalability of state-of-the-art operating system techniques through improved hardware and software design. Operating systems researchers and designers have used two different synchronization approaches to achieve scalable networking performance: data synchronization and control synchronization. Both techniques focus on enabling parallelism by allowing independent intrakernel functions to proceed simultaneously, but they differ in the way they organize per-thread access to kernel functions and data structures. Restricting the manner in which threads are allowed to access kernel resources can reduce synchronization overheads, but such restrictions may lead to load imbalances. The data synchronous approach, as taken by FreeBSD 5 and Linux 2.6, allows multiple user-level thread contexts to access kernel functions and data as necessary to service network requests. However, thread accesses to shared data structures and the network interface require synchronization. Scalability and performance efforts have been focused largely on creating fine-grained data structures that reduce the likelihood of lock contention and increase the number of accesses that are thread-private. The control synchronous approach, as taken by DragonflyBSD and Solaris 10, remaps accesses to major kernel subsystems to dedicated kernel threads based upon connections. Upon entry into the network subsystem, a network request is remapped to a kernel thread via the scheduler; accessing the scheduler requires synchronization, but by isolating connections to specific kernel threads, all subsequent accesses to connection metadata are thread-private and require no synchronization. Incoming packets are uniquely mapped to connections via the (source address, destination address, port) tuple, and outgoing requests are mapped to connections via the socket interface. We intend to quantify and compare the overheads and scalability of the two parallelization techniques. To isolate the effects of parallelization techniques on network performance, we intend to modify the FreeBSD 5 kernel to implement the control synchronous mechanisms in addition to the existing data synchronous mechanisms. With this infrastructure we can measure and compare the two techniques on a 4-way AMD Opteron multiprocessor system over a 10 Gigabit Ethernet network. Furthermore, we expect the communication between the network interface and the kernel to limit the scalability of both schemes. The control synchronous scheme opens the opportunity for the network interface to streamline that communication by demultiplexing connections to their controlling threads directly on the network interface. With the FPGA-based NIC described above, we will develop the appropriate support for such parallelized network stacks. Breakdown of Work and Yearly Tasks Rice University is focusing primarily of horizontal decomposition of the protocol stack for multiprocessor scalability and the associated near-term FPGA testbed. University of New Mexico is focusing primarily on vertical decomposition of protocols through techniques such as offload and splintering, as well as the Infiniscale testbed that will enable further research into more aggressive offload techniques and high-end NIC capabilities. Both Universities, however, will utilized the techniques and testbeds developed by the other through close collaboration to enhance their research and, as a result, their contributions to LANL-relevant codes and programs. FY06: Implement control synchronization mechanisms within the FreeBSD kernel. [Rice] Explore the scalability limits of data synchronization and control synchronization. [Rice] Quantify the scalability limits and determine the bottlenecks of each scheme for publication. [Rice] Implement an Infiniscale-based testbed for exploring various techniques for protocol offload. [UNM] Use this testbed to implement various levels of intelligent NICs to quantify the costs and benefits of different levels of protocol processing, including NICs that do only unreliable data transport (e.g. Ethernet), NICs that provide RDMA in addition to simple Ethernet-like semantics, and NICs that provide more general early demultiplexing capabilities. [UNM] Compare the existing Infiniband protocol stack with a TCP/IP stack over different virtual NICs to quantify the potential costs and benefits of the custom Infiniband protocol stack. [UNM] Analyze NAS and ASCI Purple benchmarks to determine the amount of protocol overhead currently seen by the application and the amount of time available for hiding protocol processing overhead in blocking application calls. [UNM] FY07-FY08: Implement an FPGA-based network interface to enable the exploration of alternative communication mechanisms between the operating system and the network interface. [Rice] Explore and implement improved communication mechanisms between the operating system and the network interface to improve the scalability of both the data synchronization and control synchronization schemes. [Rice] Experimental measurement of the value of splintering to HPC applications. [UNM] Performance comparison of full protocol offload, splintering, and demultiplexing-only offload. [UNM] Dynamic protocol offload and splintering based on measured application and protocol performance. [UNM] Relevance to Weapons Program The proposed testbeds will drive the design of next generation networking hardware. Commodity clusters are vital for providing the necessary computation capacity for the weapons program. Improving the communication performance of commodity networks for these clusters will significantly increase the performance/price ratio of these systems. Multi-thread, multi-core processor architectures are rapidly emerging as the dominant architectural organization. Improving the scalability of network processing is critical in order to exploit the performance improvements provided by these architectures. Budget Total Proposed Budget: $153,029 Breakdown by Site: Rice: $61,529; UNM: $91,500 Fault Tolerant Messaging Supported Personnel: Project Leads: Jack Dongarra, UTK,  HYPERLINK "mailto:dongarra@cs.utk.edu" dongarra@cs.utk.edu; Arthur Maccabe, UNM,  HYPERLINK "mailto:maccabe@cs.unm.edu" maccabe@cs.unm.edu Other Supported Personnel: UNM: Patrick Bridges LANL Point of Contact: Tim Woodall, twoodall@lanl.gov Vision As systems are constructed from larger numbers of components, long running computations will need to become much more tolerant of hardware faults encountered during their execution. In this proposal we focus on the faults that are observed during message passing and propose to explore two dimensions of this space. First, we consider approaches to masking transient communication failures and, in particular, the correct placement of protocol processing to mask these failures and provide a reliable message transport. Second, we consider process fault tolerance at the application level. A Framework for End-to-End Reliable Message Transport in Open MPI Current MPI implementations make static design tradeoffs between end-to-end reliability and performance, emphasizing one over the other. Emphasizing performance alone assumes a completely reliable network, a potentially unrealistic assumption in the case of newer, unproven networking technologies. Over emphasizing the end-to-end principal may result in duplicating a completely reliable transport protocol in application space even when the network experiences very low bit error rates. End-to-end reliability comes at a cost and this cost should directly reflect the operating environment. Our goal is to develop a flexible reliability framework for Open MPI that allows system and application designers to choose the reliability/performance tradeoff appropriate to their hardware and software configuration. There are currently no MPI implementations that address both end-to-end data reliability and adaptable network failover. MPI designers are influenced first and foremost by performance considerations. End-to-end data reliability and network failover may be considered a high cost item, unnecessary in the presence of reliable network interfaces. Such a viewpoint disregards the end-to-end principle, the long runtimes of many MPI jobs where bit error rates become a factor, and the early adoption of many unproven networking technologies in the HPC world. With this in mind, we have developed a reliability framework that allows the system and application designer to choose the appropriate level of reliability detection and recovery. This framework allows for heterogeneous network device failover and guarantees end-to-end reliability. The framework is also adaptable to various network topologies, allowing varying granularity of error detection and recovery. Open MPI is a community MPI implementation that is built using a flexible modular framework that allows complete subsystems to be chosen and changed at runtime. Our current design is based on several key Open MPI abstractions. In Open MPI, the Point-to-Point Transport Layer (PTL) is an abstraction of a single transport type, such as TCP over Ethernet or GM over Myrinet. The Point-to-Point Management layer (PML) is responsible for managing one or more PTLs. The PML is responsible for delivery of an MPI level message; the PTLs are responsible for delivery of fragments of the MPI message. The first design decision was to move as much of the reliability as possible into the PML, which we have named RPML for (Reliable Point-to-Point Management Layer). This was done to simplify the PTLs as much as possible; implementing reliability in each PTL requires duplicate functionality to manage and adds a substantial hurdle for PTL writers to overcome. This choice does come at a cost, we must abstract the reliability layer to accommodate a variety of network transports, potentially loosing transport specific optimizations. First we introduced an RPML abstraction, a Virtual Fragment (vfrag). Each MPI level message is segmented into one or more RPML level vfrags. The vfrag acts as both the unit of retransmission and acknowledgment, allowing the application designer or system administrator to choose the maximum vfrag size up to the size of MPI level message. Each vfrag is assigned to a single PTL and may be larger than the PTLs internal fragment size. This allows the PML a convenient method of monitoring the health of a single PTL in terms of number of dropped or corrupted vfrags. When the health of a PTL is in question (due to excessive dropped/corrupted vfrags), the PML may choose to retransmit the vfrag on another PTL if available. While this functionality has not yet been implemented, the overall architecture has been designed to allow for this. Each vfrag also has one or more checksums associated with it. This allows for meaningful error detection regardless of the size of the vfrag. If the sender is using rendezvous, a list of vfrag headers is sent to the receiver along with the send request. On the match, the receiver initializes these vfrag descriptors. If the sender is using an eager send, the vfrag headers are sent with the first fragment of the message. When a PML schedules some portion of the vfrag to be transmitted, a timer is set. This allows us to detect when a PTL is no longer making progress on the vfrag. On expiration of the timer, the vfrag is retransmitted. On scheduling of the last bytes of the vfrag, the PML sets an ACK timer, expecting an acknowledgment of the vfrag from the receiver. On receipt of the ACK, the timer is removed; on expiration of the timer, the vfrag is retransmitted. Retransmission of a vfrag requires a handshake or reschedule request. This is required to allow the PML to potentially choose a different PTL to retransmit on, and the receiver must be notified of this. Research plan We propose to work on improving and developing the following subsystems within Open MPI and Open RTE (Run Time Environment): Tunable Collective Communications. We have developed several optimized collective communication packages (ATCC/OCC) together with testing and optimization harnesses. These packages allow for the optimal choice of collective communication algorithm and parameters depending on both the applications needs as well as the target systems parameters. This work will involve adapting the OCC algorithms to work within the current and future collective communication subsystems of Open MPI. Additional work will also include adapting SAIS (Scalable Application Instrumentation System) to OCC. (SAIS instruments communications in much greater detail than defacto instrumentation packages, and allows a collectives package to be tuned in optimal time for a set of target production applications, rather than exhaustively for all possible communications. Building a high bandwidth and low latency point-to-point driver for the IBM LAPI interface. This will allow Open MPI to be used efficiently on and across IBM Scalable Power systems. Work will also include a POE interface to Open RTEs resource management system. Low level profiling of (near hardware) point-to-point communication subsystems. This can be thought of as PAPI for RDMA based systems. Possible integration with the KOJAK system in order to allow the user to precisely identify the bottlenecks in the application communications. Design a message scheduler manager that is optimized for driving RDMA point-to-point subsystems to support MPI-2 Single sided communications efficiently. This work would be the layer above the LAPI interface (described in second bullet). Create a new message routing layer for the Open RTE system that provides for scalable fault tolerance and dynamic routing of messages in large-scale systems. Open RTE is responsible for startup, connection information transfer, state management, IO forwarding, etc. All of these functions require scalability and resilience in internal communication. Vertical fault tolerance. Most fault tolerant schemes are horizontal in their effect and action across all the processors during check pointing, restarting, etc. When combining more than one fault tolerant approach and method it becomes necessary to integrate the actions of the processes both horizontally across the entire application as well as within each application process vertically. Integrating the actions of the different layers will require a modular framework that both coordinates the different layers as well as makes choices about which combinations of methods are appropriate. We propose to build a framework and integrate process level fault tolerance (as in FT-MPI) with system level checkpointing (as used in LAM/MPI and MPICH-V). Tasks FY06: Design of a framework that allows developers to choose the appropriate tradeoff between reliability and performance. Integration of reliable transport protocols into Open MPI. Tunable Collective Communications. Building a high bandwidth and low latency point-to-point driver for the IBM LAPI interface. FY07: Demonstration of the reliability framework, illustrating benefits for reliable and unreliable networks. Low level profiling of (near hardware) point-to-point communication subsystems. Design a message scheduler manager that is optimized for driving RDMA point-to-point subsystems to support MPI-2 Single sided communications efficiently. FY08: Integration of fault masking and fault tolerance approaches. Vertical fault tolerance. Relevance to weapons program An integrated approach to fault masking and fault tolerance will be critical to the ability to complete long running computations on systems that are constructed from many thousands of components. Budget Total Proposed Budget: $101,500 Breakdown by Site: UNM: $54,900; UTK: $46,600 Computational Science Advanced Numerical Methods for Diffusion Equations in Heterogeneous Media on Distorted Polyhedral Meshes Supported Personnel: Project Lead: Yuri Kuznetsov, UH,  HYPERLINK mailto:kuz@math.uh.edu kuz@math.uh.edu LANL Point of Contact: Misha Shashkov,  HYPERLINK mailto:shashkov@lanl.gov shashkov@lanl.gov Vision The diffusion equation is one of the most frequently appearing partial differential equations in applications ranging from radiation transport and heat transfer to flows in porous media and fluid dynamics. A number of new discretization methods for the diffusion type equations have been invented and utilized recently. The mixed finite element and mimetic finite difference methods on arbitrary polyhedral meshes are among them. These methods were developed and evaluated on ASC relevant test problems by scientists at LANL and the University of Houston within the LACSI supported project. Accurate discretizations and efficient iterative solvers for diffusion equations on distorted polyhedral meshes in heterogeneous media are a challenging problem. Major ASC codes utilize polyhedral meshes to provide flexibility for numerical simulation in complex shaped geometry. The faces of a distorted polyhedral cell usually are not flat. Then, a natural question concerns the minimal number of DOF (degrees of freedom) for the flux vector function and for the solution function (intensity, concentration, temperature, etc.) needed for the accurate discretization of the diffusion equation. Another problem arises when the medium inside a polyhedral mesh cell is split into two different types of states, for instance, solid and liquid. Accurate discretizations for the case of mixed cells are not known. Important applications to the problems with free boundaries and internal interfaces are obvious, in particular, in the TELLURIDE project. The physical solutions (density, intensity, etc.) and the solutions of the underlying diffusion equations are positive functions while the solutions in most of the discretization methods may have negative values. This contradiction is a serious problem for discretization methods. Finally, the development of efficient preconditioned iterative solvers for the algebraic systems arising in polyhedral discretizations of the diffusion equations remains a very important topic for the ASC related applications. Research Plan To address the problems involved in obtaining accurate and efficient solution methods for diffusion equations in strongly heterogeneous media on distorted polyhedral meshes we propose the following topics for a three-year (20062008) research project. This plan is a natural continuation of the recent successful cooperation of numerical mathematicians at LANL and the University of Houston. Polyhedral Discretizations with Minimal Number of DOF The interfaces between neighboring polyhedral cells are usually approximated by sets of triangles. In the known discretizations, to guarantee the accuracy of the discrete solution we have to assign separate flux DOF for each of the triangles. For instance, for a distorted cubic mesh we assign four DOF for each of the interfaces between cells. Recently, it has been observed theoretically that only three independent DOF on an arbitrary interface are sufficient to guarantee the required accuracy. In the case of the distorted cubic meshes, we expect that only two independent DOF would be needed. In this project, we plan to develop, theoretically investigate, and evaluate on test problems relevant to ASC applications new polyhedral discretization methods with minimal DOF for the flux vector function on the nonflat interface boundaries between arbitrary shaped polyhedral cells. Polyhedral Discretizations for Mixed Cells Discretization methods for the diffusion equations with mixed polyhedral cells is a topic of growing practical interest. We propose to extend the recently developed polyhedral discretizations to the case when the diffusion tensor, the absorption coefficient, and the right-hand side in the diffusion equation are discontinuous inside polyhedral cells. We have several ideas regarding how the extension can be done, including a special homogenization procedure. The algorithms to be developed will be evaluated on test cases relevant to the TELLURIDE project at LANL. Nonnegative Discrete Solutions to the Diffusion Equations The solution function of a diffusion equation with a nonnegative source function and right-hand side functions in the boundary conditions is always a positive function. The solution of the discrete equations that approximate the diffusion equation on a polyhedral mesh frequently has negative values in the nodes where the solution is close to zero. Those values do not have physical meaning. In this part of the project, we propose to investigate several approaches to designing nonnegative discrete approximations to the positive solutions of the diffusion equation. These are to reformulate a discrete problem as a constrained minimization problem in terms of variational inequalities and to develop iterative algorithms for its implementation, to develop and investigate projection/repair algorithms for obtaining the discrete solutions, and to investigate the range of applicability of the existing polyhedral discretizations and their possible modifications to guarantee nonnegativity of the discrete solutions. The algorithms to be developed are subject to preserving the discrete conservation laws. Efficient Preconditioned Iterative Solvers for Polyhedral Discretizations In this part of the project we continue our recent efforts to design and investigate efficient and robust preconditioners for the matrices arising in polyhedral approximations of the diffusion equations. Priority will be given to multilevel substructuring preconditioners with applications to problems in strongly heterogeneous media. The proposed preconditioners will be evaluated on test cases relevant to ASC applications. Tasks FY05 (These are from the existing project): Implement the proposed polyhedral discretization method and evaluate its accuracy and efficiency on 3D test problems relevant to ASC applications. Deliver a technical report with results of numerical experiments. Investigate convergence properties of the proposed methods and to derive a posteriori error estimation for polyhedral discretizations of the diffusion equations. Develop, investigate and evaluate on selected test problems the new multilevel preconditioner. Deliver report with description of preconditioners to be developed and results of numerical experiments. FY06: Develop and investigate discretization methods with minimal number of DOF for 3D diffusion equations on strongly distorted polyhedral meshes. Evaluate the method with minimal number of DOF on test problems relevant to ASC applications and deliver report with results of numerical experiments. Develop, evaluate, and investigate algorithms of constructing nonnegative discrete approximations to the solutions of 2D diffusion equations. Develop and investigate polygonal discretization methods for 2D diffusion equations with mixed materials inside mesh cells. FY07: Develop, investigate and evaluate new multilevel preconditioners for mixed finite element method with minimal number of DOF; deliver report with results of numerical experiments. Develop and investigate polyhedral discretization methods for 3D diffusion equations with mixed cells. Evaluate polyhedral discretization methods for diffusion equations with mixed cells on test problems relevant to ASC and TELLURIDE projects, and deliver report with results of numerical experiments. FY08: Develop and evaluate efficient preconditioned iterative solvers for 3D diffusion equations with mixed cells; deliver report with numerical results. Develop and investigate algorithms for constructing nonnegative polyhedral approximations to the solutions of 3D diffusion equation in heterogeneous media. Evaluate algorithms for nonnegative approximations on test problems relevant to ASC applications; deliver report with numerical results. Relevance to Weapons Program Polyhedral discretization methods with minimal number of DOF will be used in Project B to reduce the size of the systems of algebraic equations. Polyhedral discretizations for diffusion equations with mixed cells will be used in TELLURIDE and other ASC related projects to improve accuracy of discrete solutions. Nonnegative discrete approximations to positive solutions of diffusion equations are essential to provide the physical meaning of simulation results for several ASC related projects. Budget Total Proposed Budget: $150,000 Breakdown by Site: UH: $150,000 Validation and Verification Using Code-Based Sensitivity Methods Supported Personnel: Project Lead: Mike Fagan, Rice,  HYPERLINK "mailto:mfagan@rice.edu" mfagan@rice.edu Unsupported Collaborators: LANL: Rudy Henninger LANL Points of Contact: Rudy Henninger,  HYPERLINK "mailto:rjh@lanl.gov" rjh@lanl.gov; Ralph Nelson,  HYPERLINK "mailto:ran@lanl.gov" ran@lanl.gov; Dave Korzekwa,  HYPERLINK "mailto:dak@lanl.gov" dak@lanl.gov; Jim Sicilian,  HYPERLINK "mailto:sicilian@lanl.gov" sicilian@lanl.gov; Doug Kothe,  HYPERLINK "mailto:dbk@lanl.gov" dbk@lanl.gov (administrative contact) LANL Priority: Validation and Verification Los Alamos develops and employs computer models of complex and dangerous physical phenomena to augment (and sometimes replace) experimental methods. Therefore, the correctness of the computer simulation results is crucial. Consequently, LANL has established a priority labeled 'Validation and Verification' to ensure the viability of computer results. Based on the LANL Validation/Verification priority, the overall goal for this project is to develop and improve methods for the validation and verification of numerical software. General Strategy to Achieve the Research Goal Before elucidating our project strategy, we note that Validation and Verification is a very broad concern, and there are a host of methods and techniques that might be employed. Some Validation/Verification techniques may be applied in general cases. Other techniques are very specific. Consequently, Validation/Verification practitioners must employ a 'toolbox' approach. With this observation in mind, our strategy for achieving the research goal is to focus our research effort on a particular set of tools in the Validation/Verification toolbox called 'code-based sensitivity methods'. Briefly, code-based sensitivity methods combine techniques from program analysis, numerical analysis, and symbolic computation to generate augmented computer models that enable various validation and verification techniques. One widely-used augmentation is automatic differentiation. Automatic differentiation tools augment users programs with code that computes (true analytic) derivatives. This augmentation is extremely useful for Newton's method-based validation techniques. To date, Los Alamos has employed Adifor, an automatic differentiation tool for Fortran 77 programs, in Newton's method-based validation efforts for some hydrodynamics codes and some reactor safety codes. In addition, Adifor90, an automatic differentiation tool for Fortran 90, is being tested on a metal casting code. 3-Year Horizon The 3-year horizon for this research expands on the success of Adifor-based validation efforts. We envision the results of the project in 4 major categories: Improved differentiation algorithms, improved language coverage, improved integration of code-based sensitivity with the software development process, and new sensitivity augmentations. Improved Differentiation Algorithms The current Adifor differentiation algorithms can be (and are being) improved in the following areas: better automation of the recompute vs. store for adjoints, better detection and use of sparsity, detection of symmetry (self-adjoint) and linearity, improved higher order derivative methods, better handling of pointers and dynamic memory management, and direct augmentation of macros and templates. Improved Language Coverage We would like to cover more of the programming languages used by designers. The most popular requests are C/C++, Python, and Java. In addition, we would like to cover assembly language so that 3rd party code (without source) can be validated and verified as well. Improved Integration of Code-based Sensitivity with the Software Development Process We would like to integrate code-based sensitivity into the software development process, probably as a plug-in to a programming environment. For example, the integrated environment could enable: unit tests verifying that roundoff error for the test cases is acceptably low, method of manufactured solutions (MMS) unit tests that use differentiation-enabled forcing functions, and Newton's method-based validation test suites that are automated. New Sensitivity Augmentations Besides derivatives, there are many other sensitivity measures used in validation and verification. We plan on implementing code-based sensitivity calculations for the following measures: Intervals. Interval methods compute provable upper and lower bounds for a computation. Code-based methods are not well explored. Some of our current research effort constitutes a preliminary investigation, but much more needs to be done. Stochastic Calculus. As an analog to classical calculus, mathematicians have developed calculi for stochastic processes. For example, the Ito calculus handles random walks. Similarly, the Mallevin calculus handles more general processes. Statistical Expansion. As an analogy to Taylor series, random simulations employ other expansions to determine sensitivity properties of functions. One such example is the Edgeworth expansion. We propose to augment programs with statistical expansions, in the same way that classical differentiation can be seen to augment programs via Taylor series. Proposed Research Activities In general, our research activities proceed in 3 steps: determine the mathematical algorithm appropriate for the augmentation under study, implement the step 1 algorithm in our Adifor software framework, and deploy the step 2 prototype tool on a LANL problem of interest. The specific research areas that we plan to work on in the near future are as follows: roundoff error calculations using forward mode; backward error analysis using reverse mode; differentiation of simulations that use random number generation as part of the computation, (Treatment of stochastic simulation is an open problem in AD. Deterministic, Ito calculus, and stochastic expansion (like Edgeworth) are all possible candidates.); and interval analysis, in particular, applying compiler analysis techniques to improve the error bounds of classical interval analysis. Tasks FY05 (Current Year): Apply forward mode AD to a (subset of) Truchas metal casting application. Deploy Adifor 90 to LANL-specified platforms. FY06: Finish forward mode differentiation of remaining Truchas code. Conduct reverse mode AD on a (subset of) Truchas, using improved recalculation. Develop and deploy a preliminary AD tool for C & C++ (Get LANL help for pilot project). Develop and deploy a preliminary AD tool for Python (Get LANL help for pilot project). Initiate a roundoff error bound augmentation pilot project (LANL help). Begin investigation of programming environment integration (eclipse plug-in?). FY07: Continue development of C, C++, Python AD tool suite. Initiate a pilot project for object code differentiation. Begin a study for stochastic calculus via AD. Continue roundoff error bound augmentation. Begin automatic backward error analysis project. Continue programming environment investigation. FY08: Continue development of C, C++, Python AD tool suite. Continue stochastic calculus augmentation. Continue object code augmentation. Preliminary interval augmentation. Continue roundoff error bound augmentation. Continue programming environment investigation. Relevance to Weapons Program Scientists and engineers in the weapons program use computer modeling to study and certify (almost?) all aspects of weapon design and performance. This implies that the computations of the various weapons modeling codes must be trustworthy. Consequently, validation and verification of weapons modeling codes is crucial to the weapons program. This project directly addresses the validation and verification concern. In particular, this project focuses on a specific set of validation and verification techniques called code-based sensitivity. Budget Total Proposed Budget: $119,384 Breakdown by Site: Rice: $119,384 LACSI Management and Community Interaction Supported Personnel: Management Leads: Ken Kennedy, Rice,  HYPERLINK "mailto:ken@rice.edu" ken@rice.edu; Linda Torczon, Rice,  HYPERLINK "mailto:linda@rice.edu" linda@rice.edu Unsupported Collaborators: Management Leads: Andy White, LANL,  HYPERLINK "mailto:abw@lanl.gov" abw@lanl.gov; Rod Oldehoeft, LANL,  HYPERLINK "mailto:rro@lanl.gov" rro@lanl.gov LANL Point of Contact: Rod Oldehoeft,  HYPERLINK "mailto:rro@lanl.gov" rro@lanl.gov LACSI has a strong record of productive collaboration between academic researchers and LANL/ASC researchers. With the advent of the WSR program, and the reorganization of the Simulation and Computer Science Program in ASC, ongoing attention needs to be paid to keeping these interactions strong and relevant to ASC. Operational aspects also need to be maintained. Activities in this area include: maintaining contract operations, promoting interactions between LANL and the LACSI academic sites, improving the visibility of LACSI as a whole, and keeping the LACSI management structures operating. The remainder of this section describes the LACSI management structure and planning process, plans for community interaction, proposed tasks, relevance to the weapons program, and budget requirements. Management and Planning Process Andy White (LANL) directs LACSI in conjunction with Ken Kennedy (Rice), who serves as co-director of LACSI and director of the academic portion of the LACSI effort. Rod Oldehoeft (LANL) and Linda Torczon (Rice) assist the directors as executive directors. The directors make significant decisions with the advice of the LACSI Executive Committee (EC), which includes the site director for each of the six LACSI sites, key LANL personnel, the project directors for the academic portion of each of the strategic thrusts, and the executive directors. The EC currently consists of the following members: Andy White, Chair, Los Alamos National Laboratory Ken Kennedy, co-Chair, Rice University Jack Dongarra, University of Tennessee at Knoxville Bill Feiereisen, Los Alamos National Laboratory Rob Fowler, Rice University Rich Graham, Los Alamos National Laboratory Adolfy Hoisie, Los Alamos National Laboratory Lennart Johnsson, University of Houston Deepak Kapur, University of New Mexico Doug Kothe, Los Alamos National Laboratory John Mellor-Crummey, Rice University Rod Oldehoeft, Los Alamos National Laboratory Dan Reed, University of North Carolina at Chapel Hill John Thorp, Los Alamos National Laboratory Linda Torczon, Rice University The EC is responsible for planning and reviewing LACSI activities on a regular basis and establishing new directions, along with new goals and modified milestones. The EC evaluates progress based on feedback from external reviews and its assessment of the quality of the research performed and its relevance to LACSI goals. Based on the outcomes of internal and external reviews of LACSI research, technology transfer activities, and proposed directions, the EC might identify research projects and technology transfer activities to phase out and propose a collection of research projects and technology transfer activities to be undertaken, along with goals for those projects and activities. LACSI researchers to lead the new efforts would be identified and efforts would be initiated. The resulting efforts would be evaluated in subsequent reviews. The EC meets either in person or by teleconference quarterly and communicates regularly by e-mail. The EC also meets in person at the LACSI Symposium every fall and at the spring review and planning meeting. In FY05, LACSI EC meetings were held on October 13, 2004 (Santa Fe, NM) and February 7, 2005 (Los Alamos, NM). In FY06, the LACSI EC meetings will be held on October 12, 2005 (Santa Fe, NM) and February 8, 2006 (Los Alamos, NM). The LACSI directors, the LACSI executive directors, and key research and administrative personnel from LANL and Rice meet by teleconference at least once per month and correspond by e-mail to handle administrative matters related to proposals, contracts, reviews, invoicing, meeting arrangements, reporting requirements, and other administrative issues that arise. LACSI members also communicate via project planning documents, statements of work, and the results of meetings and reviews, which are posted on password-protected pages on  HYPERLINK "http://lacsi.rice.edu" http://lacsi.rice.edu. LACSI Annual Planning and Research Cycle The annual planning and funding cycle consists of an annual review followed by a planning meeting (called the Priorities and Strategies Meeting), followed by the preparation of a proposal for funding for the entire Institute. This proposal will be submitted to the appropriate research funding entity; under the current plan this is Weapons-Sponsored Research (WSR). Annual Review The LACSI annual review will be conducted by the LACSI Review Board, which will consist of members selected by LANL in consultation with the LACSI Executive Committee. The LACSI Review Board will include members who are both external and internal to LANL; in addition it will include representation from customers as well as computer and computational scientists. Review Board members will serve terms of three years, with approximately a third of the board starting new terms each year. The LACSI Annual Review will typically be conducted in February. The goals of the Annual Review will be to provide feedback to ongoing projects concerning their overall direction and approach, and to review proposals for new projects. New projects that are approved will be folded into the proposal for the next fiscal year, contingent on the availability of funds. To assist in the process of allocating limited funds, the LACSI Review Board will be asked to prioritize the proposed projects. All reviews will be based on two inputs: a proposal (for new projects) or a progress report (for continuing projects), and presentations made during the review. LACSI Priorities and Strategies Meetings In March 2002, the LACSI EC met with LACSI researchers at LANL to discuss methods of addressing issues raised in the 2001 LACSI contract review. The group developed a framework to address long-term strategic thrust areas. Specific objectives were called out as near-term priorities. The objectives were folded into the framework to form a coherent planning view. A description of the long-term vision, framework, and objectives developed in 2002 is available in a document (LAUR # 02-6613) titled Priorities and Strategies. Since 2002, the LACSI EC and Principal Investigators have met annually with senior LANL personnel to revise the framework, priorities, and strategies established at the 2002 planning meeting. The results of each meeting have been incorporated into Priorities and Strategies. The results of the April 8-9, 2003 planning meeting at Rice are included in LAUR # 03-7355; the results of the February 19-20, 2004 planning meeting at Rice are captured in LAUR # 04-7982. Relevance to the LACSI priorities and strategies outlined in the document continues to be a key evaluation criterion used when the EC evaluates progress on LACSI projects. In February 2005, the LACSI EC met with senior LANL personnel to incorporate feedback from the 2004 LACSI contract review in to the planning process. The results of the February 7-8, 2005 planning meeting, which was held at LANL, were folded into the LACSI proposal for the next fiscal year. Future LACSI Priorities and Strategies meetings will typically be conducted in February immediately after the LACSI annual review. The goal of those meetings will be to fold feedback from the LACSI review board into the LACSI planning process, and to prepare a LACSI proposal for the following fiscal year. LACSI Proposal and LACSI Academic Statement of Work Each year, the Executive Committee for the Los Alamos Computer Science Institute will produce a proposal for funding for the next fiscal year. Preparation of this proposal will begin with the Priorities and Strategies meeting. After that time the proposal will be developed into final form over the following 2-3 months for submission to a research funding program (e.g, WSR) in May. Contingent on budget, the LACSI proposal will be funded as a whole. If the final budget is significantly less than proposed, the Executive Committee will collaborate with representatives of the funding program on a reduced statement of work that will constitute the final plan for the next fiscal years activities. This plan will be adapted to form the statement of work for the academic contract and the appropriate input to the planning process for LANL as a whole. The academic statement of work will be finalized by August and funding will be in place in time for the start of the new fiscal year on October 1. Ideally, a standardized mechanism, such as the currently proposed task order strategy, will streamline the process and avoid the necessity for a new contract to be negotiated each year, which has been a major source of problems in the past. Note that LACSI will be funded as a single proposal rather than a selection of projects. This is in keeping with the partnership model described earlier. Reductions in statement of work due to budget considerations will be made by the Executive Committee in consultation with representatives of the funding program. Management of Academic Contract and Subcontracts Rice is the lead site on the contract for all academic partners, with Ken Kennedy serving as director. Linda Torczon assists him as executive director. Rana Darmara assists him as senior project administrator. Each academic site has a site director: Ken Kennedy (Rice University), Lennart Johnsson (University of Houston), Deepak Kapur (University of New Mexico), Dan Reed (University of North Carolina at Chapel Hill), and Jack Dongarra (University of Tennessee at Knoxville). Each of the following strategic thrust areas has a project director: Ken Kennedy (Components), Rob Fowler (Systems), Yuri Kuznetsov (Computational Science), John Mellor-Crummey (Application and System Performance), and Linda Torczon (Computer Science Community Interaction). Significant decisions related to the management of the academic subcontracts are made by the director with the advice of the academic site directors, the academic project directors, and the executive director. Computational Resources The academic partners will be provided with access to ASC computing platforms at LANL on a predetermined basis for development and testing. The process will make it possible to allocate a small cluster of nodes each week and a larger cluster of nodes once a month. It is understood that dedicated access may be needed for key tests and performance analyses. To the extent possible, development work will be centered on the Clustermatic testbed systems installed at Rice, UNC, and UNM. Access to large Clustermatic systems at LANL may be required for full-scale tests. Community Interaction LACSI is a collaborative research effort between Los Alamos National Laboratory, Rice University, the University of Houston, the University of New Mexico, the University of North Carolina, and the University of Tennessee at Knoxville. Effective means of supporting collaborations are important to the success of LACSI. To support collaboration, LACSI will provide a variety of opportunities for researchers from LANL and the academic partner sites to visit each other, to share ideas, and to actively collaborate on technical projects. In addition, LACSI will organize, host, and otherwise support a series of technical workshops on topics related to the LACSI technical vision. This will include a series of workshops at LANL targeted at exposing application researchers to emerging technologies. LACSI will also host an annual symposium to showcase LACSI results and to provide a forum for presenting outstanding research results from the national community in areas overlapping the LACSI technical vision. This will be a traditional conference-style meeting with participation by both LACSI members and scientists from the community at large. During the next year, LACSI members will continue to actively engage in activities associated with high-performance computing conferences, particularly SC 05. Participation will include some combination of research paper and poster presentations, exhibits and presentations in research booths associated with LACSI sites, workshops, and birds-of-a-feather (BOF) sessions. These activities will focus either on presenting LACSI research results to the high-performance computing community or on engaging the high-performance computing community in discussions of topics relevant to LACSIs research mission. LACSI will continue to update and maintain a project Web site ( HYPERLINK "http://lacsi.rice.edu" http://lacsi.rice.edu) where members of the computer science community can peruse descriptions of LACSI projects, access both a list of project publications and a list of academic project participants, and download software produced by LACSI. Information about the LACSI symposium and other LACSI events is also available from  HYPERLINK "http://lacsi.rice.edu" http://lacsi.rice.edu. We will also coordinate a technical infrastructure between LANL and the academic partners, enabling web broadcasting of local technical talks, workshops, and the annual symposium to an off-site audience. Tasks Work with LANL SUP to keep the academic contract on track, and handle budgetary change requests. Organize at least one specialized meeting each quarter at LANL between academic and lab collaborators. Increase the number of summer students at LANL from collaborating universities Organize and operate the annual LACSI Review and Priorities and Strategies meeting at LANL. Organize and operate the annual LACSI Symposium in Santa Fe, including publicity, planning, and follow-up special journal issue. Relevance to Weapons Program The LACSI contract with WSR will have components that have been selected for their technical excellence and relevance to the weapons program. This component keeps the academic research focused and maintains the technology transfer opportunities to the benefit of the weapons program. Budget Total Proposed Budget: $237,059 Breakdown by Site: Rice: $237,059 Budget Summary FY06 Budgets by Institutions and Project1.1 Integrated Performance and Reliability of Extreme-scale Systems Rice216,016UNC233,000UNM36,600UTK93,200Total578,8161.2 Compiler Technology for High-Performance ComputingRice346,925Total346,9252.1 Component Architectures for High Performance Computing Rice213,080UH55,500UTK46,600Total315,1802.2 Automatically Tuning and Retargeting High-Performance Components and LibrariesRice188,107UH55,500UTK46,600Total290,2073.1 Scalable Optimized Network Protocol Stacks Rice61,529UNM91,500Total153,0293.2 Fault Tolerant MessagingUNM54,900UTK46,600Total101,5004.1 Advanced Numerical Methods for Diffusion Equations in Heterogeneous Media on Distorted Polyhedral MeshesUH150,000Total150,0004.2 Validation and Verification Using Code-Based Sensitivity MethodsRice119,384Total119,3845. LACSI Management and Community InteractionRice237,059Total237,059FY06 Total Budget2,292,100  Finding a good specification requires an adaptive search; that specification can be reused repeatedly at low cost. Thus, the code can be maintained in its original, modular form while obtaining the performance benefits of the adaptive optimization. FY 2006 LACSI Project Proposal  PAGE 1 6/2/05 R>?A   56^_`st237\kljhfA56PJUjhfA56PJUhfA56PJjhfAUjxhfAUjhfAU hfA0JjhfAUjhfAU hfA5 hfA5CJhfA5B*ph hfA6hfA/&78 u d?@ABeD#"/. & F"!R{SSS;"1172<2%3(344::oLpLQQdi>;̎jkßğ ARS|}$&/ACƺԺ*+@Aefgvw䳾䢾jhfAU hfA0Jj]hfAUjhfAU hfA0J6 hfA5hfAOJQJ hfA6 hfAPJhfAjhfA56PJUhfA0J56PJ@%O ] B"h"$$$%%% &2&3&)|,,/566:@>X>nB & FnBoFzIIpLOQQSkVVXX] adMgiBikmpp6s!unv'yL{~   ;a5nĎƏǏaMכu AɡY  }]YXZPVŮx< [aزCCC`J/}ƺɻip$Cr/. ^`  & Fh^hǻȻɻ(78YZ[gh~9[bcst,-TгèjhfAUjhfAU hfA56hfA0J56PJjDhfA56PJUjhfA56PJUhfA56PJ hfA6 hfA5 hfA0JjhfAUjhfAUhfA2r-SlD~9'-K!L<~ & F Ncjz+*,Q_=>xy\F & F/. ^`TUVhij)=>defwxyxcz*+PQ->y   f  ) >A&&'0)ĽĦؽݽjhfAUhfA0J56jhfA56U hfA56jhfA56UhfA56PJ hfA6 hfA5hfA hfA0JjhfAUjshfAU>FO  . f  !$&0),-11123w3< & F & F0)c)--@4@=@Q@@@AA&A'A(A6A7AMANAvAwAxAAAAAAAAAAAABBB,B-B/BIBBBBBBBBBBEE#L=LhfA0J56jhfA56U hfA56jhfA56UhfA56PJj܅hfAUj hfAUj:hfAU hfA0Jj{hfAUjhfAU hfA5hfA hfA64w334455 6i66777X89s9::::;<X<<<=>@@=@ ^`<=@{@@@/B|BBBEQGHH#L|OP_S9T5XKZT[[\3^W_X_r` & F & Fx/. ^`=L8T9TQT5XPXccHe\emmppttttuu_uluuuuuuuuuuuuu v v$v6vPvQvuvvvwvvvvvvvN}O}#$WXνννhfA0J56PJhfA56PJjhfAUj-hfAU hfA0Jj^hfAUjhfAUhfAB*KHph hfA5jhfA0J-U hfA6hfAB*phhfA:r`aTbccHefffg*hi}iiij k lGllYmmmmnooo< & FoIpppuqq`r}rrrstttuuJu_uvvvJKrj$S]5ܠEw2 & F & F & F2!̨Xݪ133:[p׮ޮ/qkԼ/. ^` & F & F23:P[oǭܭݭ23Z[\nopĮծ֮׮_`y{dzGHVjkŸŖjhfA56PJUhfA>*B*phjUhfAUhfA56>*B*phhfA56PJjhfAU hfA0JjhfAUjhfAU hfA6 hfA5hfA6ԼXf28N< Fi3#`z{]dh^hd3H X' Lw,7= & F/. ^`}~)*8JKopq   >ϿϿϿϷϬĝϝ}thfA0J56jZhfA56U hfA56jhfA56UhfA56PJ hfA0JjhfAUjhfAU hfA6 hfA5 hfA@hfAhfA56>*B*PJphjhfA56PJUjhfA56PJU,=28d97\Y~, ^`*;gz#|Ag1LUm/.>?@LMNab !;AJ0C 4 {|&' [\ֱֿ֣֟ hfAPJ hfA6PJ hfA5 hfA6hfAjJhfA56UjhfA56UjȎhfA56UhfA56PJ hfA56hfA0J56jhfA56UjhfA56U5&gA0    ' l    4 ` e   N|i & F & FW]'X5aG\./. ^`\m.@Abcdpq ~yy hfA6 hfAPJhfA0J56jhfA56U hfA56jhfA56UhfA56PJj.hfAUjwhfAU hfACJjhfAU hfA0JjhfAUjhfAUhfA hfA5/ ;no8X Aq7b5/.d/ARq}6Caw%5[&\&&&&&&1'R'(2(++../0??GGGGGGGII+I,I-IBICI L LEMFMLMMMcMnMMM hfA5j:hfAUjkhfAUhfA5OJQJ hfAEH hfA0JjhfAUjhfAUhfA hfA6D5"B$%&&3(A(l*,,n1233~5T78:I:>*>d@{@BCDYGFIFIJJyJJ/KK L)LFMMMnMMMMMMMMMMMMM$Ifl J ^`MMMMMM7N8NKNLN^N_NqNrNNNNNNNNNNN=O?O@OAOPOQOROSOcOdOeOfO{O|O}OOOOOOOOOO P P P P!P"P#P%PePgPhPiPyPzP{P|PPPPPPPPPPPPPPPPPmQoQpQqQQQQQQQQQQQQhfA hfA5hfACJOJQJ^MMM"N>..$Ifl kd $$IfִXM""'&&&2&2&&&"    22 4a"N'N(N*N,N4N6N$Ifl $$Ifa$l 6N7N8N9N=--$Ifl kdd$$If4@ִXM""`'''2'2''`'"    22 4a9N=N>N@NANINJN$Ifl $$Ifa$l JNKNLNMN=--$Ifl kdM$$If4@ִXM""''2'2''"    22 4aMNQNRNTNUN\N]N$Ifl $$Ifa$l ]N^N_N`N=--$Ifl kd"$$If4@ִXM""''2'2''"    22 4a`NdNeNgNhNoNpN$Ifl $$Ifa$l pNqNrNsN=--$Ifl kd$$If4@ִXM""''2'2''"    22 4asNtNuNwN}NNN$Ifl $$Ifa$l NNNN=--$Ifl kd$$If4@ִXM""''2'2''"    22 4aNNNNNNN$Ifl $$Ifa$l NNNN=--$Ifl kd$$If4@ִXM""`'''2'2''`'"    22 4aNNNNNNN$Ifl $$Ifa$l NNN*O=--$Ifl kd$$If4@ִXM""''2'2''"    22 4a*O/O1O3O5O=O?O$Ifl $$Ifa$l ?O@OAOBO=--$Ifl kd$$If4@ִXM""`'''2'2''`'"    22 4aBOEOFOHOIOPOQO$Ifl $$Ifa$l QOROSOTO=--$Ifl kdd$$If4@ִXM""''2'2''"    22 4aTOXOYO[O\OcOdO$Ifl $$Ifa$l dOeOfOgO=--$Ifl kd9$$If4@ִXM""''2'2''"    22 4agOiOkOmOsO{O|O$Ifl $$Ifa$l |O}OOO=--$Ifl kd*$$If4@ִXM""''2'2''"    22 4aOOOOOOO$Ifl $$Ifa$l OOOO=--$Ifl kd$$If4@ִXM""`'''2'2''`'"    22 4aOOOOOOO$Ifl $$Ifa$l OOOO=--$Ifl kd$$If4@ִXM""''2'2''"    22 4aOOOPP P P$Ifl $$Ifa$l  P P P P=--$Ifl kd$$If4@ִXM""''2'2''"    22 4a PPPPP!P"P$Ifl $$Ifa$l "P#P%PUP=--$Ifl kdز$$If4@ִXM""''2'2''"    22 4aUPZP[P]P^PePgP$Ifl $$Ifa$l gPhPiPjP=--$Ifl kdɴ$$If4@ִXM""`'''2'2''`'"    22 4ajPnPoPqPrPyPzP$Ifl $$Ifa$l zP{P|P}P=--$Ifl kd$$If4@ִXM""''2'2''"    22 4a}P~PPPPPP$Ifl $$Ifa$l PPPP=--$Ifl kd$$If4@ִXM""''2'2''"    22 4aPPPPPPP$Ifl $$Ifa$l PPPP=--$Ifl kd$$If4@ִXM""`'''2'2''`'"    22 4aPPPPPPP$Ifl $$Ifa$l PPPP=--$Ifl kda$$If4@ִXM""''2'2''"    22 4aPPPPPPP$Ifl $$Ifa$l PPP\Q=--$Ifl kdR$$If4@ִXM""''2'2''"    22 4a\Q_QaQcQeQmQoQ$Ifl $$Ifa$l oQpQqQrQ=--$Ifl kd'$$If4@ִXM""`'''2'2''`'"    22 4arQsQtQvQ|QQQ$Ifl $$Ifa$l QQQQ=--$Ifl kd$$If4@ִXM""''2'2''"    22 4aQQQQQQQ$Ifl $$Ifa$l QQQQ=--$Ifl kd$$If4@ִXM""`'''2'2''`'"    22 4aQQQQQQQ$Ifl $$Ifa$l QQQ)R=--$Ifl kd$$If4@ִXM""''2'2''"    22 4aQQR?R@RSRTRURWRiRqR{RRRySzSSSSSSSSSSͼhfA0JmHnHu hfA0JjhfA0JU hfACJ hfACJjhfA0J-U hfA5hfAhfACJOJQJ)R.R0R2R4RR$Ifl $$Ifa$l >R?R@RAR=--$Ifl kd$$If4@ִXM""`'''2'2''`'"    22 4aARBRCRERKRSRTR$Ifl $$Ifa$l TRURWRiR=--$Ifl kd$$If4@ִXM""''2'2''"    22 4aiRkRmRoRqR{R}R$Ifl $$Ifa$l }R~RRzS{S~SS><<<::kd$$If0ִXM""'&&&2&2&&&"    22 4aSSSSSSS  !H$(1h/ =!"#$%DyK yK 4mailto:johnmc@cs.rice.eduDyK dongarra@cs.utk.eduyK 6mailto:dongarra@cs.utk.eduDyK yK 0mailto:Dan_Reed@unc.eduDyK yK 4mailto:bridges@cs.unm.eduDyK yK .mailto:hoisie@lanl.govDyK yK 4mailto:johnmc@cs.rice.eduDyK yK .mailto:ken@cs.rice.eduDyK yK 2mailto:keith@cs.rice.eduDyK yK (mailto:rro@lanl.govDyK ken@cs.rice.eduyK .mailto:ken@cs.rice.eduDyK dongarra@cs.utk.eduyK 6mailto:dongarra@cs.utk.eduDyK yK 4mailto:johnsson@cs.uh.eduDyK rasmussn@lanl.govyK 2mailto:rasmussn@lanl.govzDd %P  C ,ATelescopeby|iosy' ny|iosPNG  IHDR>1gAMABO pHYs.#.#x?v$tEXtSoftwareQuickTime 6.5.2 (Mac OS X)tIME) IDATx |E{z@L\NE 7DN$ *^% ꧮ+7ת "!rrDAD$ J•j35G37?~귫r$HkxAs4J@(As4J\XPabbmB34J@(%8J%D4J@(Asүi^wB4J@(AsңiQ%(5 ,*2.ˑ!]1(AsO<ʃ؄h|qyK9f% h9PB4Os*6HVM1P* x.%@Li`: /F yJ< +"N]pJrISn T,ki<̜@`(~yA,"庰E꺨wY C(Asr6 Ox,KQ"}k#Jb kAƓ!>(2q,R*Қ58d[tC>V;D!4ͣcr)"zl"CJ(_D($6$e wD=!Ӗ %9Ms Ot2ZV߭k٢EU6wtV;pСCa7j׮]/#k ˖/Y|, X⵭ZY7x˶m{x,3ߢmѢEʕ`h'[`d}v2rMѾpdG֖'bw+ cv24k֬2bvN,=CZs=Z+bp2D'gK\&D@N]3jb]07(枡 d0ZDFz:eI6Ar2TTa-OM_e.'[K de܍&ЭkHtKAXU(Г!!H .ɠXx ˄}l: 'CH7*N;V|t8gŴ,U4ӷ.+V]al3GLٜ9\lW"cIRR /|AT'=-%%N:%lhEBE#Tj%`F*ѮDts!Rt !"[Kg8/1 V+$_w؉A'*4d,QpbY+lpbY+Փo "Ƿ6cB˄}8V:Gmꐉ7quy;[oo}]3'R' *8^װJ`oݘ_ğ n:Dg $NHXJedkaO?wرܟrrz Pu"nqXn_th/"Bi*l~gstŴ7pCf*WĎx"K !HFt+Wھ}~9#1Q cƏ[ޭ[zfxV8oJ|G8K/$A'N_N#9{CnzZ}])&~L^RX[TH0MsUqϾ}zHPzjʍ78|*+{.(-*TF΅3Q]P X'm7"8M^D) Ah7)kCTFVaE ?r-(ўswN.{*VL`~ygl{e4 x!rxXJb "!<Џ,uPP5[9~_@j#X'2eiZ/:"!YHÛX b5VM6blEuw[Йn@ zĺLn%Np2'8B4,ۨ*z1idY3F/+[]dzl0wQsM(̓k1A|s߽C Ϝۡ#9;6lXUrj`]OZR/2Q \+F$%zZbFA-x'Ct W4$17giݨy9nC Kbp !f@2 ol,"[DZ-g+dH$kśbHX+b` B}#fK{sAsԕV>"xm"2f=* !{F?WH@5D9m$R "vXY@V VavMΪo 32ۻ m0 q2dRs22b7n3gKLMzɳGo'zj*Q0 "5ktsBQa1cIA7HAKyN/R&X]]an$]Hδ@-Kxr|"u\"ux<4溷l\F"?|_ҕ\ 3k%\&LViKK`Zsl.Ͻ#f]9nuru:D2Ë3^4@:Nv(/nF;-VW8XIJV!bAs9k< Yyt^\k;sŮ혜%O[K,k% $d(zxZ7~Q^L4Ys} `>{_V<ks?p$'2W^FfSN][fƎ[fMT,*$XМpݵmtq={̞=j*1 "MŊ~{b]=?6:&>@ţCf˖̙n=3#J(.SVcy'n]+($8`w ZwPC|AH:JLI(X+VZ"h{BݫڷK5y,̻;WD(j:fQ,pPGMZM,NJX+EdbgU1ڳ/QJ|ΖjUv"Y:-rׯ[%ܱ%ӄ]]Dbky @\"g>%OkԸQV$!#,<Q\I.,( e7'NHZXٳ3~E:iJ+JZ6^|R-0H֛nƩX%徲V|jnOǼ1F1dRbRHI.* $!`Itس< XmZ6 X-AkE ĝ%~:oY/7, ֹȕUbG!31E/sY{H O [$ƿQc `X<ڿ5~ "$~I1\l.+Vs]0T*"N*]d:( K:xp%yQ~kdz3Psۭwy mpb 6bBD]ls_4`k+1AcƎ0AAYx f~4K׮iuDӪD'. Oy@+Nug1x$t7BRQ,'mD Vg(odJ‡ZP$m8^kp^C e ~ 8oGA/2}IrTuN~$~tERx -^28J(g%qGzzz999jՋ/zv)$YX%<ΎE^'~B@4yǎ;rrӥE/Mܥlvó =Vb4ŋYq[v mFE9cND~ٱ[v:yEugY,"*@ք8$0k)}g N.++W,tzpXښ˄@p%lru+qVOB Nt t= dE$zqOq1'2ݺx:lYMr劭[޵ϐo5koP?+CzuftZjEר#^~{7j}_xo'bm#GKsŋ1xx֬YgЫW&MyK;4&A_}[ẋ|ɼywygԫC>?\jEծU~+5vK.To‡Ax.$}[7tXJdɿs9Qpٳ e7v>AD3]"D#hK)3ujASV6mۼc/իWJ"… yhZ2a7^{M1[xnhgnCnvoO|Ș^nw2 m[ihZpDcbt޺ۣ7^+J^ >QrV%du6W^~Y3hۭuw2SڢUq6 0 ńؕg ZxhZkvnemN+Ϟ=;1w3Sδ-DN 2UyT1ة8^U/47]WjmECmfFlr`[q1[X,hbds{<T.-OkgE|ݣ$1]\ssxz]@D67Ɏ],>wۋmAMR^a%uo'yt!lM)4Vǜgt.%jѹLP N,k% 9VB:9;P3}XaqAW Gڻ}VVՏf&:pd_LFau5W;`||2oT{Q#|t>,)^$ϡT$5VSwݛiztZ'ťOњګDYn_~I1[<7P1#>{~gDxiZ3>8ކs4*}{ޢ]?`.an0B7:'NұVGXn%"ᡝߙO3'm6>}fkZwlO*:y3bhKVVoQ6G8h{Lɭ[ǦwfL yI˖-I/M2>t($ 4g]kZQ7-o 82ofZwRja7|о19冮ߡ;m \~;ɴf%M4ZNe%.oUrٸ/j45B>1,{L.Q85* *3ڑ@-KUl.(\/KM&R14_2uZ9bAM掣ٷVyZӞ8dzoMQW<(U'8FN8jQ3·;> Kv u>`"&|jqdpγFek׮mB.OOܷ65*Tvyi*1 detB%EPsӮjשb(f{ҋlΪ|{]U>d@KmMHqwMSռEsg.YdlМHfb&|pE 1z۹ie^4+"P AϬ(%ucS6}bg@6^LJSoژpKQo`]=p>4LFb9#WﲳMSSR#ٳg,]n^VmRFmNC?nߺu޽1XP^]ޢS%BYBAK\D?VVek"-J+7 9韓˗7h05k$&9iiШQcJOOeڴ8%A=$KM30ͼO“a: Hj4MKoVW?gϞ |ϺLs HڟV׭UE3N6ɿ@y4~f];ML}w i=;ݚ.e*mg,LB9\C;ޫ:Ysm-Z. Eq], $+\\[T\N.ҦNSBL6D;zE+byD6UXlo^v۷1ˁe4l"4h,:x+Nk?+%7lVs#ɓ'ut4cn!Dn$Ƞ"M򗅟 LBE`X+BhМ}۶:%-6Yfw(98bLEJJ@ $Ps_B`UIvv&R℉7vt>\1Y*`5Zf%te ./i0< 0XK2);V/h: q4DD_?cEf^=76KM1l]~¥A(e0(i0^dg [3׃//Kung3cJVY4^]8fg`2L{*?ekDzj4@B\뺴ݶoB /YMĹ6ݻvE&  яmitymꘛF(ǹ4'Rw!H'RhWSVzC9%:Kۻ7C-^a,!7P))EO^\.E/T-phD"ˣ')T̊ o -nCDbKM\eY6maDۘC훾>b (!3ixI_`mks2YIQh1ہjPQ/+J13d 8B*$GFٲIV\ll#i͝NW:t蛫4J93͘Ț[FӜT#iDs͚5&Ne9X1Գ+py%1J%xI,ck?VI<ףG*UDԗp<.+;G^:µ\\-fcyLPzI`NV$!salϽC%m>$D2|:<)SZnWʕxTlgesY:du+s{Gqʦ B3ukqÉ9rp /^xB3ʗ+OvśPrl l2 mLu? 6$c3u b`XQ`X:\scX-e>|-]U>o˾Xs?dXQӴNvҤ+Y\\. )LXeΝ;Zpܽ='U!sܪ~: \qyd=&;xfGnMso. OKӲ]9ս-vumvPMrl5A# ;%aWl(~ m e蒈{Iy]-ǩJv?Au7%2Wa?~t,0RXX8y$e%h~!Z3F9G$~ch ):qs BY4?Vp+\3(ʨw? -~]xKO޼/s),,|u72ZD%As 4m3ŴD]orqZӨdӈ؏Of31gе(hMHt.u\J/g+n({}µ ]^#k+ڟQx2db[\VI ΊɬbKgGz[\)W^N.o٩m.ѧcj&S[IVjj9Iar}C2P9]﷣yڽH^M4j.ag Vԝq:\~yK|j27'wlR[GQ.^>e9_R8dgU!sfΦƏb&!ˌsQKQ`@9;vd ydndǨ>'vRf]dƨw(鰟?/yR:gqȪ!SmR:U[y|\x맽M={kcޠs yg~2NVƯ%&:q~B8z4S>;o >i]l{#szV\kyDP\V('}3FR7D ۟k4*N}(X#@iUb]6D( 't'tA0Tu[|1W)ϟ0>$h3WXLu߹s'i@FlVXX>PP@e]Ĝ< M!;K6am&ƈL:\`&, 4IRݶ[ [4c\h֛֯54̏ZD%|qL,XeKbHb3vj/O<&hDJ]Y`9MZ-?}z´ҦazZ1'7''P|*+%P^.X=%i+R>q?=;-zۺs'e_ظOrÑ٤W%Kt[f=;w_X<9WU}7\坥+(59Sk@ b N?bm(+ h(?bZڦu kZNKO{mZ.-߅_- 4hz^x[A\q7i\65fW9pӍ?ZQm}ʹL&wto>;+׷|Atjo* Mo ,3g<(,h!F^ +4 R*<^V<[ü`c55l|szAX@|ž.B:Ԉ;5v{ɯW*6ڜ6Ӵ_5 d̢ȻNQŪ6'ti^ڒ5eMP<6C_fSaR9Rٮ}2}]3?~;GMg79<@w%e5K\oڲ s7I*iSTOIu U];Nn[nڵt@R<$NvɆL@w3ǝ?|3fX&Fo>!s-^6̔YGmc9 K/){dԭK]=`9 V{(%ce5ٻW'ʉ`ӎ^\ԩ6̎ir8Ŧqh҄uQf. aHrAw\}X 8* HVO 榫0e'Wyd͇Ź/W,fީ)3yd]\_[{qc:r 2@r&WFҸ 7(xR)6F@E]6oވEU1C>S?,kc7m@t6.lx.߽.yjʁq,'N~o#:Nb hH=33bsvmչ҄Eg|vn0]*dE#5>7IOcyiLX[mȎl 4U}2a@<<09)m[}(|CflX[Gm4ԀU͟?ɧ\fm3;3j*=D|)L IDAT_]dvڵeˊ}jwEVue/C,OTĭkz\g%ryҥjΟߒsp_N:u췓L2̠{WZN\ɢ%JŊS"*%r~;y׼³E999~Aqy24v/KҬ"4gʂY|fߝf=3f0M:'+b1~#B_jQF2֓4vRj /z׍;֐]7g(F'"@2;\Uh>/G+bt) E-[f I.J9--m&m<2[", &(޽w´ؚ))M6Rb;KWDǤsh"{ZzZzWXWUHEcVn ;Pڀ~#zgn>}6n g~~ŋ1;S2f$vt%'ыѣgOӉrnXR#t_LGZ_{Zݻ6rvƍEBFxWW~@U{˃;8n}ɢlGGGS& 5b.xh" EV jq/FFVdEb].ŦdBյK|]l$"4D܄QϴBk#bX\\lc|}E6ǯL⬎l/f/N*NyrMsYZlj;Y v, +%?a~.qG\T\S)q ]jRxT8yt 3Bf4_$33%r{WAI /vahc.^fQlMif(ܬ{DNO5Dޒ'\Xk7SLMΝMC93v̘?.ޯ6 5z~FӸn"8{tڷmHN6nq=XМBc 9hA~}7SƍtМR#xMidԭK1޻G|Ejɧ&ԬYcFdf3Mr{vlzDn؟Asќiiy0웨_'bpף"ܹS-TOI ="osLQ3yL} ,=u%=lyMfF _r5k!% N1ձQlwƬh/O~n cPVC ׯJ:*9n!ibXFݺͤЬy3r\}ү-[ni{RuW?Sus,=˧(}ucnp}{;'N>"ǭ߀A۸qcnNz254E͡[:`SDY2oջrӆMo ?2:;ncHNf3@޻)Sx&dѤ'ehu-Mn8h|-[lM?2 n>Uk98kON;cW\qp=/h^jo^y$k׬ :h>lPӠ# ҃ZG`4{N V˾2VHe͙77)QhVXEP *Th:\?,UJZbBvNő|][JdA9R\.Қr}eFY'P҃Iq=zJFh}6Yf6:KԴM DM!,?ܙ>VqT*MLA Pv7n&ʲj5rÌm.ѽMdHG? ?ʌ9AoMF4>k3%U`rC6Kxq\D xOO5;ZF]C[Ǜ=BwgՆɍ+Qˬs֌EfPۊA]Zտ_V'Nmo:#9Y3)4'ٲ~?#y˄~%bF~ߜ0AWIt7<[o5ӆq71U]TZ*]чn3Ϙ-[Wyr(G*S ә>|_~3yo?j   =e]AQWVϨT=ӲM}%=&>[| ~也ŒӺUijgk0&zz!8:}nߚ=ulL3 MCɄ\'GN̘5s"Iœ 1lP=eUJL? [uwtXپC1h7̛ZJ-{GxsfޑC0ץ9c L[Mi8uSM!5g;ev9KFLi6gl"\p; h^zX4k~@Ԧ}6v2ɾ\zT5OC4Qzff:^3\?=֝;i<-=~{U%g zqjt2_/u4U'7!fj96-g}>Z{SұCkKSs=|1{XfX kPƱefu2 %"EAщS&O:58x@jd&qjH+W0V<~2o1O54c ) /fB}R#g^bD|5cnj1=I%YpAA˱E毚·j#6Y!hN1|jglvK{vl6GdThܜې䉘??`v&L$U~$.X9rG y[,瞊a7A?n-9~ĠhU 4W y~Yk&Bh\"yXx2FrǏgK>g\#]WCx-f͝=ga!{wSWU>3WOs-hδ:5k^Fi7; ))k^EڶUjY0HG~otU5!]ժ8mmZZn'2[Zc&s:v,kX3-xY2mo<@S)Lk׮FU#͚(UD7̙?LBDؽwO+6Jz|-Zs2FQ!9̛E< r6z&ix8gŋ飯4e@ "^.Yz;x,/{bh(\rQ73e>l<}sPG];w|}p[OkNo1g!WF/%B&as)"])q Xg% PT̞ґz\{}-[0bСɓ&-E=0X~q>zG󢣅{|͈ =OW~:#~uTRtl?n\ rzO8i۶m=ͤcYVtݰMbk@GjfJfMҏ$)*(ڵnCyTkj7suƕeb) *U;7;t4QY'sgNJ*50!$Sm4pE+f5fV<_ZzULwGg*oJ7xNܴGԛ ]qLV"9JoˆaLmvAnc`מ`Eƍ:l8Z QR;aO>7OP8y-r %mfmbo ܫh, HtxlCqƏשS'+f&Ѣe7_ rƨ۷mQnǍsE&2XhthҼy%GM$׭]' `˅M.K'cz5`{^WFՠ3g ʚU;T ԩSVD(I;hB[Ӡx䢂>c35RSz is?rZhԬ鐱w-JQ: ?\ } $֑z,!}.]4k[ mԲ1nw_NDݣ.vpg S(TKINΝ;A姳~?yAbfc;u6c4|߮kW.oQa;o~wW('6>T$F|UWDe̙^=zJOHtKdo߮ӊYis"90ѳyI4 feeYعK0E<ݛeƬ;ٻ_}-[~x6oْbE.$dG`&zygz#ÓKn4Rk%9T<'`kK|\ȱѪG;d7xۢY/m3Q=t ״ YwX6k0 wudWb;fU5⋯ q+$.ժXxhy+Χnaei_=%bhFp}S#GPX~c&w=Խ144*jy˖a KIZƕjJFݺAgd5[[1lb=3f̘;{EaT'sm6+c2Ǎ'*L"kg??}49bgצM.v@uHVKFguмy&Mϊ1|pa̍o|&1o&'sD躷4W4]+޲&x ~p\^mƾiCXaN]nY嶾iМ|Grw $`> .>cH7*"۶;_8Xk"Pc%߂ZH-LWcJ 9GjᝡT Q <|ôx)fJEoyHֽ"24)"b(8<L\ö=0}s>{9sgQ۳,c"qw)):R|6ψ0rEd!AO?HqdnNuq|ᢶROVl30*QėL4ЅDWs/*-}"f:̓S[Uz$+د.:F ./z?FXO㱜E* F\8::W_xal`U+y2p%k>Zk+s*/:8:84$yKr‡ :g+.EY zm(דf1=+i;w-q5ajjjuʌ zddpVj/Zd K`M?&u+=Й芢yY;RBʴ4p&' u%* f8EQtt MPR0dDmZ9.}pqK@ PѼI[BT!FV^U4 T)QQ 5-bVQEe!U[>O`VSܔڙ2mɣfϒ˅{w,j[!X}au8=TmR^6 SᲽZa޾=)"W8pq}Ib`Φv[[[ZMӅ7oڝ&*\]'GE-zuXj<ipu- +X=Inc  /z7K.G~~>soM)qrr84ؿwov!aΎ Ed2~:v4gx?g.z8~\yMɼ/\s^`GƋUQ^TY`OXh.s8U GX`B_NYԦVQ*[A2u^C#h1ޢ9X7 |=##qv ڐarW=Cqy-Pk?w&'(P|Q#..&EMG_Rqr|'_nʪ._ `vWfqΉ 4En!)hkcvmҘ ^ VEsS¦̂ye.bnY~(xxi;AȑcHI/i3O|Ԭqxf4j bћ fÎ(6fG׮i\bVdJhMfSQSk[%T){wGߛXQU-͜C;IZڂGޞ+j (t&Wp>ufG/):b`_ 7oiRbg6.R'Mz-v!b.Md3l,ݻcb hj\.w7z lS}ā0 Osz^1ǴͷC_~iڊe!hR^2v|8NϪnMXÈk j+v0d 7Em=׮vÓF FyE.Й8ud%.UuކX"c8n'r؍%f8<&M5+3}F׮lđѳiO"+u6 Ŧ&ќ@'SC `_ SAbk~_,p/OV棵:hr`gCZ{6i]lBSeRWOmlmȺy  yW9+W Y00 jjNyiCJyK {?AB}3"~ec)<(j2ngQ7՟.̹|QU@//ot*|!C&/ݱ\[U*ćN: n2s5|GDsPR\ÝN0nC% 5;fՕG49] RRvI!| וHyk?;H3bnz`_y7=-rMCyy ){O=7sU_Ba/Za>ڧ!p8FA1,25kn*+*.(pՕh~je)dcL[^< =V7eV VV3`~x:盟wu}y:Q7myGMEoT]Zwm/ GnJUx6 |y@ѩڶw.);8Ȅ4EdM.%WxSƥeEEkT5+xۅYr/ݨ.//VQ ?^6qU_C&e3%SRd^1my Du؅!kB.VY棵OXqFgϷ{ZrRn55Sb?/ړM^m/9*қVaB[P5/_c OsI+w%ZB+ LcG c$,Pv[LT?9d@˯QKY9R"X$ҞƆN za% <10"Ȓ Xh"uH-X"y'mqDXlhe%5j|]C[LYIO7YM'VG![nLxW{{P+o]>wıQyo/ ^8[5$dZRC zEI``8uo{]DO'c^rk]F9?ުso rJkJەlεYZ;͍'zR{ 4/6koy;ۤ+ynVh cFݻk?8{wm}걭Y3V (:8m-W"@{{X1_&!$-+$".7A 9̚n2jUMhz1M|9",6tU?բL ]dP;+ ۩o<=mC;Q?=zt%K_]fZxM'2\a/u{+*.4+N/aF}T\HfI"2Dr I$ϓc_,s{O֥f} hDT9;[SRC^+wer\X荣L:&\ VR;T`592Y0z3;xO%ܻչ+1F72` ubI2~B 1\w =;vi#tCBQWZ @ Ds(sqΎ@Wt~ XzHz 4tV?`yn?tYLldQNMs.Hڪ#YT?kD2'] RMSm=#-y@WV5Qf)-3idߨv{rId$âzjԎRO=u׉хJ Ԩ\BCKFࢵ^ [)?sR^{w_(կGUSي{He4WnT^IÇmtgDyN[$6Ӌv~՛uP'pOB#,xyy=| ,;Snѷ;zÚFxbѶxHp3*:sS1P}tW1qc&ƿq!pZ]C n@ n,y W1@GQO%И2A(3ט] Qu.©\kua+(d@TT&C+(|̨|u *_y[?WPUօ(?sY1 |^7yrdxi,2W#VG/'E0]W~H=PXaQ {HQ5-k<[!PQ\>/lDV{eg *8?5=hb&#S?_lzx d 5 _vSO`uۄj([=6b P[ӔZ993Ncu9k g/5gvnO2|"^ƌRB_n84?ը.˄bmHR UmfOS$b <}.{*Ϲ`dᮤA*/ IDATkW b7y|RlՇ<**ʹxA]YуhN6ԭBn@:IGqqmWqHZpOӽ&+PWِ?fn~.v78 ͟~!G:\BPb&ƣBYYÇr D. ፵蘹%łwטڲmIоQ#Fܱ_TZh^7ѫ0,:%kV}%!1vնH$E`Bh(W֠y)mO9m3cꊵX) dVU:2?DF% IlQUʆ~rEn5W7U٫ø.l+QNe2aGWs زjU+2@uꦥ< pMn l%!ϥ]/*ܣר_ h' b9jۨbZ+殤^ [&a KKT@|n&M,msZZ2Km\F<=ύ7Ti&k?]5q@Ӽ==[v ۃ!ЦJI5c8qoϰd~b0ZLǽOwiSL9+|$s%P2<`\Xfrx>y ?嫃كM23ݻw-rzMz&}ǣsiaa!ٜSK-H`iDG槢(6v֕v,n?.).-/yZ^VQiV)r֦+?j(WVJK*5<7qt8r=<Ǝ̊e˕7o9Ю OEoOPZ#fxѣFۣP,>v)\Ma>|7H$:hn!`#Nf|9K !#$## Б_rUXDx9g)*\̀HA@DsC}9q[tٳx<^`Pа!CHԳXj?Q$sNe9İ(>l>`mir᝽[lePJfetbOksHt>^诂j@%5Kg-J) !V)ׁ~~ bF[ 2E%oZ|7POuˆT&XQC+Tp]ܫTTIe妍:p3S6su];9Чhqcخɩ/_)ΞvlT7,@+Ú\?HHH}^^۶/CF3grteml+|?z|.~Y\^Q4_H #첦fY^o}G/ -J'RnY|]CSSee)h%nDPɁvg04؎aB|||{x UUv PΞNpp`UG!#y.%6\l:^HJ>?gfV9T&˼ݠ'ɴtf\(MGX,Qpv'FŌVsZ+ۑ3<44"bNN2LgxwGS\-sǒEQ8\Lލ́MxTBl as 6 HCr?`n'bG })CVYWNϿsh%hnU*N׬QT$ v7vWSʔT=),mb4#'4,,22ґѷ/Z(а11ޞ^FuByU<Ԣ8pm:vdQGy:og@ M?kL( _ܺzjUz5)l/J\deSO K%6|JS~ࠠT5vvϥ]x|dp'"wdQݾHdf0R2߾3!2RJ}K!ڔާ#M^sT%n%7׉ӣ߼=9CTO>  pGp+˿1w\lM J$DS@PPo۲%,"ŋۯR(`s%ǒ!z%Uwsw?r6:ݡG6oڤ-q2qs¢{ꥱfkịKWXzCvڹwQwŘqc )"e7^˒Z7V}Z|؍K:QQQA>?AWm؀ޖ.{;##C? 5.|0Q ?7}U:oT\Xfo(E#)6 WmjWu۵嗘mf¾wwrcƦK?33baaN:-Mmnnfs3s&&T[YYĤ(33S'!LMMI: ^3O%8WC 8n!bpHbQ4'G.4tuO 09E;67۹};X+`<ҺxBC~Ϭ^W(HT x,;gk mX g˦HLD{y`kkKDs f&ɤ.V9_(ϏO?ϝ=U>QIk|gM cǎ +V䊹l#(ӮJfuupHWT}dPFPE\etHP0Pyj[`DI*LҷV4;;˖ mh~I\J P7G4Br(}>=x3O="n{OȢO7:`yJd-S!}j *۷uX" E7آ?!B vhOHHQ. ݆:|} 'WW>}"0,d_Dsk?>,=ͺvJYv)k,\Iyo"7dO66!sxmkrV=OkC`5ZqnRp $dnbaIҩ8N'8T{Âvi5EIt"Y5CmMͫ !'NzDtJF*ڙvv;VVV۰^b<wåY93 $cD 6nן,*NI*uGݓ+yn-rAj1bIEsAmq^<Ç ZQ@@ŋc2fgf" 5og)ɻffS&M9ё 1]X<"pFs ,˓%KWnh8qCuR0'8Xؘp:UIֹyU؆]#eN67WX4Tmת+ߜNc;0@N}ME S^|Q]n֭_~_LaMBdITnמΒBnbb"c]mm  QKT4uQa,_,?7U&OY-o&R4bvǨ,c[㨫$=fȬpa%Q4G(<Y9t0R==O5kvV "MI$]z J4jj4|wof Sf[ߢÁ2,쐸R#bp>YWb_LPzhKQCO:.)YRz݆{d%G3}wd5 a;{;++A;wN:u9nRjrbRaqQ{r~Hwzh,,- ұ]Ya=D8'@x_f&f'bM$3gZFq8|(=ɧP\ GCOr}aˮ=1b_'Zƶ0@yK^c񰡫aPue ќ7֑yAN7bu8-H=Fϙ4sF3S.ag,b|ƃ >sŔ לj5t{L lwɉQ]~wjm/ 4Mo^A%z>7ז, oڲf rCC#7#C JW)u+eCʼnI6gۨа0F.,.} =d55T~χAmm8:'%.Zgh{.6t2_;_̭ȑ?hР;w;zC)11Es`9 6,)n)HOzj]AtA&|r%MXXZ'+ ]ɉrZٵ#Xƚ*njxv{ 3=2-ŋ|}X4n=$\N1L&jJ\ &˗EZi,5Üì),.2:mm'6G4!vprv r0d爩A@i/7+n)e]Y↺{C [O_F0LsH铃E8+V@5s,Y#7xD]L>D*nVWyAҔ^S[e21_׆JGa5`n U`eS==Yp##߉Z-iRHrRbRy_^C'zPOO!yH/I緲RQE9uue_,{Ir/mETܑA}ڵ?TV  hGe}XL'e$8l?~+עb 2 E -Y[Dz2(#t P.GNnVWvp Zq{bgOAT355mbJW3l3S3R{byrX{ȣ2NvիwK%]N?G$DtENt>Y=]+t붢q6 Կ'YvC=*鑞I+7ALxB0ASY]'7! `Kvv n{ɫ t=m:S4O䊥˨_s;8DPP&v0w0%~߅yU >qFz^ZMU3hqbȕ ם5^&HhiaF8Y&xMk `" H@0702<ϑA\މS-,-Y&Z-ou ڃf՛ڻWs?޽{?|ˣGJ9W^ IDATJ@ކ@|3 2ϵ}Fɲ^yύ G.Т +;Es'Y|%DzصZ[Rv3S%loniӆ>/p奿P 9p>[22NV^NWGY8;8{ ٺp|dۣQ.GZ ݻN&P%J1 l{%..m8XXZWoOzxxu`bbB^QQ  u!=-4:.#wToL$s%2z H 3o~ *ű|-loJ id1+v-JJ&Y5^o3'vg9 {6*fu?{y_Ł~cJJE?&'qw15(*mjYbVNcÄ7~VRH`*W͆U؞|ya|Zqܰ|lf 6p_9Eg@Bn5ur[tyG*撮3,.+K۩O魺ȐqxWgZOmg>+?^*P~}xŶ/,3!J{+u㏢GCmľBm uj~Pp+qNVkO Uaqٿ H{9IĈݣ'AIU~?7ܯr۩)D(8E'e,]czl^嘄K7QZ l@Νiykt?fOigN ˻r&OΆ0R 5>h}^ww*7S2[?L"vCWrXʰcflG&_Ԗ+p_ngA {Љ!A0TIUyK7m]u4ݍQJ|M>]`0M3͡%S446, HG6_"Wrb:2ɫ PGvvv\P+~v9҅?QTYHW'JWL]G,o!=_%\ ;rjg gHf4[J4ɕ*1|~l&7zVMf jR}"^}Qh^{, NO4l#"L!}IbvF1{6i}9 HNtAEqqq%u|xl$E생;H=nC\8jO7wwOs 2gEEEeeJ..;>x_lh҄CzdtlhX{|ߧboݻw`9ahvۆF԰A,dV iލI3pZnu궋œD>8y2B-2G<u0;OH 3qТIVhT͉7TunAz[ͷ6#ED#SZe+{Ab,H5|N&'zj;S=4זR(V0 ƢQ)Z{b{Z}vwZ.VV+j}*.((@U_G 7xg; ;D/΂"1N67NNď"d½3bΙHِ:ܗ_zπe.|WT/{w :Z?$C [.Ǽz͚7ggСwAv[uТ0 Btht͔6Ri][9'M+⣅0.] I @DsDds6 =y="WSkJ+Ba)-_>{H#Q@fϙ[0(n .±p[H@HKWi n=z&;}a]{ɊMfFFjS+pH"D㉚_^^bH4g_G ήD+vq FYMNЌHWi h g)VFv G1/[lsظ1w4О&3_׌^v+#:hT*<ݡ" oEdtw#J9r7R\c7w5Lc>N4ϊJ1Ǒ޸)e-QeFUU#^gpT^[ZZglݻ 2XusDh))?)FY\g I^wn\\]Vݪܱ8z opWAKy,Ir|Vc^FA-o\;:ڷ+JR8j7+ d:S٠tuCCDFGeddK|0/BðGfbrCP{E 4 |'ќuD8Ё_V{B^Zs;97ý"0lh7l=|[ *:*q4$4p3xz8U~ yѣ(99$eט9guWTFb6SG Z54x7KCi݂>>}gҖQ/d6n<{,}IԠT*% h v`,SdtT8_Iw*^xSo*um Ow]t͛<-.Zb,xKdd䔩S.ޟ|^o}9`e-g F[PKF2/e[.z-?rC=9]QT+H΂I߷\qWu@!1ԍ1oUwG v@RUS.\}I.o{Wd|fĢ ya1HlI?zԤ uC,+Ѹގa|}^&YܻG-Lj,[((  ^&Hİs@cMZ6PAwt/5F7<hX{2FzJ6?+CFXzUnuiq]银,+-/i6YsZ%þ])zj&xxTYTtBM?q+gKKKKu%:e &?7{U΂[.?c:CI<;euj?IM+3PG2O>?-ʄ$D:1˃ˤ͋..6Z;˛m'di 2u5_6;n^ؾٝU A(/nux|Xw"E5*Xlhde+< \\:(g[3M`.5Yb8j\TJgsb-X'dI+, vMgNe]I*7$ػ"&ͣ\msK*F*W9bhs*5)j*@4.nėgoOSZ+C2 hXW^]qMQQG;8w2ָc$}5$GQU?brnW}Z;1#C;)bR vp/>.gk5dOWpʌ{6۷FEs*y(*lF`t|$C+}}1eD$=-=+;'B2op59/emؽDEM;eP.w׿үY Tw>dQkEy;kuKAaWV\`p3Voi?ȆQt|ټ;kCC9߯_6]y'P1>oqA%m\R<֝>/ej5A#g 7ch='q‰st22X?RI2G~!D4w g<@gW,ުLm!^Z CR"ץg^,~#΂!v\&/fwhQꈧ<R8I3=ɨbۿ挥*9elBpPӧOqɓ'I( w~,L%ua=;AVRe$Ocm#^PkTm鸎}o{HǥOK;k^#th[~+ i7w`ʪxc{Ȟ9>Mh M6%yƛɌ8@\Kh-=߈ej #Bh^rW/UU?uN~nNQАWÂ= ]^Pt*OǢ-:CAׯxOw89e /\cgE0TTT#B bIn_CC&2Պov:x$ 2MLFS!~/&0(bߝ[rN{TsꚼeJz{{{xb龃}3UrlL͟>W}qbgX6%~;$(uYx5~DJF/`g]16a^ůWI<I\̷ֿqI3HCFW*!I&$ά_yT$tu0{nnG&M4&~X"pJf"k_~W#g}T͇e~_F8U{Dո1G2ݸqBv)U*.5(=Z Tہb>>_:9=ײ]n-X=~G oggN64*zi㹧!!`W{4.Gn-=y S>! F'zXbSVvO?书 %Ʌ$5b<&>k߭2lk/;4cgPF@^6ꅡqq"欨/}05)E5&%I,甖m9 [ ;ln; Y7k^>sn$k­aFOB7gmGNPqG"j~4Өǟ deCq9ȧePk1ZR]QI\VTo_,.4r9Y8(XY2-tNEshWl_EZޝGQ#g oœw0~LL=yg;aR݅UG߾Dݺ&C'/]FeGgW4Ҽ K#&Tߺ !N42 \ySQH6Ԧ_x3N/̵DӂE]&9qZrW޽S]rzHrfևˈy=m,"Ș)b> DXWb1W9o1|?Thz pGǸAD}E,&8쩉 zn}6?-M2|޾>IM#CIg4_48$Tyν,DgM?he@4N(A?#4s0~YihQa G-ZTDgФqIGuv@CQ[K Cs.(U*x,$zwVv1#Y2&&UQ;I D}Q!(9A>t}gQ+Z Egd1RU5  ŜN.KWrWܗ\.GSd] t Ѽ߹tӖnݺ544`$wEcgN# ?!*#m¥I Qxۑ@QԲq,2WMN/2+Gxn|Q}~CqA"CCð ]T*jk MݺCʃt6#r4ű܍S=.nɅ,ɉ%pjvꭏ9=9rK*V=`[ŷPm1V)yVH8 IDATdf2@+]kϞ={LWe}N4&s`NNR&-NlD4;S{0zdoo,TrE&4_T$H@ғSg3RŻ4|0M;ImFoR> 6e)y.^j֨['v͈)6RyN`),4rwV|P#LkxJiy}M O\H+Lnf>tC4 sFyH AshBBHгos\uO/d'*J$Cz?lۦl=rYZfzl^Rb0ܫy+q51jnݤ_'JkɖZ*عPiQrXm&][2.Ъj u=_bG9ݵoвИ["ݩtNbj UZ4Ay]]]] Ӱ1zm'g_mW8J [2 VdR2|*hUiMQHtTp oUjC-D$ ~`X:&JFG?ߡAo446o_4?}V+kC'dOIDQÇS7#cGW3C5}lȄ. \QI}}Zh0?ܹ۸Imm-ѣ:hPmB5r^<9/rjjpfGSYW~Asҗ%CwK":y[J}8Yq%?-򣁲kWi"VkY?3qwmq MbWVf5lKbE9 {C\ؠA@G5*8Iؚms{IFިak̫`h`ֳ<|Hǣwφ39cxļXm)^[}Q4y:\77SMG&o|f vVdQ^ v3BX41|Ǟ/g6/z-w" T*?lTW#<&z k+O_(*~Cr0EfܦewO|PqV7W?g|^hѨR04q$/N:^%R +6YmFF1xެ"+lR0ZOWDZ"Ww/qT*dž?k>ɂa?|P( gʁd7_L{Sc Kzeڂ 4ڥWg/p-i4NN/u..nNtoeg}whF(N?wө!!!-}NEMiWoL[o e7t_g[~4 s&rIACG>Q M_g? HhDt&%J*_A⃃ rKNtxrtqژyssYLzf;ggj[<`֧ th4oϚ3\F&h\Tuλv27ay_璮m^CG>LǕ ;&zS.+-A"c#5S359.9SrW9ΜOf:r'ٺ}ƔɴqJf?`}ߘ0ƶK܆TVVv ;G[P`5bN6'ߐ22"r'Zav0Fo5>}{Qjz+?nʦ+~Hha(&Pk4wȱJWY}NR:17a06[HRy{/ϾÇ 3L~chܡm /oJ >Z:mA-Ӳe Tg98JuD'x#g?$W5jM -&l+_1s_cהo3mXoYvt9|v%I."9w9;~3ѡW}njͅ[͹4+y~9mІyr(rLƎ\\̔kjw~<{r)_'Xe:_ܞrsHIx{oyoﵧ/>#9|ۤE!}dٔJ͉A'A[jbT2r o*abH^grEi xP92IQrwhOu!N3Kz7вspv54<|v,G:'NϢP(jkk2'1{){y$ߤTr2ܲ7vZrNr)e4r>H 7e:1⇄WMⴋ&;xzw]T͟kgSOHzAWJ gu33**a0aݻ3ҟʠ}Pŏ]<)V`d qs cΔ^'É\3n搑XmrZD^[MHvFDE-(jnZ)8qмYw~)˭Y=2>Yi@.]}z;Q϶Qרࠖ>pr'iK{o1f_ݪJNYifmY@Qr{xy{G,tqehǺ{y%^E{xlQ; @{rY[F˝;wvqyҁO˖|},KKZ0YrB֘N!W6keTrm}8tY«^j$вWcrvs`"rP(ܜ <=7v(_@$,228%d[V\Vϵ d~މ'/: ?)>8!.jV{2*__?;lhK;stii3F4mzw58ͅ,Ȼ+?KL|l`ˏ{d|TtlXTh@({9@[[^8@8[λ N;}HdI~ '["=jCJʄؘw..]ˊN=3*R8U#Bԏ7mugzxt?>8 /X|li Dk nUU 5 {?,183~<6d/ic1o2qǿrd@@Aa /:j$FZ~@q а0VTX.QRR\<+1Qho@`%&*]{2?:$Fh [UUqqqڂ޽/$6r@\.W0/{te>ټϿg&듂6@DGϞ,o>%@ݒ5%xӠ!AzK&)OHG28 i$l ~H8w2JmXr𴶠`N6G9ڤ$]o!Qҝ_|YpdNym˟qaذנ2ܬ3@a"n;ѣg'ٷbtOEqJNކ6f*ڎmY%!-ngM?ŲL94,칁?dݻss;n?SInN. ȑQqOaQQ'JGX6^|sx;Ke?Om ٵcٳT)@uMhm- Ba==)oz/j磳yc ;vHNPsctGq{.-.={6+3K(uv,=|}^;W^\x0#=wP^^bcfBҜdBW~7xYӖηnSƷvɩ$wc{V&y-]ӌfd۶mâc\Pdu9L3ӧF%;K$  ܷo vO*?'weP-bؘwkܨwiiᮮAxgdX 9ILl'52WД,M[FS'ito&Ob;-OlyӃc|1!6f$6NZ3=eh\\tx&Ѩ]F1lh8'vܚnUUY&EYZ?">߹{ S ҳ(rSrGz+?2u^'St2ˡlWW MSO#9GGdܬ/OZ͔;5`ֹ~vfEf;wqfom! C̺E̾EN|%S"0˥t?9]Y!aa jrWazT^ /nHI-}fMFzZ9o\\\~^^ `'D6`/'ǧpw`۩ (h%T,IDc=i%F"ƒX@c SE)R-nf3<ܼ촻໳;γ*8n LAv7 ݘ\SnYϒ9%f%@SSɧL<^9dǦ>E Bی@,ZJ}׮Η̹_}w;!Cjҋ/~Nη%7MܬD{(Ǝ B4=vd,2{&*'9p<'^|9eȑp #<þ*RzآWw׽<;{H广oF t'KLF@ʔfKN42xRBDǒCqZZ2j=3^w 3C wĤ̉;xgNuϷ7~yG<:m)ǷeO$ne.U+*{֭k /hm-U2 ̱~9c#[m5 p_9$}0%>ok閿4kx%z0kW&tA7k1_Xڻݴ_5x}vl'avIVC $/p ,.[~nq~lsyȐ>[mI G n?O?'hwu3σOmqcǎǞ[fZ]vy]vmWo{i+m>{AT~?ϕoڻ\w RP;4ogum2w.۸xw=4h֓>pv ;'0?8:z,a|Y ow_r^o|o{5hѢj@LA4KY}*ͩ:*b6eAu7o{c&}6vd|YsM;wmԨnݺ) 韔%RYԺ:׷ձrlwTI :rBQ*m&6(2 ]R @Pm]%-֍EAֲ2*GQHմ󻞍r~^GOD]MYl0-+wGAt7nܸ>}LK^F}aczkJ\bh6yaɓmݲq,LU7_D8.(Ȣ.@Z@FuȂIx5MsQFUT_)|5knѫ+ܦ}t߷Jq/U?L U_bI^N,Y1wӬʚRUǝ3EIЯ_K.7_zƋn׏D F??^wGۈ;m#GE^w{O)&.b>y[s_yW]$-U㎵d}w|a^[AnuC.P0!~{q]wXW>t~q@lRi<2l^f?/}_&Y(ׯ_*굷GivРKڰ[ݸ/͙sԛg;>*^ߵ}}1rr=\Txwl;`_sߌvM_۪qqv倦aO?d)y}lӻO~衇+ 99)6ŲTB @Q% TS5|#gȺ555}쳖ٳ &uuuԵk=IzEs\/i2n]채+EKv9Q#%y 9MTo{2'mdCQ])yKJSvyfaq[%bf!ZD\F +kF'ժ;LH )zk76T6}wK(>=<>-~w2'LTW;xU(׬]˞mA '&)U"""izh9-kLx Ew{w-WÏ@Fشsmݶ%1Q:0h^=5.{'gd)Dr'.;I9M =K)8[L-69*4K*4@-h8جAwQrI r IXd\'eQPz1W:es;D6|͓d۾}o,zŋ/_쫯J(iM IDATz6M'qx}-^Zퟀ1ѥsQv7X}j>tUi,=zܹK^={p iZym3X As%nڵk–4ݻwo6r5Xϓo2[f7k(s対0??.0)Ӵ_7nlaeݮů%z B 9ݡt|6֭[P^t> 4FP4VguNp\(JNei %qZz9s:枷G쩴Uy@~%wxm\v48<ʡRnV\11 6q#zk!cѡH9hޭ[7+/ٺ0" / ih&z̭\,9WMU5-**U05/j:/bg=JZȪj(*0/ڭ= Tg)_B{ euN|DrQ i^ldzT2\"V孔%jy-5-52)ӲJ9zBy0cjLӝ2?(V:;4 W*ҦLSdY4Ev٢|BgYn'>Xmv%` E"wNq.J@&΍[%,꜉bTQ~>@Z]D2΋뻽)NsrLA!Cs^˗-ce{$fsn-μE uݚ=w:rt{`[ʱ?]oZo3<*$b,TS\_y<}EyMsyvt=@ީ$2fa:^\\*τ^s5E4>W*㢶U':^cN23+Tי((mgEǍWco57g対 |˖rp|ƍ,=Ar}.\}IjfeYڻ猜fY%;=-4NcR01"N/YD&h]*fF "@l;^ Y+zm;dw]huTDyP¯Z14},[oX?!zT.'b R~̧O|ZO+O}. [R~< ?Ó4:ܰqW_}Ub>__V/ٓ6lظacky _l4 ԗGrܸWL)){f@o/msDz>](K|ӈuu#k7| 4DFޚ3$-vܗ“"R~f ,,Crjt|& mxDegE-{ )7z Xe#+GKd 8K'GKIsڠG֧b:': @jݴGiiT|ΛrΝYyM6q5:1"C4Gxc3T71j2Pw'Jg IJY0Z*vAٮ;>m)zf3=rAIB*9B;tz=rOi) XB/]@/sN*W;i-̭Y אUVq*=u,9L(Yxm--nٟۻE-f!i:wΎ94wOS8Sֺ _RE!%A|M.im߬ T |2Co0W7wgtjԱx2o&muo5-:/%Z:j#"FMr)l`#-.eq&EF{Mw(5fXV|76k?YҋzCIؘ~|Ѣ{$-vc CMҒ|~|Q{7\yi[|p5mƌПgݾjGy8b T\Ev8]6R4NhkL#CUũPQ[0dK~ɚZ:Ѱ~ ac\MsŢ{JCP[AڊTvQ&Vd&k6"(W蘳l"Y t99]MgZĤ`I? Z{՝,yrv]3 MP얩|KK khivrjhZl-F$s(kӲ17Qr;N.IH9*DvԮ?/::E/\*es7!'+Ա@Itܑ֔%@1){g$sHRjŶ2slCEi ;cZdVvq-4_B%ҽM813ҥKܖɄ)^hNESt=ܳxDP͞xĩ[Κ)P MQh]HqB1L G*hjSkii⏺/0jW#FTz蘻#"Z!) +BI^,U@%.'Ϣ@)J+27ԩkۇ(Թ]io\E]kڸEt*ke ]ͲOUYֆ_t]@W6\DW9klL%tY|&7jSd$~HDbxs tǙyA%:4!)`\ N*˨D4/E~rUC>!R-׋h4LN_:-ҩMWӼC'sMNLj4i휙ӄow`eM4vG6d$d9ts uku!"T(`*o\Ȅ={M8Yt?C("<-,x/F()n; iXEMo.*s.[Ϙ565ȈXߜDF\ub!ݮDrlrES;;MHf>&pT#Td2uzjE >Ν%|@ׂ9ʗEA:圙Nk[&G y$zgRAUUUO. Y1`sـ&&"FZ yAIYW+'}rK_3t}v1j}kgduYZK/]z IS244`;IG_.zi҉4&ɳЅZU(ڸ 5 CYgв߄ ^xalQ+B5@TVYl\g1busȳ5e,PMsNǜ[A_YفQjiέ&ez4,TjrNE]2Ua_BxfW=!bQ- U,$ cXxy1ߠ]sO7D6]wg6E5t>Ci=jE׫D\5=Nͣe[@ZdйL'<: J<̭^}g"}"Ke|nQ 'r;jeߔ]`ΙQxUzūK^tCw5͵(| ~߰,p< i%%kֹlk:d:*@5׷ݩ G0ߥiCvFjBwNʓmHɉ"~2I3g>8yN?$abAH˗"qiSp'{Y.=lNMM?Ǎ`y0S4mݬ=IZVAs%-}(4ݣK&MHGF*hb@uqМt~5fBiM: [r1+Bc[Dw,fX:EPӪ!mR:'U \"ʳTU ߺ8\rYйLn`x9 Tn5s~TXW21y =[8c>wh9s%O8Yuv󆩚F?hNUQ7GIZ47wfߡ_4TA{& &gS)*_׬o*a\/纯ǐtζ_vck2k_j9=Qwgy&: $?!OZλ,}+qa}V)E j 1]ޥT8gyf}I":_vfѻO:)IcrM\OWMφO>9s9F9u.aG\uiW<_~P^35KZ z))wYiՎ4B("V(ZZfqYb _zVHh{WgqTV .%G7ہI0]mBUܺ0I+$p5ܨ44 y,uTfJs-Z {i>W@GZW99BiqrTiRM \)G `G9*Npy)VhyW2l4ꜩTnR-.h` P"h.6d-!RRx6bv9|9sΕg)&beH3XwfsuUM^J@E8+^+zǝw>癢v_xE54,*Nգe+n!V%A*pqizsw2M՝iMSd7KٝC,^ H[MO$IIMsJHꛋr,ɷN%5M]]M 99]7ѹ(RE\$-:Ow+[ &oiDg(J+iXe#:N95ǹ5?]m HKh\oV7FoffMOҔFs5uP&QU5Q T}Q{s,A:_ g#iX8 Ywc~sN 994YMs$*8T:b\m[뻿h4F/<˹1|OEG YC1^L ʫuEC4%3CQcNwYXK^~3N?/DF{'iR;AsiSD$MjRVWdnL6 ȯ+hq T%«i]Pvu|"y ;B,!Yi]=*_kVw(DKÖ>5Lx@V @vxW#]/z6}:Hy1qTOz ?󬑕V@,#{2:`(^CӦ tM&\t!HWGңnw*U#SEМVk؞hu_ܲ3ݥSaEG?"C#%DaսwW/Цlgr45^@@F*4n> 'D.trQ>'&ې]eņ@+qԊ?1fz670.؃>sz'NŲRՔP$᝻tPmUDm{+ u[ι@%T_P \\}:Y~sPy1i}DmN?Ç&{Dݝ>2#ؗ_m=t@]Eqԑ'pB'Is=>Ӵ }Ԩ_^s[NfMSe 8L)ĕy!/6aV޸q#m;N\9\ܓ+sA64p$3I&y+ !iS>]9gRzI.ٛd:g-pS$G-gѭ[-!ޓN=|S+S}sM Vi!6%sPoE4bE&Yz@R7=,O&OdƵW_Sz9zkU)'h`Ҩ`*J/N/Y4hP:5nJ|?i`lrGyԜ_L$Hɓ&qԑJSmN{ 'O?\իV] =޶ӟtSB@L4.X|y@W=q_qŇ|U0'MJۄC'ͩG֔0Z-bH,,[|Ke,g0fX"D*"7ZC GR?犊y{]ã+U8.{,Ҧ4M0ડUIu N>D̷>sGݩS'Z5b/N p5mk} {g"#wN/s'JhS`_l# ? $0,b=Zz!C*ɄX’}p2 5|d8ggp՘İIE '5MnZr~O>QC"6ng 7yNoUR'ޚJ=-F/m?g<:gB}jS8Q{b-C;CXeP tȦVI#KbŊ'o,~2{o΂&h@ƅwhzg^G7RTʊ5.dÇ߈ P=.xHQ芠hX|j*.m(3;}={~F~ /4zJɛXFyvuxgMrݻ,sl&kkx俚vsզ{(AiE|rΪi9sKM 8j SrqUIHsze-:C5>cO?7 <'(ř,o."HNм z44~7p{eߝ^CHe_,?/_Y9HKw޹/˖Ţ] ; 8V[!wW^}e˖͟7/|=cz:jZwKK +S[ D0 {G77|Jatr-a #F=f4Ջm7OR8L9-T~hQt6l+_'Ϟ` ѡvb2FN;]Z3km>vjV̒??m'F{IqL_R|j t]X:7 <ʏWMq*[i;u n[qMM}*  k;0|P}1#ñٳ֭[17n\}wTbqbv9St_6W݇-ʊΜf5.)b/<oW^{ׯߙ{Ao{<,-j){IΩ*P>O<ڵk|-L'V[׿5{ f]vm|ߺ|*pGڨ N:P_l1fgwe= 5^ա2 ~oVh*_r]C%;ć=Ll7hpze&|In",]zYq:$ pgXZ)O>U4RHpH.G@u=4]R[%$.: $LT\G(,ѥs}7ZFrs;#v֬(X :ySm7_y[%0NߟaodLE w9>{1cƄ%EkmN? ?護b7KQhܓ^O\b]cbyG?h~*i qf'{<>{G#F%Ekm?~b/ʒŋc2";V[m-_!D}{.abC;L~%'Dn{֖݉oۢtyE$f!Clm.G ƒI)7x N\ }?Z'{]Ēٷ,%e`P\zɥ3ȃ+ f)S:َhݏIlwUW^sݵCAeW93m:.*h^bܸq\ڶ@h77?mEEV. |5-}8_c: TCU#qtNwR㩖^whHw$ʔ1qk9ԹU *Lg(ʺfbJP%vy&MZtXɗ9 ]5vn?dt*PT;7w,45`z@<ש<vm%Fb0{OZ?Cqigw%OXlY[a#cƌ@Zic^AeZe:OWw^ȣVP=߷yEyk֬Yz665yT\Сm7&Fإ|KqfovOocScsYA;!n]t6 Վ]a{okz{=CEc1’I~./IOWu5m޽;ghF7iۯ-[nZ)Zk~Le FgEQ tQ$iǴg,H5Z6|Pa"[wޒm2U{Ph᷻=1,s޼桤;K͐Id*]6>̔=L(דPXL!ɻV->3YEa"фHqDՠ3ȃP;@UCxn>WϞtQVyLF ţW^-]6NyMHw{.f98n U(ad_Zv3uXٴL*BD5"i-Fhv|j]-U\?i#w'cmأqX% B?(v+_Sѳ$%~-zB'CN9sQe[Ŧf-i3 tRDBYztE?RÂD~h E%|:Dw rۡ ߇SZZܙpo^!TEeD6=ôi|*Vm9_7_F<:4-iud9Gs%D(e'V[gX^UUe8D-FrClZBs{hqPd";4ZFӜ>.n=Q_wuvP~E6=TZQHtͯ=- -WL0yu*Rjc"%RlCU}gŸ7U"d ՚g!F_wdy9"/|+9"CUQLRS|PBugdC.:""m'"V""ZS Bbu~8TIcf#:YNIѲVO^jo'_zȾٷ}ylE,z8|QD&8\wtKڌܯdAb۹^e}>SqS}sZn,TB"d(\Č"k1V8bf24)y)S-cp2]V,9$pAYjv=i *4|YV$B^&c4Yŏ9y@3S ΗJ ڈ/ 5 zŲPh"r;^qY J&RH܍0.=fFU즵4kJd43H'i=iM)O! >q sUHa'*9?ɓJ =:O2N1Q^ah@#nN$}#-SnO/%^,@kM#]i2B&!cp y^C$uE;^9ZesMo%XbFaM)ɾVz6{ɓV3H02͋RMI*L Jh!IELrɎSd|.5.&:7ďUnDճK/%lw!X&wԔ ;F&$*cXjGqU"_sv:iשU"Ј7!(cćJ2Äx%^j`$c"a0:/ t s^è,>\ܓF4NAsya@ |mg~̴M@-^{N<?$IZE/HXrtT\M>j1;GV08_*Y28Ddr?J"w/Ǜ/kĶ>8Ǧr.3zPF͜VAg|Y3IUjAdעѢ'<](L]h&IZ ܼi< '&@ #:4#qF:d?.ji>-_Q49RNܲb9i). :*'޲4˕JLM(hMHEFuHBJU58_* q/kKľJs2YT6#n|Z%o舮%]eOw)՝jy;O(U3iduze7xea"tȗJ 2fxp=,-DB`b ‰Jie}>vo0 w;ӡkZ1/~JA$MhXIC$͔5:C|G]3dSlU8#zQ*GUf0| kc%_*[PW5qNL'L AsT^Ur}{ݦiU>:ofw : VHJ̓\Ce`'GKZ% ȣ4w3?ԚvECओ&'y8O,; ;{Z%ׂG7y770JH C"٢ =G .TK/ Zܝ!7o=Tk YT n t2:C|3P!EA3 :C|Զ3A<5Y>+WL?f1G>{4|"xe IDAT4Tyhr\2|eZj% Wf$@)}E]{9ϫ>^Yߵ+ `eb{Jk3mn6n  2Y4C:6~2M-D͉!^|mˬgemꄵ6_7_f\L &b!>b%_-gͲ;%k _?}Gf_:ʿ:Zbf\iđ&űtvt䀔L(JzҎ4_nԩSg>/(m 3g>xGk0z-r3쿡ÇM>$9HȚuk,b^^H*h9/ݸp ;SNs%nQ#COS9iJ-`n_kO1+w2>{928_*y 0,eY NP  9Cf9b%_ֶΐYr' #_!_wV[!w7cdemꄵ6ΐXUBldxq+&÷3TL" *Z%q]!G!g?~:s缴`Ï8ϧ㪣$^זF%eeao25_xP'Fk/v#jZm6l&Nɘ455%EkuT~٫3 1Sưhm [l3lCrd,A҇wdϰfΞ]j y IMD繻03$D!S3dfa=/͕yƽW_susPCig=M0?][v]_uϓ*C74&Oz䋈?2'ͫp8 Vj2Qt0dH̱`|xOc_{}7mH.yC+beQi9?= 9b"/kd ΗJM;CĦdGC|>r! F>\{o[! `^3ΔPkͅ*5]D\loU&bUZz8Cى3ȐӛLTD *^|{=kZÇ]w=|-Osjc9d{ΧKmg,kJ8dvd诮_)1>ron3N9)(ӯ_K.tC7qb_0;S-_m4?~TػW]5cƌ ! vcM@hhh8sg>~&Tbٲ'y ־əy[N;djGs\Нm.M@&OzkRZ Ѿɬ9rfO`E%WD4X)]#85oq(T!t1y'%;Wr4 qu^~OoĦ4|#9])*Zv$Ȉ`hKXU=Q5M y$m%/ɴ8C#f$ΐӛHMEI2pUWWW ~3rĈU05 Wc.hd>2M]~;?'ֲaBG e)r^CKo2~򶶵"7'9`ZYhfy$!L!Dtzm x1G2 iަ$ȓɆ!*M%gEܮܐ+18_*uHM79qC2q<9!ԁT#i*kcoۯ:z- ͪF t( IZZZdZE3H&-7)Mk}.E;\=  M %E!(ɜDE0ɳvCH'7nܐ!C~7u?`s)n~o~ȑlATܱ*XKs@ܐiRr,똛=CBSMwBÔ2?$'@Pr- _1b׸g>`)bK/Won>{@߼j4ݭL>?y={%c!r7lPg}s?O?M̪D.3犯Г2sιKP~ǨQ@v8:.<*}kI@ʫjAZE`ko_TmQ0{+akD4ԡb[\=ҺnV^WAWos/>P\&Q@^"DZ8!_ qjH8.".GtD]e,Ԋc!?䓳n@| JœsNdQƑ+gÁkFёQlwZ*Tr2?𠯟z)j>7SԹ E2}@!.6nnw$ ~DCdBI& WA=H}{dF /!4Uj"HpgHV48_*;=/prM& )F"B7>iAv`!@yhH:mvC5e R 2HqnZri_RyĈa4||YHl[+Ek|tds,Y0Wxۖa*Hx~^,eDq,p)"G=ٝ`ͤ{/睿ٷgg=f!9.e@%ÁGשa>v ENKJ|ȳ+̇9-19/yJ52GUDO%_*/kTn#.{6"3bH46|X  :_q~(p׍3GIZGr4x睢wve-Iyy>#m+郠9yʷoN䅽wEрګ~qUV厬<>xգQmiD77 H0w;JPV^*+#TC VLv 5$JNz+pSbF&` +/Shq."@iU@Z4yLꫯB]] ښvVη}(H0Af[V|,F=&q@<찴)У&+s PAF] +)zhډ2$1QFU',4Gru+Aê "&s.ϒ,Bqÿ"u JT9SYp Q sw΢po=>nܸo]Gt#ڎ}PEcw4]̡ϸyo!c9` E%^g3M¼_%!X(d|m ;Uh&rXddm*Yx ]eD̸јL6$@NsiAAj3-WGL@gLtdHbf&D>\S0!9[! ;7V0gFTwNoU t7{qFVWT/[ IcY-M`rpDhKApD@JͷN!Kab%_7tg^,gTsZ)Ab ӉED$ҲecwNB^J'SrP%)x%YTPKK-)Ϟ=/|[?g!i$M7MNዖ[Znub@cmߣEhMyۄ`}H{-Ls"gMPL-t..9=,RlzpllQbϵr7 ReG߼V#iNa"ڊG H~ӷOߝ,Lrer;oڥ}uzexgظ ׇ{LvD4.{؅Vޞd%oX(|Hw@;<&|Y}v xX4/;]nh﬘z4\\v33Mi(Qh$}?}۲ecq79O+VOӊ?HԈj|;\FtYJB:woVGgt+rܱ >/Oz:S+h΢Wpi@Xqmvm2dH>}6T9g蝅 Yv5~;m C^zN;<[ni[#&M۳]jUo~{i4q2Y輱wy瞛=>;W^}W֯_DwW^s^#G?~GrHo-Z+ҶGG~w۾}avqNװ8޽wNtRCy~S/y7O|)g̹KGcˤ՘H.Ja~z=WA{bݚ~E knf]}DYƞlذA+Թ v݁ﹱJ3#Q\<U 0.3LHd+JLq a G'ΛAc镱VlpUtzc=c!V@|/wocƌ7~\\]:jꐋ4^*& @0q&р;GhT; vt2՜sRpm &G)"_ #OS4ؔwPgC ީ[-jvVQıVVUyJeljxڏ?/>YosuY^z&L87|s9Ԟ|;o5ږ[l٫.lѥOM6ݪS@}߰j#V02?ZE`ADke[kk_^ժOֿ|굟^Ʒ'k=c:(,h :/?+n.C޷i.aT޳wgovy{{ k_~łW:S/^sqǏkl@>[6n}9fͶddЭ:9!A]AQ|{ykź7>wo^{uQ{Nd9]k:Z+w+Enzdw˾pr|X6}9rzFr?o܉.~5z=~kڞz}7}Xj}ϟ4yR- VǘTPj?V[ZoMjuHQKbwN蛗^T} ]x&?l hgYdNU\V\$%d .0?bXFd{F@L$ dVN/:CJ8җ\ IDAT|8m97m۱GQRI*#w2Y*`W^_.)Ra*ji]HKg}3}K}~訦aϒ[HmA(ٰAZRtJS26X۠ݳ=eЂmxϾ8}9ڗ^||!%U[E JC1 y| ~gzIՒ(Sܢ?o:攨AsoS 496a/<9j7-F {VMi |䑇xǝm0;}DG(.'"u!ŤN*iG'Ԫ)I{㰽ϽXFkw936R *]ә9 8R`H*It|;zJDCRJn e޲(6*9?40gL=]AHpa @*v\xFqyE@Y2Y tU*u+饪9[nӧ=9շ>&e'>czâA<&xpzY;0xp9AZ*4pnaϮ@vx|ЕH^ ℍ\9+kICL{BЏxC{Yd*mF$ / O@ֹE ::ljqG;6+;j%ٷMci-F{?Q>kC$ZO Ɨt~ )6am;ov|{~U0aKҴrӶdY>R)Ҵ] dLHA%Vt~0m#Xi? 6 z1w3~'ᵒlSPtͭF9b gMcu՟8~Wn3g8htc•~qeiA5 @mRow3O?QR\<㊙wuSĀy?i.gɿe79e6q?W,XVںdb9Ĝu?P_0vW#\S(o#E7߿Gt 񦛫D3ḊdkCf)p^Gt Zda J˃"]#E80Tc^ LZ>7UUNM"4$L'(%ɒ+^feJ#j Wz{ i? {z{#F&y3J`eGsl|F8:6J.x-74U9_x>c:BJtg>*vDd"h%p Dܠu+znM LJVbaPfMQ$׎L/ %P<ۄQ. L LH ׬~&%y)E8r,q% vVV>{,+%s|ZLcϟ\p$:*K uؿ:{v{芯ngH.am\qO{M//SNVZ+yǴ̣lwvY EҀ:d]ɫgn]AѩO 0. CgK#,Cun( da拦w"Akf5!Ip ,r:ւ{P#2b g?U2`<|o͟}Im1OH+_`L" Lex*%tKR7hp6&kv\GS,8}Snwv"t{oS& Ref@+7hO>i?oNkS =ԘFqCze.}j2li%6mrȢPUUҋ/uǝ7νi[B"4"/7o@~f+ @h;X',Y__z9re\sR72G&Bј;@7ǎ~_Ӯoo}F)TD["ʲL+oJF ci&z] t>GL7B\Ło$-MY%Yb\?/Qts3gՓ' W|>a"eiش7m4D.y$YH{~ꭩc=Fg 'D G?Q~B8Q:W"NsQ?o:ҰƓ-Ȫ|#`@@6+ M6yN,)+Sg/;];WL-Jc&}L8k=Ī5k?iP?mc*~K.˿e}6ќ9٠ܟsXEmu xxl>r5qS0Yו'70`(!)_Ʉʌ`rP/'Nf'WŦUf,LZ*ƻD?O ]0?֌+_9I2lzlJn^6|Eǎ؛u!;>1U݁kjmXE/'՗_FnYkz[H ꒮/g^78Wܥ*U6:=pQQѽ[k??s`]f <S uՏ?G+~V= Neuj떲Ɖ'bx-ZDkf|oόJ76;Kj9pP[M;$5j\άCV~A3"Dh.S!& Jވ#d酩,+V$CM5[ L{9YÍgzy+zspp'ZMtvnWF/~˼Lܼﾩ5AӜ@o(Zɒ&e0pBHQuI;"=#BS8rI+Y xGgΞ1T3CDy|Y1䢮$%BI*xS^~THP1_b%D78e*^{3Bt֎\0ƕ28{GOn9.D:'?ecN'q|$d|gؾmy'E(wO.am\I {|g5Y3v옡3Rq=JbQJs*޻9 <,iY"%e9LS&oXδΪWMuyg s^`g銃( ՝z4*;o7=jv Ѷѩ)PWu/33{M충(E<'1u֕@7׮]UƢ-Bc][ULVt^$P31Na)["xkgyXF̣"64.)CH1$Fo-Q t֟띻 I1mW^|EySzǖ+ђ\xkD^2}6YI 9P 9Ȕ)SxˈbucMtx;q}TA12'ZTn0 7t36k=rJKK0˸q2$)ʠW0m*C"'}.Ó5M1.6v]>X>bY9\H)\~S)]fy+@ܯtC{ݧk>n5~ *s*Ǘdɥz^WIU ƕ{g]rŜ/nVW744 DM~󩠡״$Qb[$C$YZNR-E޺K'"?z5sфlbS =?+SYOd6-sO X×P4t1ʎ:m7r bȭ>njy)9@n5Z͢VkJr k-O;wq؟YnϹ ܹhD]ͭg j A%p.҆#GXg_7(|#kJr\y%+6'Oo:iҤdFEBIM\3C Xo 999͎64tgSSٚ`˦ ^}\6MĪܹsio#Fò82 kr}wjY _RK\/3kL1r4rOJqOTdֲ뮻^ {C!_ sz-$iه&3h)n- \4{H/V6Ӓy&F6~C9gOL,JAzl^tW~e^;6N['nt) ghn )1h~F M ɟSH/<$ӧwrzd7=ݕ\ڌS֭['L,9szo8{V䟲.BIl[,ߞU޲yix{-"i`NnHP!uYo.\Y 꿯?P[6 g]HMW61N6ndx/W9<Ⴧ:hOD,R>As^Q:͛ImjltmUs ü)KlkZ[6!e!COxڵQy _}%,u^ܨb(Qtc)TdY7^b55/aW}/ jG֭N#wxRO41YTB*.heU a9E )P|t -4Yԕ9NEaR} )-g})'³JޒCzCBjY x˙&r !y4< %3镈o-g3&@7o`_qw3gj!%C6F"-frp6i"[ ,TJCV8h`mMMǖ6`D +@D'd>l7h(t#6J<=Ty=\y(1UԇSI zB _GmXHqjU-/t]- ~7_X.jbA$^@G;Ypx&7Ywd[W[Sͼ6yy9s&9}MQ'.qʌwʎl=y۸ Y8eILfceȗ36>¢r߭в6Q5SEN x볳MJbrg3gd0rYT$,LJJ8P.{an/oiΏsWH* ؑvaÇU)1yh 4?)2B¾;R~ e;TWE[OuɋYG-{oaf4]?&ٿc1+g O#^p#vúpWV>H$S;هYWHSRKˈ#:?4d\!ɓ s<8dĝ␬M 3*:b9fQTPC1' /8U -bH/`N J/:Wn݈M7qJtf3g(}T\TŽmjj&Z"5 FLAVJ*w9Zv{KK(3@姛 #昷'̪dsM:+ѥi@Wa_~%yS f۾g{w:%9%uRMJ{7c{jAI|qίWW1N]uwҖje..{?-i"e{K*>LYb ?m =oa~ҭx|k A{ kq$7;g>ֈ'V>H6dQ lng1 @"%/>8j;OA@a4&F%>0a0-M;JY49%4|⒡Xܑ=dnhVo4O'ܸ{ gA4n{Ο>sA.A洮׸(YRB IDAT:&: jњJU5Yt lUDʜrӠO@8ER\zв\:V`:At&좒D^HU:gB+Tze+5<*.c8}PyֱUFGd+=tIy#y x*OD9:K\<#܃@$R7,@Yn>E}]k /ϞB>g+6!f&˦m{оA-;X->]gA(3ݔ:^O3˟FvagM?؂ijjFKy < _.-3oDKg)zPFE]r)}^t74{rjGwo6,c CZW_Mr:ʪ:#? +ݙ8g9z=][`wl}xKqB8T9bt:BE()$"vLS\ޒ˳diDOר칌eolD hҭ!,orӠO^: JhK"W_D}yUF+ibd+C]虜\g{a0Jg"b˅v*Yַk* s}aSPPOVM)CnX[t:jj4u&QM݁|J*E1=TZ z=cWT$_e;#9V$ &eM42Hző=p翺e3:TMa4d!!tSw/?18zGHNwVmvdmak_7.?XYzbHϕhjLf]RV4D(J&9漣9qIRêҭ=f>yk7OE]1g]yhd'ILܔj7(okoǔ- + p:EAm_o&,.՟I"{U8%.4߿Jj,yT 8x#Vz$9o|gј^SʼKޮY ߯%0haf7CV{#%WA1ya$cIocSNO<"y{Vlǂsf6},d s4t?[g܂ݒ16#u'priY$\4 '$>O2T)Iݔ[Й@}^*]X1L+Ƕ:qE e.+Zп+Sp"O~9;%%=UI(J#']8aqWb|-x l 40W~4Dƒ6K,rS%Byכmm6F5+W6bn7 &SR4|' x|cϕZLQR`Zt-GƓʟ+蠢ʟ;0 |Yp'b'͟&3UnQ-1$sLRgc\ԙyBQSMi[8R :mRe"IH{hJY=|Fnڗ]I)h$el;K˗=CttyxU ھ{WLtȑ5ǪED3ꊘM:vB%NEE#pvQPWdSI;:#ȠDF -ȍWh!(:~_ЩӺxQA,n%mr}AmoD\Y~nRƥdpUj >8([AZsgЉ sT4/=dr?V랃Uz񙗔[눝>V;VYшJwClz:9 ͒;!_E|sFA݇·O}UYu$6PGޕ@As̟*fO$-JFRĔjzyxQtl EJr+hBA]? ^ wLrJ"d%9qBȫ.m>+#f>] 1AV5^BFh朾N֔^C[XrF @̨%)Z\-2ʏE+ ,D478lGGoy_mgIUGawe" S}~Q SyC6,J^W"Fc.2: ,׭7~0KMGy唫4h%zwlzTZO'Dqܼs]bOqo\t1V:]r&]sp,vƥmyT^n'A Kv"zo4* #Ͷ._nih8=D+ukV/fIҪ!>Lm;\hqȢq/*)"yp:v&jASi^ z%'&44.~Ż@6l"8vFp28amz!'(d8\91zF6leP4hlolM C"cs'Wsh47]l`IL>%, Iq=RӥkTEaU|(f[Jc [SR]:oMkd{Pu &d44^DJ09eh:Z9\u*/iPqѺ, w(t@O$Yd,)s;>]' K%H tJ͉_:(;yʼn=PV̝XBQ'k3l"*Y#*>%$12,:Te;~]ZI,ddT*R l FV&d9' Lo[L˿kV/yIf{=~ +?Wq'?O`zkWT}X.|c͕E} `Nk^e J|n 1J=֣RC>tN9Yr?eI7mZΈSq'`9VMC EY+`,؟KjRJ^<-2N49Z=O}9{ S-FdaC|[G,2G qXJDlY*Px4u}} =MG\_gJMW/C*U]UWI$ Â$Ɓ?>׮rFBkD` 9q([H69 saBy Rx\OC@^nfUu-I>T Ď3D~tr nڵ/j`u Yu$1cm)DSeuؕ9#{%d!x!' y$$6u. SwTFד2tJqT? tbTlG,!g QTUɣ~x܀D̵3.c<`,ӧЅ7%ؖ ׽Z+e 02{x'S30#YeoIOtΤe/c+jSSV$eOt! hC8Ќ=|M=+HL+Rf#sE^z~?kV8"İ 9"c鼝o6bq3<5]mtաmNj3Kksr/mS3 6\Q)yt9ix9| o5#GO'm@"25.lyݽ$L" 㝾F PRҜmmrl |?~/KNv.AZ6ɔtess~+Լ`:™;wM$3jDWC2h>Z5}ώ_z剂>*o#;FcJѸ5Ϊ(m8Z:K"J..ҀIfVvHyE}sIBd͵ৈCE)?;(ba)&(D*-MIMK"*VzU1EDQKxOt{ g,avfvX.>F{f9Ϝ,&:K<}״:k͉[pv\0h"n\T+*vKxm8kjЪe`h{Ֆm2ZZ/j5cj@cn4+V~w=MyGҶ7CcrrrGAo5Gs@'xnFp,i= j;fXоYxFD|Eǁ_1`6┽'n 6~cJ:bWŴ 7a}:E=-|@e>XF}+[?z*X<ٝ:7Q]py1_(o:"OĚ:l4!¿4{8~w9߼&V.Ǹ= ʲoηfB34oduejVfYI`R4[_8>](W񣶛VhlMjP-ݽ ꩏\~-&,MFMI<.t\Ckxv遗D^/%7)丿/Ujɢ"(7EZ zܭG }g>}^W :uRrCӕU/ivRV;9҇TՃ*ofGj;j 8:ە(){OյSܫXQLGxĝ_i7+>!-SzWk5B|v[D}q~1c<߼QV(wN/{Z xa,?Y(^aoᘢ|E3&.9p,F(!g_d뗙aة3jɧK5GrD:ƂrD4xwjhA4|#f6^~A~Z./oޗE[Q,1v>g| M> 7? 2a<2Xy֥۾Ò/?}B9bڨAN;艧G Ȓ( 1=߭Gf\V6-@scy5ŋY"p\󟐡 _Sbқs6nʼwoy*>XV:.,~Pv{bgO[k@KUՈ/iu~t:s+u/۴ +j <I\6+Ei<2RX]W:3U5bݎЀ PW1cYbvYqr5Nby3 )_/Yrr}\`>jʈ)xO~od4:vpVbR6 AߴK5LȜ?D683;M(LjN{pA\Zlp6'ƙ˶vic8Q[[wn$6~@X7g{e3\f\n-+vpANэUB!M$((&£:iPnm wi->R[ϩ1M̼wigCkUzgl;z8*-is [tsv!q`[3etU5qr.heYlOԭq-x[D4 n\%X3/ X<mWKu{*u]9U{QPW׍Yi GuvWůOq];u$&j0#%ĭiajAŨ&'l4I1m2e;n_i{K>=a`|gPuÁtlӦ -Vkç_>[!Ϸ' jebytv>FLPgeVRdQ䕕*j;lEΒ.Νܻtյg?fHӊ%:YV#}u۶F+\v"(&ϥ fWhM]\S+ڷ2POjNYIc! [/~Ϫ5Lٹwv+U%%8dተ<aGsW^zx5_JsGݎX9Uq<\&GsGq~|~׷whg>vbHXI + 3f EsNT'vs!SӮ};ǏM_l^w1T:UgǸIruzt8u>04kuvbπz9JrvQVd\7XU'Oߦ0+ A9NϙLNØ*#w>)5BE@XϻbhX/Fes9߼Ӽ^o$6|l%)SGSzz?^ɹOIpQ3''O `8vBǙ00gsТ94U66*\XU8*nߪX|E&lljhqqІ:/`Ʀn Ɇ^krZhnTHBFQŗVm=+Vwܝ>o1s8)%'VV_>~4|䵻.S{36׻(W9/E _ݴ#?m(瑱2<)IbxGmY@#W~0?*b,3 ;=į{XRTxn%:'G-]a%ܩ!83cU< IDAT7܅M !Bq@PS w 㜷/HEv;BLI>1Z 'Ix]Ž_^&/P\$zɬ**e!U1w0.Fl+.zec׵PlM*q/D7=f`Z@4vzx}P_<(RV$ 0/^H#3hמq:Ħ.5R$~2O]DZW@wvlbpRթT?dd |eŒ/OOòK7-:Ŋ;=# GUw0̦G(Oc)NNR6n||丏NL#݈-IR 4R 4}7C:;Zƶ*)z}݋tS(r.eKnMqS`)m?1cOL1u mlhv s>&6_9XМ^؎7a#JyvCD(vvd\2/F^i9>Vs72t4cu]P ظy}?]CnԮA_~3HCPMcPښl#9n`l`M"|Dsj 5U5aYh6v(~rZ_ \P7Mi SP?.9fL6Ŝ0nRtO/{Dzs%4)0@C"7s ssU,Gƈ'26ؒ mشF}!֦~UD⫸7bhnXhΓ͗T557XW2\z>d;2VƶkçzϪhM"sPFlZJM;r&;Qb9qjq$̍H.01o[+9~G];C<^yd7W~@n|FJ}jQo|TsP `xH|ռ||&n!񼥡\ D"ԗ/ԭ.4LeCOtA`z?d(wϟűL+ED}zp'C_H,§aV.%RwmTB4|/ѭs<IϘgXU?.+(.IRN[oͤՇͪJb[[n|JYXTt_;8U j͜'ƥg1P:2w*H&??JP*XgqxYWb>>Թٱ&֟ѮGo@9+Y$1@i{@,kfUJئk| 5r97/vj=9SCCᾝnAhJN 6 _'|e\,%Lʯq߷r9qrO/a9tҍ?!6#նgGR# 3|̤~ϸvo`Γ-0(˞;V jȯwb+5wjЍϘ r.e9C-wg6:'Ovcii'~O^R 0; h|l؉4xnDоmɠLFH_:'5P~iQܾ=-aDYGS4DzEs!7T '.Xӯk@!AG34s]1@\YZҎIFUq&J5$:P|fs +˛d"bK4W?yݦg`KCy;H XNvoa\4ӊ]W.dՓ+70y!I{-VIBޝTQ$$,2R&i)&F1!"g.h:ܝr׊8[,zq@'-R78u?W/eGLŝ<'1>Qv-_P3Y3s3|0cFg:a-WtqP?gI$ILfǶ{y{4U+4tǔ+W=:۝@Kj4f 4 ^` ' 56Z#Aޯ'ukJSUG LdJ9dj(7Y]L,Swp{Ǒ&. iYI!gbOyr)@vyYQVѮ"mM%@8<::&e%w+nae#uNu-VxTdjHsi؎FTC*' wH:s(?7*zxeE9ڈ7斜qQeNx 9БOjcSWW4辡N%w*ќ&Nܯu}I蓈bjXϜ5cR^yᵢ첛$' 0SG#HN]Დ?E 0'N !ŐQ}pBI.{{z-(f:"xDӻ7'v㧒 `XSaiQ V^/eՂ\>9@!lsُ}]Q=d> P\U|5;P똵W}* Ajv1Ȯ9*@#67o;> hx ^fy6Uڋd=C3&_psx!ec_Jiъ9ⲘӺZhmn2>zzVE~iKc.YM楟=kӓF W/fu~{)z5p H "jae*Z[DyIyq@g%m)Ig ׋q|b05* {^{%`Γ\Krh2Ac+>*cs%kh3%gP&*w[wLQ{p=qCP5XHcK&p}z&_gd9@7y۷"J"M͌ML9Lf!C8DI ͅee&e6T~۠}{B|ݾ@`22/Yp|3@cYx.5J{mA"3isF{>ϙ?VciQ~?2Y>57]UVK P6nB.tXumì8} 3uaJ ܯ_wn9>rd$t(1gX[b2a4eEg'ϋ$kŠ[*>ŋA:RDODYR\θ9H1|_(p WqN5{u:_QRVEQq ޹!>mBJ@:mm 5 {2i<k6ׅD&l%\'d&9^J&@s!TsXdUX4ì8NSBOv6 U $iv@%>|BuY/T9JF&Y(V v6N>ac(--倠yyyS9 k8}YdԌ|}$ǺAg}퐜W>mJ7_+e#(-1bw Zz鉸qRqv&3 Uc`CpOvRs|~mBASC @47U5؃ms x7-mqWBEU{;`aP7s&[ڊdca@ImC^pv[o{\yc]=$%QW.#ʗSOы?p^McS3zTID͸ k[qǸ[DB!_v#K6dyW:H9GE~^4q}h!py ׉ٗ1%|8C5J!ẗahעn%|~-1Ds.nmhլvB5F0 N;³>w*߯9o(> OLCLΖdC6vQQ\HY.IҙN7)nBv$%GHD\(?q8V rSkL>IҴt.[rtɼtEDu$AĠOm ڊX,qΣ;^N>+j@OsM'%1 mV֜Y\g]uUSb!C-J7~qR] rSCz"6،>#$#N[ u. C"]J8(qsqucg΋l ǁ%Q8"بeQ ]̧iGΤC%6m uRx0 ,R˯_a䉢';KhwL5Ȍ* JӋ \=USWTih# hfAuuI8ìQ  Ce/ +Y|!am5 :1ٽ_7FWί~/P(j!XafM;^҈͐׃oג eU&;ZwUsOK}8oa?:6,7~BASni=a a'S2OD}((ӧ=xʫx0i ͑|O9]mTzɃ[+q6K(@4@1>iAҧORوT6Xby~/}C?}v3"5ehhszNGY_Q}ε529?0yi5t 򭛷3lWgM\UJCXj=t؍[caX "e\mlmϟ+FXj *s"!u;-9ʽ IDATEmZס;Tea=Ft`d`zE.2>Q\xCBxg]4(-{თDtv'ycccK "=2bwM qwuSE#(Exnscsr2DA B*tUH5"] )슣2չyDߍeAB[@@P]NT45=/۪c6l1J/;JEQquӨD۽WvoEU{S2-AG^'n>)AG&^)25ÝJjo|S*}j #n};+?\yL/yTsr= w|6wOπiWQralj"K8!!FWeK!(;Ll"V,cd xiSO= _ϗmj>n1w t~s)[$Flb@Si2% T׺ P5 *!"<j U_jzںV=/kkWhS ҇/xŖ`yDKK,af23HfvfW?wڗ&'̙h4w/4(2ӧ+qZJ E簞N5%nUe*cѼ WkllRPiQYLK*pxVVX.riѥbuK1GC1)x2*]׈6~IIh?U"gz4q=9N?<z2,woGsI9R:a sXg-ӌ[RB*5&>mH1lpdWoºY>MQ" E7ؾ?+%jRI%;~,28Ɗy|l8sq*'BWgg,OaI9%Ho[vPk=DsMn9qqg՗ 0̜^^c9b$Z?o{e0H'E K1 a,-<:qӧGKtڮ҉Xce{eL')~ t.AA] nw rjax1Nα"1ShHD,pchڅ^rp$Xy)qqqa/,xcbij2צY?TzX^Wʢe4cZHYX1G/sO&b01on~/̶|rhz`75'N7/UYs˓8 `qS"5d:̿VT2Eu ;UŅ[6Z?MN:XlOVWJ:Оɞ92:V >[tz^)dލ+"rv _%朢, w:Ju|hu[ɩ|l8j?tI˅N#ǫ0 Y5}ַ80 .`0۷mѴby_9ڮ ^}c@'팃M5+>?Hbb&1d<IJbCa\f36NάɩVcCsh͕jV ,L;$+昩 3pwcd>^b~"8@6/2}G9swM8Evo{LNxBdD$B|G 3!ywp{p$Q ZaKKfօv\|@QL|<օmj.suJ_(iiMPV\Dac>X#St}KXdpw ^O8QsĐa@?j٢plejJ9`kh0`1ǁ:ׇ3F\!!|}11n^-Dgrqҡ⋜yPDF8l//I||F4WWUj[d89: "Xd1oe|GΜl }/)/Ѽqwm9\lv4Wwͩ]BeFΎ2agywfz̆?Y;).J#z 4jfԛIHY&GL ݨR?&K PӫG T QD\|pw 3b}x'KaԁhPB4ϛ3 ]kX۹q,NK9IypLekɲ0RL/,S<$Y[7eNwLg "l !mV]Ui2ի} ;`S8;" nOE$b3dE7q7tvoZ aˎ*mis{eg}e%YSxUOLff>\hnWUaЧ.dFÙYY,@|""Ļ)Q;54SE80uSgZ},<بh۸t𶶶Zim`P1vY/oV?mv g RT9w7ۡ씙Oy!3+2Y 1&W{VѥbIUXyœl$SZ tګՅʂuSڒƯ2U8\tړ[=PE[}%+$%J}?M?v;UG|d2d`/ߝXg`2o5; TA}r}NaB鯩ki+{[q9s x0tp^"6 v"xP *lT4f)g}qT_op3ϙ3M׃vZm6͟e?HfIS5Z){Ww1QhK?Bm0NgiMnk]\/郥5628&_hпWrŪ+[M'`? @8gܠ@>…n 陇.~SJ4#U29ihS+eJXX=c6&daaS`>/?1)inb7x/Es"PtcDtXHбk-RLl4UcV >UȄ} ,"̄A`ptT*SS2A.2<s2 &`&1rbڵAZ[9z\ἱhNuHL$ϥ?1{X R?\x3RaI[t{H<'OCd ^_^۬ZL[sTsx|Ɋ.=Y9f!ޮNX^XaYTp%%W=OQ{bI[GΪ =b=rz1Ifښ6l\Fhkk XS]7Ds,k(aoo7tan6lN;9iG;{{&0AP]ځIwt4,3|aaDQvvvЧqe﬎9\~d6cG%hggEbʕ1n1bĴʹhdh693P aÆN''gGG<C䌦SOOvpvo?IO%۷  ӦΝ7oɓU$?_8+,^튿-eҵ[oTE195g3`[r]fag4:"aTNda_gb<ģqZ٫u=%N_Q~>97(ޒ~$TΈ8?Rc#J(dg_;~ Uթ<\ gyE/~}H M|nn.g^/O}z D)=:83irr>|aBvBS81!; y6L>LD,*O ?&gփOrpdgRre&N@[L-iH ̌Vn`6(*eh΀mͫ*пNTȑ뽸Gģ [7eV{hOv@O:TMuUa>,oY8:E ޙ2'%GB'/"]uu:9p)Q 9^Q$x LoMnL/uTS+[dpȫcdFCޣ OjQ< :WZ \/K@(g iL]x,ЍDsRX/0XqvSSjm\iѥbN~tp ]1& C T-_wOe^^>5s7?tR3v* …tD1sM 0!Mt蟉Q3h֙U駳av];XWի79z -;lbu]KRţxl y괩7m dlΞNĘIL)蜱>1(ͱNu54g9jnuo%d 1uj'gB}a|f2>QB6" 3ft":3'^`QGM&ҹGpY i)S2`T+;Jќ|sfGIYF~JT2tB h=b9%dpȫ"3BRВj^6>6 ~WW]KS& {Fjr)XBIboog:0i?v+15as؎z\rV~a' _##g'Z}W-`¼ſᅿY-o L3Od9^0cc0akwmOdxHqm{>wT' C0if[ `-xk~z@w[ٞC4-2hѨj`G=9A2.0c@l9|Up25X  []޼xPmA `[sK.\}5='d378fJz(C*/;4} ǎ1>)o&'F ! X4APk*Vj鵨+uUU,., V j ʢ$$9C{䙜g!=?)ھ琥'#Lc@4XO+Klppq" ;W q@Fbq5{ Ov@YDZOmkF>4=`4r.D7Wؚ!NCU(r|0T֋nHV̥I-~:'-\yZYQxLt^hhWP&ExT|RMg k|nny[(@7C&L`ueA@)FlӹcݒQ!i1:@-I(HiPÔ }&y٫2MTlhtOŞQ$[g_ @&1{A@`.|p<*u:pohD=ko^pr\q&n*b./K:˧SIY75aat^u ]m9TDs@'@'0GF9M{7eΉ*;Ha"u3sIڨsjzsԷߠOF3]ņm_`e~h vQ/m(u6 \m܋[R"6<%;|L(ns=o !5Ud)yL_{/ حIĪ[j [_uuqvB+yLS:nyrqZP%aAROɸ#ܘN4qg䏶, h8).:-FeA2J5_._*gRϡE5z*=~k6hP4zc|c:MGbVB«"aKqB9_ZJ<%K.l R?K5ZO;M;45G'&3 @.\) mkPWŧ3#:1?J8< %KΚDvҦm?U"nMFѤZn0aD[&oZюk⺁\öjzkrRmɹ۞mga(:A49a܋!f Q 3w9 / M}ZPPGI򂋣 rVowL AMJ_w' ~S>hܒ͋w"zE2~.BQ*3!Wv,:җ,7ЄnV]L6Sm'FƵ"Jbu\!m/~ P}n(9jgڹ6EÇ~?n765?'Oh))=nE@VhY3jѣ(/NN|pb"ǣJեv\j[ިGGwf~zAVʷ?U9 ihh((u) շ#?n2 BbcbM v"@k8ܬ{wR&nWwgإsCZ ƄY^:dR9fՅ]OZfl#NE]س/ֶD.V|N[sz1MhɎn"(-{~4˩zr&kM|MM̋Z!|w(퇱gˉA3hώp@UNL`#rs[a=6A(%42m4o_YǬ-?Vnk{j= iMMmĎB+ҹ=~7- s<Ds!n,J%#ϡ pܼX-P.L%.'b ʛiDŽgYGsÉ}ƣpe~!oܴfQ_+j!1m[{g`wf0",->a/#'t]vv-b܋$%='v$sn/hި^za=R X6SմsD6/q~imR8 lh(vccaN100`삀hlqg| =Bp+6Rf'jT^.iEQ^6>ӎjDs9wq+G1%oɸXj'N3\)Ba;ݱ9+H(-}k#wã?XۉmY9Ū;q)ix(={1WM¥m^1).9RX+z lDKchh:@4sE&~Ns(!WJࡖCů:ܷN}8_],tdT(ޭ~ZYNgobN2Aז`sn0+ |w'į,]@%av;ȧ_ztyA!_N+g)|̃WNs\a8k6ssxL,[ N.ޓKSH;`tvn>)yU};D1T=w#pd*@?Ϻ{T`X CfԄ2/ppym=cA7򸡺v%sK+(p/?pPƜ1ղv3lle]{^Vz{ ;C:-mFV+$@+p-%{VW~w++>2OQIT`s8FcOC3w+Jb$!ok>'3&b3?W;WmR0fgEwNyrGK{̝FzI4ee?B~t u?q<)8{ 7K9PhJB-aYurPy4:de&|ЪH&BFDG~z>*:HtQik>v"@{:U\-{Zvk=nr*"jN144 iEDsM004xKa(Z'bV(aqh*rYԊ 2muqy~Gx}'ڪ <-$6&nQ8/]=ujx0E.=<Vh}S͎Eg]խ3z쬴#},AJ7(tQIWYǚ@S|h'l%WcO/_X5eW^$۫j\O*+K]%!e#E ' .G+nb=FNvΜK쇌Vv%迦0͆AǠ(SY]hV`ՔKߵƠ!\_hrS!6glYW+o7:isl=o`,{w6Hg`],VVKͰ7&j\OaqۨVW2HۍG1[m勮u)}wIz@_D>W7qvKoyF>1a#6vIT?SKx Y-n$=ɾ\+pw3] M ܬEL0Ç H[6/]d넯ϝ=y㇇o&&= =zD5#M~t/ Qk䕿_n+~~j57aS'9gkvKY GnN\+H@Oz/`2/vM)*j֯K)xXXjʎ>It_1""}ToPޯVVV*{wj*K7H)ާO 0:&=Q0WV\ i?ѝyڙ]B-q'L_ 'g1v|xf1QN^yg`)I:=j^L#wc"={պ'M0j&<45d[NJƝub|G(,++ռOnGW7 yINiW`['!Ԇ۲ 2ڿ?mf+xCm1C딭^BsO@ 2h2v$K@'PiwMKDyM1<לkV. 9BW_o_2sԉsN$'?cŬ7{lSp>ߨRK(fI(")F{!=)7<]:'\ăZitԠ`T6EYrIO.JA~AzM<+ydo:4/S-H4.o{6$Ѽb0kzPd|Z.->=0wEyg.Akžq }b!~~K*5n9hC-ZMGnVr;ٛJaw>2Ĺi;4[p,,VyÆGP[^dRz?!:8V>ܬsҦaZp'h"0gOŃh@jTmlDUʤkB=5@D.OJJ, CE?yÛ?xcB{֭I4.m|'RJ<~t)F򠾮\[OКMZm*/,{M<KЊ"- .۬###c5Itk 4O&;Jr2%9q{qpB^BWѧkSB..ן7e+\ɣhҞ۷: Etme}>ao Kmc"4@#llx֒J7G6F{oETc'K\0zG\\Pxb4ezsJ$)sltSIuQc_(FSZjJI v]48<V^sGIU o_cw~Ѥ=b5ޚj7mݕ%lS^ lX׳\i0RVt#FR8EQsM jikO ts>nNamfALZJD9!kS9\o0}j+[u_i6E5؊9eU!ܜIZ͈9]`G1n}k?6b`F QYѪqX*G^@!lAO]3>|`@ $rMdſ= at}Bu Nqārqמ{Kݻ;h)?!i03ٞc kM\=' w5~ju@4ZXxC?V\)6Zl;K̖tZo9gʥu5coVC|P`Š)$A#}gT{МaU2d~zdM'XjA(޺!)A!a ߲SŞ5>)@RXrg,g7+z= m<24utuUa :f2hk @1 vS΁KrN-isX4ЃL;Ra:lXVgMU!צtf\z FUb!r\cbZVQj%e&-lSNeJ#(Ds`p|͘[:#ɫnp6.Bv,*ζ4rcc# KjEsҔ/ Zȏ&1fS$Y @'9-Px=sAKdSgSKo-߰Xut1li蝧^U~JQ͜W n؊\k0FՕkbM>Lzj,\ЕYBб@ROc/#Ya*KO\a]FRN޻]l9% ֑<mL]1e¶w!|+G@9/_јQxwe#eC?лp!]9٧8ksYzg8i16I<{LLAu #)a/I\}z DlO 13x_/״|Z>MPڬf9l y0#he~n'˃.+h"yNI :CfVH!&-2iqͽ*1CϮ gY-g1U/;Bђy4]B|ծ"jHqƈuGTvL%)8qL6s CjF%8k&xDiu=Ȣ*/6aW)O^rV\%Ws/Tcb.gN~ .r2om{raɈب}ћIi?[?7|GsĸӲ?]Ǖv9F1hD.Zzb"[:^V9@Ds`'hg|쎤|i]+4%VKeھ23[bkQ\+ K.E'?I( <۟3uFjJI:x4 n->ŷ;I+ Y4ܺM1QCV+5u>)\{y׫?e̚+xob碆Dred{+B 4p_/!2nNگWÝa%rњ %.SA8T $ٗĺ $K%n./п#UK#qwB$ugN9?jti%4RZxɛ!;Ic2\׈R 7ϴ p.zŮjur$OAr:~O<(Ct Ѻ'ZjxS>AF᝱\>3#q/ 0 P*(@,畻i]{VZZn/RJh^  Q$qCI2́={3gaY}g==]4J>hs;ӥXE͟,N3.e<ßm *t Vp Yxl ]h{͙ƓC=joǍOzWU; cƟWbx;[P(Cx0]bNֲ|1SޒW,iFh%^yx\wf߻dv^,KҊ-l$fFsm*`&HGW[pb0]H5~$?/2sJTS*gCz\.'Z@+H'/Df aJE[I~yABMMOl>h~^&rscګ[(2zRR{E"?R=\NVlGDe +}@Ҭ 'w!7=AsYwNNH ~mEG 4\U&\B&$ȃFCOX wrדJZIA&`tR{/v[LDvNiGUK/Yy}03܍ %+ i3HS}?@t+>PSATd޺e]F>NYN5&w9#nD|qq[>庫t*DMB&J a#xNiE'VA~!Ctr@@DHбiS{NIY q0KMM5[PE8Ҏkh릵B&4JryE^@ӗclaFvsn;+vj#G%Jt ucW!]yYgkVlT&u,)of%x=hȑ"?BHy|`)o'EG` Hh."z@ZoٮR)ɻ&gdvN;VG2JFsٗ#*<16%5i)v&OS3g-9R?xp!533KH^;PΖ+*&Y3A󭻊:vwlw~t|P1@LT ŦW}pa{gDT輪҉YijB܆5VWl i ij]rW93'rvI Y_gOO|'M&T*U[B}΂?eMgcgfMƤ;Y`_?Uo7}7ifEΔ[yI5vP+Sw!#0w촩.}vQѰ =RRB#UdNΚW;SqD~%Ͼ,0+7㪵Oʸ;K^wR:«adBf]i6zTBBܵ[H&dܼyoWxx9d93Vx0rlh/櫒_3.DOkw yCbdgw CG#kkj~z[YI!bT۾cu句Ӽז$7v6\nlh NVxi*-˪/Rc:NZRw 3=i%< ?5h`R0* {rOZN&#S]$.y/ĉ5DAAA"<9 xגRU1yY1̬"jnI8ΗxJм^ljO+ѰodJ /}pGۍ*:uK2N1YG]2}}1U绦EnR+noK354 #qx|%ߖNA(!ciB7Of'$HjVw 7,[\=*T`Z`sX[wj\E9Ys?O( 1OJ7;{6䟤\xÇӋg/ }YT2T:Ǝqlp/XթZ.$ 'L+k(F!O> #>͝¸ͳ;9Â6ź{7YtNHKI%}Pu%cv}j[ob.yR߿E{ KeRktV 4j;cׯ:zar@TyJe2T\2JEg2iNq4^&x"wl6G󍦫NI4RNŅr{Kf'μyl)ոH؇+)m?cT=˖OU7IEp_ b!\&NM,K(khmFR耤P?snr\`'OfMxb>y?*Ȏ`똽#GtnIw 9VRqt:MM'B\vl_EDDЋW阧8\IRƃS%7"wcPqqq$h~ls?`!l%~h%ȡw9ͨ;lԁ^e'2 /TFvɤ;48^l>o虆gH9h|8Zm|,~STOee [ȩ@QbHH9#vHRؗ"kHm,"9-%5"veK`_q֓͟qc\;p ޯ_????;=AszN@KWj;[~ B\;9(5$ҿ r/ZfS0(*欟9~\jɢG' L&喦kD ;bhX(WMl#rM {T'W(_6oE\+pt"{FT4x0i.ɴڮtlܩ3̐'--mv>1õ- '0~LekdXGE:9rTYf, R/Z'&xcLuuL2R ?R?etfv|!luWc'ux{V%5?,R{ #C&Cs>N:Oh~N` YHHMQ. (aI&AK -:lz(7{!IloypМD̿ o^va'A?g6<*J}rI銤f9o(;m]>Zyx,GٞUbt ,)t@> 6;j`'ifWE]~ /Yf b܌39rJvrcQYJq{Nb@PB'bq}(w'Ŗ%b<篮ccG`Bzqs:\EM=zXg젹µCl_ǕjS| dQ9,$((АܐG/jTf }l@f\oDfF鴨,y$$=k=i`Z.63|Փ`Iž{c~8Ozytenn@o`.y>D4h1mP$B/XDB hY~dav7X$[`~ -כG?wwb~5_s~[ 7: B&nH*1W[ ܭXƧ-^<<2ill_x4f.d2 Đ":&4n :Pn*\#eRr+N|B/2H=wyiL(t?Ak۶?-?{g'EuZz%. 7)0сH(F@P1Q(\ &* F%+zp% h.,1zQYJwwk{ϩ齟?ӧOUު~խe} (9~s/u(]\Ŝȼ&p %E*N4g\=jj?o\mEſ=ރ`_(@(4|KQI@+8ye# )ʃx:[r>. ;U S̏yJ"#?4"RħЀF4/-! R@s =sL-T(6ov.7_\B+{nӶme|m^ۅP]Te',<籝:u*T@\ќ1K}ycuNzW@ſh\.@ِ{?;b۰ja'&;=INUZż\h\_y]Ígכ/Ks\ [ <[nnٲ%l|m+d'&;=ie$9 +*XiNs_M%Ch}Č+ش5_?>~Q IDAT%FiuRGf?31Wڃ;;j`[6ܲaUU|H"Mar$`)lMᕅLU37ID@V RE7Kg ^"6qkލ01ȝ0yNẁ¶"ې`,Ĺ*fr*"?z;n?+W}wQ6k}ֽWߦMkժ5"PT xd*UUm7MN61LX|Cb2*4(h^\|%-*\2CVTw-{+T'd#~Ggr>uP^@ӱc9G}i_^=!PTr9#ޣ+o 7q/?#ΙͿ+?ܺeWv;q猆tʘ_yrGoWߦMc{o +F_tQ=2gο>\r#+>_rT.ߧe˞ztGz>G~;k_c{Bu|}ѓr9ڵ+wM;>'O~f¥.iq;sIsrK}>X}>]"!ڵk8ټuˇ (]׹L۶mk{.\ La!}Ϲ_۝/.xbѨWlDNs= =Dw 'uWOO{(ovX¦U˓]ZlY۷ρ6`FWkirkE4$-rެ$Uq9k@U{δur1D7`H䂧ch@F<R?\&sEQKasuf xXa;(Nx\| Qvn2s>xIoZv X7_÷ܯwy߾ON9z#05@_W֦TZKC߭Q-mi_pCi@FDwzy⬯vf,^TWyDDq܌paE.8IvXR/?sgN^c{McwJæ. %9M͟7p̈́BN;gϞ-Y7}_}gϪgztֵUt謷\؇ݽ~Oͪ,v-Z@JZAKUaEsF%3Xxɚիm{{ s\.3_0|g믯zsW_~)m=yK@yO˖;H$MjPf=K.QSN=ee5W7ه] rw>* NO?ކ!M;"HCB"Ea"k|Z\hxٶlCMyXHUUMMYgVZK(~{j!isoɳSZ6*Lè&WROjn7%,:9q{sf{fD-UVOq lQUv GT>ąPFD6 ȞgwHCO)]/|.ʻb|Js5l1$Nb1Ӕ{SGXځ>/7񽍛{m]+@6m۶?}NpMUN⡏sG4 WEA3)9/SsR@iB8gM A[$ڽl)R<]TWf?T$e1qs>ڼig}_}fo=!,{۵lْ+uQ%mtrlxw$ѐ?|KLqA A ""@amU=yB~FBI]dZ<)ƍ>/?tw~ p}[xn*/z磡DRYhqSDO[fݵW2e"w>-b1+Lbēav|ӧѨWHY65Y}]fpPVЛazXOxf{/ts;01~>ۻw/oF--XS= }$e[Zf@&Eb+$m~ Z(CbX4tqbѽQlkv\&-+Ư.3Wza 6IAvh+ xl'B@Bw'phQݢsg*w^+~j_Bg;|T4Qkcu ~-"iVٚ(mS9uɱmV΂bC@f KY@v?iy-.8ELR3Pi+6'PNtM|K]Opi*8ʹRNN4q\T3q2!8yݳr>4}E:醼'E/_wiLY@-@JSPDIe 0@VCO4 7'Dp!c<:|vP~<wDsSD@z&_t:!S$_LTu5%\@N`|WATLWu,+87 XfknI5q2 Ds"Ѩ'"1iY#/ НET('Umy:Y:`b9~sD*T ~S}%e1[%R &׹zG;hKMMͱz lv yE.(icْ "_* T-ma$BުUP\gݼoƚpݻo[b_5d=o}{!ODDeZE]WQϥJ7 =7+@&]tvuY@t79.{x%vi,o[޳{~wC8n5=zpﾵr{&|cѦzucQU{:PIDb81!(y@ېo7ǐ=X4 /~IY ڳPXj+HYh7L**H`4O01|!QDx"ʞJ#jVUUŭJR\p!CtC^#ށ^7sb8(QJ!އSex-Le ho@!>$S1J74̌1hn. )aB"`tnIU@KQfB47墹x'gJH"M@4( {m|K0'"x#ش|l5+Ԗ)xFԘW:Jh$&cZqO)!7!c^PJ-p60,ȳ!ч`J.w3*b^%%ȐH̟,A>_W {Ӊ1`I˶LjjN޴taȧI៚.$M@)D5  ]+Xr? F. Ⱥƙ³A*Jh ,DW蹫>rbRh1N~+KNT zU 7= 4X-NAxU^<ہ+;Mlq| #,U٤|{Ț{U9{Sk+BӰɏj69[;0F]ϳFS%V4 GDSyѱJHG=Am+"|qDEM512"RrE<;Ed‰r==|o]:Š*ş(Hc3ܦ&9l,6MJՅq@< /\W'-ێDT7tX"i}>@mɟ-Vk{]A: |d/uJI=_s;$*VU +Os'4L=[Tœ-Zs)jɓӤqsV*WUDL^d M@4(OsJKkiDx+!ܧ%/؇Zt0Wb)wf4 Se2lN^KC7@Sa8kH.lYo>(Sݞ 1wh$MX4'gA)RE\zKFeWL|,cp\P >*{k\ȈiN=EVIki}ZCyjdI4#˂@4P@nuI<7ėZ EnHHڲ,-U1ro׭pE  V\ع4w)Dc²/E. #rO}gZ¬LnnP×$Nb;-U!^hjFb}X@&JӜZP ]6uaȽ{(5!ÛLey5'RGb ƍ 19'm[e 006 Os_YpOk Z.rUU57TEb$YS6_͋ެc,2ht%dD 1V#ۇ+jv,hY1TK["&#HyIy)5js\>PR1Qu'Q hЀ,z|oyE >IU̢+V %-Kwt"3|u\ɕEXAjʰe/ |/ &H2чp˹U!1ܲ=17,xNQNˈl{p^|V*OsWJ7$昚r-ܭ>“,LAc*dh&@\!8a 42Ұ !O4g?9Ӝg:%~+bhn"kP(74I(Z,RĪ*> kQY{/ LJ,޳V4<[wJQv K*MMSzLR,ww-׉[Y"h _"(CRT& 2H= :Be &EDKi+fӜO|V).tߜy!ӟ4+!R%i@Vy "-*k&9gܳGWxkj0MZjW^Dw5W"sJ:ҏ=T";UJӅjU^2&5 ZZf}!\<|Խ읆TcƎ%bO65$RhdxcF8gH.*Up| bhffju< / IDZ'Y4bsLc8;R>gs ;Aex^8GIpGceG]&r "4Λ< }EM#W򂳘)aȣITGߓKi /mYa/JvDsgq@$49SYsK,ۢ*c-ˊŸAXX'3F bp{x(Is\ eaȧ8HjC|jEu%^E7ta")tE BPv:@l[Ωpʼn6 ;ES0EᦴlVUU^\F=[J:*K&ǒo4k1TO˂C3YجT%8'Ct#ElbS_: )$BRZM>,zzڶZEJ_0G yC* jb;вlɲ2tn1KQMM|Ti؄#$&a7r* 9ffxʕ`.*/^.ϓ xܦ1\ym qO'fBȝjO>3^"PhO.^D4W%Be\ƺ\ IDATLGhVqTV*-oYeM^"DK:BT\*հ}" ?}#C~GCh%B~],maa)=x+/մ|uT;T Kӟ<;ֈu-cOso|4Ǭ0F̛U4҄c@Ab1]6@@leF$PDmP{AH֦ԜVH8a 'x4P &hNrVtZiވG\Js/( `B& v"mzuwtIeTZ. p f"膡:mU>存`+ouSH*N6k7/wl$*M֊YQrMEڬ)&R&⾷R;>>K1Qcwq96D[GXI (r[_JUAx^\Db:m**P2ov7gqHp6揼 Dpv^,n"I2A-M!KˆV+u /{[-_K-{xeYSbhP~.ٱc7IJIR(ˉ0x"}tQXgE J䘶$ _$]BeF蠝\hEOąjB+yV E^Olr/ʫ~'M5ZS>yOaTdr9UUE)%F0Dj"3U! %aDL_Q3Uћ,zSzD}&)f-t I l&v:7\"Nք> >f*OsͷmGB@*u^&HfisQHg+l0\P!ME y[1oWbxҹ7I /x 1yz |dӀ,{e;fgrmFɨ9>=Aϕq>į q,!O7}_EVWR>r:+4CtVVs0n}.ivi?:SGzw3+B}6c[)y<E%?P(Oyw6j7" !طYܽџ=&gI8Ncda DGo,NMD(@>E'"O4)* ]ꍫYT MK'aPëȝ*$JyW-βlsKiu@Kt:,$pF"Dg [Np&ǜz٪:O%4H { CA%ШA4z+LC}"/Lx'HS6H6 xh9Ds4;yV-jk42Q1kĻ\ [ڌZ /arl`)EvV6hD7kwZ?(EϬ0udIX,M{A׽X61l@-xm_*ĩ"'4튦Qaj8rZgSkrZCpV۵y9!>/4GL! b8=إAB'=*b8 G}(*\=A4U y jJ[JP|EF7NFS &nBO-O05YupS4+ tD)ќ¶QJ NYEp+lC1m/DM(k3(+7y& Y Cl( IL~ݧ{{ay&v12<]5DxތpC @ xM@4(=8ΫYC>ճM݆3JD`:jq@= 6!<0,c̬ y`BQm !1>?1߲E. ^lYUt9PDָno\P9|oŬ-.Y" )rI/ɍ:1BQpJ@ 4ӏth,E#K4.: P4'.fBh!lLxLbB3ifk$ϛyW%iETgH4怞 2$ᘦCl'AY2Au)eiKq~!SHfbK鍻m~])Xg鸨H?TO%*Tp yY #!S\VPp- 7m1x>irЋq 3Ti3TKB*aDb̒=`kph4Q,#״p!)T68+e<)Jx}ҟI$QAIaqiQ@- {r63zBF7`^@ ɕ QtؾP\ O.mfB鍥*;I]aBcojp9Hb׌~%h%..7} iެ=i1!UGUhIu}n2P~{m\߳wٳg{^b$ Y|&S/8ͷcժUn9sS _>0ByoJAϤ!Vrp)i;lUe(hŜBެBש#^Pb7= 2#_-0[w] Vr>ElO>@O7 b8ApYЅtJA #dpT )[.+wsg<%(ROsaC2r!373BGGȻG/ *J7ܱSO@{zgvr J v.G3:ԛŭ-}sQ|qc~[nye)[n%7,ihx7Ӵ<-$?ͷq{ 9 uk6o[YHᰱ,)S̬XBZlD;a+=N'\{m=/d<#Jewo79ð2a3[ОmXT?xHŜr?م;̔ 9{!sN9RŒ.(vS.#>dG]4z !JنE(o?E2ni}}}}{a+?餉7\yhg՞~F:TG]Yɓe[F-"mB^N>aZ\,($րwk:u`ƍe}|bYsf{]u~Sn=g9FQkeڞփ xo~qCsn:Ϗdf5>Si߮… ZWgoպb{$XШcu˖p'/ˏ#۶TI;MTko<OU.J ^6u3f"7g9;/Yھcǒ{/j(NO_T"fqZ<rްaɫ',[wr?5۵cEQ }6mw#1/%نER%h%Kڍ`8۾cGeZ(Vl|?=wy|jqe9 ;wz%A|s]Z?a5sӣEvꫛ&r+23S:Oh'wPPXmZI@k.i}%+-Zeݻpoݺi۶W^G}3~_6cG}D'ܹ3Qz=]\_aQcccғߚx$W_ݴi^ݪu>} Uk߸a֬Y[`uw`[OeTV?WڶSDGu~]?ᄑ t;9̚;癅 ԱsIPw4=`z|` >6>MZ~=;Nvrc߲J_}Dz6oٲ<۷C~{^!))OFa~eSO;Mo ;ϛvZw'a6 _ 6g{=D NӲJ>^nݪO݀ss<;y. P8B67\QMkrJ@N$Ζhc^Lz {WX,tٶ7{L:۷yΖZ^IJ{"a<7+ko&/ӹ "ⓤ_x@10}Ə}0͘ЃreGͷNzGĩھ}_DW^1ZP\:۷oմOzSn$+>y=JWө],_]ï_=^p0x/wQ%]$F>0a_^0o0`kDܛ0* WJΝq4?P mWM)?_y̶g\?Qh('[VoY3O籽z>v..hN1|ZLW֞˧nu fyrfԴ:sh\ީSwQJ-ooQݻls{򎹊͛6T] GYl3OwOqؾs%!<1A' >)<۳E^j_&:Gwѵ[tbP#[ gv&|M!Fu2Y:lť]#%6, tү u NFE7\V+8iMB!_˲-sf.ds. IDATfa٘/~UWWe-7_Z߾];~0¹λIPa);6;b7-'ۏlu$l"iLf.]|쿬|qYzu1$ ʗ͞;'ۣC>xw8|M=۰K.{;sG&- Νdn֬Y<2_rƏ{KƌI^vPh]3 JvVi3b1`ؼi* l\z1ܰ!Mð{.^fkoԓOO=CΙWd+B4߹kȑ#8'(Wo/y䙳Sce$Pi>gIvMΞ:wܬXKBv꫗_}Y͵t~;o]qJj\/y{7#0n3tƏ]QӚ<1=O;ctv"nRĬz۔m/͔Zgm%B[3ӽm;ujrukׅYa+K|vϚ;'[SNS+V6̛ioo'裏:zot1)М.O_ !wAs(]i /檫}o~W~۴n#tgc/9ܘq#wyGZA'EE!Yw;*IϛM@3%Giֲf䁓Oj*>?%O_pQ3[ V|Br󭓞#/JiU^vB Ɩ kfqdreI7+Bp/tvfGqЮr)nU7n*}J-Ltm:/Q>0"]uC6s饾C: зSŽ7mtvHSٽ;>۹O;byɕ#mܷ_W^y%E>pHiY5:t/]R H1Pm:`='mX4> ŋn<'D&Nl~o2fV[!}&oիVIG)g[Sdpa>G}.QT*gOwx2`]lylҷ/ykނOɥ2A 9x쌛?o ![҃裏6w v>mI_|!Ⱥ+ɓ$wW^R53>55*lire֥֭[nRo/"Z?z_r]6ǺMl'܏?sʔb@rۭQ5JrR:u:XZgG)y~Uc@`]w)=YS?7*H|wyT (7,,^Bx G|b߿I}ٽjq9+ʊgqƨonݚk:voDyG?6P΍6!*UδӇ \䊹PgUtxјKݰaR̳qW\}6q兣Ge W)5W4ؗ4?ߑT V$d{u=Xm^43SX4? gq֭vﾭ8mZѣ,qP4㨮{e* ?G\082sf vV¨kJ骱͞Ӆ9et!wu7ݭӞA:eT9uƏbN 7ŴKSvcf12Aw*W \֬^}G&̮A WZ%σz?p)MfT "ݻv|f͚6m;RlfA,Qokqۥmn2cFT9.YxZ)cUb CS꽙55yI<[6LlhqUYC':)].7mRIƬ^*qdI,s1*1k G`7=?@Z~黨c kNmX$%s2,۞/5* ~x_zI5˥uߟa:H(vOvߪUI4t*t P0w0+y9\e_7^` _8zDL1}L5ڭ+XW'Þ!N_]+ik'H%N&о]v3 J}+^wN"0p@Z-7m};v^ҫje[lzƍY[/}COn'9;ߥ"j:u,,G)GLxaQ3B }wmuwI(˶ݿt'ܶmÏЈF(%z_6 DsYvE g9ǎwŴө}ǎYs\8zoo$NljAlgd}դ+K+U>J_?'l>|U19b{l1h'3mx'O>@?}Pm&N ީS}9gy Bi?FF1_ϲMՓ6s<ٲT9N//3[:k1O2,u c%Qzʩ ~ui*MPD(,kVv >鍯qi{;<|/]6:67~o=w%=',^԰lteV,ڸ/ٜ*O Oٮ{SJN-+^Hr7W_ ;<-nЃJ_Oflv. }qOgIw k\7p@#Rvv򀺣>zc_~wڵvZv i^{^zQQݻ'EHsEs]׽hZb)m-]{Jf;+'2i mV<ȞݻU21U*<N>su`6TtH!Үn޴I5Sөj 3amW*;2\A3yr))w\ƴok'Hώ{NM9ߟn;1NYjؾ`w/yi4{.yVOXpٲ%1ﾫ\mXfKRnj'Ex#>M3}Qnum͸~UJ) K~TհsKk5 I~q]wVe(iتMCj"{ON.+M1f) 2_O!;Y, Х5rENO ~amU϶Omm眣J ji;GFɎeK޵[!npwC'T?X|S kG%dK,l7yZGiugS}mgY8m#lǹ1n*f_{zva OX ba]DÍl?<>e:.;NH .'jfYTٚخ żfhTZY1|iOh.PƗ al^30D36-[$NN8S$feo+_]q֭)5qƠA"~m߾/YBkMѥKfu XK=߾cko̙'W^4)wL5S?xݗ݃ʜq'9в\AӁ Eu~%Dֲ,A#'%ri민/>to])\MژۘtH$u #Kd -WbwByeAz>۱g9۪kL&K&uu.IUDbLY{yPᗨ*e"4gP}gOlܿHsI6yz;SJ4[ͤ6?(hcx?{̚3;>CņNI\,s,"Q1|M68|HWj ?=PI2 2f3)"OsԿsү̚=XhJcIJI.jt\nD׳=G'#[ւ\96j\??*豽zv9+iZ}PUmuqٳ0~ti:Ht۶s^91WGIIPt9QT_= gsHQFKTPS3bihnTm5M91"۪tVo:g܌{++8vY 8ҁwB@0*o0ݯEG/]ءFztV*N?є ("{2-+':gƥX4Ygj9ws -~%n{H}-Bm.Bm[7ɆR1S#ʤj_ G&^JjuްatVgb}\KU/m<@pȑ/℉׍pd,tw"̞/gl9b//t/laLaM^6zϞi֬.b|xDikοG2NKͪ~(`}IiN(fp('~m{buQ[R\swMKzA^v4Ll|l H,BUYl()%"gq?ӗΕr@)jќqŸq>ݶmڴ暴yCHp>묞{&y酯.]AB3WB؝PQ|S'l*s4&OSt7'9IkmǦ\^Fy9Iۼg?3j?{UY7.9m^31z߬ x][{I{ (T&5/N"ǼJnM,ǹAfLnZ!${II=Sr hČxP"RXB+rL<]r#GzϞkƏg+% 3&^wGvQ}κnb>,ɡhN e<{֜t6mJ_|q޼y[h9hjocgsΓO="ҷD'󏊽\|,_.yi*9HDR7> AJx{WlCYկo|p9ឩ~RnOXDz Ki^3_Ȝ6l>F*3fkK*X%2TVSQb>b𭛷[櫝_5Ɗ8Wy^5:qB0^W>QJcǞxI pԵ?Ppv[__U:$3n55 U¸+5y?ϿWTꔘhsW544WgQ>֭Y; ck{Uv*dLbpOa2IDATm[ԣ'fynౘFIg,|[n)W?a)b'o31ɎiDĔГ gj"e~GĞ$?ʫ(#GrW)?w'wJ֊)FI9D^P\X7R̦咩ϊ.4%zjU-؛.C< nsԩƛV}YGv֥r$Es#6~O=_OٷU[ʉo~b;:?sn6i&$ nmKbJ`"*Vu Ap6D@Pq!$})HʢЮ@[)nq39wsyf3#y=3s%3s!>W/<}矿 _? > IuxruZTyܘw7==ܓڛ_w箽3vZE_yttFKF҇7Uݿ*ӉXآ| u1Sb<}p1?[n/!Y.-9_Ӽe !ÐSYiaȩ0TV`r*+m0 966LO⦗?_W5;p[S%!c6RQzUXwux\5oW;ONعZ^8׾v}pv?%7vd]<<EA7|^MZV`i*+YXڬ ,mVe6KUYͪfUV`i")?c=Gy'c+=.GzKD񺵒]<.%_ciǷ4?z+vG>~ 7\sͅ뮻뮋iÉujyt/n/޷R?<'tfu /MrßO~ S5?{JO3? Sڀ/_~$-2 a C0a0 `04 ah0 Gg=9崋7p_|Nʡ-/})._}ե7ysl0C駟?}&[3\U~=C|Lyδloo0 9| Cn!Ða0c1 | C>!˗Z,W_k~=]Vhiޜ9_O9hm$iUW'G֡ OiZo}kЗGW=!+Ða z 7ܬoY;,Wfˢ[\2Nc*o.泯Nޮ;t=KkNa? Ӷ^1Z=O',O<Ġ$:]tdDӻߟcLϯTTZ5aXa0de2  CV!Ða0c2 Yŗܙ_y/u:%xbQ=,ڕ7gVk yz嗍Kz /!+;X.^xM7k_Yռ vx=Mټx=?{qt{h8/K=zok< ~go|}^׼ 7]+v^}_W1Ga8ÐW:0de3 _} CVa8ÐW:0de3 _} CVa u3_?q-̾7|v±ц[oO&KQ3LӺ (IteS7/1pJ} *3*@c['ka})/i!947Nx~=U5nj[QW]?L2Y= EOw¡{3q/e !ÐSYiaȩ0TV`r*+m0 96J CNe CX~:yuu:,㪺r:Qb|i[e49KsEyf꺎uj"E<'Zѫ-ji%;?^?+h?]u_<:~S%z;\Tænf[ið 6u ÒcJJ ú Caa1% a]0ð䘒ð.waXrLIi!e};=:;G'[qzUB VGWL[$c݋:,`F[,TV&栗^z)zIT^>9lvSG%uvzK]QWUlL;NriCi]a ӆKÐA v !LJ , CV6Jm#Cb!:ڊ+gozC<$6Wt7U]^UJ٭qt8J/x|N]ttRޔgߝizGu2CvCUX>ֳ?ٜuJ93m8 K[[V`6`1 Y C>!+Ða0de2 xngW]ɳh7웥9eÐgLG$LO_Gqyzߧ$?zVm(Ny; ɎSdPZ`i`:ȴҮ0duiCi]a ӆKÐA ct젞%QYZb=GEբu=mQ1i;09}G5yo>N%YCwd3T m+SmCI;M`ez z CðaXaa2 1 = ia=ahlkwRksr׵g9Kss=K&T!iƩ>'uT33סNUegp03;T9pE bds{zW꤯<~*o>Jc֗:͏ߓ7rL_3/h~7Ѹί[=w]ϪEya ԵCmx(h1,`n4MmoיҪ'oԓ\ܞD_tLz:dRG;T/M5x cC0TV`r*+m0 96J CNe !ÐSYiaȩ!lSI*Žz̫語x9ܾe2[qp{L;ȴҮ0duiCi]a ӆKÐA v !LJ \Vڎmps JUOyj0e/PҼdt_uO-;Ǥv/$d/c`3SGvJ[V`ez3 ))m0 2 ǔ6u cJJ ú Ca1% 8 UbbO{xTq{3ǼԳ9Y94r]K,LRD_ː&+S kKzlW50aʎo66pYiaȩ0TV`r*+m0 96J CNe !ÐSYiCi^kl&:ÎͣNcʛ?Uʟ{49Ks4=tV}ܼDAy\TӇ>M6N>LapYTAyj*>z4YRu>zzSC 8H=)2JTw*Y${TC-g Zg}*^+li,`<%SWqO` ^8tHe\)is0gisi#S}~+j[,"_!u8|fܲ49Ks;S' /v9Y94_8^M8,`t p6~9,`t3`,`,`,`,`56IENDB`DyK keith@rice.eduyK ,mailto:keith@rice.eduDyK dongarra@cs.utk.eduyK 6mailto:dongarra@cs.utk.eduDyK johnsson@cs.uh.eduyK 4mailto:johnsson@cs.uh.eduDyK ken@cs.rice.eduyK .mailto:ken@cs.rice.eduDyK thorp@lanl.govyK ,mailto:thorp@lanl.govDyK bridges@cs.unm.eduyK 4mailto:bridges@cs.unm.eduDyK alc@cs.rice.eduyK .mailto:alc@cs.rice.eduDyK rixner@rice.eduyK .mailto:rixner@rice.eduDyK dongarra@cs.utk.eduyK 6mailto:dongarra@cs.utk.eduDyK maccabe@cs.unm.eduyK 4mailto:maccabe@cs.unm.eduDyK yK .mailto:kuz@math.uh.eduDyK yK 2mailto:shashkov@lanl.govDyK mfagan@rice.eduyK .mailto:mfagan@rice.eduDyK  rjh@lanl.govyK (mailto:rjh@lanl.govDyK  ran@lanl.govyK (mailto:ran@lanl.govDyK  dak@lanl.govyK (mailto:dak@lanl.govDyK sicilian@lanl.govyK 2mailto:sicilian@lanl.govDyK  dbk@lanl.govyK (mailto:dbk@lanl.govDyK  ken@rice.eduyK (mailto:ken@rice.eduDyK linda@rice.eduyK ,mailto:linda@rice.eduDyK  abw@lanl.govyK (mailto:abw@lanl.govDyK  rro@lanl.govyK (mailto:rro@lanl.govDyK  rro@lanl.govyK (mailto:rro@lanl.govDyK http://lacsi.rice.eduyK .http://lacsi.rice.edu/DyK http://lacsi.rice.eduyK .http://lacsi.rice.edu/DyK http://lacsi.rice.eduyK .http://lacsi.rice.edu/Y$$If!vh5555252555#v#v#v#v2#v#v#v:V ",,555525559/ /  / /  / / / 22 4 $$If!vh5555252555#v#v#v#v2#v#v#v:V 4@"+++,,,5555255599/ / / / / / / / / / / / /  / / 22 4 $$If!vh5555252555#v#v#v#v2#v#v#v:V 4@"+++,,,555525559/ / / / / / / / / / / /  / / 22 4 $$If!vh5555252555#v#v#v#v2#v#v#v:V 4@"+++,,,555525559/ / / / / / / / / / / /  / / 22 4 $$If!vh5555252555#v#v#v#v2#v#v#v:V 4@"+++,,,555525559/ / / / / / / / / / / /  / /  / / 22 4 $$If!vh5555252555#v#v#v#v2#v#v#v:V 4@"+++,,,555525559/ / / / / / / / / / / /  / / 22 4 $$If!vh5555252555#v#v#v#v2#v#v#v:V 4@"+++,,,5555255599/ / / / / / / / / / / / /  /  / / 22 4 $$If!vh5555252555#v#v#v#v2#v#v#v:V 4@"+++,,,555525559/ / / / / / / / / / / /  / / 22 4 $$If!vh5555252555#v#v#v#v2#v#v#v:V 4@"+++,,,5555255599/ / / / / / / / / / /  / / / 22 4 $$If!vh5555252555#v#v#v#v2#v#v#v:V 4@"+++,,,555525559/ / / / / / / / / / / /  / / 22 4 $$If!vh5555252555#v#v#v#v2#v#v#v:V 4@"+++,,,555525559/ / / / / / / / / / / /  / /  / / 22 4 $$If!vh5555252555#v#v#v#v2#v#v#v:V 4@"+++,,,555525559/ / / /  / / / / / / / / / /  / / 22 4 $$If!vh5555252555#v#v#v#v2#v#v#v:V 4@"+++,,,5555255599/ / / / / / / / / / / / /  / / / 22 4 $$If!vh5555252555#v#v#v#v2#v#v#v:V 4@"+++,,,555525559/ / / / / / / / / / / /  / / 22 4 $$If!vh5555252555#v#v#v#v2#v#v#v:V 4@"+++,,,555525559/ / / / / / / / / / / /  / /  / / 22 4 $$If!vh5555252555#v#v#v#v2#v#v#v:V 4@"+++,,,555525559/ / / /  / / / / / / / / / /  / / 22 4 $$If!vh5555252555#v#v#v#v2#v#v#v:V 4@"+++,,,5555255599/ / / / / / / / / / / / /  / / / 22 4 $$If!vh5555252555#v#v#v#v2#v#v#v:V 4@"+++,,,555525559/ / / / / / / / / / / /  / /  / / 22 4 $$If!vh5555252555#v#v#v#v2#v#v#v:V 4@"+++,,,555525559/ / / / / / / / / / / /  / / 22 4 $$If!vh5555252555#v#v#v#v2#v#v#v:V 4@"+++,,,5555255599/ / / / / / / / / / /  / / / 22 4 $$If!vh5555252555#v#v#v#v2#v#v#v:V 4@"+++,,,555525559/ / / / / / / / / / / /  / /  / / 22 4 $$If!vh5555252555#v#v#v#v2#v#v#v:V 4@"+++,,,555525559/ / / / / / / / / / / /  / / 22 4 $$If!vh5555252555#v#v#v#v2#v#v#v:V 4@"+++,,,5555255599/ / / / / / / / / / / / /  /  / / 22 4 $$If!vh5555252555#v#v#v#v2#v#v#v:V 4@"+++,,,555525559/ / / / / / / / / / / /  / / 22 4 $$If!vh5555252555#v#v#v#v2#v#v#v:V 4@"+++,,,5555255599/ / / / / / / / / / / / /  /  / / 22 4 $$If!vh5555252555#v#v#v#v2#v#v#v:V 4@"+++,,,555525559/ / / / / / / / / / / / /  / / / 22 4 $$If!vh5555252555#v#v#v#v2#v#v#v:V 4@"+++,,,5555255599/ / / / / / / / / / / / /  /  / / 22 4 $$If!vh5555252555#v#v#v#v2#v#v#v:V 4@"+++,,,555525559/ / / / / / / / / / / / /  / / 22 4 Y$$If!vh5555252555#v#v#v#v2#v#v#v:V 0",,555525559/  / /  /  / / / 22 4 b@@@ NormalCJOJQJmH sH tH \@\ Heading 1$ & FX@&5B*CJKH OJQJphb@b Heading 2'$ & F#@&^#`56OJQJJ@J Heading 3$ & Fx@&56F@F Heading 4$dx@&5D@D Heading 5$x@&6PJv@v Heading 6=$1$7$8$@&H$ & 0` P@ 6B*phB@B Heading 7$@& >*W;yH@H Heading 8$$@&a$ >*W;yD @D Heading 9 $@&56WfDA@D Default Paragraph FontZi@Z  Table Normal :V 4 l4a _H(k(No List 21@2 List NumberDC@D Body Text Indent h^hHR@H Body Text Indent 2 ^8O"8 Bullet & F ((0O20 Text1 $a$4@B4 Header  !4 @R4 Footer  !.)@a. Page Number6U@q6 Hyperlink >*B*phFV@F FollowedHyperlink >*B* ph@@  Balloon Text CJOJQJ>O> Vita Normal  & FqPJ6B@6 Body TextxPJ<Z@< Plain Text CJOJ QJ BOB Numbered List  & F$5BP@B Body Text 25OJPJQJHS@H Body Text Indent 3 8^8<Q@< Body Text 3 B*ph:>@: Title!$dha$5CJ<J@"< Subtitle"$a$ 56CJRY@2R Document Map#-D M OJPJ QJN@BN Note Level 1$$ & F@& OJ PJ QJ N@RN Note Level 2%$ & F@& OJ PJ QJ N@bN Note Level 3&$ & F@& OJ PJ QJ N@rN Note Level 4'$ & F@& OJ PJ QJ N@N Note Level 5($ & F@& OJ PJ QJ N@N Note Level 6)$ & F@& OJ PJ QJ N@N Note Level 7*$ & F@& OJ PJ QJ N@N Note Level 8+$ & F@& OJ PJ QJ N@N Note Level 9,$ & F@& OJ PJ QJ @&@@ Footnote ReferenceH*FOQF Personnel .<5CJOJQJPOP Personnel List/d^ CJOJQJX^@X Normal (Web)0dd[$\$B*OJ PJ QJ ph0O0 eudoraheaderDO"D Normal-11-number 2 & F8O28 Appendix 1 3 & FHOBH Normal-11 Indent 4`CJ^O!R^ Style Normal-11-number + 11 pt15CJxOax $Style Normal-11-number + 11 pt1 CharCJ_HmH sH tH u>'@q> Comment ReferenceCJ8@8 Comment Text8CJTOT xl25!9dd%dO[$\$CJPJtH uTOT xl26!:dd'dQ[$\$CJPJtH uVOV xl27!;dd%dO[$\$5CJPJtH uZOZ xl28'<$dd%dO[$\$a$CJPJtH udOd xl292=dd&d'dPQ[$\$CJPJtH uVOV xl30!>dd%dO[$\$5CJPJtH udOd xl312?dd$d'dNQ[$\$CJPJtH uVOV xl32!@dd%dO[$\$5CJPJtH uVOV xl33!Add%dO[$\$5CJPJtH udO"d xl342Bdd%d&dOP[$\$CJPJtH uTO2T xl35!Cdd&dP[$\$CJPJtH uVOBV xl36!Ddd'dQ[$\$5CJPJtH u\OR\ xl37'E$dd%dO[$\$a$5CJPJtH uJObJ xl38F$dd[$\$a$5CJPJtH u\Or\ xl39'G$dd'dQ[$\$a$5CJPJtH u~O~ xl40IH$dd$d%d&dNOP[$\$a$5CJPJtH ujOj xl418I$dd$d&dNP[$\$a$CJPJtH u|O| xl42IJ$dd$d&d'dNPQ[$\$a$CJPJtH u~O~ xl24IK$dd$d%d&dNOP[$\$a$5CJPJtH uZOZ xl43'L$dd$dN[$\$a$CJPJtH uBOB xl44Mdd[$\$CJPJtH uTOT xl45!Ndd$dN[$\$CJPJtH uBOB xl46Odd[$\$CJPJtH uTOT xl47!Pdd&dP[$\$CJPJtH udOd xl482Qdd$d&dNP[$\$CJPJtH uTO"T xl49!Rdd%dO[$\$CJPJtH udO2d xl502Sdd%d&dOP[$\$CJPJtH ujOBj xl516Tdd$d%d9DNO[$\$5CJPJtH uXORX xl52%Udd%d9DO[$\$CJPJtH uhObh xl536Vdd%d&d9DOP[$\$CJPJtH ujOrj xl546Wdd$d%d9DNO[$\$5CJPJtH uvOv xl55CXdd$d&d'dNPQ[$\$CJPJtH uhOh xl566Ydd%d&d9DOP[$\$CJPJtH uXOX xl57%Zdd%d9DO[$\$CJPJtH ulOl xl588[$dd$d&dNP[$\$a$5CJPJtH uXOX xl59%\dd$d9DN[$\$CJPJtH uFOF xl60]dd9D[$\$CJPJtH uXOX xl61%^dd&d9DP[$\$CJPJtH uTOT xl62!_dd'dQ[$\$CJPJtH udOd xl632`dd&d'dPQ[$\$CJPJtH udOd xl642add$d'dNQ[$\$CJPJtH u]M,      !"#$%&'()*+,  !"#$%&'()*+MM, z z z z z z z z z z z z z z z z z z z z z z z z z z z z z z z z !z "z #z $z %z &z 'z (z )z *z +z ,zB '9#K [k|<~D +5BS`ukOw5ձ]95=)8 FGMxs`<n  3 q9B}mFo !"#?$%+&V'1(R)*+&78ud ? @ A B e  D #"%O]Bh 2 3 #|&&)/004@8X8n<o@zCCpFIKKMkPPRRW [^MacBcegjj6m!onp'sLux y {|;a5nĈƉljaMוu AɛY }]YXZPVŨx< [aجCC`J/}ƴɵip$Cʽտr-SlD~9'-K!L<~ Ncjz+*,Q_=>xy\FO.f   0#&'+++,-w--..// 0i00111X23s3:44456X66678::=:{:::/<|<<<?QABB#F|IJ_M9N5RKTTUUV3XWYXYrZ[T\]]H_```a*bc}cccd e fGffYgggghiiiIjjjukk`l}lllmnnnooJo_opppz|}}J~K~rj$S]5ܚEw2!̢Xݤ133:[pרި/qkԶǻXf28N< Fi3#`z{]d3H X' Lw,7=28d97\Y~,*;gz#|Ag1LUm&gA0'l4`eN| i   W ]    ' X      5 a   G\ ;no8X Aq7b5B  3"A"l$&&n+,--~/T124I48*8d:{:<=>YAFCDDyDD/EE F)FFGMGnGGGGGGGGGGGGGGG"H'H(H*H,H4H6H7H8H9H=H>H@HAHIHJHKHLHMHQHRHTHUH\H]H^H_H`HdHeHgHhHoHpHqHrHsHtHuHwH}HHHHHHHHHHHHHHHHHHHHHHH*I/I1I3I5I=I?I@IAIBIEIFIHIIIPIQIRISITIXIYI[I\IcIdIeIfIgIiIkImIsI{I|I}IIIIIIIIIIIIIIIIIIIIIIIJJ J J J J JJJJJ!J"J#J%JUJZJ[J]J^JeJgJhJiJjJnJoJqJrJyJzJ{J|J}J~JJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJ\K_KaKcKeKmKoKpKqKrKsKtKvK|KKKKKKKKKKKKKKKKKKKKKKK)L.L0L2L4LL?L@LALBLCLELKLSLTLULWLiLkLmLoLqL{L}L~LLzM{M~MMMMMM!0p"0p0p0p0p 0p 0p0p0p0ʀ0p0p0p0p 0p 0B B pH.0e /0 /0 H.0e ( 0e e 0 0 0 0 q 0 q 0 q 0 q 0 0 0 ( 0e e 0O80O0B0Bq 0Bq 0Bq 0Bq 0Bq 0Bq 0 B0B0B0BH0B0|&0|&0|&H0B0000H0B0@80@80@8H0B0zC0zC0zCH0B0K0K80O0kPH0kP0R0R0R0R0R80O0c0c0cH0c0j0j0j0j0j0jH0c0x0x0x80O0;0;H0;05q 0 5q 0 5q 0 505050505H0;0a0a0a0a80O0 0 0 0 ( 0e e 80q 0 q 0q 0q 0q 0q 0q 0q 0q 0q 0q 0q 0q 0q 0q 0q 080q 0Pq 0Pq 0Pq 0 Pq 0!Pq 0"Pq 0#P80q 0$[q 0%[q 0&[q 0'[q 0([( 0e e 0Cq 0)Cq 0*Cq 0+Cq 0,Cq 0-C0C0C( 0e e 00 0B B H.0}/0/0H.0}( 0}}0i0i0i0i( 0}}0տ0տ0տ0տ( 0}}0-0-0-q 0.-q 0/-q 00-0-0-( 0}}80q 01'q 02'q 03'q 04'q 05'80q 06q 07q 08q 0980q 0:q 0;q 0<( 0}}0( 0}}00 0 0 H.0/0N/0NH.0( 00z0z0z0z0z0z0z( 00Q 0Q0Q 0Q0Q0Q0Q0Q0Q0Q0Q0Q0Q0Q0Q0Q0Q 0Q 0Q 0Q 0Q0Q0Q0Q0Q0Q0Q0Q0Q( 080+q 0=+q 0>+q 0?+q 0@+q 0A+80+q 0B.q 0C.q 0D.q 0E.q 0F.q 0G.80+q 0H1q 0I1q 0J1q 0K1q 0L1q 0M180+q 0N4q 0O4q 0P4q 0Q4( 0q 0R6q 0S6q 0T6( 00:0: 0 H.0{:/0:/0:H.0{:( 0{:{:0<0<0<( 0{:{:0B0B0B0B0B0B0B0B 0B 0B 0B 0B0B0B0B 0B 0B0B0B0B( 0{:{:80`q 0U`q 0V`q 0W`q 0X`q 0Y`80`q 0Zcq 0[cq 0\cq 0]cq 0^cq 0_cq 0`c0c80`q 0agq 0bgq 0cgq 0dgq 0egq 0fg80`q 0gjq 0hjq 0ijq 0jjq 0kj( 0{:{:q 0llq 0ml( 0{:{:0n0n 0 0ooH.0o/0JoH.0o( 0oo0p0p 0p 0p 0p( 0oo80Ow0aw0aw0aw0aw 0aw 0aw0aw0aw0aw80Ow00080Ow0$0$0$( 0oo0ܚ80ܚ 0 0 0 0 0 0 080ܚ 0 0 0 0 0( 0oo 0 0 0( 0oo0303 0ooH.0/0/0H.0( 00ר80ר0/0/0/0/0/0/0/( 00Xq 0nXq 0oXq 0pXq 0qXq 0rXq 0sX( 080q 0tq 0uq 0vq 0w80q 0xq 0yq 0z80q 0{q 0|0( 00{( 00]0] 0 0H.0/03H.0( 000000( 00 80 080 0L80 0q 0}q 0~q 00080 0=( 0802q 08q 08q 08802q 0q 0q 0q 0802q 0q 0q 0802q 0q 0q 0( 0q 0~q 0~q 0~( 000 0H.0/0H.0H.0( 00;0;( 00z0z0z0z( 00800|q 0|q 0|q 0|q 0|q 0|q 0|8001800Uq 0Uq 0Uq 0U800gq 0gq 0gq 0g( 00 0 0 000q 0q 0q 0q 0( 080q 0q 080q 0|q 0|q 0|q 0|q 0|q 0|80q 0W q 0W q 0W q 0W q 0W q 0W 80q 0 q 0 q 0 q 0 q 0 q 0 ( 00 0 ( 000 0H.0/0GH.0/0H.0/00q 0q 0q 0q 000 008 08 08 08 08 08 08 08 08 08 0 8 0 8 0 8 0 8 0 8 0808080808( 0880 80 03"03"80 0&0&0&80 0-0-0-0- 004( 04408 00d:0d:0d:0d:0d:0d: 0q 0Dq 0Dq 0Dq 0Dq 0D 00 F 00FG0FG 0000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 00ʀ@0ɀ00ɀ0x&78ud ? @ A B e  D M!0̀"0000 0 00000000 0 0  0w G@0w G@0w G@0w G@0wG@:::=T0)=L>\MQS+.479<ADGJLOnB  CrFw3=@r`oa}2Լd=5FIM"N6N9NJNMN]N`NpNsNNNNNN*O?OBOQOTOdOgO|OOOOOO P P"PUPgPjPzP}PPPPPPPP\QoQrQQQQQQ)R>RARTRiR}RSS,/0123568:;=>?@BCEFHIKMNPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~S-  5 _ s   k *@fvǵ7Zg,Uh=ew;';6;M;w;;;;;;<,<<<<ooooo pPpvppܧ2[njJp ?La @cp[   AAAC,CBCMXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX&-/=! _Hlt480523181 _Hlt514470077 _Hlt515086998 _Hlt513867813 iAM@@@@ jAM] c d i j r ooooooPpppppp  @qsvwL{MMMM1 > _op\L{MMMMd+$%&'()*+,lb]     ,^Hk(D)̫o,+Z |cWAP 0~ڳ= I t: I1 B m6Q|*U+^hKrQ6\YRM SVN_lJmO2\_ln>7=XPiBa91uu$ja8-rIQDn`HgfYmB?jT2Tw}!TJTL_lR3 {8 #T"u"ʛ#,1#P%[%.oAl&N^&=nt`&2='A bC' W"+'Pj?yc (γ/x(_l[(,:G)G.d)4&A)7 -"`L>B}-ZdF."i=1TUzS1~U2v3`Un4؎G'X5dI>yn5ZHG?q6{8\F6쿪ir68$m7 =7JJ8Z& 9(zi 9.*e9ow:bt;_l3<Y^4=ZHGSb?R 7?wyADZHG21E~b2EF_lKdF0[Gt~OXG_l0HH2D$.EIS@I= Z$K,Lv,}MjddON_lNB)#PKz ;Q_l`EQ(\kR.y*{ ZR5R2O(SnoF!TʕUT^3ic UN&W7dWLWb Z8@o["R&8|\ W",\*]IO]Ws]Ӱcd_Vpa_l ub42$#RccFE=dhleTQBgUfFT`ff[gM j^z:j0 jv0jl*= kv,/?k6C[k:ALvk~X0lZ@~ &mhNy3n,?4korN% p@7t q_l lq?{lr C mrP r2AHs TsshrNbFt@H)Let\/h)u}#uapv̱ *v̄QgXvZ vTvDw{w_l9d9xƇo&5y2IyuD*"zQB}-ujmB? RIQ7 -ss[Gd)=Xm7#{lroF!T[(vP%O]|c?q6R3 I t: ,L ki=1/}bC'&8|\ J8w`fD*"z`(SI1 -G% prz8"ET, : dAM                   :,j긧~6H[4y`T]jhr                  2d<                 Fo[4x)&2Xw".f $TFL f        26k       2d<        N        <-        4,                 2d<         LK b \tjH!蜎&M:מÎy          қp&)pP1wT&j*                  ,         FH#         Fo[4x)&2Xw".f $TFL                   |tx\q,ecպG Y J(6 kAh> Vt;ƫ,_[         2d<         ?F        қp&)pP1wT&j*          Fo[4x)&2Xw".f $TFL                          ,                  ,         ؽ~g                 HZ                 <-                 TŤ         Fo[4x)&2Xw".f $TFL         2d<                 ؽ~g         q8+:[eBYilU8=N> h¶N                           қp&)pP1wT&j*         N        ¶N         HZ        m        <-                          yZȰFP,,PXbXnjnv yZȰFP,,PXbXnjnv                  > 7X1 {:GGGGGGGGGGGG"H'H(H*H,H4H6H7H8H9H=H>H@HAHIHJHKHLHMHQHRHTHUH\H]H^H_H`HdHeHgHhHoHpHqHrHsHtHuHwH}HHHHHHHHHHHHHHHHHHHHHHH*I/I1I3I5I=I?I@IAIBIEIFIHIIIPIQIRISITIXIYI[I\IcIdIeIfIgIiIkImIsI{I|I}IIIIIIIIIIIIIIIIIIIIIIIJJ J J J J JJJJJ!J"J#J%JUJZJ[J]J^JeJgJhJiJjJnJoJqJrJyJzJ{J|J}J~JJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJ\K_KaKcKeKmKoKpKqKrKsKtKvK|KKKKKKKKKKKKKKKKKKKKKKK)L.L0L2L4LL?L@LALBLCLELKLSLTLULWLiLkLmLoLqL{L}L~LLyM{MMMM@P4 /M0 @UnknownGTimes New Roman5Symbol3 ArialG  MS Mincho-3 fg7Courier;HelveticaE Century Gothic3Times5 Tahoma? Courier New7N@(-3 00007 VerdanaK1 MS Gothic-3 0000e& ??Arial Unicode MS0000҉0 Pro W3;WingdingsCComic Sans MS"1h##!U@, ,NFA$4dSoGG 3qH? #Priorities and Strategies113026Rice University                           ! " # $ % & ' ( ) * + , - . / 0 1 2 3 4 5 6 7 8 9 : ; < = > ? @ A B C D E F G H I J K L M N O P Q R S T U V W X Y Z [ \ ] ^ _ ` a b c d e f g h i j k l m n o p q r s t u v w x y z { | } ~   Oh+'0  4 @ L Xdlt|'Priorities and Strategies113026130NormalRice University2Microsoft Word 11.2@F#@dg@,4m@,4m,!U@ ՜.+,D՜.+,X hp  'Los Alamos National Lab S Priorities and Strategies Title 8@ _PID_HLINKS'A9)rhttp://lacsi.rice.edu/9)ohttp://lacsi.rice.edu/9)lhttp://lacsi.rice.edu/<dimailto:rro@lanl.gov<dfmailto:rro@lanl.gov7tcmailto:abw@lanl.govZ`mailto:linda@rice.edu<s]mailto:ken@rice.edu.tZmailto:dbk@lanl.gov#Wmailto:sicilian@lanl.gov.wTmailto:dak@lanl.gov=wQmailto:ran@lanl.gov;|Nmailto:rjh@lanl.govS~Kmailto:mfagan@rice.edu+Hmailto:shashkov@lanl.gov<IEmailto:kuz@math.uh.eduBmailto:maccabe@cs.unm.eduF"?mailto:dongarra@cs.utk.eduQd<mailto:rixner@rice.edu1N9mailto:alc@cs.rice.edu6mailto:bridges@cs.unm.eduJ 3mailto:thorp@lanl.gov6G0mailto:ken@cs.rice.edupc-mailto:johnsson@cs.uh.eduF"*mailto:dongarra@cs.utk.eduS'mailto:keith@rice.edu9$mailto:rasmussn@lanl.govpc!mailto:johnsson@cs.uh.eduF"mailto:dongarra@cs.utk.edu6Gmailto:ken@cs.rice.edu<dmailto:rro@lanl.govY3mailto:keith@cs.rice.edu6Gmailto:ken@cs.rice.edueymailto:johnmc@cs.rice.eduVp mailto:hoisie@lanl.gov mailto:bridges@cs.unm.edusmailto:Dan_Reed@unc.eduF"mailto:dongarra@cs.utk.edueymailto:johnmc@cs.rice.edua* Telescope  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-./012345789:;<=?@ABCDEFQRoot Entry Fw:SData 1Table܄WordDocument*SummaryInformation(6DocumentSummaryInformation8> CompObjXObjectPoolw:w: FMicrosoft Word DocumentNB6WWord.Document.8