Oak Ridge Leadership Computing Facility

Today's high-performance computing (HPC) platforms are still dominated by batch jobs. Accordingly, effective batch job scheduling is crucial to obtain high system efficiency. Existing HPC batch job schedulers typically leverage heuristic priority functions to prioritize and schedule jobs. But, once configured and deployed by the experts, such priority functions can hardly adapt to the changes of job loads, optimization goals, or system settings, potentially leading to degraded system efficiency when changes occur. To address this fundamental issue, we present RLScheduler, an automated HPC batch job scheduler built on reinforcement learning. RLScheduler relies on minimal manual interventions or expert knowledge, but can learn high-quality scheduling policies via its own continuous `trial and error'. We introduce a new kernel-based neural network structure and trajectory filtering mechanism in RLScheduler to improve and stabilize the learning process. Through extensive evaluations, we confirm that RLScheduler can learn high-quality scheduling policies towards various workloads and various optimization goals with relatively low computation cost. Moreover, we show that the learned models perform stably even when applied to unseen workloads, making them practical for production use.

The complexity of scientific pursuits is increasing rapidly with aspects that require dynamic integration of experiment, observation, theory, modeling, simulation, visualization, machine learning (ML), artificial intelligence (AI), and analysis. Research projects across the Department of Energy (DOE) are increasingly data and compute intensive. Innovative research teams are accelerating the pace of discovery by using high-performance computational and data tools in their research workflows and leveraging multiple research infrastructures. Additionally, several recent high-level U.S. government reports underscore the necessity of a new advanced computing ecosystem for international competitiveness and national security. International competitors are moving forward with major research infrastructure integration efforts that seek to capture a competitive advantage in the global innovation race. Owing to its unparalleled constellation of world-class experimental and observational facilities and high-performance and extreme-scale computational, data, and networking infrastructure, DOE is positioned to be a global leader in this new era of integrated science. However, this new integration paradigm will demand continuing evolution to ensure the U.S. remains a global leader in research and innovation. The DOE Office of Science (SC) has seized on the strategic importance of integration and has adopted a vision for Integrated Research Infrastructure (IRI): To empower researchers to meld DOE’s world-class research tools, infrastructure, and user facilities seamlessly and securely in novel ways to radically accelerate discovery and innovation. To respond to the evolving computational requirements of research and the competitive international innovation landscape, experimental facilities could be connected with high performance computing resources for near real-time analysis, and resources should be provided for merging enormous and diverse data for AI/ML techniques and analysis.

This article consists of a collection of slides from the author's conference presentation. The Titan System's goal is to deliver breakthrough science specifically for the US Department of Energy (DOE), industry, and the nation. More about Tian can be found at http://www.olcf.ornl.gov/titan

The in-medium similarity renormalization group (IMSRG) is a powerful and flexible many-body method to compute the structure of nuclei starting from nuclear forces. Recent developments have extended the IMSRG from its standard truncation at the normal-ordered two-body level, the IMSRG(2), to a precision approximation including normal-ordered three-body operators, the IMSRG(3)-<a:math xmlns:a="http://www.w3.org/1998/Math/MathML"><a:msup><a:mi>N</a:mi><a:mn>7</a:mn></a:msup></a:math>. This improvement provides a more precise solution to the many-body problem and makes it possible to quantify many-body uncertainties in IMSRG calculations. We explore the structure of <b:math xmlns:b="http://www.w3.org/1998/Math/MathML"><b:mmultiscripts><b:mi>Ca</b:mi><b:mprescripts/><b:none/><b:mrow><b:mn>44</b:mn><b:mo>,</b:mo><b:mn>48</b:mn><b:mo>,</b:mo><b:mn>52</b:mn></b:mrow></b:mmultiscripts></b:math> using the IMSRG(3)-<c:math xmlns:c="http://www.w3.org/1998/Math/MathML"><c:msup><c:mi>N</c:mi><c:mn>7</c:mn></c:msup></c:math>, focusing on understanding existing discrepancies of the IMSRG(2) to experimental results. We find a significantly better description of the first <d:math xmlns:d="http://www.w3.org/1998/Math/MathML"><d:msup><d:mn>2</d:mn><d:mo>+</d:mo></d:msup></d:math> excitation energy of <e:math xmlns:e="http://www.w3.org/1998/Math/MathML"><e:mmultiscripts><e:mi>Ca</e:mi><e:mprescripts/><e:none/><e:mn>48</e:mn></e:mmultiscripts></e:math>, improving the description of the shell closure at <f:math xmlns:f="http://www.w3.org/1998/Math/MathML"><f:mrow><f:mi>N</f:mi><f:mo>=</f:mo><f:mn>28</f:mn></f:mrow></f:math>. At the same time, we find that the IMSRG(3)-<g:math xmlns:g="http://www.w3.org/1998/Math/MathML"><g:msup><g:mi>N</g:mi><g:mn>7</g:mn></g:msup></g:math> corrections to charge radii do not resolve the systematic underprediction of the puzzling large charge radius difference between <h:math xmlns:h="http://www.w3.org/1998/Math/MathML"><h:mmultiscripts><h:mi>Ca</h:mi><h:mprescripts/><h:none/><h:mn>52</h:mn></h:mmultiscripts></h:math> and <i:math xmlns:i="http://www.w3.org/1998/Math/MathML"><i:mmultiscripts><i:mi>Ca</i:mi><i:mprescripts/><i:none/><i:mn>48</i:mn></i:mmultiscripts></i:math>. We present estimates of many-body uncertainties of IMSRG(2) calculations applicable also to other systems based on the size extensivity of the method.

The FAIR principles for scientific data (Findable, Accessible, Interoperable, Reusable) are also relevant to other digital objects such as research software and scientific workflows that operate on scientific data. The FAIR principles can be applied to the data being handled by a scientific workflow as well as the processes, software, and other infrastructure which are necessary to specify and execute a workflow. The FAIR principles were designed as guidelines, rather than rules, that would allow for differences in standards for different communities and for different degrees of compliance. There are many practical considerations which impact the level of FAIR-ness that can actually be achieved, including policies, traditions, and technologies. Because of these considerations, obstacles are often encountered during the workflow lifecycle that trace directly to shortcomings in the implementation of the FAIR principles. Here, we detail some cases, without naming names, in which data and workflows were Findable but otherwise lacking in areas commonly needed and expected by modern FAIR methods, tools, and users. We describe how some of these problems, all of which were overcome successfully, have motivated us to push on systems and approaches for fully FAIR workflows.

The mission of the U.S. Department of Energy Office of Science (DOE SC) is the delivery of scientific discoveries and major scientific tools to transform our understanding of nature and to advance the energy, economic, and national security missions of the United States. To achieve these goals in today’s world requires investments in not only the traditional scientific endeavors of theory and experiment, but also in computational science and the facilities that support large-scale simulation and data analysis. The Advanced Scientific Computing Research (ASCR) program addresses these challenges in the Office of Science. ASCR’s mission is to discover, develop, and deploy computational and networking capabilities to analyze, model, simulate, and predict complex phenomena important to DOE. ASCR supports research in computational science, three high-performance computing (HPC) facilities — the National Energy Research Scientific Computing Center (NERSC) at Lawrence Berkeley National Laboratory and Leadership Computing Facilities at Argonne (ALCF) and Oak Ridge (OLCF) National Laboratories — and the Energy Sciences Network (ESnet) at Berkeley Lab. ASCR is guided by science needs as it develops research programs, computers, and networks at the leading edge of technologies. As we approach the era of exascale computing, technology changes are creating challenges for science programs in SC for those who need to use high performance computing and data systems effectively. Numerous significant modifications to today’s tools and techniques will be needed to realize the full potential of emerging computing systems and other novel computing architectures. To assess these needs and challenges, ASCR held a series of Exascale Requirements Reviews in 2015–2017, one with each of the six SC program offices,1 and a subsequent Crosscut Review that sought to integrate the findings from each. Participants at the reviews were drawn from the communities of leading domain scientists, experts in computer science and applied mathematics, ASCR facility staff, and DOE program managers in ASCR and the respective program offices. The purpose of these reviews was to identify mission-critical scientific problems within the DOE Office of Science (including experimental facilities) and determine the requirements for the exascale ecosystem that would be needed to address those challenges. The exascale ecosystem includes exascale computing systems, high-end data capabilities, efficient software at scale, libraries, tools, and other capabilities. This effort will contribute to the development of a strategic roadmap for ASCR compute and data facility investments and will help the ASCR Facility Division establish partnerships with Office of Science stakeholders. It will also inform the Office of Science research needs and agenda. The results of the six reviews have been published in reports available on the web at http://exascaleage.org/. This report presents a summary of the individual reports and of common and crosscutting findings, and it identifies opportunities for productive collaborations among the DOE SC program offices.

High-performance computing (HPC) storage systems provide data availability and reliability using various hardware and software fault tolerance techniques. Usually, reliability and availability are calculated at the subsystem or component level using limited metrics such as, mean time to failure (MTTF) or mean time to data loss (MTTDL). This often means settling on simple and disconnected failure models (such as exponential failure rate) to achieve tractable and close-formed solutions. However, such models have been shown to be insufficient in assessing end-to-end storage system reliability and availability. We propose a generic simulation framework aimed at analyzing the reliability and availability of storage systems at scale, and investigating what-if scenarios. The framework is designed for an end-to-end storage system, accommodating the various components and subsystems, their interconnections, failure patterns and propagation, and performs dependency analysis to capture a wide-range of failure cases. We evaluate the framework against a large-scale storage system that is in production and analyze its failure projections toward and beyond the end of lifecycle. We also examine the potential operational impact by studying how different types of components affect the overall system reliability and availability, and present the preliminary results

U.S. Department of Energy (DOE) High Performance Computing (HPC) facilities are on the verge of a paradigm shift in the way they deliver systems and services to science and engineering teams. Research projects are producing a wide variety of data at unprecedented scale and level of complexity, with community-specific services that are part of the data collection and analysis workflow. On June 18-19, 2014 representatives from six DOE HPC centers met in Oakland, CA at the DOE High Performance Operational Review (HPCOR) to discuss how they can best provide facilities and services to enable large-scale data-driven scientific discovery at the DOE national laboratories. The report contains findings from that review.

We explore how to optimally deploy several different types of machine-learned surrogate models used in rotorcraft aerodynamics on HPC. We first developed three different rotorcraft models at three different orders of magnitude (2M, 44M, and 212M trainable parameters) to use as test models. Then we developed a benchmark, which we call “smiBench”, that uses synthetic data to test a wide range of alternative configurations to study optimal deployment scenarios. We discovered several different types of optimal deployment scenarios depending on the model size and inference frequency. For most cases, it makes sense to use multiple inference servers, each bound to a GPU with a load balancer distributing the requests across multiple GPUs. We tested three different types of inference server deployments: (1) a custom Flask-based HTTP inference server, (2) TensorFlow Serving with gRPC protocol, and (3) RedisAI server with SmartRedis clients using the RESP protocol. We also tested three different types of load balancing techniques for multi-GPU inferencing: (1) Python concurrent.futures thread pool, (2) HAProxy, and (3) mpi4py. We investigated deployments on both DoD HPCMP’s SCOUT and DoE OLCF’s Summit POWER9 supercomputers, demonstrated the ability to inference a million samples per second using 192 GPUs, and studied multiple scenarios on both Nvidia T4 and V100 GPUs. Moreover, we studied a range of concurrency levels, both on the client-side and the server-side, and provide optimal configuration advice based on the type of deployment. Finally, we provide a simple Python-based framework for benchmarking machine-learned surrogate models using the various inference servers.

Oak Ridge National Laboratory’s Leadership Computing Facility (OLCF) continues to deliver the most powerful resources in the United States for open science. At 2.33 petaflops peak performance, the Cray XT Jaguar delivered more than 1.4 billion core hours in calendar year (CY) 2012 to researchers around the world for performing computational simulations relevant to national and energy security; advancing the frontiers of knowledge in physical sciences and areas of biological, medical, environmental, and computer sciences; and providing world-class research facilities for the nation’s science enterprise. OLCF users achieved numerous wide-ranging research accomplishments and technological innovations in 2012. It is not possible to fully summarize the breadth and impact of their productivity within this brief report—OLCF researchers published more than 300 research articles in 2012 alone. Here we identify selected accomplishments that advance the state of the art in science and engineering research and development. The work was recognized through peer-review publications in notable journals such as Science, Nature, and The Proceedings of the National Academy of Sciences (PNAS), among the many noted in this report. Exploration of the nuclear landscape carried out by Innovative and Novel Computational Impact on Theory and Experiment (INCITE) researchers and their theoretical prediction of isotopes were featured in Nature in 2012 (see Section 3.2.2). On the other end of the physical-scale spectrum, researchers executed a 22,000-year transient Earth System Model simulation that explained the misleading lag of carbon dioxide behind Antarctic temperature records and pointed to carbon dioxide’s role in driving global climate change over glacial cycles. This deglaciation study and related work by OLCF users were featured in Nature and PNAS in 2012 (see Section 3.2.3). Other representative achievements by OLCF users include generation of spectroscopic and photometric data for more accurate distance measurements, necessary for planning future National Science Foundation and Department of Energy (DOE) missions such as the Large Synoptic Survey Telescope and the Palomar Transient Factory; calculations to enable the experimental verification of Bose glass; and screening of 2 million compounds against a targeted receptor in a matter of days, as opposed to the months that would be required for computing clusters, creating a vast library of molecular compounds that can be used for future screenings of potential drug candidates. These and other accomplishments are described in Section 3.

We demonstrate NekRS performance results on various advanced GPU architectures. NekRS is a GPU-accelerated version of Nek5000 that is targeting high performance on forthcoming exascale platforms. It is being developed in DOE’s Center of Efficient Exascale Discretizations (CEED), which is one of the co-design centers under the Exascale Computing Project (ECP). In this report, we consider Frontier, Crusher, Spock, Polaris, Perlmutter, ThetaGPU and Summit. Simulations are performed using ExaSMR’s 17×17 rod-bundle geometries with different problem sizes. The report focuses on strong scaling performance and analysis. Many of the results shown in this report are the outcome from participation in the ALCF GPU Hackathon on Polaris, which was held on 7/19/22, and 7/26–7/28/22. Members of the Nek5000/RS team included Misun Min, Yu-Hsiang Lan, Paul Fischer and Thilina Rathnayake. Mentors were Kris Rowe (ALCF) and Peng Wang (NVIDIA). Also presented in this report are results on Frontier, which were obtained in collaboration with John Holmen at OLCF.

The "Shaping the Future of Self-Driving Autonomous Laboratories" workshop, held in Denver on November 7-8, 2024, brought together leading experts from materials science and computing to address the growing need to revolutionize scientific research through AI-driven autonomous laboratories. The workshop identified critical challenges, including the integration of heterogeneous data, development of AI systems that understand fundamental physical principles, and comprehensive safety protocols. Key recommendations emerged around developing universal laboratory equipment interfaces, implementing automated metadata collection systems, and creating hybrid AI approaches that combine data-driven learning with scientific principles. The workshop emphasized maintaining human oversight while leveraging automation, transforming scientific education to prepare the next generation of researchers, and establishing a national consortium leveraging DOE facilities as anchors for broader collaboration with academia and industry. Participants stressed the urgency of addressing the growing disconnect between human decision-making timescales and modern instrumentation capabilities, highlighting the need for strategic automation while preserving essential human insight and oversight in the research process.

Machine learning interatomic potentials (MLIPs) have emerged as powerful tools for investigating atomistic systems with high accuracy and a relatively low computational cost. However, a common and unaddressed challenge with many current neural network (NN) MLIP models is their limited ability to accurately predict the relative energies of systems containing isolated or nearly isolated atoms, which appear in various reactive processes. To address this limitation, we present a mathematical technique for modifying any existing atom-centered NN architecture to account for the energies of isolated atoms. The result produces a consistent prediction of the atomization energy (AE) of a system using minimal constraints on the model. Using this technique, we build a model architecture that we call hierarchically interacting particle neural network (HIP-NN)-AE, an AE-constrained version of the HIP-NN, as well as ANI-AE, the AE-constrained version of the accurate NN engine for molecular energies (ANI). Our results demonstrate AE consistency of AE-constrained models, which drastically improves the AE predictions for the models. We compare the AE-constrained approach to unconstrained models as well as models from the literature in other scenarios, such as bond dissociation energies, bond dissociation pathways, and extensibility tests. These results show that the constraints improve the model performance in some of these tasks and do not negatively affect the performance on any tasks. The AE constraint approach thus offers a robust solution to the challenges posed by isolated atoms in energy prediction tasks.

The widespread use of computing in the American economy would not be possible without a thoughtful, exploratory research and development (R&D) community pushing the performance edge of operating systems, computer languages, and software libraries. These are the tools and building blocks — the hammers, chisels, bricks, and mortar — of the smartphone, the cloud, and the computing services on which we rely. Engineers and scientists need ever-more specialized computing tools to discover new material properties for manufacturing, make energy generation safer and more efficient, and provide insight into the fundamentals of the universe, for example. The research division of the U.S. Department of Energy’s (DOE’s) Office of Advanced Scientific Computing and Research (ASCR Research) ensures that these tools and building blocks are being developed and honed to meet the extreme needs of modern science. See also http://exascaleage.org/ascr/ for additional information.

Oak Ridge National Laboratory’s (ORNL’s) Leadership Computing Facility (OLCF) continues to surpass its operational target goals: supporting users; delivering fast, reliable systems; creating innovative solutions for high-performance computing (HPC) needs; and managing risks, safety, and security aspects associated with operating one of the most powerful computers in the world. The results can be seen in the cutting-edge science delivered by users and the praise from the research community. Calendar year (CY) 2015 was filled with outstanding operational results and accomplishments: a very high rating from users on overall satisfaction that ties the highest-ever mark set in CY 2014; the greatest number of core-hours delivered to research projects; the largest percentage of capability usage since the OLCF began tracking the metric in 2009; and success in delivering on the allocation of 60, 30, and 10% of core hours offered for the INCITE (Innovative and Novel Computational Impact on Theory and Experiment), ALCC (Advanced Scientific Computing Research Leadership Computing Challenge), and Director’s Discretionary programs, respectively. These accomplishments, coupled with the extremely high utilization rate, represent the fulfillment of the promise of Titan: maximum use by maximum-size simulations. The impact of all of these successes and more is reflected in the accomplishments of OLCF users, with publications this year in notable journals Nature, Nature Materials, Nature Chemistry, Nature Physics, Nature Climate Change, ACS Nano, Journal of the American Chemical Society, and Physical Review Letters, as well as many others. The achievements included in the 2015 OLCF Operational Assessment Report reflect first-ever or largest simulations in their communities; for example Titan enabled engineers in Los Angeles and the surrounding region to design and begin building improved critical infrastructure by enabling the highest-resolution Cybershake map for Southern California to date. The Titan system provides the largest extant heterogeneous architecture for computing and computational science. Usage is high, delivering on the promise of a system well-suited for capability simulations for science. This success is due in part to innovations in tracking and reporting the activity on the compute nodes, and using this information to further enable and optimize applications, extending and balancing workload across the entire node. The OLCF continues to invest in innovative processes, tools, and resources necessary to meet continuing user demand. The facility’s leadership in data analysis and workflows was featured at the Department of Energy (DOE) booth at SC15, for the second year in a row, highlighting work with researchers from the National Library of Medicine coupled with unique computational and data resources serving experimental and observational data across facilities. Effective operations of the OLCF play a key role in the scientific missions and accomplishments of its users. Building on the exemplary year of 2014, as shown by the 2014 Operational Assessment Report (OAR) review committee response in Appendix A, this OAR delineates the policies, procedures, and innovations implemented by the OLCF to continue delivering a multi-petaflop resource for cutting-edge research. This report covers CY 2015, which, unless otherwise specified, denotes January 1, 2015, through December 31, 2015.

We used Data Direct Networks’ (DDN) SFA10K as the storage backend during this evaluation. It consists of 200 SAS drives and 280 SATA drives, organized into various RAID levels by two active-active RAID controllers. The exported RAID groups by these controllers are driven by four hosts. Each host has two InfiniBand (IB) QDR connections to the storage backend. We used a single dualport Mellanox connectX IB card per host. By our calculation, this setup can saturate SFA10K’s maximum theoretical throughput (~12 GB/s). Our Ceph testbed employs a collection of testing nodes. These nodes and their roles are summarized in Table 1. In the following discussion, we use “servers”, “osd servers”, “server hosts” interchangeably. We will emphasize with “client” prefix when we want to distinguish it from above. All hosts (client and servers) were configured with Redhat 6.3 and kernel version 3.5.1 initially, and later upgraded to 3.9 (rhl-ceph image), Glibc 2.12 with syncfs support, locally patched. We used the Ceph 0.48 and 0.55 release in the initial tests, upgraded to 0.64 and then to 0.67RC for a final round of tests.

Data and Python3 scripts to support the results and reproduce the figures of "Computational schemes for the Magnus expansion of the in-medium similarity renormalization group" by M. Heinz.

This is an opensource library for benchmarking the system's GPU mixed precision capabilities. The software calculates solution of the system of linear equation in 64bit accuracy using mixed precision techniques and iterative refinement. Original benchmark designed is done by ICL, and it is name HPL-MxP (HPL-AI)

To manufacture light-weight, advanced metal alloy components for gas turbine engines, quench heat-treatment processes are typically used. By quenching the component from elevated tempera-tures, the alloy sometimes undergoes a solid-state phase transformation which produces special microstructures with the required, enhanced mechanical properties. However, the quenching can also lead to cracks forming in the component. Addressing the quench cracking problems adds a significant burden to the cost, schedule, and energy demand of manufacture. Currently, optimizing the quench process to mitigate or avoid the cracking is performed largely by trial-and-error, relying heavily on costly experimental (thermocouple) trials to understand the local thermal gradients which cause the cracks to form. In this first part (Phase 1) of the work, high-performance computing is employed to establish the ability of modern CFD (computational fluid dynamics) to alleviate or wholly replace the experimental quenching trials by virtual testing. A baseline CFD model is defined and its accuracy established to be comparable to (and which usually exceeds) the accuracy of existing HTC (heat-transfer correlation) based simulation methods of quenching. As a first-principles based approach, “calibration” of the Baseline CFD model is independent of the quench process itself, but instead relies on the accuracy of the underlying (modeled), generic two-phase fluid processes which cannot be currently resolved by CFD for large, industrial-scale cases. A novel, high-fidelity DNS capability has been developed and verified to examine and further improve upon the mean-field closure submodels on which the Baseline CFD approach is based.

The Viskores User's Guide, Release 1.1 Viskores_USE_DOUBLE_PRECISIONIf on, then Viskores will use double precision (64-bit) floating point numbers for calculations where the precision type is not otherwise specified.If off, then single precision (32-bit) floating point numbers are used.Regardless of this setting, Viskores's templates will accept either type. Building ViskoresOnce CMake successfully configures Viskores and generates the files for the build system, you are ready to build Viskores.As stated earlier, CMake supports generating configuration files for several different types of build tools.Make and ninja are common build tools, but CMake also supports building project files for several different types of integrated development environments such as Microsoft Visual Studio and Apple XCode.The Viskores libraries and test files are compiled when the default build is invoked.For example, if a Makefile was generated, the build is invoked by calling textfilename{make} in the build directory.Expanding on Example 1 Example 2: Using make to build Viskores.tar xvzf ~/Downloads/viskores-v2.1.0.tar.gzmkdir viskores-build cd viskores-build cmake-gui ../viskores-v2.1.0make -j make install Did You Know?Makefile and other project files generated by CMake support parallel builds, which run multiple compile steps simultaneously.On computers that have multiple processing cores (as do almost all modern computers), this can significantly speed up the overall compile.Some build systems require a special flag to engage parallel compiles.For example, make requires the -j flag to start parallel builds as demonstrated in Example 2. Did You Know?Example 2 assumes that a make build system was generated, which is the default on most system.However, CMake supports many more build systems, which use different commands to run the build.If you are not sure what the appropriate build command is, you can run cmake --build to allow CMake to start the build using whatever build system is being used. Common ErrorsCMake allows you to switch between several types of builds including default, Debug, and Release.Programs and libraries compiled as release builds can run much faster than those from other types of builds.Thus, it is important to perform Release builds of all software released for production or where runtime is a concern.Some integrated development environments such as Microsoft Visual Studio allow you to specify the different build types within the build system.But for other build programs, like make, you have to specify the build type in the CMAKE_BUILD_TYPE CMake configuration variable, which is described in Section 2.2 (Configuring Viskores).CMake creates several build "targets" that specify the group of things to build.The default target builds all of Viskores's libraries as well as tests, examples, and benchmarks if enabled.The test target executes each of the Viskores regression tests and verifies they complete successfully on the system.The install target copies the subset of files required toThe Viskores User's Guide, Release 1.1 viskores::filter Contains Viskores's pre-built filters.Applications that are looking to use Viskores filters will need to link to this library.The filters are further broken up into several smaller library packages (such as viskores::filter_contour, :cmake:variable`viskores::filter_flow`, viskores::filter_field_transform, and many more.viskores::filter is actually a meta library that links all of these filter libraries to a CMake target.viskores::io Contains Viskores's facilities for interacting with files.For example, reading and writing png, NetBPM, and VTK files.viskores::rendering Contains Viskores's rendering components.This library is only available if Viskores_ENABLE_RENDERING is set to true.viskores::source Contains Viskores's pre-built dataset generators suchas Wavelet, Tangle, and Oscillator.Most applications will not need to link to this library. Did You Know?The "libraries" made available in the Viskores do more than add a library to the linker line.These libraries are actually defined as external targets that establish several compiler flags, like include file directories.Many CMake packages require you to set up other target options to compile correctly, but for Viskores it is sufficient to simply link against the library.The Viskores User's Guide, Release 1.1The width can be specified by appending the desired number of bits in the same way as the floating point textidenti-fier{Vec}s.For example, viskores::Vec4ui_8 is a textidentifier{Vec} of 4 unsigned bytes.using viskores::