SEARCH · Search NASA

Results for “Software Stack”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

SourceResearch connectionFrom yearThrough year

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 325 records · Page 18

All sources NASA NTRS DOE OSTI

DOE OSTI2014

F3D Image Processing and Analysis for Many - and Multi-core Platforms

F3D is written in OpenCL, so it achieve[sic] platform-portable parallelism on modern mutli-core CPUs and many-core GPUs. The interface and mechanims to access F3D core are written in Java as a plugin for Fiji/ImageJ to deliver several key image-processing algorithms necessary to remove artifacts from micro-tomography data. The algorithms consist of data parallel aware filters that can efficiently utilizes[sic] resources and can work on out of core datasets and scale efficiently across multiple accelerators. Optimizing for data parallel filters, streaming out of core datasets, and efficient resource and memory and data managements over complex execution sequence of filters greatly expedites any scientific workflow with image processing requirements. F3D performs several different types of 3D image processing operations, such as non-linear filtering using bilateral filtering and/or median filtering and/or morphological operators (MM). F3D gray-level MM operators are one-pass constant time methods that can perform morphological transformations with a line-structuring element oriented in discrete directions. Additionally, MM operators can be applied to gray-scale images, and consist of two parts: (a) a reference shape or structuring element, which is translated over the image, and (b) a mechanism, or operation, that defines the comparisons to be performed between the image and the structuring element. This tool provides a critical component within many complex pipelines such as those for performing automated segmentation of image stacks. F3D is also called a "descendent" of Quant-CT, another software we developed in the past. These two modules are to be integrated in a next version. Further details were reported in: D.M. Ushizima, T. Perciano, H. Krishnan, B. Loring, H. Bale, D. Parkinson, and J. Sethian. Structure recognition from high-resolution images of ceramic composites. IEEE International Conference on Big Data, October 2014.

Source record↗

DOE OSTI2025

automesh: Automatic mesh generation in Rust

automesh is an open-source Rust software program that uses a segmentation, typically generated from a 3D image stack, to create a finite element mesh, composed either of hexahedral (volumetric) or triangular (isosurface) elements. automesh converts between segmentation formats (.npy, .spn) and mesh formats (.exo, .inp, .mesh, .stl, .vtk). automesh can defeature voxel domains, apply Laplacian and Taubin smoothing, and output mesh quality metrics. automesh uses an internal octree for fast performance.

Hovey, Chad Brian [Sandia National Laboratories (S↗

NASA NTRS2016

Mechanical Design and Development of TES Bolometer Detector Arrays for the Advanced ACTPol Experiment

The next generation Advanced ACTPol (AdvACT) experiment is currently underway and will consist of four Transition Edge Sensor (TES) bolometer arrays, with three operating together, totaling 5800 detectors on the sky. Building on experience gained with the ACTPol detector arrays, AdvACT will utilize various new technologies, including 150 mm detector wafers equipped with multichroic pixels, allowing for a more densely packed focal plane. Each set of detectors includes a feedhorn array of stacked silicon wafers which form a spline pro le leading to each pixel. This is then followed by a waveguide interface plate, detector wafer, back short cavity plate, and backshort cap. Each array is housed in a custom designed structure manufactured from high purity copper and then gold plated. In addition to the detector array assembly, the array package also encloses cryogenic readout electronics. We present the full mechanical design of the AdvACT high frequency (HF) detector array package along with a detailed look at the detector array stack assemblies. This experiment will also make use of extensive hardware and software previously developed for ACT, which will be modi ed to incorporate the new AdvACT instruments. Therefore, we discuss the integration of all AdvACT arrays with pre-existing ACTPol infrastructure.

Advanced ACTPol (AdvACT)↗

DOE OSTI2014

F3D Image Processing and Analysis for Many - and Multi-core Platforms

Source record↗

DOE OSTI2016

Application Characterization at Scale: Lessons learned from developing a distributed Open Community Runtime system for High Performance Computing

Since 2012, the U.S. Department of Energy’s X-Stack program has been developing solutions including runtime systems, programming models, languages, compilers, and tools for the Exascale system software to address crucial performance and power requirements. Fine grain programming models and runtime systems show a great potential to efficiently utilize the underlying hardware. Thus, they are essential to many X-Stack efforts. An abundant amount of small tasks can better utilize the vast parallelism available on current and future machines. Moreover, finer tasks can recover faster and adapt better, due to a decrease in state and control. Nevertheless, current applications have been written to exploit old paradigms (such as Communicating Sequential Processor and Bulk Synchronous Parallel processing). To fully utilize the advantages of these new systems, applications need to be adapted to these new paradigms. As part of the applications’ porting process, in-depth characterization studies, focused on both application characteristics and runtime features, need to take place to fully understand the application performance bottlenecks and how to resolve them. This paper presents a characterization study for a novel high performance runtime system, called the Open Community Runtime, using key HPC kernels as its vehicle. This study has the following contributions: one of the first high performance, fine grain, distributed memory runtime system implementing the OCR standard (version 0.99a); and a characterization study of key HPC kernels in terms of runtime primitives running on both intra and inter node environments. Running on a general purpose cluster, we have found up to 1635x relative speed-up for a parallel tiled Cholesky Kernels on 128 nodes with 16 cores each and a 1864x relative speed-up for a parallel tiled Smith-Waterman kernel on 128 nodes with 30 cores.

Application characterization↗

NASA NTRS2017

Reconfigurable Wideband Circularly Polarized Stacked Square Patch Antenna for Cognitive Radios

An almost square patch, a square patch and a stacked square patch with corner truncation for circular polarization (CP) are researched and developed at X-band for cognitive radios. Experimental results indicate, first, that the impedance bandwidth of a CP almost square patch fed from the edge by a 50 ohm line is 1.70% and second, that of a CP square patch fed from the ground plane side by a surface launch connector is 1.87%. Third, the impedance bandwidth of a CP stacked square patch fed by a surface launch connector is 2.22%. The measured center frequency for the CP square patch fed by a surface launch connector without and with an identical stacked patch is 8.45 and 8.1017 GHz, respectively. By stacking a patch, separated by a fixed air gap of 0.254 mm, the center frequency is observed to shift by as much as 348.3 MHz. The shift in center frequency, brought about by the reconfiguring of the physical layer antenna, can be exploited in a cognitive system since it expands the usable frequency spectrum for software reconfiguration in the presence of interference. In addition, varying the fixed air gap in the stacked antenna geometry by increments of 0.254 mm further expands the usable frequency spectrum.

Cognitive↗

DOE OSTI2018

Modernising ATLAS Software Build Infrastructure

In the last year ATLAS has radically updated its software development infrastructure hugely reducing the complexity of building releases and greatly improving build speed, flexibility and code testing. The first step in this transition was the adoption of CMake as the software build system over the older CMT. This required the development of an automated translation from the old system to the new, followed by extensive testing and improvements. This resulted in a far more standard build process that was married to the method of building ATLAS software as a series of 12 separate projects from Subversion. We then proceeded with a migration of the code base from Subversion to Git. As the Subversion repository had been structured to manage each package more or less independently there was no simple mapping that could be used to manage the migration into Git. Instead a specialist set of scripts that captured the software changes across official software releases was developed. With some clean up of the repository and the policy of only migrating packages in production releases, we managed to reduce the repository size from 62 GiB to 220 MiB. After moving to Git we took the opportunity to introduce continuous integration so that now each code change from developers is built and tested before being approved. With both CMake and Git in place we also dramatically simplified the build management of ATLAS software. Many heavyweight homegrown tools were dropped and the build procedure was reduced to a single bootstrap of some external packages, followed by a full build of the rest of the stack. This has reduced the time for a build by a factor of 2. It is now easy to build ATLAS software, freeing developers to test compile intrusive changes or new platform ports with ease. We have also developed a system to build lightweight ATLAS releases, for simulation, analysis or physics derivations which can be built from the same branch.

97 MATHEMATICS AND COMPUTING↗

DOE OSTI2022

Resilience Design Patterns: A Structured Approach to Resilience at Extreme Scale (V.2.0)

Reliability is a serious concern for future extreme-scale high-performance computing (HPC) systems. Projections based on the current generation of HPC systems and technology roadmaps suggest the prevalence of very high fault rates in future systems. The errors resulting from these faults will propagate and generate various kinds of failures, which may result in outcomes ranging from result corruptions to catastrophic application crashes. Therefore, the resilience challenge for extreme-scale HPC systems requires coordination between various hardware and software technologies that are capable of handling a broad set of fault models at accelerated fault rates. Also, due to practical limits on power consumption in future HPC systems, they are likely to embrace innovative architectures, increasing the levels of hardware and software complexities. Therefore, the techniques that seek to improve resilience must navigate the complex trade-off space between resilience and the overheads to power consumption and performance. While the HPC community has developed various resilience solutions, application-level techniques as well as system-based solutions, the solution space of HPC resilience techniques remains fragmented. There are no formal methods to integrate the various HPC resilience techniques into composite solutions, nor are there methods to holistically evaluate the adequacy and efficacy of such solutions in terms of their protection coverage, and their performance & power efficiency characteristics. Additionally, few implementations of current resilience solutions are portable to newer architectures and software environments that will be deployed on future systems. We developed a new structured approach to the management of HPC resilience using the concept of resilience-based design patterns. In general, a design pattern is a repeatable solution to a commonly occurring problem. We identified the well-known solutions that are commonly used to deal with faults, errors and failures in HPC systems. In the initial design patterns specification (version 1.0), we described the various solutions, which address specific problems in the design of resilient HPC environments, in the form of patterns. Each pattern describes a problem caused by a fault, error or failure event in an HPC environment, and then describes the core of the solution of the problem in such a way that this solution may be adapted to different systems and implemented at different layers of the system stack. The catalog of these resilience design patterns provides designers with a collection of design elements. To construct complete resilience solutions using combinations of various patterns, we defined a framework that enhances HPC designers' understanding of the important constraints and the opportunities for the design patterns to be implemented and deployed at various layers of the system stack. The design framework is also useful for establishing interfaces and mechanisms to coordinate flexible fault management across hardware and software components, as well as to consider the trade-off between performance, resilience, and power consumption when constructing a solution. The resilience design patterns specification version 1.1 included more detailed explanations of the pattern solutions, the context in which the patterns are applicable, and the implications for hardware or software design. It also provided several additional examples and detailed case studies to demonstrate the use of patterns to build realistic solutions. In version 1.2 of the specification document, we have improved the pattern descriptions, including graphical representations of the pattern components. These improvements are largely based on critical comments, feedback and suggestions received from pattern experts and readers of the previous versions of the specification. The pattern classification has been modified to further clarify the relationships between pattern categories. This version of the specification also introduces a pattern language for resilience design patterns. The pattern language presents the patterns in the catalog as a network, revealing the relations among the resilience patterns. The language provides designers with the means to explore alternative techniques for handling a specific fault model that may have different efficiency and complexity characteristics. Using the pattern language also enables the design and implementation of comprehensive resilience solutions as a set of interconnected resilience patterns that can be instantiated across layers of the system stack. The overall goal of this work is to provide hardware and software designers, as well as the users and operators of HPC systems, a systematic methodology for the design and evaluation of resilience technologies in HPC systems that keep scientific applications running to a correct solution in a timely and cost-efficient manner despite frequent faults, errors, and failures of various types. Version 2.0 expands the resilience design pattern classification and catalog to include self-stabilization patterns and reliability, availability and performance models for each structural pattern.

97 MATHEMATICS AND COMPUTING↗

NASA NTRS2012

Compact Autonomous Hemispheric Vision System

Solar System Exploration camera implementations to date have involved either single cameras with wide field-of-view (FOV) and consequently coarser spatial resolution, cameras on a movable mast, or single cameras necessitating rotation of the host vehicle to afford visibility outside a relatively narrow FOV. These cameras require detailed commanding from the ground or separate onboard computers to operate properly, and are incapable of making decisions based on image content that control pointing and downlink strategy. For color, a filter wheel having selectable positions was often added, which added moving parts, size, mass, power, and reduced reliability. A system was developed based on a general-purpose miniature visible-light camera using advanced CMOS (complementary metal oxide semiconductor) imager technology. The baseline camera has a 92 FOV and six cameras are arranged in an angled-up carousel fashion, with FOV overlaps such that the system has a 360 FOV (azimuth). A seventh camera, also with a FOV of 92 , is installed normal to the plane of the other 6 cameras giving the system a > 90 FOV in elevation and completing the hemispheric vision system. A central unit houses the common electronics box (CEB) controlling the system (power conversion, data processing, memory, and control software). Stereo is achieved by adding a second system on a baseline, and color is achieved by stacking two more systems (for a total of three, each system equipped with its own filter.) Two connectors on the bottom of the CEB provide a connection to a carrier (rover, spacecraft, balloon, etc.) for telemetry, commands, and power. This system has no moving parts. The system's onboard software (SW) supports autonomous operations such as pattern recognition and tracking.

Pingree, Paula J.↗

NASA NTRSDate not supplied

Space Launch System (SLS) Human Factors Engineering Modeling & Analysis

The Human Systems Integration & Engineering (HSI&E) team at NASA’s Marshall Space Flight Center (MSFC) strives to advocate for the humans in the loop of Space Launch System’s (SLS) ground operations. Using assessment methods like human simulation, virtual reality, and physical mockups, both flight hardware and ground support equipment (GSE) are evaluated for human integration. Those ranging from 5th percentile female (approximately 5’2” tall) to 95th percentile male (approximately 6’2” tall) should be able to perform all SLS stacking operations. Operations include element physical mates, element electrical mates, and testing activities. The primary human simulation software used is Process Simulate Human (PSH) made by Siemens. This software supplies highly accurate human manikins that can interact with CAD models. PSH was used to evaluate the Transportation and Integration Platform’s (TIP) side opening that was designed for access to the Payload Adapter (PLA) cables. Technicians will need to access these cables for testing purposes before element stacking at Kennedy Space Center (KSC). After performing an analysis in PSH using the TIP side opening, it was found that neither a 5th percentile female or a 95th percentile male could perform the task as the designers had intended. There is a C-beam that blocks access to the cables (both physically and visually). An alternative analysis was performed using PSH to look at another access point to the PLA cables. Although this method would disrupt already established procedures and produce more work, the designers confirmed it was an option. Instead of technicians accessing the cables through the side opening in the TIP, a human simulation was performed for going through a panel opening in the bottom of the TIP. This method requires removal of a TIP panel and a stepladder of at least 36 inches for a 5th percentile female to access the cables.

human factors↗

DOE OSTI2022

Commercial Building Sensors and Controls Systems: Barriers, Drivers, and Costs

Building sensors and controls systems, including building automation systems, consists of the sensor-based devices installed in buildings and the control and automation of those devices. Optimized sensors and controls systems could lead to 29% annual energy savings in commercial buildings and are integral to the growth of grid-interactive efficient buildings. Only 8% of small commercial buildings, however, have installed sensors and controls systems. This is largely due to cost barriers. This work seeks to increase the transparency of system costs and identify specific barriers and drivers for increased adoption. To gather industry insights, the team reached out to building owners, vendors, and contractors and conducted 20 interviews with the goal of collecting cost data and market characteristics regarding building sensors and controls. The qualitative interview data was analyzed using grounded theory to identify overarching concepts, such as barriers, drivers, and future directions on the field. From this analysis, primary barriers were found to be complexity, a lack of knowledge, and money. Primary drivers were found to be the knowledge of data, savings, and remote access. The qualitative cost data was collected in the form of invoices during the interviews. The cost values were used to develop a percentage-based cost stack which identifies the average fraction of the total cost attributed to each category (hardware, software, labor, fees, and taxes). This greater understanding of costs and barriers associated with commercial building sensors and controls systems lays the groundwork for future steps in increasing system adoption, reducing energy consumption, and market transformation.

advanced building controls↗

DOE OSTI2019

Multi-layer Printing of Complex Antennas Using Aerosol Jet Technology (CRADA NFE-18-07315 Final Report)

This project demonstrated the feasibility of producing multilayer radio-frequency (RF) and microwave-frequency components using aerosol jet additive manufacturing technology. Funded by the U.S. Department of energy, Advanced Manufacturing Office, this effort focused on novel stacked component designs for devices such as antennas, electronic filters, resistive/inductive/capacitive (RLC) components, and transmission lines. Our approach to RF/microwave component fabrication by aerosol jet printing has the potential to reduce component size, improve performance characteristics, and allow devices to be fabricated on non-planar surfaces. Specifically, folded micro-patch antenna designs were fabricated by stacking layers of conductors and dielectrics printed in sequence using Optomec’s aerosol jet technology. ORNL supported the effort by providing design input on printing parameters and characterizing the performance of printed structures. ORNL identified suitable stacked antenna designs, produced finite element models (FEM) in high-frequency simulation software (HFSS), and provided the designs to Optomec for printing. After printing, the devices were tested and characterized at ORNL to determine the frequency response and material characteristics of the printed components. These proof-of-principle devices will provide feedback on printing parameters, optimizations for the FEM models, and a path for more complex multilayer device designs.

42 ENGINEERING↗

DOE OSTI2024

How to Build a Quantum Supercomputer: Scaling from Hundreds to Millions of Qubits

In the span of four decades, quantum computation has evolved from an intellectual curiosity to a potentially realizable technology. Today, small-scale demonstrations have become possible for quantum algorithmic primitives on hundreds of physical qubits and proof-of-principle error-correction on a single logical qubit. Nevertheless, despite significant progress and excitement, the path toward a full-stack scalable technology is largely unknown. There are significant outstanding quantum hardware, fabrication, software architecture, and algorithmic challenges that are either unresolved or overlooked. These issues could seriously undermine the arrival of utility-scale quantum computers for the foreseeable future. Here, we provide a comprehensive review of these scaling challenges. We show how the road to scaling could be paved by adopting existing semiconductor technology to build much higher-quality qubits, employing system engineering approaches, and performing distributed quantum computation within heterogeneous high-performance computing infrastructures. These opportunities for research and development could unlock certain promising applications, in particular, efficient quantum simulation/learning of quantum data generated by natural or engineered quantum systems. To estimate the true cost of such promises, we provide a detailed resource and sensitivity analysis for classically hard quantum chemistry calculations on surface-code error-corrected quantum computers given current, target, and desired hardware specifications based on superconducting qubits, accounting for a realistic distribution of errors. Furthermore, we argue that, to tackle industry-scale classical optimization and machine learning problems in a cost-effective manner, heterogeneous quantum-probabilistic computing with custom-designed accelerators should be considered as a complementary path toward scalability.

Mohseni, Masoud↗

DOE OSTI2017

Resilience Design Patterns - A Structured Approach to Resilience at Extreme Scale (version 1.2)

We developed a new structured approach to the management of HPC resilience using the concept of resilience-based design patterns. In general, a design pattern is a repeatable solution to a commonly occurring problem. We identified the well-known solutions that are commonly used to deal with faults, errors and failures in HPC systems. In the initial design patterns specification (version 1.0), we described the various solutions, which address specific problems in the design of resilient HPC environments, in the form of patterns. Each pattern describes a problem caused by a fault, error or failure event in an HPC environment, and then describes the core of the solution of the problem in such a way that this solution may be adapted to different systems and implemented at different layers of the system stack. The catalog of these resilience design patterns provides designers with a collection of design elements. To construct complete resilience solutions using combinations of various patterns, we defined a framework that enhances HPC designers’ understanding of the important constraints and the opportunities for the design patterns to be implemented and deployed at various layers of the system stack. The design framework is also useful for establishing interfaces and mechanisms to coordinate flexible fault management across hardware and software components, as well as to consider the trade-off between performance, resilience, and power consumption when constructing a solution. The resilience design patterns specification version 1.1 included more detailed explanations of the pattern solutions, the context in which the patterns are applicable, and the implications for hardware or software design. It also provided several additional examples and detailed case studies to demonstrate the use of patterns to build realistic solutions. In this version 1.2 of the specification document, we have improved the pattern descriptions, including graphical representations of the pattern components. These improvements are largely based on critical comments, feedback and suggestions received from pattern experts and readers of the previous versions of the specification. The pattern classification has been modified to further clarify the relationships between pattern categories. This version of the specification also introduces a pattern language for resilience design patterns. The pattern language presents the patterns in the catalog as a network, revealing the relations among the resilience patterns. The language provides designers with the means to explore alternative techniques for handling a specific fault model that may have different effciency and complexity characteristics. Using the pattern language also enables the design and implementation of comprehensive resilience solutions as a set of interconnected resilience patterns that can be instantiated across layers of the system stack. The overall goal of this work is to provide hardware and software designers, as well as the users and operators of HPC systems, a systematic methodology for the design and evaluation of resilience technologies in HPC systems that keep scientific applications running to a correct solution in a timely and cost-effcient manner despite frequent faults, errors, and failures of various types.

97 MATHEMATICS AND COMPUTING↗

NASA NTRS1991

Stacking-sequence optimization for buckling of laminated plates by integer programming

Integer-programming formulations for the design of symmetric and balanced laminated plates under biaxial compression are presented. Both maximization of buckling load for a given total thickness and the minimization of total thickness subject to a buckling constraint are formulated. The design variables that define the stacking sequence of the laminate are zero-one integers. It is shown that the formulation results in a linear optimization problem that can be solved on readily available software. This is in contrast to the continuous case, where the design variables are the thicknesses of layers with specified ply orientations, and the optimization problem is nonlinear. Constraints on the stacking sequence such as a limit on the number of contiguous plies of the same orientation and limits on in-plane stiffnesses are easily accommodated. Examples are presented for graphite-epoxy plates under uniaxial and biaxial compression using a commercial software package based on the branch-and-bound algorithm.

Haftka, Raphael T.↗

DOE OSTI2017

XPRESS: eXascale PRogramming Environment and System Software

The XPRESS project is the research and development of a complete software architecture for Exascale computing. The four major R&D thrusts include: 1) an Exascale lightweight kernel operating system (LXK), based on the Kitten operating system (OS), to manage billion way hardware parallelism, management of faults and power, management of global virtual name space, and other features of future system architectures; 2) a runtime system (HPX-5), co-designed with LXK, based on the ParalleX execution model that supports dynamic resource management and task scheduling; 3) system interfaces for interoperability between the runtime system and both the OS and the runtime system (RIOS); 4) compilation strategies and systems to translate MPI and OpenMP legacy codes to a form that can be run with performance at least as good as a native code implementation. The software architecture development has been driven by performance evaluation of mini-applications developed at Department of Energy Co-Design Centers as well as ancillary in-house developed applications and benchmarks. Research on the ParalleX execution model has been driven by the development of formal semantics and model checkers for the execution model. The major components of the software architecture are: ParalleX execution model – guiding principles for co-design of components of the system stack with advances in locality management and task prioritization through introspection; HPX runtime system – support of application dynamic adaptive resource management, task scheduling, and introspective control policies; LXK operating system – lightweight kernel operating system for order-constant scalability and low/no noise to manage resources; RIOS – a realm of Exascale system operation unique in the XPRESS project that includes the relationship between the new generation of lightweight kernel operating systems and runtime system software; XPI advanced programming model – intermediate form and low-level (readable) programming interface reflecting the ParalleX model, providing a target for source-to- source high level parallel language translation, and supporting early direct programming experimentation and measurement; Performance models & metrics – providing parameters and their mutual sensitivities to guide co-design and quantify operational behavior; Legacy migration – ensuring seamless transition of legacy codes and programming methods to the future generation of ParalleX-based Exascale systems; . Experiments and evaluation – critical to determining degree of effectiveness and likelihood of ultimate success as well as guiding corrective design changes to achieve DOE objectives; and Applications – collaborations with Co-Design Centers and other mission critical codes. The exemplar implementation of the ParalleX execution model, HPX-5, has been released along with five fully ported applications (LULESH, HPCG, SSSP, WAMR, and DASHMM) and multiple microbenchmarks. Using these applications, the system architecture demonstrated dynamic load balancing through active migration, legacy code migration, and data-driven approaches to for graph-like applications. Crucially for Exascale and billion way parallelism, the needs and patterns of irregular applications in HPX-5 were addressed using local flow control rather than relying on globally synchronized data structures.

97 MATHEMATICS AND COMPUTING↗

DOE OSTI2022

EMSL-Computing/CoreMS-Portal

Software that orchestrate data processing and management for mass spectrometry workflows and data products. Stack presented contains a web application, data processing job scheduling, and data processing workers for data processing and management.

Corilo, Yuri↗

DOE OSTI2014

SU-E-T-384: Experimental Verification of a Monte Carlo Linear Accelerator Model Using a Radiochromic Film Stack Dosimeter

Purpose: To experimentally verify a Monte Carlo (MC) linear accelerator model for the simulation of intensity-modulated radiation therapy (IMRT) treatments of moving targets. Methods: A Varian Clinac™ 21EX linear accelerator was modeled using the EGSnrc user code BEAMnrc. The mean energy, radial-intensity distribution, and divergence of the electron beam incident on the bremsstrahlung target were adjusted to achieve agreement between simulated and measured percentage-depth-dose and transverse field profiles for a 6 MV beam. A seven-field step-and-shoot IMRT lung procedure was prepared using Varian Eclipse™ treatment planning software. The plan was delivered using a Clinac™ 21EX linear accelerator and measured with a Gafchromic™ EBT2 film stack dosimeter (FSD) in two separate static geometries: within a cylindrical water-equivalent-plastic phantom and within an anthropomorphic chest phantom. Two measurements were completed in each setup. The dose distribution for each geometry was simulated using the EGSnrc user code DOSXYZnrc. MC geometries of the treatment couch, cylindrical phantom, and chest phantom were developed by thresholding CT data sets using MATLAB™. The FSD was modeled as water. The measured and simulated dose distributions were normalized to the median dose within the FSD. Results: Using an electron beam with a mean energy of 6.05 MeV, a Gaussian radial-intensity distribution with a full width at half maximum of 1.5 mm, and a divergence of 0°, the measured and simulated dose profiles agree within 1.75% and 1 mm. Measured and simulated dose distributions within both the cylindrical and chest phantoms agree within 3% over 94% of the FSD volume. The overall uncertainty in the FSD measurements is 3.1% (k=1). Conclusion: MC simulations agree with FSD measurements within measurement uncertainty, thereby verifying the accuracy of the linear accelerator model for the simulation of IMRT treatments of static geometries. The experimental verification will be extended to treatments of targets undergoing three-dimensional motion.

60 APPLIED LIFE SCIENCES↗