Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “data requests”

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 541 records · Page 30

Guidance for Federal Agencies on EPAct 2005 Section 701: Alternative Fuel Use Requirements for Dual-Fueled Vehicles

Section 701 of the Energy Policy Act of 2005 (EPAct 2005) requires Federal agencies to use alternative fuel in dual-fueled vehicles when it is reasonably available and not unreasonably more expensive than gasoline (42 U.S.C. Section 6374(a)(3)(E)). Since 2007, Federal agencies have requested waivers for vehicles from the Section 701 requirements as part of a June data call for the subsequent fiscal year (FY). The U.S. Department of Energy (DOE) Federal Energy Management Program (FEMP) has reviewed those waiver requests and granted or denied them prior to the subsequent FY. At the end of each FY, DOE FEMP has reviewed each Federal agency's covered alternative fuel use and compared it to total fuel use in non-waivered vehicles to determine compliance. This guidance provides two different processes through which DOE will begin evaluating waiver requests for FY 2021 (beginning with the FY 2020 data call): Automated reporting in the Federal Fleet Sustainability Dashboard (FleetDASH), and waiver requests in FAST.

29 ENERGY PLANNING, POLICY, AND ECONOMY↗

High-Resolution Imaged-Based 3D Reconstruction Combined with X-Ray CT Data Enables Comprehensive Non-Destructive Documentation and Targeted Research of Astromaterials

Providing web-based data of complex and sensitive astromaterials (including meteorites and lunar samples) in novel formats enhances existing preliminary examination data on these samples and supports targeted sample requests and analyses. We have developed and tested a rigorous protocol for collecting highly detailed imagery of meteorites and complex lunar samples in non-contaminating environments. These data are reduced to create interactive 3D models of the samples. We intend to provide these data as they are acquired on NASA's Astromaterials Acquisition and Curation website at http://curator.jsc.nasa.gov/.

Blumenfeld, E. H.↗

A Kriging-Based Approach to Autonomous Experimentation with Applications to X-Ray Scattering

Abstract Modern scientific instruments are acquiring data at ever-increasing rates, leading to an exponential increase in the size of data sets. Taking full advantage of these acquisition rates will require corresponding advancements in the speed and efficiency of data analytics and experimental control. A significant step forward would come from automatic decision-making methods that enable scientific instruments to autonomously explore scientific problems—that is, to intelligently explore parameter spaces without human intervention, selecting high-value measurements to perform based on the continually growing experimental data set. Here, we develop such an autonomous decision-making algorithm that is physics-agnostic, generalizable, and operates in an abstract multi-dimensional parameter space. Our approach relies on constructing a surrogate model that fits and interpolates the available experimental data, and is continuously refined as more data is gathered. The distribution and correlation of the data is used to generate a corresponding uncertainty across the surrogate model. By suggesting follow-up measurements in regions of greatest uncertainty, the algorithm maximally increases knowledge with each added measurement. This procedure is applied repeatedly, with the algorithm iteratively reducing model error and thus efficiently sampling the parameter space with each new measurement that it requests. We validate the method using synthetic data, demonstrating that it converges to faithful replica of test functions more rapidly than competing methods, and demonstrate the viability of the approach in an experimental context by using it to direct autonomous small-angle (SAXS) and grazing-incidence small-angle (GISAXS) x-ray scattering experiments.

36 MATERIALS SCIENCE↗

Architecture for Control of the K9 Rover

Software featuring a multilevel architecture is used to control the hardware on the K9 Rover, which is a mobile robot used in research on robots for scientific exploration and autonomous operation in general. The software consists of five types of modules: Device Drivers - These modules, at the lowest level of the architecture, directly control motors, cameras, data buses, and other hardware devices. Resource Managers - Each of these modules controls several device drivers. Resource managers can be commanded by either a remote operator or the pilot or conditional-executive modules described below. Behaviors and Data Processors - These modules perform computations for such functions as planning paths, avoiding obstacles, visual tracking, and stereoscopy. These modules can be commanded only by the pilot. Pilot - The pilot receives a possibly complex command from the remote operator or the conditional executive, then decomposes the command into (1) more-specific commands to the resource managers and (2) requests for information from the behaviors and data processors. Conditional Executive - This highest-level module interprets a command plan sent by the remote operator, determines whether resources required for execution of the plan are available, monitors execution, and, if necessary, selects an alternate branch of the plan.

Bresina, John L.↗

Email-Based Informed Consent: Innovative Method for Reaching Large Numbers of Subjects for Data Mining Research

Since the 2010 NASA authorization to make the Life Sciences Data Archive (LSDA) and Lifetime Surveillance of Astronaut Health (LSAH) data archives more accessible by the research and operational communities, demand for data has greatly increased. Correspondingly, both the number and scope of requests have increased, from 142 requests fulfilled in 2011 to 224 in 2014, and with some datasets comprising up to 1 million data points. To meet the demand, the LSAH and LSDA Repositories project was launched, which allows active and retired astronauts to authorize full, partial, or no access to their data for research without individual, study-specific informed consent. A one-on-one personal informed consent briefing is required to fully communicate the implications of the several tiers of consent. Due to the need for personal contact to conduct Repositories consent meetings, the rate of consenting has not kept up with demand for individualized, possibly attributable data. As a result, other methods had to be implemented to allow the release of large datasets, such as release of only de-identified data. However the compilation of large, de-identified data sets places a significant resource burden on LSAH and LSDA and may result in diminished scientific usefulness of the dataset. As a result, LSAH and LSDA worked with the JSC Institutional Review Board Chair, Astronaut Office physicians, and NASA Office of General Counsel personnel to develop a "Remote Consenting" process for retrospective data mining studies. This is particularly useful since the majority of the astronaut cohort is retired from the agency and living outside the Houston area. Originally planned as a method to send informed consent briefing slides and consent forms only by mail, Remote Consenting has evolved into a means to accept crewmember decisions on individual studies via their method of choice: email or paper copy by mail. To date, 100 emails have been sent to request participation in eight HRP-funded studies. The development of the Remote Consent process, the laws allowing transmission of consent via electronic means, total metrics to date, and remaining challenges (e.g., response issues, use of International Partner data, biospecimens/genetic data) for the research use of LSAH/LSDA data will be described.

Lee, Lesley R.↗

An Analysis of Peak Wind Speed Data from Collocated Mechanical and Ultrasonic Anemometers

This study focuses on a comparison of peak wind speeds reported by mechanical and ultrasonic anemometers at Cape Canaveral Air Force Station and Kennedy Space Center (CCAFS/KSC) on the east central coast of Florida and Vandenberg Air Force Base (VAFB) on the central coast of California. The legacy mechanical wind instruments on CCAFS/KSC and VAFB weather towers are being changed from propeller-and-vane (CCAFS/KSC) and cup-and-vane (VAFB) sensors to ultrasonic sensors under the Range Standardization and Automation (RSA) program. The wind tower networks on KSC/CCAFS and VAFB have 41 and 27 towers, respectively. Launch Weather Officers, forecasters, and Range Safety analysts at both locations need to understand the performance of the new wind sensors for a myriad of reasons that include weather warnings, watches, advisories, special ground processing operations, launch pad exposure forecasts, user Launch Commit Criteria (LCC) forecasts and evaluations, and toxic dispersion support. The Legacy sensors measure wind speed and direction mechanically. The ultrasonic RSA sensors have no moving parts. Ultrasonic sensors were originally developed to measure very light winds (Lewis and Dover 2004). The technology has evolved and now ultrasonic sensors provide reliable wind data over a broad range of wind speeds. However, because ultrasonic sensors respond more quickly than mechanical sensors to rapid fluctuations in speed, characteristic of gusty wind conditions, comparisons of data from the two sensor types have shown differences in the statistics of peak wind speeds (Lewis and Dover 2004). The 45th Weather Squadron (45 WS) and the 30 WS requested the Applied Meteorology Unit (AMU) to compare data from RSA and Legacy sensors to determine if there are significant differences in peak wind speed information from the two systems.

Short, David A.↗

An Operational Land Imager for the Landsat Data Continuity Mission

The National Aeronautics and Space Administration (NASA) released a request for proposals (RFP) on January 09, 2007 for an Operational Land Imager (OLI). The RFP specified the OLI as the principal sensor for the Landsat Data Continuity Mission (LDCM), the successor mission to Landsat 7. The RFP provides requirements for OLI performance, special calibration tests, and mission assurance without specifying a particular technical design. The performance specifications derive from the heritage and societal benefits of data from the previous Landsat satellites, the high standards set by the performance of the Landsat 7 Enhanced Thematic Mapper-Plus, direction from the Executive Office of the President, cognizance of current technology, and an eye to the future of land remote sensing beyond the LDCM. The specification includes nine spectral bands (four visible, one near infrared, three shortwave infrared, and one panchromatic band), spatial resolution of 30 m with the exception of a 15 m panchromatic resolution, stringent radiometric performance and absolute calibration, and accurate image geolocation with precise band-to-band and multitemporal image-to-image registration. Proposals were due on February 23, 2007 with selection and contract award anticipated by June 2007. The RFP requires delivery of a well-characterized instrument for spacecraft integration within 39 months of contract award. This schedule leads to a target LDCM launch date of July, 2011.

Irons, James R.↗

Vertical Aerosol Profiling during SAIL (VAPS) Field Campaign Report

To more fully address the science goals of the U.S. Department of Energy (DOE) Atmospheric Radiation Measurement (ARM) user facility’s Surface Atmosphere Integrated Field Laboratory (SAIL) campaign, particularly the key science question of “How strongly do aerosols affect the surface energy and water balance by altering clouds, precipitation, and surface albedo, and how do these impacts vary seasonally?”, our campaign added instrumentation to planned tethered balloon system (TBS) flights in May and July of 2022. A key aspect of aerosol-cloud interactions is understanding cloud condensation nuclei (CCN) and ice nucleating particle (INP) populations, and how they vary seasonally and spatially. Because the interactions between aerosols and clouds is the target of this work, vertical distributions are particularly important to evaluate. Measurements of aerosol at ground level, below-cloud, and in-cloud will allow a better understanding of the airmasses that are feeding cloud-active particles into low- and mid-level clouds. Measurements of INP and aerosol populations often differ between the ground and aloft, with relationships that likely depend on regional and seasonal. Because of this, collocated measurements of aerosol, CCN, and INP, across different seasons, are crucial to reducing uncertainties in relationships between ground-level and cloud-base aerosol populations. Our campaign added online measurements of CCN using a compact CCN counter and offline filter collections for measurement of INP populations to the SAIL campaign TBS flights in May and July of 2022. The CCN instrument, the CloudPuck, flew and successfully collected data for a total of eight flights across both campaign periods. The IcePuck flew for most flights during the same period. Both instruments have continued to be used for other campaign requests in the SAIL domain. Analysis of this data was proposed through a concurrent DOE Atmospheric System Research (ASR) project submission, which was not funded in 2022. A similar proposal, which would involve analysis of the samples and data collected from this campaign, has been resubmitted in 2023 but a funding decision has not yet been made. If the proposal is again declined, we will seek other resources to ensure that this data can be analyzed.

54 ENVIRONMENTAL SCIENCES↗

Sharing tuples across independent coordination namespace systems

A system and method for federating a tuple storage database across multiple coordinated namespace (CNS) extended memory storage systems allowing the sharing of tuples and tuple data across independent systems. The method provides a federation service for multiple coordination namespace systems. The method retrieves a tuple from connected independent CNS systems wherein a local CNS Controller sends a read request to the local gatekeeper to retrieve a first tuple and creates a local pending remote record. The local gatekeeper at a requesting node sends a broadcast query to a plurality of remote gatekeepers for the tuple and Remote gatekeepers at remote nodes query in its local CNS for the tuple. The Local gatekeeper process at the requesting node receives results from a plurality of remote gatekeepers for the said tuple and selects one remote gatekeeper to receive the requested tuple and broadcasts a read for tuple data with selected gatekeeper.

Jacob, Philip↗

Driver Identification Dataset

The ORNL Driver Identification Dataset was created to collect and analyze driving behavior data from 50 different drivers. Each driver operated a 2014 Kenworth T270 Class 6 truck around Fort Collins, Colorado while various data sources recorded their driving behavior and vehicle performance. The dataset includes CANbus (Controller Area Network) data, GPS data, inertial measurement data, and biometric data from a heart rate monitor. A cyberattack was executed during each drive, which caused multiple dashboard warning lights to illuminate and set the tachometer and speedometer to zero, regardless of actual speed. The attack was stopped either after one minute or if the driver pulled over. By downloading the dataset, you agree to the following: 1) I will not use or disclose the data for any purpose other than Research as that term is defined in 10 CFR 745.102. 2) I will not, under any circumstances, request or accept private or linking identifiers for the data used. 3) I will not attempt to determine the identity of the individuals associated with the data. 4) I will use appropriate safeguards to prevent the use or disclose of the data for any purpose other than Research.

99 GENERAL AND MISCELLANEOUS↗

Distributed gather/scatter operations across a network of memory nodes

Devices, methods, and systems for distributed gather and scatter operations in a network of memory nodes. A responding memory node includes a memory; a communications interface having circuitry configured to communicate with at least one other memory node; and a controller. The controller includes circuitry configured to receive a request message from a requesting node via the communications interface. The request message indicates a gather or scatter operation, and instructs the responding node to retrieve data elements from a source memory data structure and store the data elements to a destination memory data structure. The controller further includes circuitry configured to transmit a response message to the requesting node via the communications interface. The response message indicates that the data elements have been stored into the destination memory data structure.

97 MATHEMATICS AND COMPUTING↗

Microprogramming for real-time data acquisition

Transmit microcode trap logic is conditioned by preset clock. Measurement request or issuance of command is controlled by set of software-initialized polling tables. Receive microcode trap logic is conditioned by transmit/receive hardware when response is returned on data bus.

Patella, F. J.↗

Analysis of the access patterns at GSFC distributed active archive center

The Goddard Space Flight Center (GSFC) Distributed Active Archive Center (DAAC) has been operational for more than two years. Its mission is to support existing and pre Earth Observing System (EOS) Earth science datasets, facilitate the scientific research, and test Earth Observing System Data and Information System (EOSDIS) concepts. Over 550,000 files and documents have been archived, and more than six Terabytes have been distributed to the scientific community. Information about user request and file access patterns, and their impact on system loading, is needed to optimize current operations and to plan for future archives. To facilitate the management of daily activities, the GSFC DAAC has developed a data base system to track correspondence, requests, ingestion and distribution. In addition, several log files which record transactions on Unitree are maintained and periodically examined. This study identifies some of the users' requests and file access patterns at the GSFC DAAC during 1995. The analysis is limited to the subset of orders for which the data files are under the control of the Hierarchical Storage Management (HSM) Unitree. The results show that most of the data volume ordered was for two data products. The volume was also mostly made up of level 3 and 4 data and most of the volume was distributed on 8 mm and 4 mm tapes. In addition, most of the volume ordered was for deliveries in North America although there was a significant world-wide use. There was a wide range of request sizes in terms of volume and number of files ordered. On an average 78.6 files were ordered per request. Using the data managed by Unitree, several caching algorithms have been evaluated for both hit rate and the overhead ('cost') associated with the movement of data from near-line devices to disks. The algorithm called LRU/2 bin was found to be the best for this workload, but the STbin algorithm also worked well.

Johnson, Theodore↗

The EOSDIS Version 0 Distributed Active Archive Center for physical oceanography and air-sea interaction

The Distributed Active Archive Center (DAAC) at the Jet Propulsion Laboratory will support scientists specializing in physical oceanography and air-sea interaction. As part of the NASA Earth Observing System Data and Information System Version 0 the DAAC will build on existing capabilities to provide services for data product generation, archiving, distribution and management of information about data. To meet scientist's immediate needs for data, existing data sets from missions such as Seasat, Geosat, the NOAA series of satellites and the Global Positioning Satellite system will be distributed to investigators upon request. In 1992, ocean topography, wave and surface roughness data from the Topex/Poseidon radar altimeter mission will be archived and distributed. New data products will be derived from Topex/Poseidon and other sensor systems based on recommendations of the science community. In 1995, ocean wind field measurements from the NASA Scatterometer will be supported by the DAAC.

Hilland, Jeffrey E.↗

Status of the Landsat Data Continuity Mission

Efforts to begin implementing a successor mission to Landsat 7, called the Landsat Data Continuity Mission (LDCM), suffered a set back in 2003. NASA and the Department of Interior (DOI)/U.S. Geological Survey (USGS) currently manage the Landsat Program as an interagency partnership. The two agencies had planned to purchase data meeting LDCM specifications from a privately owned and commercially operated satellite system beginning in March, 2007. This approach represented a departure from the traditional procurement of a government owned and operated satellite system. NASA, however, cancelled a Request-for-Proposals (RFP) for providing the required data after an evaluation of proposals received from private industry. NASA concluded that the proposals failed to meet a key objective and expectation of the RFP, namely, to form a fair and equitable partnership between the Government and private industry. Alternative strategies for implementing an LDCM are now under consideration. The Executive Office of the President formed an interagency working group on the LDCM following the RFP cancellation. The working group is considering other options for implementing a successor system to Landsat 7 consistent with the Land Remote Sensing Policy Act of 1992 (Public Law 102-555). This Act lists four management options for consideration: 1) private sector funding and management; 2) an international consortium; 3) funding and management by the U.S. Government; and 4) a cooperative effort between the US. Government and the private sector. The working group is currently attempting to minimize the risk of a Landsat data gap through development of a strategy that leads to a Landsat 7 successor mission. The selected strategy and the status of the mission will be presented at the Symposium.

Irons, James R.↗

Providing the Persistent Data Storage in a Software Engineering Environment Using Java/COBRA and a DBMS

An investigation was undertaken to build the software foundation for the WHERE (Web-based Hyper-text Environment for Requirements Engineering) project. The TCM (Toolkit for Conceptual Modeling) was chosen as the foundation software for the WHERE project which aims to provide an environment for facilitating collaboration among geographically distributed people involved in the Requirements Engineering process. The TCM is a collection of diagram and table editors and has been implemented in the C++ programming language. The C++ implementation of the TCM was translated into Java in order to allow the editors to be used for building various functionality of the WHERE project; the WHERE project intends to use the Web as its communication back- bone. One of the limitations of the translated software (TcmJava), which militated against its use in the WHERE project, was persistent data management mechanisms which it inherited from the original TCM; it was designed to be used in standalone applications. Before TcmJava editors could be used as a part of the multi-user, geographically distributed applications of the WHERE project, a persistent storage mechanism must be built which would allow data communication over the Internet, using the capabilities of the Web. An approach involving features of Java, CORBA (Common Object Request Broker), the Web, a middle-ware (Java Relational Binding (JRB)), and a database server was used to build the persistent data management infrastructure for the WHERE project. The developed infrastructure allows a TcmJava editor to be downloaded and run from a network host by using a JDK 1.1 (Java Developer's Kit) compatible Web-browser. The aforementioned editor establishes connection with a server by using the ORB (Object Request Broker) software and stores/retrieves data in/from the server. The server consists of a CORBA object or objects depending upon whether the data is to be made persistent on a single server or multiple servers. The CORBA object providing the persistent data server is implemented using the Java progranu-ning language. It uses the JRB to store/retrieve data in/from a relational database server. The persistent data management system provides transaction and user management facilities which allow multi-user, distributed access to the stored data in a secure manner.

Dhaliwal, Swarn S.↗

AESD (Advanced Energy System Design) Records API [SWRs-17-50, 17-51, 17-52]

The Records API (application program interface) for Advanced Energy System Design (AESD) enables software that serves multidimensional record-oriented data to interoperate with software than uses such data. In the context of the Records API, multidimensional data records are simply tuples of real numbers, integers, and character strings, where each data value is tagged by a variable name, according to a pre-defined schema, and each record is assigned a unique integer identifier. Conceptually, these records are isomorphic to rows in a relational database, JSON objects, or key-value maps. Records servers might supply static datasets, sensor measurements that periodically update as new telemetry become available, or the results of simulations as the simulations generate new output. Records client software might display or analyze the data, but in the case of simulations the client request the creation of new ensembles for specified input parameters. It is also possible to chain records clients and servers together so that a client consuming data from a server might transform that data and serve it to additional clients. This minimalist API avoids imposing burdensome metadata, structural, or implementation requirements on developers by relying on open-source technologies that are readily available for common programming languages. In particular, the API has been designed to place the least possible burden on services that provide data. This document defines the message format for the Records API, a transport mechanism for communicating the data, and the semantics for interpreting it. The message format is specified as Google Protocol Buffers and the transport mechanism uses WebSockets. We discuss three major use cases for serving and consuming records data: (i) static data, (ii) dynamically augmented data, (iii) on-demand simulations, (iv) with filters, and (v) with bookmarks. Separate implementations of the API exist in C++, Haskell, JavaScript, Python, and R.

Bush, Brian↗