Engineering PapersSearch

SEARCH · Engineering Papers

Results for “log file analysis”

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 19 records

TraceContract

TraceContract is an API (Application Programming Interface) for trace analysis. A trace is a sequence of events, and can, for example, be generated by a running program, instrumented appropriately to generate events. An event can be any data object. An example of a trace is a log file containing events that a programmer has found important to record during a program execution. Trace - Contract takes as input such a trace together with a specification formulated using the API and reports on any violations of the specification, potentially calling code (reactions) to be executed when violations are detected. The software is developed as an internal DSL (Domain Specific Language) in the Scala programming language. Scala is a relatively new programming language that is specifically convenient for defining such internal DSLs due to a number of language characteristics. This includes Scala s elegant combination of object-oriented and functional programming, a succinct notation, and an advanced type system. The DSL offers a combination of data-parameterized state machines and temporal logic, which is novel. As an extension of Scala, it is a very expressive and convenient log file analysis framework.

Kavelund, Klaus

TraceContract: A Scala DSL for Trace Analysis

In this paper we describe TRACECONTRACT, an API for trace analysis, implemented in the SCALA programming language. We argue that for certain forms of trace analysis the best weapon is a high level programming language augmented with constructs for temporal reasoning. A trace is a sequence of events, which may for example be generated by a running program, instrumented appropriately to generate events. The API supports writing properties in a notation that combines an advanced form of data parameterized state machines with temporal logic. The implementation utilizes SCALA's support for defining internal Domain Specific Languages (DSLs). Furthermore SCALA's combination of object oriented and functional programming features, including partial functions and pattern matching, makes it an ideal host language for such an API.

log file analysis

Analysis of the request patterns to the NSSDC on-line archive

NASA missions, both for earth science and for space science, collect huge amounts of data, and the rate at which data is being gathered is increasing. For example, the EOSDIS project is expected to collect petabytes per year. In addition, these archives are being made available to remote users over the Internet. The ability to manage the growth of the size and request activity of scientific archives depends on an understanding of the access patterns of scientific users. The National Space Science Data Center (NSSDC) of NASA Goddard Space Flight Center has run their on-line mass storage archive of space data, the National Data Archive and Distribution Service (NDADS), since November 1991. A large world-wide space research community makes use of NSSDC, requesting more than 20,000 files per month. Since the initiation of their service, they have maintained log files which record all accesses the archive. In this report, we present an analysis of the NDADS log files. We analyze the log files, and discuss several issues, including caching, reference patterns, clustering, and system loading.

Johnson, Theodore

Checking Flight Rules with TraceContract: Application of a Scala DSL for Trace Analysis

Typically during the design and development of a NASA space mission, rules and constraints are identified to help reduce reasons for failure during operations. These flight rules are usually captured in a set of indexed tables, containing rule descriptions, rationales for the rules, and other information. Flight rules can be part of manual operations procedures carried out by humans. However, they can also be automated, and either implemented as on-board monitors, or as ground based monitors that are part of a ground data system. In the case of automated flight rules, one considerable expense to be addressed for any mission is the extensive process by which system engineers express flight rules in prose, software developers translate these requirements into code, and then both experts verify that the resulting application is correct. This paper explores the potential benefits of using an internal Scala DSL for general trace analysis, named TRACECONTRACT, to write executable specifications of flight rules. TRACECONTRACT can generally be applied to analysis of for example log files or for monitoring executing systems online.

temporal logic

DE-FE0029488 - North Dakota Integrated Carbon Capture and Storage Complex Feasibility Study Public Data

Data from award DE-FE0029488 - North Dakota Integrated Carbon Capture and Storage Complex Feasibility Study performed by the Energy & Environmental Research Center including the following: - 2D Seismic {Input data, sgy files, maps, logs, and descriptors} - Core Petrophysics {Core analysis of plugs from the two stratigraphic test wells (Flemmer-1 [API 33-057-00039] and BNI-1 [API 33-065-00018])} - North Dakota Oil and Gas File No 37380 Files - North Dakota Oil and Gas File No 37672 Files - Well Testing Data {Summary of well testing methods and results from the stratigraphic test wells (Flemmer-1 and BNI-1)} Additional References: https://www.netl.doe.gov/sites/default/files/2017-12/Wesley-Peck-_Mastering-the-Subsurface_CarbonSAFE-Phase-II_August-2017-final.pdf Peck, W.D., Ayash, S.C., Klapperich, R.J., Gorecki, C.D. (2019) The North Dakota integrated carbon storage complex feasibility study, International Journal of Greenhouse Gas Control, Volume 84, 2019, Pages 47-53, https://doi.org/10.1016/j.ijggc.2019.03.001

Carbon Storage

Discrete event simulation tool for analysis of qualitative models of continuous processing systems

An artificial intelligence design and qualitative modeling tool is disclosed for creating computer models and simulating continuous activities, functions, and/or behavior using developed discrete event techniques. Conveniently, the tool is organized in four modules: library design module, model construction module, simulation module, and experimentation and analysis. The library design module supports the building of library knowledge including component classes and elements pertinent to a particular domain of continuous activities, functions, and behavior being modeled. The continuous behavior is defined discretely with respect to invocation statements, effect statements, and time delays. The functionality of the components is defined in terms of variable cluster instances, independent processes, and modes, further defined in terms of mode transition processes and mode dependent processes. Model construction utilizes the hierarchy of libraries and connects them with appropriate relations. The simulation executes a specialized initialization routine and executes events in a manner that includes selective inherency of characteristics through a time and event schema until the event queue in the simulator is emptied. The experimentation and analysis module supports analysis through the generation of appropriate log files and graphics developments and includes the ability of log file comparisons.

Malin, Jane T.

SOHO Ultraviolet Coronagraph Spectrometer (UVCS) Mission Operations and Data Analysis

The scientific goal of UVCS is to obtain detailed empirical descriptions of the extended solar corona as it evolves over the solar cycle and to use these descriptions to identify and understand the physical processes responsible for coronal heating, solar wind acceleration, coronal mass ejections (CMEs), and the phenomena that establish the plasma properties of the solar wind as measured by 'in situ' solar wind instruments. This report covers the period from 01 February 2002 to 15 February 2003. During that time, UVCS observations have consisted of three types: 1) standard synoptic observations comprising, primarily, the H I Ly alpha line profile and the O VI 103.2 and 103.7 nm intensity over a range of heights from 1.5 to about 3.0 solar radii and covering 360 degrees about the sun, 2) sit and stare watches for CMEs, and 3) special observations designed by the UVCS Lead Observer of the Week for a specific scientific purpose. The special observations are often coordinated with those of other space-based and ground-based instruments and they often are part of SOHO joint observation programs and campaigns. Lead observers have included UVCS Co-Investigators, scientists from the solar physics community and several graduate and undergraduate level students. UVCS has continued to achieve its purpose of using powerful spectroscopic diagnostic techniques to obtain a much more detailed description of coronal structures and dynamic phenomena than existed before the SOHO mission. The new descriptions of coronal mass ejections (CMEs) and coronal structures from UVCS have inspired a large number of theoretical studies aimed at identifying the physical processes responsible for CMEs and solar wind acceleration in coronal holes and streamers. UVCS has proven to be a very stable instrument. Stellar observations have demonstrated its stability. UVCS has required no flight software modifications and all mechanisms are operational. The UVCS O VI Channel with its redundant optical path for wavelengths near H I Ly alpha is capable of observing the entire UVCS wavelength range. Since December 1998, the O VI Channel has been used for all UVCS observations. Although the H I Ly alpha Channel and detector are still operational, increases in the dark count up to about 5 x 10(exp -4) counts/sec/pixel and an increase in high voltage current to within a factor of two of the maximum used in the laboratory before flight led to the decision to not use that detector at the present time. There is no significant decrease in the scientific capability of UVCS owing to the O VI channel redundant optical path. UVCS data, data analysis software, calibration files and the mission log are available from the SOHO archive and SAO. All UVCS data is now available to scientists and the general public via the SOHO Data Archive and SAO within three months of the observations. UVCS has resulted in 46 scientific papers in 2002. There were numerous presentations at scientific meetings. All requests for observation time by qualified outside users have been granted.

Kohl, John L.

SOHO Ultraviolet Coronagraph Spectrometer (UVCS) Mission Operations and Data Analysis

The scientific goal of UVCS is to obtain detailed empirical descriptions of the extended solar corona as it evolves over the solar cycle and to use these descriptions to identify and understand the physical processes responsible for coronal heating, solar wind acceleration, coronal mass ejections (CMEs), and the phenomena that establish the plasma properties of the solar wind as measured by "in situ" solar wind instruments. This report covers the period from 15 February 2003 to 14 April 2004. During that time, UVCS observations have consisted of three types: 1) standard synoptic observations comprising, primarily, the H I Lyalpha line profile and the 0 VI 103.2 and 103.7 nm intensity over a range of heights from 1.5 to about 3.0 solar radii and covering 360 degrees about the Sun, 2) sit and stare observations for major flare watches, and 3) special observations designed by the UVCS Lead Observer of the Week for a specific scientific purpose. The special observations are often coordinated with those of other space-based and ground-based instruments and they often are part of SOHO joint observation programs and campaigns. Lead observers have included UVCS Co-Investigators, scientists from the solar physics community and several graduate and undergraduate level students. UVCS has continued to achieve its purpose of using powerful spectroscopic diagnostic techniques to obtain a much more detailed description of coronal structures and dynamic phenomena than existed before the SOHO mission. The new descriptions of coronal mass ejections (CMEs) and coronal structures from UVCS have inspired a large number of theoretical studies aimed at identifying the physical processes responsible for CMEs and solar wind acceleration in coronal holes and streamers. UVCS has proven to be a very stable instrument. Stellar observations have demonstrated its radiometric stability. UVCS has not required any flight software modifications and all mechanisms are operational. The UVCS 0 VI Channel with its redundant optical path for wavelengths near H I Lyalpha is capable of observing the entire UVCS wavelength range. The regions of the detector currently being used require different grating angles for direct OVI observations and redundant path H I Lyalpha observations, and so those can no longer be observed simultaneously. Since December 1998, the 0 VI Channel has been used for all UVCS observations. Although the H I Lyalpha Channel and detector are still operational, increases in the dark count up to about 5x10(exp 4) counts/sec/pixel and an increase in high voltage current to within a factor of two of the maximum used in the laboratory before flight led to the decision to not use that detector after 1998. The visible light channel functioned nominally during the reporting period. UVCS data, data analysis software, calibration files and the mission log are available from the SOHO archive and SAO. All UVCS data are now available within three months of the observations to scientists and the general public via the SOHO Data Archive and SAO. UVCS has resulted in 33 scientific papers in 2003. There were numerous presentations at scientific meetings. UVCS Education and Public Outreach activities involved nine members of the UVCS team. During the reporting period, there were over a dozen events directed at students and teachers, museum audiences, and public audiences via the mass media, internet and educational literature.

Gurman, Joseph

Improved performance in NASTRAN (R)

Three areas of improvement in COSMIC/NASTRAN, 1989 release, were incorporated recently that make the analysis program run faster on large problems. Actual log files and actual timings on a few test samples that were run on IBM, CDC, VAX, and CRAY computers were compiled. The speed improvement is proportional to the problem size and number of continuation cards. Vectorizing certain operations in BANDIT, makes BANDIT run twice as fast in some large problems using structural elements with many node points. BANDIT is a built-in NASTRAN processor that optimizes the structural matrix bandwidth. The VAX matrix packing routine BLDPK was modified so that it is now packing a column of a matrix 3 to 9 times faster. The denser and bigger the matrix, the greater is the speed improvement. This improvement makes a host of routines and modules that involve matrix operation run significantly faster, and saves disc space for dense matrices. A UNIX version, converted from 1988 COSMIC/NASTRAN, was tested successfully on a Silicon Graphics computer using the UNIX V Operating System, with Berkeley 4.3 Extensions. The Utility Modules INPUTT5 and OUTPUT5 were expanded to handle table data, as well as matrices. Both INPUTT5 and OUTPUT5 are general input/output modules that read and write FORTRAN files with or without format. More user informative messages are echoed from PARAMR, PARAMD, and SCALAR modules to ensure proper data values and data types being handled. Two new Utility Modules, GINOFILE and DATABASE, were written for the 1989 release. Seven rigid elements are added to COSMIC/NASTRAN. They are: CRROD, CRBAR, CRTRPLT, CRBE1, CRBE2, CRBE3, and CRSPLINE.

Chan, Gordon C.

ILRS Station Reporting

Network stations provided system configuration documentation upon joining the ILRS. This information, found in the various site and system log files available on the ILRS website, is essential to the ILRS analysis centers, combination centers, and general user community. Therefore, it is imperative that the station personnel inform the ILRS community in a timely fashion when changes to the system occur. This poster provides some information about the various documentation that must be maintained. The ILRS network consists of over fifty global sites actively ranging to over sixty satellites as well as five lunar reflectors. Information about these stations are available on the ILRS website (http://ilrs.gsfc.nasa.gov/network/stations/index.html). The ILRS Analysis Centers must have current information about the stations and their system configuration in order to use their data in generation of derived products. However, not all information available on the ILRS website is as up-to-date as necessary for correct analysis of their data.

satellites

Contamination Analysis Tools

This talk presents 3 different tools developed recently for contamination analysis:HTML QCM analyzer: runs in a web browser, and allows for data analysis of QCM log filesJava RGA extractor: can load in multiple SRS.ana files and extract pressure vs. time dataC++ Contamination Simulation code: 3D particle tracing code for modeling transport of dust particulates and molecules. Uses residence time to determine if molecules stick. Particulates can be sampled from IEST-STD-1246 and be accelerated by aerodynamic forces.

Automated Test Systems for Toxic Vapor Detectors

The NASA Toxic Vapor Detection Laboratory (TVDL) at the Kennedy Space Center (KSC), Florida, has been using Personal Computer based Data Acquisition and Control Systems (PCDAS) for about nine years. These systems control the generation of toxic vapors of known concentrations under controlled conditions of temperature and humidity. The PCDAS also logs the test conditions and the test article responses in data files for analysis by standard spreadsheets or custom programs. The PCDAS was originally developed to perform standardized qualification and acceptance tests in a search for a commercial off-the-shelf (COTS) toxic vapor detector to replace the hydrazine detectors for the Space Shuttle launch pad. It has since become standard test equipment for the TVDL and is indispensable in producing calibration standards for the new hydrazine monitors at the 10 part per billion (ppb) level. The standard TVDL PCDAS can control two toxic vapor generators (TVG's) with three channels each and two flow/temperature/humidity (FIFH) controllers and it can record data from up to six toxic vapor detectors (TVD's) under test and can deliver flows from 5 to 50 liters per minute (L/m) at temperatures from near zero to 50 degrees Celsius (C) using an environmental chamber to maintain the sample temperature. The concentration range for toxic vapors depends on the permeation source installed in the TVG. The PCDAS can provide closed loop control of temperature and humidity to two sample vessels, typically one for zero gas and one for the standard gas. This is required at very low toxic vapor concentrations to minimize the time required to passivate the sample delivery system. Recently, there have been several requests for information about the PCDAS by other laboratories with similar needs, both on and off KSC. The purpose of this paper is to inform the toxic vapor detection community of the current status and planned upgrades to the automated testing of toxic vapor detectors at the Kennedy Space Center.

Mattson, C. B.

Automated Test Systems for Toxic Vapor Detectors

The NASA Toxic Vapor Detection Laboratory (TVDL) at the Kennedy Space Center (KSC), Florida, has been using Personal Computer based Data Acquisition and Control Systems (PCDAS) for about nine years. These systems control the generation of toxic vapors of known concentrations under controlled conditions of temperature and humidity. The PCDAS also logs the test conditions and the test article responses in data files for analysis by standard spreadsheets or custom programs. The PCDAS was originally developed to perform standardized qualification and acceptance tests in a search for a commercial off-the-shelf (COTS) toxic vapor detector to replace the hydrazine detectors for the Space Shuttle launch pad. It has since become standard test equipment for the TVDL and is indispensable in producing calibration standards for the new hydrazine monitors at the 10 part per billion (ppb) level. The standard TVDL PCDAS can control two toxic vapor generators (TVG's) with three channels each and two flow/ temperature / humidity (FTH) controllers and it can record data from up to six toxic vapor detectors (TVD's) under test and can deliver flows from 5 to 50 liters per minute (L/m) at temperatures from near zero to 50 degrees Celsius (C) using an environmental chamber to maintain the sample temperature. The concentration range for toxic vapors depends on the permeation source installed in the TVG. The PCDAS can provide closed loop control of temperature and humidity to two sample vessels, typically one for zero gas and one for the standard gas. This is required at very low toxic vapor concentrations to minimize the time required to passivate the sample delivery system. Recently, there have been several requests for information about the PCDAS by other laboratories with similar needs, both on and off KSC. The purpose of this paper is to inform the toxic vapor detection community of the current status and planned upgrades to the automated testing of toxic vapor detectors at the Kennedy Space Center.

Mattson, C. B.

Web-Enabled Optoelectronic Particle-Fallout Monitor

A Web-enabled optoelectronic particle- fallout monitor has been developed as a prototype of future such instruments that (l) would be installed in multiple locations for which assurance of cleanliness is required and (2) could be interrogated and controlled in nearly real time by multiple remote users. Like prior particle-fallout monitors, this instrument provides a measure of particles that accumulate on a surface as an indication of the quantity of airborne particulate contaminants. The design of this instrument reflects requirements to: Reduce the cost and complexity of its optoelectronic sensory subsystem relative to those of prior optoelectronic particle fallout monitors while maintaining or improving capabilities; Use existing network and office computers for distributed display and control; Derive electric power for the instrument from a computer network, a wall outlet, or a battery; Provide for Web-based retrieval and analysis of measurement data and of a file containing such ancillary data as a log of command attempts at remote units; and Use the User Datagram Protocol (UDP) for maximum performance and minimal network overhead.

Lineberger, Lewis 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

DKRZ workload analysis

The UniTree product as it is released emits a rather large amount of logging information into various log files, but this data typically is meant for operator information in difficult operational situations or directly for debugging purposes. It is strongly advised that the existing logging functionality in the standard release is advanced by adding messages with relevant parameters for every major event in the course of executing file or device oriented requests as described. This upgrade would be relatively easy in terms of implementation effort. The benefit is a complete sequence of transaction descriptions generated by external user requests or by internal administration commands. This collection of transaction records can be used for intensive statistics and performance evaluations. It is furthermore a perfect source to drive realistic system simulations to study the effects of possible hardware or software changes.

Fichter, Hartmut

PKI solar thermal plant evaluation at Capitol Concrete Products, Topeka, Kansas

A system feasibility test to determine the technical and operational feasibility of using a solar collector to provide industrial process heat is discussed. The test is of a solar collector system in an industrial test bed plant at Capitol Concrete Products in Topeka, Kansas, with an experiment control at Sandia National Laboratories, Albuquerque. Plant evaluation will occur during a year-long period of industrial utilization. It will include performance testing, operability testing, and system failure analysis. Performance data will be recorded by a data acquisition system. User, community, and environmental inputs will be recorded in logs, journals, and files. Plant installation, start-up, and evaluation, are anticipated for late November, 1981.

Hauger, J. S.

Concentration-Discharge Relationships in the Six Largest Arctic Rivers, 2003-2019

This dataset provides the results of the analysis of the relationship of dissolved analyte concentrations and river discharges in the six largest Arctic rivers across the global panarctic region (see Figure 1 in documentation file *.pdf). Long-term measurements of dissolved analyte concentrations and river discharge have been collected for each of the Kolyma, Lena, Mackenzie, Ob, Yenisey, and Yukon rivers by the Arctic Great Rivers Observatory (ArcticGRO) project from ~2003-present (Shiklomanov, 2021). The relationship of dissolved analyte concentrations and discharges in each river was characterized by statistical analysis of the slope of the log(concentration) vs log(discharge) (b), the coefficient of variation ratio (CVc/CVq), the 2.5% and 97.5% confidence intervals of b, and assigning a chemostatic, flushing, diluting, or non-systematic behavior category according to Koger (2018). The summary of these analyses for all six rivers is provided in one .csv file. The concentrations of 20 dissolved analytes and discharge measurement data for the individual Kolyma, Lena, Mackenzie, Ob, Yenisey, and Yukon rivers are also provided with this dataset. There are seven *.csv files; one for each river plus the statistical summary. These public ArcticGRO data at "https://www.arcticgreatrivers.org" (Shiklomanov, 2021) were downloaded on Feb 13, 2020, but each river has different measurement dates over the sampling and analysis period. The ArcticGRO metadata document (*.pdf) downloaded on Feb 13, 2020 is also included in this dataset. The Next-Generation Ecosystem Experiments: Arctic (NGEE Arctic), was a research effort to reduce uncertainty in Earth System Models by developing a predictive understanding of carbon-rich Arctic ecosystems and feedbacks to climate. NGEE Arctic was supported by the Department of Energy's Office of Biological and Environmental Research. The NGEE Arctic project had two field research sites: 1) located within the Arctic polygonal tundra coastal region on the Barrow Environmental Observatory (BEO) and the North Slope near Utqiagvik (Barrow), Alaska and 2) multiple areas on the discontinuous permafrost region of the Seward Peninsula north of Nome, Alaska. Through observations, experiments, and synthesis with existing datasets, NGEE Arctic provided an enhanced knowledge base for multi-scale modeling and contributed to improved process representation at global pan-Arctic scales within the Department of Energy's Earth system Model (the Energy Exascale Earth System Model, or E3SM), and specifically within the E3SM Land Model component (ELM).

54 ENVIRONMENTAL SCIENCES