Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “PORT”

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 343 records · Page 19
All sourcesNASA NTRSDOE OSTI
DOE OSTI2022

Insulated exhaust port liner for a cylinder head assembly of a motor vehicle

An insulated exhaust port liner of a cylinder head assembly for fluidly connecting to an internal combustion engine of a motor vehicle includes a sealing layer. The sealing layer has a first surface defining a passage for fluidly connecting to the internal combustion engine and receiving exhaust gas. The sealing layer further includes a second surface opposite to the first surface. The liner further includes a thermal barrier layer coated onto the second surface of the sealing layer. The thermal barrier layer is a porous non-woven material for supporting the sealing layer on the cylinder head and reducing a transfer of heat from the sealing layer to the cylinder head.

Andruskiewicz, IV, Peter P.↗
DOE OSTI2015

Container inspection in the port container terminal by using 14 MeV neutrons

A proposal for an autonomous and flexible ship container inspection system is presented. This could be accomplished by the incorporation of inspection system on the container transportation devices (straddle carriers, yard gentry cranes automated guided vehicles, trailers). This configuration is terminal specific and it will be decided by container terminal operator. In such a way no part of port operational area will be used for inspection. The inspection scenario will include container transfer from ship to transportation device with inspection unit mounted on it, inspection during container movement to the container location. A neutron generator without associated alpha particle detection will be used. This will allow the use of higher neutron intensity (5x10{sup 9} - 10{sup 10} n/s in 4π). The inspected container will be stationary in the 'inspection position' on the transportation device while the 'inspection unit' will move along its side. Following analytical methods will be used simultaneously: neutron radiography, X-ray radiography, neutron activation analysis, (n,γ) and (n,n'γ) reactions, neutron absorption, and scattering, X-ray backscattering, Neutron techniques will take the advantage of using 'smart collimators' for neutrons and gammas, both emitted and detected. The inspected voxel will be defined by intersections/union of neutron generator and detectors solid angles. The container inspection protocol will be based on identification of discrepancies between its cargo manifest and its elemental 'fingerprint' and radiography profiles. In addition, the information on container weight will be obtained during the container transport and foreseen screening from the measurement of density of material in the container. (authors)

42 ENGINEERING↗
DOE OSTI2023

Operational Focused Data Analytics for Optimizing Radiation Portal Monitor-Based Nuclear Smuggling Detection Systems at Global Ports of Entry

The National Nuclear Security Administration’s Office of Nuclear Smuggling Detection and Deterrence has deployed a fleet of radiation portal monitors (RPMs) across the world at global ports of entry including seaports, airports, and land border crossings. These RPMs are integrated into radiation detection systems (RDS) that also include fixed cameras, optical character recognition (OCR) systems, primary scanning systems (e.g., X-ray or gamma-ray), and secondary scanning systems (e.g., spectroscopic radiation portal monitors, portable radiation detection systems). The data from these sensing technologies is collected at the Central Alarm Station (CAS) where servers and computers reside to control and operate the system. Operators utilize the data collected by the CAS and declared cargo information to make decisions on how to respond to an alarm.This work explores the use of CAS-located data, looking at both the sensor data streams and operator inputs, to perform analysis which supports customs and border protection agencies to improve training capability and operational effectiveness. We focus on analyzing site level effectiveness and behavior by rolling up CAS-located data collected from individual occurrences. To-date, more than 15 sites (e.g., seaports, airports, border crossings) have been analyzed in this manner with the goal of understanding system operations to verify effectiveness and recommend potential improvements. This work first aims to provide background information on relevant CAS-located data sources and our current operational system analytics process including example results. After summarizing our current analytic techniques, we discuss how the future data analytics systems can provide key benefits to improving operational performance while minimizing the burden these detection systems place on operators.

Kuhn, Michael↗
DOE OSTI2023

Transfer ports for confinement gloveboxes and related methods

Transfer ports for confinement gloveboxes may include a flange sized and shaped to be secured within an opening in a wall of a glovebox. A sleeve may be secured to the flange and define a passage through the flange. A first cap may be removably secured to the sleeve on a first side of the flange and obstruct the passage on the first side. A second cap may be removably secured to the sleeve on a second, opposite side of the flange and obstruct the passage on the second side.

Balsmeier, Aaron A.↗
DOE OSTI2022

Experiences with Porting the FLASH Code to Ookami, an HPE Apollo 80 A64FX Platform

We present initial experiences with running the community simulation code FLASH, developed at the University of Chicago for multi-scale multi-physics applications, on Ookami, a technology testbed featuring the A64FX processor developed by Fujitsu. Our effort focused largely on running FLASH “right out of the box” to see which combinations of compilers and software implementations (e.g. MPI) allowed the code to run with minimal modification. FLASH was one application in a larger effort to deploy Ookami; it served as a test for different versions of newly installed software, and as a cornerstone for the FAQ page of the Ookami website. Here, we report on our results with different compilers and other software, along with our initial scaling results and attempts to utilize the A64FX’s SVE instructions and NUMA architecture. We found that FLASH readily ran with different compilers and MPI implementations, and showed the expected good scaling with no turning. However, more work must be done to fully take advantage of the A64FX’s architectural features and produce a significant speedup for FLASH on Ookami.

79 ASTRONOMY AND ASTROPHYSICS↗
DOE OSTI2025

ComPort: Rigorous Testing Methods to Safeguard Software Porting (Final Technical Report)

This is a technical report from the lead institution – University of Utah, Kahlert School of Computing – funded under the Department of Energy, Office of Science, Office of Advanced Scientific Computing Research under award number DE-SC0022252. We summarize our work done over the three years of funding received. The relevant papers and software have already been uploaded at the DOE site.

97 MATHEMATICS AND COMPUTING↗
NASA NTRS1994

Add an RS-232 Port to an EPLD

As EPLDs become part of small systems the level of integration is increased, cost and time to market go down.

RS-232 port↗
DOE OSTI2018

Porting DMRG++ Scientific Application to OpenPOWER

With the rapidly changing microprocessor designs and architectural diversity (multi-cores, many-cores, accelerators) for the next generation HPC systems, scientific applications must adapt to the hardware, to exploit the different types of parallelism and resources available in the architecture. To get the benefit of all the in-node hardware threads, it is important to use a single programming model to map and coordinate the available work to the different heterogeneous execution units in the node (e.g., multi-core hardware threads (latency optimized), accelerators (bandwidth optimized), etc.).Our goal is to show that we can manage the node complexity of these systems by using OpenMP for in-node parallelization by exploiting different “programming styles” supported by OpenMP 4.5 to program CPU cores and accelerators. Finding out the suitable programming-style (e.g., SPMD style, multi-level tasks, accelerator programming, nested parallelism, or a combination of these) using the latest features of OpenMP to maximize performance and achieve performance portability across heterogeneous and homogeneous systems is still an open research problem.We developed a mini-application, Kronecker Product (KP), from the original DMRG++ application (sparse matrix algebra) computational motif to experiment with different OpenMP programming styles on an OpenPOWER architecture and present their results in this paper.

Chatterjee, Ronnie↗
DOE OSTI2025

Lessons Learned and Scalability Achieved When Porting Uintah to DOE Exascale Systems

A key challenge faced when preparing codes for Department of Energy (DOE) exascale systems was designing scalable applications for systems featuring hardware and software not yet available at leadership-class scale. With such systems now available, it is important to evaluate scalability of the resulting software solutions on these target systems. One such code designed with the exascale DOE Aurora and DOE Frontier systems in mind is the Uintah Computational Framework, an open-source asynchronous many-task (AMT) runtime system. To prepare for exascale, Uintah adopted a portable MPI+X hybrid parallelism approach using the Kokkos performance portability library (i.e., MPI+Kokkos). This paper complements recent work with additional details and an evaluation of the resulting approach on Aurora and Frontier. Results are shown for a challenging benchmark demonstrating interoperability of 3 portable codes essential to Uintah-related combustion research. These results demonstrate single-source portability across Aurora and Frontier with scaling characteristics shown to 3,072 Aurora nodes and 9,216 Frontier nodes. In addition to showing results run to new scales on new systems, this paper also discusses lessons learned through efforts preparing Uintah for exascale systems.

Holmen, John [ORNL] (ORCID:0000000259342641)↗
DOE OSTI2012

Experiences with High-Level Programming Directives for Porting Applications to GPUs. In: Facing the Multicore--Challenge II, Lecture Notes in Computer Science.

HPC systems now exploit GPUs within their compute nodes to accelerate program performance. As a result, high-end application development has become extremely complex at the node level. In addition to restructuring the node code to exploit the cores and specialized devices, the programmer may need to choose a programming model such as OpenMP or CPU threads in conjunction with an accelerator programming model to share and manage the different node resources. This comes at a time when programmer productivity and the ability to produce portable code has been recognized as a major concern. In order to offset the high development cost of creating CUDA or OpenCL kernels, directives have been proposed for programming accelerator devices, but their implications are not well known. In this paper, we evaluate the state of the art accelerator directives to program several applications kernels, explore transformations to achieve good performance, and examine the expressivity and performance penalty of using high-level directives versus CUDA. We also compare our results to OpenMP implementations to understand the benefits of running the kernels in the accelerator versus CPU cores.

CUDA Implementation↗