Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “file system”

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.

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

At least 865 records · Page 48

Development of an Optical-Real Time Polarimetric Imaging System for Aerospace Applications

The design of an optical polarimetric imaging system, aimed to detect cracks or structural defects on the surface of rotating aircraft engine shafts, is presented. The experimental results have been processed by a real time wavelet denouncing system implemented by a Filed Programmable Gate Arrays (FPGA), which has been designed for this purpose. The experimental results clearly indicate that high signal-to-noise ratio signals can be obtained.

Giakos, George C.↗

Development of a Prototype Automation Simulation Scenario Generator for Air Traffic Management Software Simulations

A technique for automated development of scenarios for use in the Multi-Center Traffic Management Advisor (McTMA) software simulations is described. The resulting software is designed and implemented to automate the generation of simulation scenarios with the intent of reducing the time it currently takes using an observational approach. The software program is effective in achieving this goal. The scenarios created for use in the McTMA simulations are based on data taken from data files from the McTMA system, and were manually edited before incorporation into the simulations to ensure accuracy. Despite the software s overall favorable performance, several key software issues are identified. Proposed solutions to these issues are discussed. Future enhancements to the scenario generator software may address the limitations identified in this paper.

Khambatta, Cyrus F.↗

Definition and maintenance of a telemetry database dictionary

A telemetry dictionary database includes a component for receiving spreadsheet workbooks of telemetry data over a web-based interface from other computer devices. Another component routes the spreadsheet workbooks to a specified directory on the host processing device. A process then checks the received spreadsheet workbooks for errors, and if no errors are detected the spreadsheet workbooks are routed to another directory to await initiation of a remote database loading process. The loading process first converts the spreadsheet workbooks to comma separated value (CSV) files. Next, a network connection with the computer system that hosts the telemetry dictionary database is established and the CSV files are ported to the computer system that hosts the telemetry dictionary database. This is followed by a remote initiation of a database loading program. Upon completion of loading a flatfile generation program is manually initiated to generate a flatfile to be used in a mission operations environment by the core ground system.

Knopf, William P.↗

Effect of Surface Traffic Count on Taxi Time at Dallas-Fort Worth (DFW) International Airport

As the amount of air traffic increases over the years, most airports simply do not have the means of expanding to handle the intensified traffic on the surface that will ensue. Precise surveillance equipment and automation concepts, as well as advanced surface traffic algorithms are being developed to improve airport efficiency. These surface algorithms require inputs unique to each airport to ensure maximum efficiency, and minimal taxi delay. This study analyzes surface traffic at Dallas-Fort Worth International Airport (DFW) to determine the effect of the number of aircraft on the surface and the amount of stop and go situations they experience to the amount of additional taxi time encountered. If the surface capacity of an airport is known, minimal delay can be accomplished by limiting the number of taxiing aircraft to that capacity. This concept is related to highways, where traffic flow drastically decreases as more cars occupy the road. An attempt to minimize this effect on highways is seen with the use of metering lights at freeway on-ramps. Since the surface traffic at airports is highly regulated, and aircraft are less mobile on the ground, limiting the surface count to a certain number can greatly reduce the amount of additional taxi time encountered, as well as reduce hazardous emissions. This study will also find the regions of an airport that encounter the most additional taxi time when the number of aircraft in that area is increased. This could help surface traffic algorithms avoid congesting that area, or re-route aircraft to different runways when that area reaches its capacity. The relationship between the amount of stop and go situations an aircraft encounters and their effect on the taxi time of that aircraft will also be investigated. This will help to determine the effect of holding an aircraft on the taxiway as opposed to re-routing it. The lesser of the two should be used when developing surface traffic algorithms to further minimize the delay encountered. The fields investigated in this study include taxi time, the number of aircraft on the surface, the number of stop and go situations, and the time stopped for each aircraft. Taxi time is defined as spot to runway for departures, and runway to spot for arrivals. It does not include ramp area taxi time because the ramp area is controlled differently, and surface traffic schedulers do not currently incorporate them. Taxi time is found by finding the difference between take-off time (OFF) and spot crossing time for departures, and spot crossing time and landing time (ON) for arrivals. All surface data was either found directly using the Surface Operations Data Analysis and Adaptation (SODAA), a tool to analyze the Surface Management System (SMS) generated log files, or indirectly from SODAA using Matlab to derive values from SODAA data. The number of aircraft on the surface is found by looping through the ON times, OFF times, and spot times for each aircraft during a particular day. For each departure aircraft, surface counts are taken at its spot crossing and OFF time. The average of these two is used as the surface count for that aircraft. For arrivals, surface counts are taken at its ON time and its spot crossing time. The average of these two is used.

Kistler, Matthew Stephen↗

Planetary Geologic Mapping Handbook - 2009

Geologic maps present, in an historical context, fundamental syntheses of interpretations of the materials, landforms, structures, and processes that characterize planetary surfaces and shallow subsurfaces (e.g., Varnes, 1974). Such maps also provide a contextual framework for summarizing and evaluating thematic research for a given region or body. In planetary exploration, for example, geologic maps are used for specialized investigations such as targeting regions of interest for data collection and for characterizing sites for landed missions. Whereas most modern terrestrial geologic maps are constructed from regional views provided by remote sensing data and supplemented in detail by field-based observations and measurements, planetary maps have been largely based on analyses of orbital photography. For planetary bodies in particular, geologic maps commonly represent a snapshot of a surface, because they are based on available information at a time when new data are still being acquired. Thus the field of planetary geologic mapping has been evolving rapidly to embrace the use of new data and modern technology and to accommodate the growing needs of planetary exploration. Planetary geologic maps have been published by the U.S. Geological Survey (USGS) since 1962 (Hackman, 1962). Over this time, numerous maps of several planetary bodies have been prepared at a variety of scales and projections using the best available image and topographic bases. Early geologic map bases commonly consisted of hand-mosaicked photographs or airbrushed shaded-relief views and geologic linework was manually drafted using mylar bases and ink drafting pens. Map publishing required a tedious process of scribing, color peel-coat preparation, typesetting, and photo-laboratory work. Beginning in the 1990s, inexpensive computing, display capability and user-friendly illustration software allowed maps to be drawn using digital tools rather than pen and ink, and mylar bases became obsolete. Terrestrial geologic maps published by the USGS now are primarily digital products using geographic information system (GIS) software and file formats. GIS mapping tools permit easy spatial comparison, generation, importation, manipulation, and analysis of multiple raster image, gridded, and vector data sets. GIS software has also permitted the development of project-specific tools and the sharing of geospatial products among researchers. GIS approaches are now being used in planetary geologic mapping as well (e.g., Hare and others, 2009). Guidelines or handbooks on techniques in planetary geologic mapping have been developed periodically (e.g., Wilhelms, 1972, 1990; Tanaka and others, 1994). As records of the heritage of mapping methods and data, these remain extremely useful guides. However, many of the fundamental aspects of earlier mapping handbooks have evolved significantly, and a comprehensive review of currently accepted mapping methodologies is now warranted. As documented in this handbook, such a review incorporates additional guidelines developed in recent years for planetary geologic mapping by the NASA Planetary Geology and Geophysics (PGG) Program s Planetary Cartography and Geologic Mapping Working Group s (PCGMWG) Geologic Mapping Subcommittee (GEMS) on the selection and use of map bases as well as map preparation, review, publication, and distribution. In light of the current boom in planetary exploration and the ongoing rapid evolution of available data for planetary mapping, this handbook is especially timely.

Tanaka, K. L.↗

Planetary Geologic Mapping Handbook - 2010

Geologic maps present, in an historical context, fundamental syntheses of interpretations of the materials, landforms, structures, and processes that characterize planetary surfaces and shallow subsurfaces. Such maps also provide a contextual framework for summarizing and evaluating thematic research for a given region or body. In planetary exploration, for example, geologic maps are used for specialized investigations such as targeting regions of interest for data collection and for characterizing sites for landed missions. Whereas most modern terrestrial geologic maps are constructed from regional views provided by remote sensing data and supplemented in detail by field-based observations and measurements, planetary maps have been largely based on analyses of orbital photography. For planetary bodies in particular, geologic maps commonly represent a snapshot of a surface, because they are based on available information at a time when new data are still being acquired. Thus the field of planetary geologic mapping has been evolving rapidly to embrace the use of new data and modern technology and to accommodate the growing needs of planetary exploration. Planetary geologic maps have been published by the U.S. Geological Survey (USGS) since 1962. Over this time, numerous maps of several planetary bodies have been prepared at a variety of scales and projections using the best available image and topographic bases. Early geologic map bases commonly consisted of hand-mosaicked photographs or airbrushed shaded-relief views and geologic linework was manually drafted using mylar bases and ink drafting pens. Map publishing required a tedious process of scribing, color peel-coat preparation, typesetting, and photo-laboratory work. Beginning in the 1990s, inexpensive computing, display capability and user-friendly illustration software allowed maps to be drawn using digital tools rather than pen and ink, and mylar bases became obsolete. Terrestrial geologic maps published by the USGS now are primarily digital products using geographic information system (GIS) software and file formats. GIS mapping tools permit easy spatial comparison, generation, importation, manipulation, and analysis of multiple raster image, gridded, and vector data sets. GIS software has also permitted the development of projectspecific tools and the sharing of geospatial products among researchers. GIS approaches are now being used in planetary geologic mapping as well. Guidelines or handbooks on techniques in planetary geologic mapping have been developed periodically. As records of the heritage of mapping methods and data, these remain extremely useful guides. However, many of the fundamental aspects of earlier mapping handbooks have evolved significantly, and a comprehensive review of currently accepted mapping methodologies is now warranted. As documented in this handbook, such a review incorporates additional guidelines developed in recent years for planetary geologic mapping by the NASA Planetary Geology and Geophysics (PGG) Program's Planetary Cartography and Geologic Mapping Working Group's (PCGMWG) Geologic Mapping Subcommittee (GEMS) on the selection and use of map bases as well as map preparation, review, publication, and distribution. In light of the current boom in planetary exploration and the ongoing rapid evolution of available data for planetary mapping, this handbook is especially timely.

Tanaka, K. L.↗

Applying Standard Interfaces to a Process-Control Language

A method of applying open-operating-system standard interfaces to the NASA User Interface Language (UIL) has been devised. UIL is a computing language that can be used in monitoring and controlling automated processes: for example, the Timeliner computer program, written in UIL, is a general-purpose software system for monitoring and controlling sequences of automated tasks in a target system. In providing the major elements of connectivity between UIL and the target system, the present method offers advantages over the prior method. Most notably, unlike in the prior method, the software description of the target system can be made independent of the applicable compiler software and need not be linked to the applicable executable compiler image. Also unlike in the prior method, it is not necessary to recompile the source code and relink the source code to a new executable compiler image. Abstraction of the description of the target system to a data file can be defined easily, with intuitive syntax, and knowledge of the source-code language is not needed for the definition.

Berthold, Richard T.↗

Metadata staging tools

Django application providing a user-interface for building a file and metadata management system. Operates in conjunction with https://github.com/usgin/metadata-server.

Source record↗

Management of Documents and Information on Radioactive Waste - 19455

The assurance of the safety of a repository for low- and intermediate-level radioactive waste, during the 300 years of institutional control after closure, depends on assuming that the responsible institution will be capable to control the documents with information regarding the facility, the disposed of waste and the established measures for counteracting events that could breach the isolation of the radioactive material. Management of documents or information does not represent a major challenge in itself in view of consolidated practices and international standards, such as ISO 15489. However, considering the time scale involved in the disposal of the radioactive wastes, efforts should be made to ensure the preservation and proper access to documents and information. In this matter, the technological aspect of document production can be a complicating factor. In fact, it is common to be unable to access electronic documents produced 20 or 30 years ago, due either to problems related to the media where the information is stored, or to a lack of compatible systems for reading the files. This is just one example of complication when thinking about production, organization, representation, preservation and retrieval of recorded information that is to last for centuries. In this way, this work seeks to present the situation of the management of documents and information on radioactive waste in the scope of the Institute of Energy and Nuclear Research (IPEN) and with national regulation in Brazil. (authors)

12 MANAGEMENT OF RADIOACTIVE AND NON-RADIOACTIVE W↗

Multi-User Space Link Extension (SLE) System

The Multi-User Space (MUS) Link Extension system, a software and data system, provides Space Link Extension (SLE) users with three space data transfer services in timely, complete, and offline modes as applicable according to standards defined by the Consultative Committee for Space Data Systems (CCSDS). MUS radically reduces the schedule, cost, and risk of implementing a new SLE user system, minimizes operating costs with a lights-out approach to SLE, and is designed to require no sustaining engineering expense during its lifetime unless changes in the CCSDS SLE standards, combined with new provider implementations, force changes. No software modification to MUS needs to be made to support a new mission. Any systems engineer with Linux experience can begin testing SLE user service instances with MUS starting from a personal computer (PC) within five days. For flight operators, MUS provides a familiar-looking Web page for entering SLE configuration data received from SLE. Operators can also use the Web page to back up a space mission's entire set of up to approximately 500 SLE service instances in less than five seconds, or to restore or transfer from another system the same amount of data from a MUS backup file in about the same amount of time. Missions operate each MUS SLE service instance independently by sending it MUS directives, which are legible, plain ASCII strings. MUS directives are usually (but not necessarily) sent through a TCP-IP (Transmission Control Protocol Internet Protocol) socket from a MOC (Mission Operations Center) or POCC (Payload Operations Control Center) system, under scripted control, during "lights-out" spacecraft operation. MUS permits the flight operations team to configure independently each of its data interfaces; not only commands and telemetry, but also MUS status messages to the MOC. Interfaces can use single- or multiple-client TCP/IP server sockets, TCP/IP client sockets, temporary disk files, the system log, or standard in, standard out, or standard error as applicable. By defining MUS templates in ASCII, the flight operations team can include any MUS system variable in telemetry or command headers or footers, and/or in status messages. Data fields can be arranged within messages in different sequences, according to the mission s needs. The only constraints imposed are on the format of MUS directive strings, and some bare minimum logical requirements that must be met in order for MUS to read the mission control center's spacecraft command inputs. The MUS system imposes no limits or constraints on the numbers and combinations of missions and SLE service instances that it will support simultaneously. At any time, flight operators may add, change, delete, bind, connect, or disconnect.

Perkins, Toby↗

Motion Tracking Above and Below Water Dataset

This data set includes one trial of above and under water motion tracking measurements from a Qualysis motion tracking system. The Qualisys native .qtm file can be opened by the Qualisys Track Manager software. Data from this file has been exported to a tab separated value (.tsv) file which is a generic ASCII file format that can be read by a text editor, MATLAB, Excel, etc... Also exported is a native MATLAB formatted file (.mat) which can be loaded directly into MATLAB. The trial is from a three body wave energy converter device, using the underwater system for the central nacelle data, and above water system for the fore and aft floats.

16 TIDAL AND WAVE POWER↗

COMET Progresses Toward First Mission

The COMmercial Experiment Transporter (COMET) is a set of hardware and related infrastructure used to support orbital experiments of the CDD's and their industrial partners. During this year major support contracts were signed, preliminary design reviews conducted, experiments selected for the first mission, and long lead items place on order. The Program Office and CCDS Monitors took an active role in guiding COMET through the activation maze. Launch and recovery sites were selected and licenses for the launch vehicle, recovery system, and recovery operations were filed by the contractors with the Department of Transportation. As the period closed, COMET was preparing for Critical Design Reviews on all major systems and a target launch data was selected. This report deals primarily with the programmatic issues which were resolved as the program matured. At times is is impossible to disassociate the technical from the programmatic and, in such cases the technical material is presented to provide insight into the paths selected by both CCDS and Contractor Management.

Pawlick, J.↗

Multi-resolution Arctic Shrub Cover Dataset Derived from UAS and Airborne SfM and LiDAR (2013-2025)

We synthesized 177 unoccupied aerial system flights and 77 airborne flights across the Arctic and created a multi-resolution benchmark data of low-to-tall shrub fractional cover leveraging Structure-from-Motion and Light Detection and Ranging. The resulting dataset covered a total of 1899 km2 across Alaska, Western Canada, Sweden, and Siberian Arctic, including key sites from the Oro Arctic to the High Arctic. The dataset is organized into 6 primary data collection directories (“Abisko,” “AWI,” “ERE,” “Fairbanks,” “NGEE,” “Toolik”), each containing site and flight subdirectories. Flight directories include shrub cover rasters (*.tifs) at 1 m, 5 m, and 30 m resolution, the canopy height model at 1 m resolution (*.tifs), and a bounding box *.kml file. For the AWI, Abisko, NGEE, and Fairbanks collections, we also include the GCC raster at 1 m resolution (*.tif). Files are organized by Collection > Site > Flight Name > Data Files. Flight rasters are in the local UTM zone and the .kml files are in the geographic coordinate system EPSG 4326. We also include a .csv file that details the source datasets for every flight. The Next-Generation Ecosystem Experiments in the Arctic (NGEE Arctic) project is a research effort to reduce uncertainty in the Department of Energy’s Energy Exascale Earth System Model (E3SM) by developing a predictive understanding of Arctic tundra ecosystems underlain by permafrost and to quantify feedbacks from the Arctic tundra to the Earth system. NGEE Arctic is supported by the Department of Energy's Office of Biological and Environmental Research. Over Phases 1–3, observations made by the NGEE Arctic team across a gradient of permafrost landscapes in Arctic Alaska improved the representation of tundra processes in the land surface component of E3SM (the E3SM Land Model, ELM). Model improvements emphasized unique aspects of permafrost environments and explored reductions in model complexity while retaining predictive power. The Arctic-informed ELM developed by NGEE Arctic has been used to make novel predictions on processes ranging from permafrost thaw to soil biogeochemical cycling to Earth system feedbacks associated with the unique characteristics of tundra plants. In Phase 4, the NGEE Arctic team is evaluating our new predictive understanding under novel conditions across the Arctic domain. In collaboration with partners at long-term pan-Arctic research sites we are examining whether an Arctic-informed ELM can faithfully simulate interactions among surface and subsurface processes at site, regional, and pan-Arctic scales. In turn, we are using variety of tools to dynamically extend and evaluate ELM inference, with an emphasis on data synthesis and pan-Arctic model evaluation, reintegration of code with an evolving E3SM, scaling across heterogeneous Arctic landscapes, and the appropriate representation of the impacts of increasingly frequent Arctic disturbances.

canopy height model↗

Data Albums: An Event Driven Search, Aggregation and Curation Tool for Earth Science

One of the largest continuing challenges in any Earth science investigation is the discovery and access of useful science content from the increasingly large volumes of Earth science data and related information available. Approaches used in Earth science research such as case study analysis and climatology studies involve gathering discovering and gathering diverse data sets and information to support the research goals. Research based on case studies involves a detailed description of specific weather events using data from different sources, to characterize physical processes in play for a specific event. Climatology-based research tends to focus on the representativeness of a given event, by studying the characteristics and distribution of a large number of events. This allows researchers to generalize characteristics such as spatio-temporal distribution, intensity, annual cycle, duration, etc. To gather relevant data and information for case studies and climatology analysis is both tedious and time consuming. Current Earth science data systems are designed with the assumption that researchers access data primarily by instrument or geophysical parameter. Those who know exactly the datasets of interest can obtain the specific files they need using these systems. However, in cases where researchers are interested in studying a significant event, they have to manually assemble a variety of datasets relevant to it by searching the different distributed data systems. In these cases, a search process needs to be organized around the event rather than observing instruments. In addition, the existing data systems assume users have sufficient knowledge regarding the domain vocabulary to be able to effectively utilize their catalogs. These systems do not support new or interdisciplinary researchers who may be unfamiliar with the domain terminology. This paper presents a specialized search, aggregation and curation tool for Earth science to address these existing challenges. The search tool automatically creates curated "Data Albums", aggregated collections of information related to a specific science topic or event, containing links to relevant data files (granules) from different instruments; tools and services for visualization and analysis; and information about the event contained in news reports, images or videos to supplement research analysis. Curation in the tool is driven via an ontology based relevancy ranking algorithm to filter out non-relevant information and data.

Ramachandran, Rahul↗

Khoros software specification format and interoperability

Khoros defines formats for User Interface Specification (UIS) and Program Specification (PS) files. From such files, its code generator, Ghostwriter, creates source files and documentation. The great advantage of the system is that the code fragments that make up part of the PS file are purely generic. All Khoros-related code is created by the code generator; this includes all user interface code. As a matter of fact, both specification files are very generic in nature. Thus, one could imagine using it as the basis for other software systems. A case is made that writing a code generator that would create IRAF-compatible code from the Khoros UIS and PS files is fairly trivial. Another aspect of the Khoros system conventions concerns the way execution commands are generated by the user interface and the actual syntax of those commands. The protocols are such that interoperability at the level of executable modules is readily possible.

Rots, A. H.↗

The Evolution of Dust in the Multiphase ISM: Grain Destruction Processes

This proposal covered year one of a long term project in which we acquired the necessary hardware and softwaxe needed to calculate grain destruction processes in the interstellar medium (ISM). The long term goal of this research is to develop a model for the dust evolution in the ISM capable of explaining observations of elemental depletions, the grain size distribution, and the emission characteristics of the ISM from the X-ray through the FIR. We purchased a SUN Ultra 10 workstation and peripheral devices including an Exabyte Tape drive, HP Laser Printer, and Seagate External Hard Disk. The PI installed the hardware and Solaris operating system on the workstation and integrated the hardware into the network. Software was also purchased to enable connections to the workstation from a PC (Hummingbird Exceed). Additional freeware required to carry out the proposed program was installed on the system including compilers (g77, gcc, g++), editors (emacs), a markup language (LaTeX), and display programs (WIP, XV, SAOtng). We have also successfully modified the required plot files to work with our system which display the results of grain processing.

Wolfire, Mark↗

Application Program Interface for the Orion Aerodynamics Database

The Application Programming Interface (API) for the Crew Exploration Vehicle (CEV) Aerodynamic Database has been developed to provide the developers of software an easily implemented, fully self-contained method of accessing the CEV Aerodynamic Database for use in their analysis and simulation tools. The API is programmed in C and provides a series of functions to interact with the database, such as initialization, selecting various options, and calculating the aerodynamic data. No special functions (file read/write, table lookup) are required on the host system other than those included with a standard ANSI C installation. It reads one or more files of aero data tables. Previous releases of aerodynamic databases for space vehicles have only included data tables and a document of the algorithm and equations to combine them for the total aerodynamic forces and moments. This process required each software tool to have a unique implementation of the database code. Errors or omissions in the documentation, or errors in the implementation, led to a lengthy and burdensome process of having to debug each instance of the code. Additionally, input file formats differ for each space vehicle simulation tool, requiring the aero database tables to be reformatted to meet the tool s input file structure requirements. Finally, the capabilities for built-in table lookup routines vary for each simulation tool. Implementation of a new database may require an update to and verification of the table lookup routines. This may be required if the number of dimensions of a data table exceeds the capability of the simulation tools built-in lookup routines. A single software solution was created to provide an aerodynamics software model that could be integrated into other simulation and analysis tools. The highly complex Orion aerodynamics model can then be quickly included in a wide variety of tools. The API code is written in ANSI C for ease of portability to a wide variety of systems. The input data files are in standard formatted ASCII, also for improved portability. The API contains its own implementation of multidimensional table reading and lookup routines. The same aerodynamics input file can be used without modification on all implementations. The turnaround time from aerodynamics model release to a working implementation is significantly reduced

Robinson, Philip E.↗

Independent calculation-based verification of IMRT plans using a 3D dose-calculation engine

Independent monitor unit verification of intensity-modulated radiation therapy (IMRT) plans requires detailed 3-dimensional (3D) dose verification. The aim of this study was to investigate using a 3D dose engine in a second commercial treatment planning system (TPS) for this task, facilitated by in-house software. Our department has XiO and Pinnacle TPSs, both with IMRT planning capability and modeled for an Elekta-Synergy 6 MV photon beam. These systems allow the transfer of computed tomography (CT) data and RT structures between them but do not allow IMRT plans to be transferred. To provide this connectivity, an in-house computer programme was developed to convert radiation therapy prescription (RTP) files as generated by many planning systems into either XiO or Pinnacle IMRT file formats. Utilization of the technique and software was assessed by transferring 14 IMRT plans from XiO and Pinnacle onto the other system and performing 3D dose verification. The accuracy of the conversion process was checked by comparing the 3D dose matrices and dose volume histograms (DVHs) of structures for the recalculated plan on the same system. The developed software successfully transferred IMRT plans generated by 1 planning system into the other. Comparison of planning target volume (TV) DVHs for the original and recalculated plans showed good agreement; a maximum difference of 2% in mean dose, − 2.5% in D95, and 2.9% in V95 was observed. Similarly, a DVH comparison of organs at risk showed a maximum difference of +7.7% between the original and recalculated plans for structures in both high- and medium-dose regions. However, for structures in low-dose regions (less than 15% of prescription dose) a difference in mean dose up to +21.1% was observed between XiO and Pinnacle calculations. A dose matrix comparison of original and recalculated plans in XiO and Pinnacle TPSs was performed using gamma analysis with 3%/3 mm criteria. The mean and standard deviation of pixels passing gamma tolerance for XiO-generated IMRT plans was 96.1 ± 1.3, 96.6 ± 1.2, and 96.0 ± 1.5 in axial, coronal, and sagittal planes respectively. Corresponding results for Pinnacle-generated IMRT plans were 97.1 ± 1.5, 96.4 ± 1.2, and 96.5 ± 1.3 in axial, coronal, and sagittal planes respectively.

61 RADIATION PROTECTION AND DOSIMETRY↗