Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Code of Record”

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 253 records · Page 14
All sourcesNASA NTRSDOE OSTI
NASA NTRS1992

Enhancing Soundtracks From Old Movies

Proposed system enhances soundtracks of old movies. Signal on optical soundtrack of film digitized and processed to reduce noise and improve quality; timing signals added, and signal recorded on compact disk. Digital comparator and voltage-controlled oscillator synchronizes speed of film-drive motor and compact disk motor. Frame-coded detector reads binary frame-identifying marks on film. Digital comparator generates error signal if marks on film do not match those on compact disk.

Frazer, Robert E.↗
NASA NTRS1991

Spectral fitting, shock layer modeling, and production of nitrogen oxides and excited nitrogen

An analysis was made of N2 emission from 8.72 MJ/kg shock layer at 2.54, 1.91, and 1.27 cm positions and vibrational state distributions, temperatures, and relative electronic state populations was obtained from data sets. Other recorded arc jet N2 and air spectral data were reviewed and NO emission characteristics were studied. A review of operational procedures of the DSMC code was made. Information on other appropriate codes and modifications, including ionization, were made as well as a determination of the applicability of codes reviewed to task requirement. A review was also made of computational procedures used in CFD codes of Li and other codes on JSC computers. An analysis was made of problems associated with integration of specific chemical kinetics applicable to task into CFD codes.

Blackwell, H. E.↗
NASA NTRS1997

Experimental and Computational Studies of the Flow Over a Sting Mounted Planetary Probe Configuration

This paper summarizes the results of a series of experimental studies in the LENS shock tunnel and computations with DSMC and Navier Stokes codes which have been made to examine the aerothermal and flowfield characteristics of the flow over a sting-supported planetary probe configuration in hypervelocity air and nitrogen flows. The experimental program was conducted in the LENS hypervelocity shock tunnel at total enthalpies of 5and 10 MJkg for a range of reservoir pressure conditions from 70 to 500 bars. Heat transfer and pressure measurements were made on the front and rear face of the probe and along the supporting sting. High-speed and single shot schlieren photography were also employed to examine the flow over the model and the time to establish the flow in the base recirculation region. Predictions of the flowfield characteristics and the distributions of heat transfer and pressure were made with DSMC codes for rarefied flow conditions and with the Navier-Stokes solvers for the higher pressure conditions where the flows were assumed to be laminar. Analysis of the time history records from the heat transfer and pressure instrumentation on the face of the probe and in the base region indicated that the base flow was fully established in under 4 milliseconds from flow initiation or between 35 and 50 flow lengths based on base height. The measurements made in three different tunnel entries with two models of identical geometries but with different instrumentation packages, one prepared by NASA Langley and the second prepared by CUBRC, demonstrated good agreement between heat transfer measurements made with two different types of thin film and coaxial gage instrumentation. The measurements of heat transfer and pressure to the front face of the probe were in good agreement with theoretical predictions from both the DSMC and Navier Stokes codes. For the measurements made in low density flows, computations with the DSMC code were found to compare well with the pressure and heat transfer measurements on the sting, although the computed heat transfer rates in the recirculation region did not exhibit the same characteristics as the measurements. For the 10MJkg and 500 bar reservoir match point condition, the measurements and heat transfer along the sting from the first group of studies were in agreement with the Navier Stokes solutions for laminar conditions. A similar set of measurements made in later tests where the model was moved to a slightly different position in the test section indicated that the boundary layer in the reattachment compression region was close to transition or transitional where small changes in the test environment can result in larger than laminar heating rates. The maximum heating coefficients on the sting observed in the present studies was a small fraction of similar measurements obtained at nominally the same conditions in the HEG shock tunnel, where it is possible for transition to occur in the base flow, and in the low enthalpy studies conducted in the NASA Langley high Reynolds number Mach 10 tunnel where the base flow was shown to be turbulent. While the hybrid Navier- StokedDMSC calculations by Gochberg et al. (Reference 1) suggested that employing the Navier- Stokes calculations for the entire flowfield could be seriously in error in the base region for the 10 MJkg, 500 bar test case, similar calculations performed by Cornell, presented here, do not.

Holden, Michael S.↗
NASA NTRS1994

A proven approach for more effective software development and maintenance

Modern space flight mission operations and associated ground data systems are increasingly dependent upon reliable, quality software. Critical functions such as command load preparation, health and status monitoring, communications link scheduling and conflict resolution, and transparent gateway protocol conversion are routinely performed by software. Given budget constraints and the ever increasing capabilities of processor technology, the next generation of control centers and data systems will be even more dependent upon software across all aspects of performance. A key challenge now is to implement improved engineering, management, and assurance processes for the development and maintenance of that software; processes that cost less, yield higher quality products, and that self-correct for continual improvement evolution. The NASA Goddard Space Flight Center has a unique experience base that can be readily tapped to help solve the software challenge. Over the past eighteen years, the Software Engineering Laboratory within the code 500 Flight Dynamics Division has evolved a software development and maintenance methodology that accommodates the unique characteristics of an organization while optimizing and continually improving the organization's software capabilities. This methodology relies upon measurement, analysis, and feedback much analogous to that of control loop systems. It is an approach with a time-tested track record proven through repeated applications across a broad range of operational software development and maintenance projects. This paper describes the software improvement methodology employed by the Software Engineering Laboratory, and how it has been exploited within the Flight Dynamics Division with GSFC Code 500. Examples of specific improvement in the software itself and its processes are presented to illustrate the effectiveness of the methodology. Finally, the initial findings are given when this methodology was applied across the mission operations and ground data systems software domains throughout Code 500.

Pajerski, Rose↗
DOE OSTI2024

HarDWR - Harmonized Water Rights Records

For a detailed description of the database of which this record is only one part, please see the HarDWR meta-record. Here we present a new dataset of western U.S. water rights records. This dataset provides consistent unique identifiers for each spatial unit of water management across the domain, unique identifiers for each water right record, and a consistent categorization scheme that puts each water right record into one of 7 broad use categories. These data were instrumental in conducting a study of the multi-sector dynamics of intersectoral water allocation changes through water markets (Grogan et al., in review). Specifically, the data were formatted for use as input to a process-based hydrologic model, WBM, with a water rights module (Grogan et al., in review). While this specific study motivated the development of the database presented here, U.S. west water management is a rich area of study (e.g., Anderson and Woosly, 2005; Tidwell, 2014; Null and Prudencio, 2016; Carney et al, 2021) so releasing this database publicly with documentation and usage notes will enable other researchers to do further work on water management in the U.S. west. The raw downloaded data for each state is described in Lisk et al. (in review), as well as here. The dataset is a series of various files organized by state sub-directories. The first two characters of each file name is the abbreviation for the state the in which the file contains data for. After the abbreviation is the text which describes the contents of the file. Here is each file type described in detail: XXFullHarmonizedRights.csv: A file of the combined groundwater and surface water records for each state. Essentially, this file is the merging of XXGroundwaterHarmonizedRights.csv and XXSurfaceWaterHarmonizedRights.csv by state. The column headers for each of this type of file are: state - The name of the state the data comes from. FIPS - The two-digit numeric state ID code. waterRightID - The unique identifying ID of the water right, the same identifier as its state uses. priorityDate - The priority date associated with the right. origWaterUse - The original stated water use(s) from the state. waterUse - The water use category under the unified use categories established here. source - Whether the right is for surface water or groundwater. basinNum - The alpha-numeric identifier of the WMA the record belongs to. CFS - The maximum flow of the allocation in cubic feet per second (ft3s-1). Arizona is unique among the states, as its surface and groundwater resources are managed with two different sets of boundaries. So, for Arizona, the basinNum column is missing and instead there are two columns: surBasinNum - The alpha-numeric identifier of the surface water WMA the record belongs to. grdBasinNum - The alpha-numeric identifier of the groundwater WMA the record belongs to. XXStatePOD.shp: A shapefile which identifies the location of the Points of Diversion for the state's water rights. It should be noted that not all water right records in XXFullHarmonizedRights.csv have coordinates, and therefore may be missing from this file. XXStatePOU.shp: A shapefile which contains the area(s) in which each water right is claimed to be used. Currently, only Idaho and Washington provided valid data to include within this file. XXGroundwaterHarmonizedRights.csv: A file which contains only harmonized groundwater rights collected from each state. See XXFullHarmonizedRights.csv for more details on how the data is formatted. XXSurfaceWaterHarmonizedRights.csv: A file which contains only harmonized surface water rights collected from each state. See XXFullHarmonizedRights.csv for more details on how the data is formatted. Additionally, one file, stateWMALabels.csv, is not stored within a sub-directory. While we have referred to the spatial boundaries that each state uses to manage its water resources as WMAs, this term is not shared across all states. This file lists the proper name for each boundary set, by state. For those whom may be interested in exploring our code more in depth, we are also making available an internal data file for convenience. The file is in .RData format and contains everything described above as well as some minor additional objects used within the code calculating the cumulative curves. For completeness, here is a detailed description of the various objects which can be found within the .RData file: states: A character vector containing the state names for those states in which data was collected for. More importantly, the index of the state name is also the index in which that state's data can be found in the various following list objects. For example, if California is the third index in this object, the data for California will also be in the third index for each accompanying list. rightsByState_ground: A list of data frames with the cleaned ground water rights collected from each state. This object holds the the data that is exported to created the xxGroundwaterHarmonizedRights.csv files. rightsByState_surface: A list of data frames with the cleaned surface water rights collected from each state. This object holds the the data that is exported to created the xxSurfaceWaterHarmonizedRights.csv files. fullRightsRecs: A list of the combined groundwater and surface water records for each state. This object holds the the data that is exported to created the xxFullHarmonizedRights.csv files. projProj: The spatial projection used for map creation in the beginning of the project. Specifically, the World Geodetic System (WGS84) as a coordinate reference system (CRS) string in PROJ.4 format. wmaStateLabel: The name and/or abbreviation for what each state legally calls their WMAs. h2oUseByState: A list of spatial polygon data frames which contain the area(s) in which each water right is claimed to be used. It should be noted that not all water right records have a listed area(s) of use in this object. Currently, only Idaho and Washington provided valid data to be included in this object. h2oDivByState: A list of spatial points data frames which identifies the location of the Point of Diversion for the state's water rights. It should be noted that not all water right records have a listed Point of Diversion in this object. spatialWMAByState: A list of spatial polygon data frames which contain the spatial WMA boundaries for each state. The only data contained within the table are identifiers for each polygon. It is worth reiterating that Arizona is the only state in which the surface and groundwater WMA boundaries are not the same. wmaIDByState: A list which contains the unique ID values of the WMAs for each state. plottingDim: A character vector used to inform mapping functions for internal map making. Each state is classified as either "tall" or "wide", to maximize space on a typical 8x11 page. The code related to the creation of this dataset can be viewed within HarDWR GitHub Repository/dataHarmonization.

Economics↗
NASA NTRS2000

Case Study Analyses of the SUCCESS DC-8 Scanning Lidar Database

Under project SUCCESS (Subsonic Aircraft Contrail and Cloud Effects Special Study) funded by the Atmospheric Effects of Aviation Program, SRI International (SRI) developed an angular scanning backscatter lidar for operation on the NASA DC-8 research aircraft and deployed the scanning lidar during the SUCCESS field campaign. The primary purpose of the lidar was to generate real-time video displays of clouds and contrails above, ahead of, and below the DC-8 as a means to help position the aircraft for optimum cloud and contrail sampling by onboard in situ sensors, and to help extend the geometrical domain of the in situ sampling records. A large, relatively complex lidar database was collected and several data examples were processed to illustrate the value of the lidar data for interpreting the other data records collected during SUCCESS. These data examples were used to develop a journal publication for the special SUCCESS Geophysical Research Letters issue. The data examples justified data analyses of a larger part of the DC-8 lidar database and is the objective of the current study. Efficient processing of the SUCCESS DC-8 scanning lidar database required substantial effort to enhance hardware and software components of the data system that was used for the initial analyses. MATLAB instructions are used to generate altitude and distance color-coded lidar displays corrected for effects introduced by aircraft pitch and forward movement during an angular scan time interval. Onboard in situ sensor atmospheric measurements are propagated to distances ahead of the DC-8 using recorded aircraft velocity so that they can be plotted on the lidar displays for comparison with lidar remotely observed aerosol distributions. Resulting lidar and in situ sensor polar scan displays over extended sampling intervals are integrated into a time series movie format for 36 case studies. Contrails and clouds were detected to ranges of 15 km by the forward-viewing angular scanning lidar and were progressively mapped as the aircraft approached and penetrated them. Near aircraft lidar observations were much better correlated with in situ sensor observations than lidar observations at greater distances ahead of the aircraft. The major cause of this difference was thought to be the about 2 deg. offset of the lidar viewing direction from the flight direction. Contrail spatial distributions were not of the quality obtainable from ground-based lidar observations. This results because contrails tend to become horizontally stratified, vertical distance between angular lidar observations increases with increased distance from the aircraft, and erratic aircraft motions during an angular scan. The most useful lidar observations were made with lidar viewing directions of vertically upward or vertically downward. These provided real-time information on aircraft altitudes to achieve optimum in situ cloud and contrail sampling. At sampling altitudes, the forward viewing angular scanning observations were useful for fine-tuning the aircraft altitude for cloud and contrail penetration. Best information on cloud and contrail properties were obtained from vertically directed lidar observations as the aircraft performed a series of upward and downward penetrations of contrails. This operational mode was especially well suited for lidar and radiometric evaluation of cloud and contrail optical and radiative properties. The vertical viewing lidar detected ice crystals thought to be precipitating from an aircraft contrail and their scavenging by a cirrus cloud layer. The lidar display indicates that the crystals are effective for increasing cirrus cloud density. Vertical angular scanning observations can evaluate the sharp decrease in lidar backscatter for small off-vertical viewing directions that result from horizontally aligned ice crystals and perhaps can provide additional information on crystal shapes. The about 2 deg. offset of the lidar viewing direction from the flight direction is thought to have greatly degraded the forward-viewing angular scanning observations and this mode of operation was not fully evaluated. However, the reasoning for this capability remains valid and the angular scan presentations collected during this program justifies modification of the lidar pod for true forward direction lidar viewing during future cloud and contrail studies.

Uthe, Edward E.↗
DOE OSTI2023

Illustration of bunch merge simulation in RHIC

Following are examples of a 4 to 2 to 1 merge of proton bunches in RHIC obtained by running the simulation code rhic2mrg23. As the code runs, the user is prompted to enter several numbers. For these examples, RF harmonic number 1440.0 is entered. An RF frequency of 112.597 696 626 MHz at this harmonic is entered. This gives a proton energy of 100 GeV. The merge simulation starts with a uniform distribution of unbunched protons. 2.0 eV-s is entered for the longitudinal emittance of the distribution. The code will recommend a voltage to capture the unbunched protons into 4 harmonic 1440 buckets. A capture voltage of 142.390 kV is recommended. 144.0 kV is entered. It is desirable to capture the protons as “adiabatically” as possible. A capture time of 3318 ms is recommended by the code. 3320.0 ms is entered. A 4 to 2 merge time of 1659 ms is recommended by the code. 1660.0 ms is entered. A 2 to 1 merge time twice that of the 4 to 2 merge is recommended by the code. 3320.0 ms is entered. The code requests a “time fraction” FQMRG to be entered. This is a number (from 0.1 to 1.0) that determines the time at which data are recorded during the 4 to 2 merge. The number 0.5 is entered. This encodes the recording of data halfway through the 4 to 2 merge.

43 PARTICLE ACCELERATORS↗
DOE OSTI2023

Illustration of bunch merge simulation in AGS

Following are examples of a 4 to 2 to 1 merge of proton bunches in AGS obtained by running the simulation code ags2mrg23. As the code runs, the user is prompted to enter several numbers. For these examples, RF harmonic number 12.0 is entered. An RF frequency of 4.453 913 448 73 MHz at this harmonic is entered. This gives proton G γ = 45.5. The merge simulation starts with a uniform distribution of unbunched protons. 2.0 eV-s is entered for the longitudinal emittance of the distribution. The code will recommend a voltage to capture the unbunched protons into 4 harmonic 12 buckets. A capture voltage of 0.0527 kV is recommended. 0.053 kV is entered. It is desirable to capture the protons as “adiabatically” as possible. Because of the long synchrotron period (372 ms), a capture time of 74,707 ms is recommended by the code. A shorter time, 10,000 ms, is entered to reduce the running time of the code. A 4 to 2 merge time of 37,353 ms is recommended by the code. 4000.0 ms is entered. A 2 to 1 merge time twice that of the 4 to 2 merge is recommended by the code. 8000.0 ms is entered. The code requests a “time fraction” FQMRG to be entered. This is a number (from 0.1 to 1.0) that determines the time at which data are recorded during the 4 to 2 merge. The number 0.5 is entered. This encodes the recording of data halfway through the 4 to 2 merge.

43 PARTICLE ACCELERATORS↗
NASA NTRS1987

PCACE-Personal-Computer-Aided Cabling Engineering

PCACE computer program developed to provide inexpensive, interactive system for learning and using engineering approach to interconnection systems. Basically database system that stores information as files of individual connectors and handles wiring information in circuit groups stored as records. Directly emulates typical manual engineering methods of handling data, thus making interface between user and program very natural. Apple version written in P-Code Pascal and IBM PC version of PCACE written in TURBO Pascal 3.0

Billitti, Joseph W.↗
NASA NTRS1991

Software manual for operating particle displacement tracking data acquisition and reduction system

The software manual is presented. The necessary steps required to record, analyze, and reduce Particle Image Velocimetry (PIV) data using the Particle Displacement Tracking (PDT) technique are described. The new PDT system is an all electronic technique employing a CCD video camera and a large memory buffer frame-grabber board to record low velocity (less than or equal to 20 cm/s) flows. Using a simple encoding scheme, a time sequence of single exposure images are time coded into a single image and then processed to track particle displacements and determine 2-D velocity vectors. All the PDT data acquisition, analysis, and data reduction software is written to run on an 80386 PC.

Wernet, Mark P.↗
NASA NTRS1992

Antagonistic otolith-visual units in cat vestibular nuclei

The nature of neural coding of visual (Vis) and vestibular (Vst) information on translational motion in the region of the vestibular nuclei was investigated using extracellular single-unit recordings in alert adult cats. Responses were recorded and averaged over 60 cycles of stimulation in the vertical and horizontal planes, which included the Vst (movement of the animal in the dark), Vis (movement within lighted visual surround), and combined Vis and Vst (movement of the animal within the lighted stationary visual surround). Data are reported on responses to stimulations along the axis showing maximal sensitivity. A small number of units were identified that showed an antagonistic relationship between their Vis and Vst responses (since they were maximally excited by Vis and by Vst stimulations in the same direction). Results suggest that antagonistic units may belong to an infrequently encountered, but functionally distinct, class of neurons.

Daunton, Nancy G.↗
NASA NTRS1997

The Joint Damping Experiment (JDX)

The Joint Damping Experiment (JDX), flown on the Shuttle STS-69 Mission, is designed to measure the influence of gravity on the structural damping of a high precision three bay truss. Principal objectives are: (1) Measure vibration damping of a small-scale, pinjointed truss to determine how pin gaps give rise to gravity-dependent damping rates; (2) Evaluate the applicability of ground and low-g aircraft tests for predicting on-orbit behavior; and (3) Evaluate the ability of current nonlinear finite element codes to model the dynamic behavior of the truss. Damping of the truss was inferred from 'Twang' tests that involve plucking the truss structure and recording the decay of the oscillations. Results are summarized as follows. (1) Damping, rates can change by a factor of 3 to 8 through changing the truss orientation; (2) The addition of a few pinned joints to a truss structure can increase the damping by a factor as high as 30; (3) Damping is amplitude dependent; (4) As gravity induced preloads become large (truss long axis perpendicular to gravity vector) the damping is similar to non-pinjointed truss; (5) Impacting in joints drives higher modes in structure; (6) The torsion mode disappears if gravity induced preloads are low.

Folkman, Steven L.↗
NASA NTRS2010

Evaluation of the VIIRS Land Algorithms at Land PEATE

The Land Product Evaluation and Algorithm Testing Element (Land PEATE), a component of the Science Data Segment of the National Polar-orbiting Operational Environmental Satellite System (NPOESS) Preparatory Project (NPP), is being developed at the NASA Goddard Space Flight Center (GSFC). The primary task of the Land PEATE is to assess the quality of the Visible Infrared Imaging Radiometer Suite (VIIRS) Land data products made by the Interface Data Processing System (IDPS) using the Operational (OPS) Code during the NPP era and to recommend improvements to the algorithms in the IDPS OPS code. The Land PEATE uses a version of the MODIS Adaptive Processing System (MODAPS), NPPDAPS, that has been modified to produce products from the IDPS OPS code and software provided by the VIIRS Science Team, and uses the MODIS Land Data Operational Product Evaluation (LDOPE) team for evaluation of the data records generated by the NPPDAPS. Land PEATE evaluates the algorithms by comparing data products generated using different versions of the algorithm and also by comparing to heritage products generated from different instrument such as MODIS using various quality assessment tools developed at LDOPE. This paper describes the Land PEATE system and some of the approaches used by the Land PEATE for evaluating the VIIRS Land algorithms during the pre-launch period of the NPP mission and the proposed plan for long term monitoring of the quality of the VIIRS Land products post-launch.

Wolfe, Robert E.↗
NASA NTRS2013

SpaceCube Version 1.5

SpaceCube 1.5 is a high-performance and low-power system in a compact form factor. It is a hybrid processing system consisting of CPU (central processing unit), FPGA (field-programmable gate array), and DSP (digital signal processor) processing elements. The primary processing engine is the Virtex- 5 FX100T FPGA, which has two embedded processors. The SpaceCube 1.5 System was a bridge to the SpaceCube 2.0 and SpaceCube 2.0 Mini processing systems. The SpaceCube 1.5 system was the primary avionics in the successful SMART (Small Rocket/Spacecraft Technology) Sounding Rocket mission that was launched in the summer of 2011. For SMART and similar missions, an avionics processor is required that is reconfigurable, has high processing capability, has multi-gigabit interfaces, is low power, and comes in a rugged/compact form factor. The original SpaceCube 1.0 met a number of the criteria, but did not possess the multi-gigabit interfaces that were required and is a higher-cost system. The SpaceCube 1.5 was designed with those mission requirements in mind. The SpaceCube 1.5 features one Xilinx Virtex-5 FX100T FPGA and has excellent size, weight, and power characteristics [4×4×3 in. (approx. = 10×10×8 cm), 3 lb (approx. = 1.4 kg), and 5 to 15 W depending on the application]. The estimated computing power of the two PowerPC 440s in the Virtex-5 FPGA is 1100 DMIPS each. The SpaceCube 1.5 includes two Gigabit Ethernet (1 Gbps) interfaces as well as two SATA-I/II interfaces (1.5 to 3.0 Gbps) for recording to data drives. The SpaceCube 1.5 also features DDR2 SDRAM (double data rate synchronous dynamic random access memory); 4- Gbit Flash for storing application code for the CPU, FPGA, and DSP processing elements; and a Xilinx Platform Flash XL to store FPGA configuration files or application code. The system also incorporates a 12 bit analog to digital converter with the ability to read 32 discrete analog sensor inputs. The SpaceCube 1.5 design also has a built-in accelerometer. In addition, the system has 12 receive and transmit RS- 422 interfaces for legacy support. The SpaceCube 1.5 processor card represents the first NASA Goddard design in a compact form factor featuring the Xilinx Virtex- 5. The SpaceCube 1.5 incorporates backward compatibility with the Space- Cube 1.0 form factor and stackable architecture. It also makes use of low-cost commercial parts, but is designed for operation in harsh environments.

Geist, Alessandro↗
DOE OSTI2024

Tracking the topology of neural manifolds across populations

Neural manifolds summarize the intrinsic structure of the information encoded by a population of neurons. Advances in experimental techniques have made simultaneous recordings from multiple brain regions increasingly commonplace, raising the possibility of studying how these manifolds relate across populations. However, when the manifolds are nonlinear and possibly code for multiple unknown variables, it is challenging to extract robust and falsifiable information about their relationships. We introduce a framework, called the method of analogous cycles, for matching topological features of neural manifolds using only observed dissimilarity matrices within and between neural populations. We demonstrate via analysis of simulations and in vivo experimental data that this method can be used to correctly identify multiple shared circular coordinate systems across both stimuli and inferred neural manifolds. Conversely, the method rejects matching features that are not intrinsic to one of the systems. Further, as this method is deterministic and does not rely on dimensionality reduction or optimization methods, it is amenable to direct mathematical investigation and interpretation in terms of the underlying neural activity. We thus propose the method of analogous cycles as a suitable foundation for a theory of cross-population analysis via neural manifolds.

97 MATHEMATICS AND COMPUTING↗
NASA NTRS2007

Boundary Layer Development on a Turbine Blade in a Linear Cascade

Several different boundary-layer development patterns for flow over the suction surface of a turbine airfoil in a linear cascade were studied and documented using a sliding surface hot-film sensor. The state of the boundary layer, whether laminar, transitional or turbulent, was determined at numerous locations along the airfoil suction surface from leading to trailing edge. Boundary-layer transition from laminar to turbulent flow through laminar separation and turbulent reattachment, or through a combination of bypass transition and strong and weak separation and turbulent reattachment, or through solely bypass transition without separation, was observed and benchmark data were recorded. Surface flow visualization and numerical boundary-layer analysis results are consistent with the hot-film data. Flow and geometry information necessary for nmerical code operation is available.

Halstead, Dave↗
DOE OSTI2021

Cylinder Occupancy and Measurement Suite

This software automatically records data from the Unattended Cylinder Verification Station, determines the state of the instrument, captures images of uranium hexafluoride shipment cylinders, and determines their weight. The code has been developed primarily for the International Atomic Energy Agency, but this type of instrument could be of interest to any facility operator in the uranium supply chain that handles uranium hexafluoride shipment cylinders (e.g. the 30B and 48Y cylinder). Operators may be interested in having this instrument confirm shipper declared measurement values upon receipt of a cylinder. They may also use it to aid in process monitoring if the quantity of material in the cylinder changes due to a processing activity.

Stewart, Scott L↗
DOE OSTI2024

HarDWR - Harmonized Water Rights Records

For a detailed description of the database of which this record is only one part, please see the HarDWR meta-record. Here we present a new dataset of western U.S. water rights records. This dataset provides consistent unique identifiers for each spatial unit of water management across the domain, unique identifiers for each water right record, and a consistent categorization scheme that puts each water right record into one of 7 broad use categories. These data were instrumental in conducting a study of the multi-sector dynamics of intersectoral water allocation changes through water markets (Grogan et al., in review). Specifically, the data were formatted for use as input to a process-based hydrologic model, WBM, with a water rights module (Grogan et al., in review). While this specific study motivated the development of the database presented here, U.S. west water management is a rich area of study (e.g., Anderson and Woosly, 2005; Tidwell, 2014; Null and Prudencio, 2016; Carney et al, 2021) so releasing this database publicly with documentation and usage notes will enable other researchers to do further work on water management in the U.S. west. The raw downloaded data for each state is described in Lisk et al. (in review), as well as here. The dataset is a series of various files organized by state sub-directories. The first two characters of each file name is the abbreviation for the state the in which the file contains data for. After the abbreviation is the text which describes the contents of the file. Here is each file type described in detail: XXFullHarmonizedRights.csv: A file of the combined groundwater and surface water records for each state. Essentially, this file is the merging of XXGroundwaterHarmonizedRights.csv and XXSurfaceWaterHarmonizedRights.csv by state. The column headers for each of this type of file are: state - The name of the state the data comes from. FIPS - The two digit numeric state ID code. waterRightID - The unique identifying ID of the water right, the same identifier as its state uses. priorityDate - The priority date associated with the right. origWaterUse - The original stated water use from the state. waterUse - The water use category under the unified use categories established here. source - Whether the right is for surface water or groundwater. basinNum - The alpha-numeric identifier of the WMA the record belongs to. CFS - The maximum flow of the allocation in cubic feet per second (ft3s-1). Arizona is unique among the states, as its surface and groundwater resources are managed with two different sets of boundaries. So, for Arizona, the basinNum column is missing and instead there are two columns: surBasinNum - The alpha-numeric identifier of the surface water WMA the record belongs to. grdBasinNum - The alpha-numeric identifier of the groundwater WMA the record belongs to. XXStatePOD.shp: A shapefile which identifies the location of the Points of Diversion for the state's water rights. It should be noted that not all water right records in XXFullHarmonizedRights.csv have coordinates, and therefore may be missing from this file. XXStatePOU.shp: A shapefile which contains the area(s) in which each water right is claimed to be used. Currently, only Idaho and Washington provided valid data to included within this file. XXGroundwaterHarmonizedRights.csv: A file which contains only harmonized groundwater rights collected from each state. See XXFullHarmonizedRights.csv for more details on how the data is formatted. XXSurfaceWaterHarmonizedRights.csv: A file which contains only harmonized surface water rights collected from each state. See XXFullHarmonizedRights.csv for more details on how the data is formatted. Additionally, one file, stateWMALabels.csv, is not stored within a sub-directory. While we have referred to the spatial boundaries that each state uses to manage its water resources as WMAs, this term is not shared across all states. This file lists the proper name for each boundary set, by state.

Economics↗