Search NASA⌕ Search

SEARCH · Search NASA

Results for “code sharing”

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 379 records · Page 21
All sourcesNASA NTRSDOE OSTI
DOE OSTI2019

PHISICS User Manual

PHISICS (Parallel and Highly Innovative Simulation for INL Code System) is a reactor physics package developed at the Idaho National Laboratory. It is composed of several modules: a nodal and semi-structured transport core solver (INSTANT), a depletion module (MRTAU), a time-dependent solver (TimeIntegrator), a cross-section interpolation and manipulation framework (MIXER), a SuperHomogenization scheme (SPH) a criticality search module (CRITICALITY), a fuel management and shuffling component (SHUFFLE) and a coupling API with RELAP5-3D. PHISICS has been built in a highly modular fashion so that different physical models can be activated or deactivated depending on the physics relevant to the particular type of analysis. This approach simplifies development as well as mid- and long-term maintenance of the code. PHISICS is entirely written in FORTRAN 95/2003. Each of its components is fully parallelized and designed to take full advantage of shared-memory computers (multiprocessor desktops and workstations) and middle to large high-performance computing systems (10 to 1000 processors). The aim of this document is to detail the input requirements for PHISICS (and all its modules) focusing on the input structure.

73 NUCLEAR PHYSICS AND RADIATION PHYSICS↗
DOE OSTI2019

CIAE-ANL CRADA for SFR SAFETY ANALYSIS: Final CRADA Report

The purpose of this project is joint verification and validation of system analysis code capabilities for Sodium-cooled Fast Reactor (SFR) design and licensing. As the researchers and code developers at the Argonne National Laboratory (ANL) and China Institute of Atomic Energy (CIAE) independently build their own SFR system analysis capabilities, this collaboration facilitated exchange of information on, and evaluation of alternative approaches for, modeling the key phenomena (such as decay heat removal and natural circulation) and the safety-related components (such as pumps, heat exchangers, and outlet plenum) common in SFR systems. The analysis at ANL and CIAE also applied their respective computational capabilities and methods (in SAS4A/SASSYS-1 computer code at ANL and FR-Sdaso computer code at CIAE) on jointly identified benchmark problems for verification, and publicly available integral tests for validation, of their results. ANL team also shared the expertise on the established software quality assurance practices and the techniques for component reliability estimates to support probabilistic risk assessments.

21 SPECIFIC NUCLEAR REACTORS AND ASSOCIATED PLANTS↗
DOE OSTI2024

County Level Annual Population Projections for SSP3 and SSP5

This dataset consist of annual (2020-2100) county-level population projections for the United States (U.S.) for Shared Socioeconomic Pathways (SSPs) 3 and 5. The original decadal state-level data is used as an input to the gridded population data model to downscale the state-level projections for each SSP to a 1 km grid. The 1 km data is then aggregated to the county-level using the 2020 TIGER/Line county shapefiles from the U.S. Census Bureau. The two data files are shared as .csv files with the following structure: Rows = Data for individual counties which are identified using their Federal Information Processing Standard (FIPS) code. The FIPS code is stored in the first column. Columns = Each year from 2020-2100 is an individual column. For easier reference, the state name associated with each row is stored in the last column. Values in each cell are the downscaled estimated population for that county-year combination. Values are fractional due to the weighting scheme used in the downscaling. The paper and model source code cited in the "Related Works" section describes the initial source of the population projections.

FIPS↗
NASA NTRS2006

General Aviation Data Framework

The Flight Research Services Directorate at the NASA Langley Research Center (LaRC) provides development and operations services associated with three general aviation (GA) aircraft used for research experiments. The GA aircraft includes a Cessna 206X Stationair, a Lancair Colombia 300X, and a Cirrus SR22X. Since 2004, the GA Data Framework software was designed and implemented to gather data from a varying set of hardware and software sources as well as enable transfer of the data to other computers or devices. The key requirements for the GA Data Framework software include platform independence, the ability to reuse the framework for different projects without changing the framework code, graphics display capabilities, and the ability to vary the interfaces and their performance. Data received from the various devices is stored in shared memory. This paper concentrates on the object oriented software design patterns within the General Aviation Data Framework, and how they enable the construction of project specific software without changing the base classes. The issues of platform independence and multi-threading which enable interfaces to run at different frame rates are also discussed in this paper.

Blount, Elaine M.↗
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↗
DOE OSTI2018

Evolutionary conservation of transferrin genomic organization and expression characterization in seven freshwater turtles

Highlights: • Transferrin have evolutionary conservation in genomic organization in freshwater turtles. • Transferrin have evolutionary conservation in expression characterization in freshwater turtles. • 12 positive selected sites were detected in freshwater turtles which were mainly located on the surface of Tf proteins. Serum transferrin (tf), encoding an iron-binding glycoprotein, has been revealed to play important roles in iron transportation and immune response, and it also has been demonstrated to be valuable for phylogenetic analysis in vertebrates. However, the evolutionary conservation, expression profiles and positive selection of transferrin genes among freshwater turtle species remain largely unclear. Here, the genomic DNA and coding sequences of transferrin genes were cloned and characterized in seven freshwater turtles including Mauremys mutica, Mauremys sinensis, Cyclemys dentate, Mauremyssi reevesi, Heosemys grandis, Trachemys scripta and Chrysemys picta. The isolated coding sequences of turtles' tf genes were 2118 bp or 2121 bp, encoding 706 or 707 amino acids. The predicted Tf proteins of turtles share high identities with M. mutica Tf, up to 91%–98% and the M. mutica Tf has the highest identity (91%) in amino acid with the Chelomia mydas Tf, the moderate with other reptiles' Tfs (65%–59%), chicken (58%), and Human Tf (∼55%), and the lowest with zebrafish Tf (41%). Additionally, tf genes were consistently composed of 17 exons and 16 introns with the same splicing sites in introns in all the turtles examined. Moreover, 12 positive selected sites were detected in these turtles’ Tf and mainly distributed on the surface of transferrin protein. Importantly, it was found that transferrin genes in all turtles examined were predominantly expressed in adult liver via real-time quantitative PCR. The molecular characterizations and expression profiles of transferrin would shed new insights into understanding the conversations and divergences of transferrin genes in turtles, even in vertebrates.

60 APPLIED LIFE SCIENCES↗
DOE OSTI2018

Symmetric Indefinite Linear Solver Using OpenMP Task on Multicore Architectures

Recently, the Open Multi-Processing (OpenMP) standard has incorporated task-based programming, where a function call with input and output data is treated as a task. At run time, OpenMP's superscalar scheduler tracks the data dependencies among the tasks and executes the tasks as their dependencies are resolved. On a shared-memory architecture with multiple cores, the independent tasks are executed on different cores in parallel, thereby enabling parallel execution of a seemingly sequential code. With the emergence of many-core architectures, this type of programming paradigm is gaining attention-not only because of its simplicity, but also because it breaks the artificial synchronization points of the program and improves its thread-level parallelization. In this paper, we use these new OpenMP features to develop a portable high-performance implementation of a dense symmetric indefinite linear solver. Obtaining high performance from this kind of solver is a challenge because the symmetric pivoting, which is required to maintain numerical stability, leads to data dependencies that prevent us from using some common performance-improving techniques. To fully utilize a large number of cores through tasking, while conforming to the OpenMP standard, we describe several techniques. Our performance results on current many-core architectures-including Intel's Broadwell, Intel's Knights Landing, IBM's Power8, and Arm's ARMv8-demonstrate the portable and superior performance of our implementation compared with the Linear Algebra PACKage (LAPACK). The resulting solver is now available as a part of the PLASMA software package.

Computer Science↗
NASA NTRS2006

YAM- A Framework for Rapid Software Development

YAM is a software development framework with tools for facilitating the rapid development and integration of software in a concurrent software development environment. YAM provides solutions for thorny development challenges associated with software reuse, managing multiple software configurations, the development of software product-lines, multiple platform development and build management. YAM uses release-early, release-often development cycles to allow developers to incrementally integrate their changes into the system on a continual basis. YAM facilitates the creation and merging of branches to support the isolated development of immature software to avoid impacting the stability of the development effort. YAM uses modules and packages to organize and share software across multiple software products. It uses the concepts of link and work modules to reduce sandbox setup times even when the code-base is large. One side-benefit is the enforcement of a strong module-level encapsulation of a module s functionality and interface. This increases design transparency, system stability as well as software reuse. YAM is in use by several mid-size software development teams including ones developing mission-critical software.

simulations↗
NASA NTRS2012

pyam: Python Implementation of YaM

pyam is a software development framework with tools for facilitating the rapid development of software in a concurrent software development environment. pyam provides solutions for development challenges associated with software reuse, managing multiple software configurations, developing software product lines, and multiple platform development and build management. pyam uses release-early, release-often development cycles to allow developers to integrate their changes incrementally into the system on a continual basis. It facilitates the creation and merging of branches to support the isolated development of immature software to avoid impacting the stability of the development effort. It uses modules and packages to organize and share software across multiple software products, and uses the concepts of link and work modules to reduce sandbox setup times even when the code-base is large. One sidebenefit is the enforcement of a strong module-level encapsulation of a module s functionality and interface. This increases design transparency, system stability, and software reuse. pyam is written in Python and is organized as a set of utilities on top of the open source SVN software version control package. All development software is organized into a collection of modules. pyam packages are defined as sub-collections of the available modules. Developers can set up private sandboxes for module/package development. All module/package development takes place on private SVN branches. High-level pyam commands support the setup, update, and release of modules and packages. Released and pre-built versions of modules are available to developers. Developers can tailor the source/link module mix for their sandboxes so that new sandboxes (even large ones) can be built up easily and quickly by pointing to pre-existing module releases. All inter-module interfaces are publicly exported via links. A minimal, but uniform, convention is used for building modules.

Myint, Steven↗
DOE OSTI2022

2.3.3.404 - National Lab and University Collaboration for MHK Instrumentation and Data Processing Tools

Field and laboratory validation, testing, demonstration, and operation are critical steps for increasing the technology readiness level of marine energy (ME) converters because they provide high-quality testing and performance data that are critical information used to feed all aspects of technology development. This project, in partnership with industry, enables the marine and hydrokinetic energy (MHK) community to reliably and efficiently collect, process, manage, and share quality data by facilitating access to and development of instrumentation, guidelines and data processing/QA tools. Under this project, open-source data processing code (MHKiT) and tools (ME Data Pipeline, MRE Code Hub, PRIMRE Code Catalog), instrumentation (loads measurements), data acquisition systems (miniDAQ), and measurement guidance tools (Telesto, high EMI guidance) were developed to facilitate the collection and processing of quality laboratory and field data. Overall, this project is intended to improve the quality of the data collected during laboratory and field demonstration projects by standardizing the collection and processing techniques, as well as by improving access to instrumentation, code, and measurement guidance. Quality data will, in turn, lead to improved knowledge capture following ME device testing.

data processing↗
DOE OSTI2023

Gamma Spectrometry Code Rodeo for Uranium Enrichment—FY 2022 Report

In the first two quarters of FY22, data acquisition continued at ORNL and LLNL using uranium sources of known enrichments. This was an FY21 task which could not be completed in FY21 because of problems encountered with the ORNL M400 CZT in Q4 of FY21, and the subsequent repairs. The detector was received back from H3D in the first of September 2021 , and the measurements resumed . Measurements using the repaired detector were completed in Q1 of FY22. The spectra were distributed by ORNL to the analyzing labs. Analysis results were received in Q2 of FY2022. The results from the various codes were intercompared and an ANOVA analysis was performed. Random and systematic uncertainties were established for each code. The ANOVA results and discussions were included in a revised version of FY21Annual Report issued in March 2022. A paper was presented at the INMM 2022Annual Conference, with the analysis results from the various isotopic codes, and the ANOVA table with random and systematic uncertainties. The Project Work Plan (PWP) for FY22 included a task to perform field testing of the M400 CZT and the analysis codes using UF 6 cylinder measurements at the Framatome Fuel Fabrication Facility in Richland, WA. PNNL was the lead for the field testing task. PNNL drafted a Field Test Plan, and refined it based on comments received from the team. PNNL coordinated with Framatome facility, the logistics of carrying out the field testing . A collimator and shield made out of TFlex (tungsten impregnated polymer) was designed and professionally manufactured. The collimators were used in the field test measurements. The measurements at Framatome were completed on April 21, 2022. A total of 34 Type 30B cylinders were measured using three M400 detectors (PNNL, LLNL, and ORNL detectors). Measurements using M400 were taken at two locations on the side of each cylinder and from the end-on bottom location. Additionally, HPGe measurements were taken at the end-on location to establish ground truth. Cylinder wall thickness measurements were also made at all three locations. To gain a better understanding of the effect of background from surrounding cylinders, the same five cylinders measured individually in low background locations were measured again in the cylinder storage yards. Due to inclement weather, manufacturer delays, shipping delays, and equipment failure, the measurement campaign spanned twice as long compared to the original timeline. Gamma-ray spectra from M400 and HPGe detectors, along with the cylinder data and photographs were organized and shared with the collaborators for further analysis. Spectra were analyzed by the participating laboratories. FY22 PWP also consists of tasks related to plutonium source measurements, adapting the codes to analyze plutonium spectra, and inter-comparison of the results from various codes. Plutonium spectra are being acquired at LANL, ORNL, and LLNL. LANL, SNL and LLNL are in the process of modifying FRAM, GADRAS, and CZTU, respectively. The plutonium related tasks will be completed in Q2 of FY23.

46 INSTRUMENTATION RELATED TO NUCLEAR SCIENCE AND ↗
DOE OSTI2015

Advanced Code for Photocathode Design

The Phase I activity demonstrated that PhotoQE could be upgraded and modified to allow input using a graphical user interface. Specific calls to platform-dependent (e.g. IMSL) function calls were removed, and Fortran77 components were rewritten for Fortran95 compliance. The subroutines, specifically the common block structures and shared data parameters, were reworked to allow the GUI to update material parameter data, and the system was targeted for desktop personal computer operation. The new structures overcomes the previous rigid and unmodifiable library structures by implementing new, materials library data sets and repositioning the library values to external files. Material data may originate from published literature or experimental measurements. Further optimization and restructuring would allow custom and specific emission models for beam codes that rely on parameterized photoemission algorithms. These would be based on simplified and parametric representations updated and extended from previous versions (e.g., Modified Fowler-Dubridge, Modified Three-Step, etc.).

43 PARTICLE ACCELERATORS↗
DOE OSTI2015

SU-E-P-26: Oncospace: A Shared Radiation Oncology Database System Designed for Personalized Medicine, Decision Support, and Research

Purpose: Advancement in Radiation Oncology (RO) practice develops through evidence based medicine and clinical trial. Knowledge usable for treatment planning, decision support and research is contained in our clinical data, stored in an Oncospace database. This data store and the tools for populating and analyzing it are compatible with standard RO practice and are shared with collaborating institutions. The question is - what protocol for system development and data sharing within an Oncospace Consortium? We focus our example on the technology and data meaning necessary to share across the Consortium. Methods: Oncospace consists of a database schema, planning and outcome data import and web based analysis tools.1) Database: The Consortium implements a federated data store; each member collects and maintains its own data within an Oncospace schema. For privacy, PHI is contained within a single table, accessible to the database owner.2) Import: Spatial dose data from treatment plans (Pinnacle or DICOM) is imported via Oncolink. Treatment outcomes are imported from an OIS (MOSAIQ).3) Analysis: JHU has built a number of webpages to answer analysis questions. Oncospace data can also be analyzed via MATLAB or SAS queries.These materials are available to Consortium members, who contribute enhancements and improvements. Results: 1) The Oncospace Consortium now consists of RO centers at JHU, UVA, UW and the University of Toronto. These members have successfully installed and populated Oncospace databases with over 1000 patients collectively.2) Members contributing code and getting updates via SVN repository. Errors are reported and tracked via Redmine. Teleconferences include strategizing design and code reviews.3) Successfully remotely queried federated databases to combine multiple institutions’ DVH data for dose-toxicity analysis (see below – data combined from JHU and UW Oncospace). Conclusion: RO data sharing can and has been effected according to the Oncospace Consortium model: http://oncospace.radonc.jhmi.edu/ . John Wong - SRA from Elekta; Todd McNutt - SRA from Elekta; Michael Bowers - funded by Elekta.

60 APPLIED LIFE SCIENCES↗
DOE OSTI2016

The 2016 Bioinformatics Open Source Conference (BOSC)

The Bioinformatics Open Source Conference (BOSC) is a yearly meeting organized by the Open Bioinformatics Foundation (OBF), a non-profit group dedicated to promoting the practice and philosophy of Open Source software development and Open Science within the biological research community. BOSC has been run since 2000 as a two-day Special Interest Group (SIG) before the annual ISMB conference. The 17th annual BOSC (http://www.open-bio.org/wiki/BOSC_2016) took place in Orlando, Florida in July 2016. As in previous years, the conference was preceded by a two-day collaborative coding event open to the bioinformatics community. The conference brought together nearly 100 bioinformatics researchers, developers and users of open source software to interact and share ideas about standards, bioinformatics software development, and open and reproducible science.

59 BASIC BIOLOGICAL SCIENCES↗
DOE OSTI2019

Test Problems for 3-Phase AMR

This document will be shared with LBNL in April 2019. It contains the initial conditions of 4 explosion problems that will test the ability of the 3-Phase AMR code to cope with various cases of 3- phase flows.

37 INORGANIC, ORGANIC, PHYSICAL, AND ANALYTICAL CH↗
NASA NTRS2018

Performance Evaluation of Cognitive Interference Channels Using a Spectrum Overlay Strategy

The use of cognitive radios (CR) and cooperative communications techniques may assist in interference mitigation via sensing of the environment and dynamically altering communications parameters through the use of various mechanisms - one of which is the overlay technique. This report provides a performance analysis of an interference channel with a cognitive transceiver operating in an overlay configuration to evaluate the gains from using cognition. As shown in this report, a cognitive transceiver can simultaneously share spectrum while enhancing performance of non-cognitive nodes via knowledge of the communications channel as well as knowledge of neighboring users' modulation and coding schemes.

Knoblock, Eric J.↗
NASA NTRS2021

The CHIMAERA System for Retrievals of Cloud Top, Optical and Microphysical Properties from Imaging Sensors

Continuity and consistency of geophysical retrieval products obtained from different Earth-observing spaceborne or airborne atmospheric multispectral imagers can be challenging due to inherent differences in the instruments and/or the use of different retrieval algorithms. The Cross-platform HIgh resolution Multi-instrument AtmosphEric Retrieval Algorithms (CHIMAERA) system addresses the latter aspect of the inter-sensor continuity problem for cloud property retrievals by removing retrieval methodology and implementation as a source of inconsistency when applied to instruments that share common measurement capabilities. Transferring an existing retrieval algorithm to a new sensor oftentimes is a nontrivial task, as it is common for an algorithm code to be tightly coupled to the sensor for which it was developed. By creating a clear division between the science algorithm and the instrument I/O codes, CHIMAERA allows easy migration of science algorithms to different sensors. CHIMAERA is built from C and FORTRAN source code, and can operate in a variety of environments ranging from a personal laptop to a high-performance computing environment for near real-time satellite data production. It is highly adaptable, low-maintenance and allows for easy expansion such that adding new instruments into the system requires only instrument-specific I/O and provision of any external lookup tables specific to the instrument's spectral characteristics. CHIMAERA currently supports 14 spaceborne and airborne atmospheric imagers from a single code base, and has been in use since 2007. In this paper we describe the engineering aspects of CHIMAERA and briefly discuss a few examples from its many current applications.

Galina (Gala) Wind↗
NASA NTRS1992

Sharing Resources In Mobile/Satellite Communications

Report presents preliminary theoretical analysis of several alternative schemes for allocation of satellite resource among terrestrial subscribers of landmobile/satellite communication system. Demand-access and random-access approaches under code-division and frequency-division concepts compared.

Yan, Tsun-Yee↗