Engineering PapersSearch

SEARCH · Engineering Papers

Results for “coding standards”

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 37 records · Page 2

Code Sharing and Collaboration: Experiences from the Scientist's Expert Assistant Project and their Relevance to the Virtual Observatory

In the Virtual Observatory (VO), software tools will perform the functions that have traditionally been performed by physical observatories and their instruments. These tools will not be adjuncts to VO functionality but will make up the very core of the VO. Consequently, the tradition of observatory and system independent tools serving a small user base is not valid for the VO. For the VO to succeed, we must improve software collaboration and code sharing between projects and groups. A significant goal of the Scientist's Expert Assistant (SEA) project has been promoting effective collaboration and code sharing between groups. During the past three years, the SEA project has been developing prototypes for new observation planning software tools and strategies. Initially funded by the Next Generation Space Telescope, parts of the SEA code have since been adopted by the Space Telescope Science Institute. SEA has also supplied code for SOFIA, the SIRTF planning tools, and the JSky Open Source Java library. The potential benefits of sharing code are clear. The recipient gains functionality for considerably less cost. The provider gains additional developers working with their code. If enough users groups adopt a set of common code and tools, defacto standards can emerge (as demonstrated by the success of the FITS standard). Code sharing also raises a number of challenges related to the management of the code. In this talk, we will review our experiences with SEA - both successes and failures - and offer some lessons learned that may promote further successes in collaboration and re-use.

Jones, Jeremy

IPHE Regulations Codes and Standards Working Group - Type IV COPV Round Robin Testing

This manuscript presents the results of a multi-lateral international activity intended to understand how to execute a cycle stress test as specified in a chosen standard (GTR, SAE, ISO, EIHP...). The purpose of this work was to establish a harmonized test method protocol to ensure that the same results would be achieved regardless of the testing facility. It was found that accurate temperature measurement of the working fluid is necessary to ensure the test conditions remain within the tolerances specified. Continuous operation is possible with adequate cooling of the working fluid but this becomes more demanding if the cycle frequency increases. Recommendations for future test system design and operation are presented.

Maes, M.

Method of Test for Evaluating Building Performance Simulation Software

ANSI/ASHRAE Standard 140 Method of Test for Evaluating Building Performance Simulation Software specifies the method to test the core competency of building performance simulation (BPS) software, a broad class of software which includes building energy modeling (BEM) software. Standard 140 has been widely used by BEM software vendors to help diagnose and compare the results from the program with other modeling programs. The Standard is also referenced by codes, standards, government programs, and other incentive programs as a part of minimum requirements for qualifying BEM software. The explanatory information, summary tables and figures in this 140 User’s Manual (referred to as “this Manual”) are provided to help users in implementing various suites of tests specified in Standard 140-2023 (referred to in this manual as “Standard 140” or “the Standard”).

97 MATHEMATICS AND COMPUTING

Code Sharing and Collaboration: Experiences From the Scientist's Expert Assistant Project and Their Relevance to the Virtual Observatory

In the Virtual Observatory (VO), software tools will perform the functions that have traditionally been performed by physical observatories and their instruments. These tools will not be adjuncts to VO functionality but will make up the very core of the VO. Consequently, the tradition of observatory and system independent tools serving a small user base is not valid for the VO. For the VO to succeed, we must improve software collaboration and code sharing between projects and groups. A significant goal of the Scientist's Expert Assistant (SEA) project has been promoting effective collaboration and code sharing among groups. During the past three years, the SEA project has been developing prototypes for new observation planning software tools and strategies. Initially funded by the Next Generation Space Telescope, parts of the SEA code have since been adopted by the Space Telescope Science Institute. SEA has also supplied code for the SIRTF (Space Infrared Telescope Facility) planning tools, and the JSky Open Source Java library. The potential benefits of sharing code are clear. The recipient gains functionality for considerably less cost. The provider gains additional developers working with their code. If enough users groups adopt a set of common code and tools, de facto standards can emerge (as demonstrated by the success of the FITS standard). Code sharing also raises a number of challenges related to the management of the code. In this talk, we will review our experiences with SEA--both successes and failures, and offer some lessons learned that might promote further successes in collaboration and re-use.

Korathkar, Anuradha

Advanced Manufactured Home Case Study: A Collaboration for High-Efficiency, Affordable Housing

The introduction of Zero Energy Ready Home Manufactured Homes (ZERH MH) qualification for manufactured homes has generated significant attention and interest in the industry to employ advanced manufacturing techniques. VEIC engaged with Titan Homes to create an advanced manufactured home design that employs ZERH standards, other client-driven above-code standards, and manufacturing processes improvements. This case study identifies specific energy-efficient and quality improvement measures that were implemented to achieve certification and take advantage of incentives for home manufacturers.

14 SOLAR ENERGY

Building Performance Standards and Energy Code Alignment - Technical Brief

Building energy codes focus on building design, construction and renovation and have significantly increased building efficiency since the first national energy code was published in 1975. Most jurisdictions have energy codes based on ANSI/ASHRAE/IES Standard 90.1 (hereto referred to as Standard 90.1) and the International Energy Conservation Code (IECC). Compliance options available in these model energy codes include a prescriptive path, whole building performance paths – including IECC Total Building Performance (TBP), Standard 90.1 Energy Cost Budget (ECB) method and Performance Rating Method (PRM) – and system performance paths for envelope and heating, ventilation, and air-conditioning systems. Building performance standard (BPS) policies are an emerging policy tool used by jurisdictions to reduce the operational energy use or greenhouse gas (GHG) emissions of the existing commercial building stock. BPS policies vary widely between jurisdictions and are tailored to each location’s climate and energy goals. Intuitively, projects that met a recent edition of the energy code should comply with the BPS targets. However, some new buildings may struggle with meeting the BPS for the following reasons: 1. Energy codes focus on the design of the building and its projected ability to perform efficiently, while BPS compliance is dependent on the actual ongoing performance of the building, considering variables like occupancy, operation, and maintenance. 2. There are significant differences in the methodologies used to determine BPS compliance versus code compliance, including how each handles compliance metrics, handling of building amenities, and renewable energy generation. 3. The prescriptive compliance path in the energy code is based on performance of individual building components, as opposed to the performance compliance path which accounts for holistic building design strategies and interdependent building systems. This can result in a significant variability in post-occupancy performance for buildings built using the prescriptive path. Designs on the lower end of the permitted efficiency range may struggle with meeting the BPS.

32 ENERGY CONSERVATION, CONSUMPTION, AND UTILIZATI

GCAS Visualization Codebase Augmentation Migration to Modern Standards and Feature Enhancements

The Glenn Research Center Communication Analysis Suite (GCAS) includes many analysis tools that can be used to support a wide range of scenarios. It includes a visualization tool that implements the three.js graphics library to display a three-dimensional (3D) representation of its results. This software will enable researchers, engineers, and mission planners to interact intuitively with and understand the results of their analyses, which might not be apparent from raw data. With NASA’s efforts to return humans to the Moon as a part of the Artemis missions, the GCAS has been used extensively for lunar terrain and landing system development analysis, which is vital to ensuring mission achievability and safety. This has created the need to add several significant features to the visualization tool, such as the ability to display the terrain of the lunar surface accurately and to provide information demonstrating how a given region might impact mission objectives. Many of the changes made to the visualization tool can be separated into one of three general advancements: code restructuring to adhere to modern coding standards and practices, new user camera controls for first-person and third-person perspective views, and a terrain generation feature to enable rendering highly accurate terrains based on any celestial body’s digital elevation model (DEM) in GeoTIFF format. These improvements notably elevate the visualization tool's functionality, accuracy, and user interaction while providing a robust foundation for future development.

Visualization

International standards activities in image data compression

Integrated Services Digital Network (ISDN); coding for color TV, video conferencing, video conferencing/telephone, and still color images; ISO color image coding standard; and ISO still picture standard are briefly discussed. This presentation is represented by viewgraphs only.

Haskell, Barry

Coordinated design of coding and modulation systems

The joint optimization of the coding and modulation systems employed in telemetry systems was investigated. Emphasis was placed on formulating inner and outer coding standards used by the Goddard Spaceflight Center. Convolutional codes were found that are nearly optimum for use with Viterbi decoding in the inner coding of concatenated coding systems. A convolutional code, the unit-memory code, was discovered and is ideal for inner system usage because of its byte-oriented structure. Simulations of sequential decoding on the deep-space channel were carried out to compare directly various convolutional codes that are proposed for use in deep-space systems.

Massey, J. L.

Multi-mode modem/codec designs

The design of an integrated modem/codec unit which can receive coded and uncoded BPSK an QPSK using de facto standard coding schemes as well as 8PSK-TCM and 16PSK-TCM is examined. The design is totally compatible with today's modulation schemes and capable of processing tomorrow's TCM codes. This is accomplished in the modem by using quadrature channel carrier recovery processing and a version of the MAP phase detector algorithm. The symbol synchronization is accomplished with a derivative of an early-late gate designed to accommodate multilevel signals.

Osborne, William

Field and Model Data Associated with the Manuscript “Drivers of Streamflow Intermittency in Humid Regions: 2. Evaluating Controls on Flow Persistence in an Urbanized Catchment”

This package contains field data, modeling files, and scripts supporting the investigation of the drivers of streamflow intermittency in an urbanized catchment. It includes the field data collected from electrical resistivity tomography (ERT) surveys, distributed temperature sensing (DTS), continuous self-potential (SP) monitoring, groundwater and stilling well. In addition, it contains the data and results of the coupled water- and electrical-flow model developed using the COMSOL Multiphysics and Advanced Terrestrial Simulator (ATS), as well as software files and Jupyter notebooks used to process the data and generate figures in the manuscript submitted for peer review. The data archive is organized in the following directories: 1) Climate Includes hourly precipitation and daily evapotranspiration time series (2024 – 2025) provided as CSV files, alongside a text file detailing dataset units. 2) Coupled_model Field_Application subfolder contains the ATS XML input scripts, data files, output data for the SP site. It also contains the Jupyter notebook (Plot_final_calib.ipynb) to visualize the results of the modeled SP, stream-groundwater exchange and moisture content. The flow model simulation is executed using the ATS XML scripts and the included Python script (generate_data_set.py) to convert ATS output to COMSOL-ready input. COMSOL Multiphysics template (.m can only be used with COMSOL with MATLAB) is executed using the ATS output data to simulate the potential field. 3) Discharge Includes the electrical conductivity (EC) time series (provided as CSV files) from salt slug injections. It also includes the Jupyter notebook (Discharge_process.ipynyb) used to estimate discharge. All discharge measurements collated into rating_curve_processed.csv 4) DTS Contains collated DTS data including raw Stokes and anti-Stokes measurement (provided as .h5 file). It also includes DTS processing.ipynb, a Jupyter notebook for calibrating the DTS data using dts_calibration Python package. cooler_calibration.csv is the DTS calibration CSV used in the calibration sequence. 5) ERT Contains raw resistivity data (provided as CSV files), spatial location of each of the electrodes (provided as CSV files), and files used for the resistivity inversion. 6) Slug_test Includes the slug test data at all the groundwater wells provided as CSV files, as well as the Jupyter notebook (Slug_test.ipynb) for calculating hydraulic conductivity. 7) SP Contains the SP data collected in field at the SP sites (provided as CSV files). 8) Well_data Contains two subfolders: 1) Raw, which provides unprocessed pressure, electrical conductivity and temperature timeseries downloaded from the loggers in all the groundwater and stilling wells, and 2) Processed, which contains sorted, QA/QC timeseries data for each well. The data archive also contains data_process.ipynb, a Jupyter notebook used for field data analysis and generating figures (plotting well, SP, climate, and discharge data, as well as calculating head gradient at sites with nested groundwater wells). Note: Code files (.ipynb, .py, .xml) can be opened in any standard code editor, .exo file can be viewed using Paraview, .h5 files can be opened using HDFView software and h5py Python package, and .resipy file can be opened with the open-source ResIPy software.

ATS

Time synchronized video systems

The idea of synchronizing multiple video recordings to some type of 'range' time has been tried to varying degrees of success in the past. Combining this requirement with existing time code standards (SMPTE) and the new innovations in desktop multimedia however, have afforded an opportunity to increase the flexibility and usefulness of such efforts without adding costs over the traditional data recording and reduction systems. The concept described can use IRIG, GPS or a battery backed internal clock as the master time source. By converting that time source to Vertical Interval Time Code or Longitudinal Time Code, both in accordance with the SMPTE standards, the user will obtain a tape that contains machine/computer readable time code suitable for use with editing equipment that is available off-the-shelf. Accuracy on playback is then determined by the playback system chosen by the user. Accuracies of +/- 2 frames are common among inexpensive systems and complete frame accuracy is more a matter of the users' budget than the capability of the recording system.

Burnett, Ron

An experiment to assess the cost-benefits of code inspections in large scale software development

This experiment (currently in progress) is designed to measure costs and benefits of different code inspection methods. It is being performed with a real development team writing software for a commercial product. The dependent variables for each code unit's inspection are the elapsed time and the number of defects detected. We manipulate the method of inspection by randomly assigning reviewers, varying the number of reviewers and the number of teams, and, when using more than one team, randomly assigning author repair and non-repair of detected defects between code inspections. After collecting and analyzing the first 17 percent of the data, we have discovered several interesting facts about reviewers, about the defects recorded during reviewer preparation and during the inspection collection meeting, and about the repairs that are eventually made. (1) Only 17 percent of the defects that reviewers record in their preparations are true defects that are later repaired. (2) Defects recorded at the inspection meetings fall into three categories: 18 percent false positives requiring no author repair, 57 percent soft maintenance where the author makes changes only for readability or code standard enforcement, and 25 percent true defects requiring repair. (3) The median elapsed calendar time for code inspections is 10 working days - 8 working days before the collection meeting and 2 after. (4) In the collection meetings, 31 percent of the defects discovered by reviewers during preparation are suppressed. (5) Finally, 33 percent of the true defects recorded are discovered at the collection meetings and not during any reviewer's preparation. The results to date suggest that inspections with two sessions (two different teams) of two reviewers per session (2sX2p) are the most effective. These two-session inspections may be performed with author repair or with no author repair between the two sessions. We are finding that the two-session, two-person with repair (2sX2pR) inspections are the most expensive, taking 15 working days of calendar time from the time the code is ready for review until author repair is complete, whereas two-session, two-person with no repair (2sX2pN) inspections take only 10 working days, but find about 10 percent fewer defects.

Porter, A.

GCS programmer's manual

A variety of instructions to be used in the development of implementations of software for the Guidance and Control Software (GCS) project is described. This document fulfills the Radio Technical Commission for Aeronautics RTCA/DO-178A guidelines, 'Software Considerations in Airborne Systems and Equipment Certification' requirements for document No. 4, which specifies the information necessary for understanding and programming the host computer, and document No. 12, which specifies the software design and implementation standards that are applicable to the software development and testing process. Information on the following subjects is contained: activity recording, communication protocol, coding standards, change management, error handling, design standards, problem reporting, module testing logs, documentation formats, accuracy requirements, and programmer responsibilities.

Lowman, Douglas S.

Toward a standardization of cryostructure and cryogenic soil structure terminology for the field description of permafrost‐affected soils

This paper establishes standardized terminology and field documentation protocols for cryostructures and cryogenic soil structures in permafrost‐affected soils and provides brief guidance on descriptions of ground ice morphology and ice volume estimates. We consolidate permafrost terminology from Russian and North American literature, clarify long‐standing ambiguities, and provide explicit guidelines that align with US Department of Agriculture‐Natural Resources Conservation Service soil description standards. Our scheme makes critical distinctions between cryostructure, the distribution of ice within soil, and cryogenic soil structure, the morphological structure of soil resulting from ice formation. The scheme organizes cryostructures into three main categories: non‐segregated ice, visible segregated ice, and ice matrices. We introduce standardized codes and parameters for field descriptions of ice and soil that enable machine‐readable data collection compatible with existing soil information systems. This standardization will significantly enhance the integration of field observations into landscape‐scale assessments of permafrost stability, infrastructure vulnerability, and ecosystem response to permafrost thaw, addressing an urgent need for quantitative data to inform modeling and decision‐making in rapidly changing Arctic and subarctic environments.

Andersen, Megan L. [University of Minnesota, Saint

Guidelines for development structured FORTRAN programs

Computer programming and coding standards were compiled to serve as guidelines for the uniform writing of FORTRAN 77 programs at NASA Langley. Software development philosophy, documentation, general coding conventions, and specific FORTRAN coding constraints are discussed.

Earnest, B. M.

NED and SIMBAD Conventions for Bibliographic Reference Coding

The primary purpose of the 'reference code' is to provide a unique and traceable representation of a bibliographic reference within the structure of each database. The code is used frequently in the interfaces as a succinct abbreviation of a full bibliographic reference. Since its inception, it has become a standard code not only for NED and SIMBAD, but also for other bibliographic services.

NED SIMBAD bibliographic reference coding astronom

XML-Based Generator of C++ Code for Integration With GUIs

An open source computer program has been developed to satisfy a need for simplified organization of structured input data for scientific simulation programs. Typically, such input data are parsed in from a flat American Standard Code for Information Interchange (ASCII) text file into computational data structures. Also typically, when a graphical user interface (GUI) is used, there is a need to completely duplicate the input information while providing it to a user in a more structured form. Heretofore, the duplication of the input information has entailed duplication of software efforts and increases in susceptibility to software errors because of the concomitant need to maintain two independent input-handling mechanisms. The present program implements a method in which the input data for a simulation program are completely specified in an Extensible Markup Language (XML)-based text file. The key benefit for XML is storing input data in a structured manner. More importantly, XML allows not just storing of data but also describing what each of the data items are. That XML file contains information useful for rendering the data by other applications. It also then generates data structures in the C++ language that are to be used in the simulation program. In this method, all input data are specified in one place only, and it is easy to integrate the data structures into both the simulation program and the GUI. XML-to-C is useful in two ways: 1. As an executable, it generates the corresponding C++ classes and 2. As a library, it automatically fills the objects with the input data values.

Hua, Hook