Search NASA⌕ Search

SEARCH · Search NASA

Results for “Check Standard Model”

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.

86 records · Page 5

From Informal Safety-Critical Requirements to Property-Driven Formal Validation

Most of the efforts in formal methods have historically been devoted to comparing a design against a set of requirements. The validation of the requirements themselves, however, has often been disregarded, and it can be considered a largely open problem, which poses several challenges. The first challenge is given by the fact that requirements are often written in natural language, and may thus contain a high degree of ambiguity. Despite the progresses in Natural Language Processing techniques, the task of understanding a set of requirements cannot be automatized, and must be carried out by domain experts, who are typically not familiar with formal languages. Furthermore, in order to retain a direct connection with the informal requirements, the formalization cannot follow standard model-based approaches. The second challenge lies in the formal validation of requirements. On one hand, it is not even clear which are the correctness criteria or the high-level properties that the requirements must fulfill. On the other hand, the expressivity of the language used in the formalization may go beyond the theoretical and/or practical capacity of state-of-the-art formal verification. In order to solve these issues, we propose a new methodology that comprises of a chain of steps, each supported by a specific tool. The main steps are the following. First, the informal requirements are split into basic fragments, which are classified into categories, and dependency and generalization relationships among them are identified. Second, the fragments are modeled using a visual language such as UML. The UML diagrams are both syntactically restricted (in order to guarantee a formal semantics), and enriched with a highly controlled natural language (to allow for modeling static and temporal constraints). Third, an automatic formal analysis phase iterates over the modeled requirements, by combining several, complementary techniques: checking consistency; verifying whether the requirements entail some desirable properties; verify whether the requirements are consistent with selected scenarios; diagnosing inconsistencies by identifying inconsistent cores; identifying vacuous requirements; constructing multiple explanations by enabling the fault-tree analysis related to particular fault models; verifying whether the specification is realizable.

Cimatti, Alessandro↗

Statistical Approach on Utilizing Ground-Based Experiments to Model Break-Up Events

Two laboratory-based impact tests have been conducted to develop and extend the capability of NASA satellite breakup models. The first experiment, the Satellite Orbital Debris Characterization Impact Test (SOCIT), was conducted by the U.S. Department of Defense and NASA in 1992. It employed a fully functional U.S. Navy Transit spacecraft, fabricated from materials commonly used in the 1960s. SOCIT fragmentation data formed the basis of the current NASA Standard Satellite Breakup Model (SSBM). A second experiment, DebriSat, was conducted in 2014 by the DebriSat consortium: the NASA Orbital Debris Program Office, the United States Space Force Space Systems Command, formerly the Air Force Space and Missile Systems Center, the Air Force Arnold Engineering Development Complex, and the University of Florida. This impact test was performed on a high-fidelity mock-up satellite assembled from modern components. Data from both experiments are expected to contribute to the next-generation models for on-orbit breakup analyses, long-term environment predictions, and debris risk assessment. This paper uses the direct statistical sampling of the SOCIT and DebriSat data ensembles to model an on-orbit breakup event, rather than the analytic expressions estimated from the samples in the SSBM and its predecessor. This direct method involves drawing fragments (i.e., sampling with replacement) from each fragmentation data-subset containing mass, shape category, material density, characteristic length, mass, and cross-sectional area. As part of the sampling process, the properties of sampled fragment data (e.g., area-to-mass ratios) are numerically checked to ensure they do not contain unrealistic quantities. The process to simulate a breakup cloud composed of fragments from SOCIT and DebriSat datasets is discussed. The methodology for ensuring that conservation of overall mass of the sampled fragment cloud under this sampling approach is highlighted. Finally, the results are compared with simulated clouds generated from SSBM for specific historical breakup events.

Andrew Vavrin↗

Statistical Approach on Utilizing Ground-based Experiments to Model Break-up Events

Two laboratory-based impact tests have been conducted to develop and extend the capability of NASA satellite breakup models. The first experiment, the Satellite Orbital Debris Characterization Impact Test (SOCIT), was conducted by the U.S. Department of Defense and NASA in 1992. It employed a fully functional U.S. Navy Transit spacecraft, fabricated from materials commonly used in the 1960s. SOCIT fragmentation data formed the basis of the current NASA Standard Satellite Breakup Model (SSBM). A second experiment, DebriSat, was conducted in 2014 by the DebriSat consortium: the NASA Orbital Debris Program Office; the United States Space Force Space Systems Command, formerly the Air Force Space and Missile Systems Center, the Air Force Arnold Engineering Development Complex, and the University of Florida. This impact test was performed on a high-fidelity mock-up satellite assembled from modern components. Data from both experiments are expected to contribute to the next-generation models for on-orbit breakup analyses, long-term environment predictions, and debris risk assessment. This paper uses the direct statistical sampling of the SOCIT and DebriSat data ensembles to model an on-orbit breakup event, rather than the analytic expressions estimated from the samples as with as with the NASA SSBM and its predecessor. This direct method involves drawing fragments (i.e., sampling with replacement) from each fragmentation data-subset containing mass, shape category, material density, characteristic length, mass, and cross-sectional area. As part of the sampling process, the properties of sampled fragment data (e.g., area-to-mass ratios) are numerically checked to ensure they do not contain unrealistic quantities. The process to simulate a breakup cloud composed of fragments from SOCIT and DebriSat datasets is discussed. The methodology for ensuring that conservation of overall mass of the sampled fragment cloud under this sampling approach is highlighted. Finally, the results are compared with simulated clouds generated from SSBM for specific historical breakup events.

Andrew Vavrin↗

Automated ISS Flight Utilities

During my internship at NASA Johnson Space Center, I worked in the Space Radiation Analysis Group (SRAG), where I was tasked with a number of projects focused on the automation of tasks and activities related to the operation of the International Space Station (ISS). As I worked on a number of projects, I have written short sections below to give a description for each, followed by more general remarks on the internship experience. My first project is titled "General Exposure Representation EVADOSE", also known as "GEnEVADOSE". This project involved the design and development of a C++/ ROOT framework focused on radiation exposure for extravehicular activity (EVA) planning for the ISS. The utility helps mission managers plan EVAs by displaying information on the cumulative radiation doses that crew will receive during an EVA as a function of the egress time and duration of the activity. SRAG uses a utility called EVADOSE, employing a model of the space radiation environment in low Earth orbit to predict these doses, as while outside the ISS the astronauts will have less shielding from charged particles such as electrons and protons. However, EVADOSE output is cumbersome to work with, and prior to GEnEVADOSE, querying data and producing graphs of ISS trajectories and cumulative doses versus egress time required manual work in Microsoft Excel. GEnEVADOSE automates all this work, reading in EVADOSE output file(s) along with a plaintext file input by the user providing input parameters. GEnEVADOSE will output a text file containing all the necessary dosimetry for each proposed EVA egress time, for each specified EVADOSE file. It also plots cumulative dose versus egress time and the ISS trajectory, and displays all of this information in an auto-generated presentation made in LaTeX. New features have also been added, such as best-case scenarios (egress times corresponding to the least dose), interpolated curves for trajectories, and the ability to query any time in the EVADES output. As mentioned above, GEnEVADOSE makes extensive use of ROOT version 6, the data analysis framework developed at the European Organization for Nuclear Research (CERN), and the code is written to the C++11 standard (as are the other projects). My second project is the Automated Mission Reference Exposure Utility (AMREU).Unlike GEnEVADOSE, AMREU is a combination of three frameworks written in both Python and C++, also making use of ROOT (and PyROOT). Run as a combination of daily and weekly cron jobs, these macros query the SRAG database system to determine the active ISS missions, and query minute-by-minute radiation dose information from ISS-TEPC (Tissue Equivalent Proportional Counter), one of the radiation detectors onboard the ISS. Using this information, AMREU creates a corrected data set of daily radiation doses, addressing situations where TEPC may be offline or locked up by correcting doses for days with less than 95% live time (the total amount time the instrument acquires data) by averaging the past 7 days. As not all errors may be automatically detectable, AMREU also allows for manual corrections, checking an updated plaintext file each time it runs. With the corrected data, AMREU generates cumulative dose plots for each mission, and uses a Python script to generate a flight note file (.docx format) containing these plots, as well as information sections to be filled in and modified by the space weather environment officers with information specific to the week. AMREU is set up to run without requiring any user input, and it automatically archives old flight notes and information files for missions that are no longer active. My other projects involve cleaning up a large data set from the Charged Particle Directional Spectrometer (CPDS), joining together many different data sets in order to clean up information in SRAG SQL databases, and developing other automated utilities for displaying information on active solar regions, that may be used by the space weather environment officers to monitor solar activity. I consulted my mentor Dr. Ryan Rios and Dr. Kerry Lee for project requirements and added features, and ROOT developer Edmond Offermann for advice on using the ROOT library. I also received advice and feedback from Dr. Janet Barzilla of SRAG, who tested my code. Besides these inputs, I worked independently, writing all of the code by myself. The code for all these projects is documented throughout, and I have attempted to write it in a modular format. Assuming that ROOT is updated accordingly, these codes are also Y2038-compliant (and Y10K-compliant). This allows the code to be easily referenced, modified and possibly repurposed for non-ISS missions in the future, should the necessary inputs exist. These projects have taught me a lot about coding and software design - I have become a much more skilled C++ programmer and ROOT user, and I also learned to code in Python and PyROOT (and its advantages and disadvantages compared to C++/ ROOT). Furthermore, I have learned about space radiation and radiation modeling, topics that greatly interest me as I pursue a degree in physics. Working alongside experimental physicists like Dr. Rios, I have developed a greater understanding and appreciation for experimental science, something I have always leaned towards but to which I lacked significant exposure. My work in SRAG has also given me the invaluable opportunity to witness the work environment for physicists at NASA, and what a career in academia may look like at a government laboratory such as NASA Johnson Space Center. As I continue my studies and look forward to graduate school and a future career, this experience at NASA has given me a meaningful and enjoyable opportunity to put my skills to use and see what my future career path might hold.

Offermann, Jan Tuzlic↗

Virtualization - A Key Cost Saver in NASA Multi-Mission Ground System Architecture

With science team budgets being slashed, and a lack of adequate facilities for science payload teams to operate their instruments, there is a strong need for innovative new ground systems that are able to provide necessary levels of capability processing power, system availability and redundancy while maintaining a small footprint in terms of physical space, power utilization and cooling.The ground system architecture being presented is based off of heritage from several other projects currently in development or operations at Goddard, but was designed and built specifically to meet the needs of the Science and Planetary Operations Control Center (SPOCC) as a low-cost payload command, control, planning and analysis operations center. However, this SPOCC architecture was designed to be generic enough to be re-used partially or in whole by other labs and missions (since its inception that has already happened in several cases!)The SPOCC architecture leverages a highly available VMware-based virtualization cluster with shared SAS Direct-Attached Storage (DAS) to provide an extremely high-performing, low-power-utilization and small-footprint compute environment that provides Virtual Machine resources shared among the various tenant missions in the SPOCC. The storage is also expandable, allowing future missions to chain up to 7 additional 2U chassis of storage at an extremely competitive cost if they require additional archive or virtual machine storage space.The software architecture provides a fully-redundant GMSEC-based message bus architecture based on the ActiveMQ middleware to track all health and safety status within the SPOCC ground system. All virtual machines utilize the GMSEC system agents to report system host health over the GMSEC bus, and spacecraft payload health is monitored using the Hammers Integrated Test and Operations System (ITOS) Galaxy Telemetry and Command (TC) system, which performs near-real-time limit checking and data processing on the downlinked data stream and injects messages into the GMSEC bus that are monitored to automatically page the on-call operator or Systems Administrator (SA) when an off-nominal condition is detected. This architecture, like the LTSP thin clients, are shared across all tenant missions.Other required IT security controls are implemented at the ground system level, including physical access controls, logical system-level authentication authorization management, auditing and reporting, network management and a NIST 800-53 FISMA-Moderate IT Security plan Risk Assessment Contingency Plan, helping multiple missions share the cost of compliance with agency-mandated directives.The SPOCC architecture provides science payload control centers and backup mission operations centers with a cost-effective, standardized approach to virtualizing and monitoring resources that were traditionally multiple racks full of physical machines. The increased agility in deploying new virtual systems and thin client workstations can provide significant savings in personnel costs for maintaining the ground system. The cost savings in procurement, power, rack footprint and cooling as well as the shared multi-mission design greatly reduces upfront cost for missions moving into the facility. Overall, the authors hope that this architecture will become a model for how future NASA operations centers are constructed!

Ground System Architecture↗

Land Surface Reflectances from Geostationary Sensors

GEONEX is a processing pipeline that produces a suite of satellite land surface products using data streams from the latest geostationary (GEO) sensors including the GOES016/ABI and the Himawari-8/AHI. The suite, created collaboratively by scientists from NASA and NOAA, includes top-of-atmosphere (TOA) reflectances, land surface reflectances (LSRs), vegetation indices, LAI/fPAR, and other downstream products. As a key component of the GEONEX product processing, we have adapted the Multi-Angle Implementation of Atmospheric Correction (MAIAC) algorithm to produce LSRs from the TOA data. Because the algorithm depends on building "stacks" of images, we first run internal geo-registration checks to ensure geo-spatial accuracy and consistency of the input (L1B) data before transferring them from the geostationary projection into a tile system in geographic grids. Scan-time is inferred from metadata and applied to calculate the sun-sensor angles for each grid cell. The MAIAC algorithm is run to detect clouds/shadows, estimate aerosol optical thickness (AOT), perform atmospheric corrections, and generate LSRs. We have processed 18-months (from 2016/04 onward) of AHI data over East Asia and Oceania at a 10-minute time step and 10-months (from 2018/01 onward) of ABI data over North and South Americas at a 15-minute time step. As a verification measure, we compare the GEONEX (AHI/ABI) surface reflectances with the standard MODIS products (MOD09GA) and the MODIS MAIAC products over pixels that have similar sun-view geometries. The results indicate general linear relationships between GEONEX and corresponding MODIS LSRs. In particular, the RMSEs between GEONEX and MOD09 data are comparable to those between MOD09 and MODIS MAIAC products, suggesting that the uncertainties of GEONEX LSRs fall into an acceptable range. However, direct comparisons of LSRs over pixels with different sun-view angles are not as straightforward and require more modeling efforts to correct the directional effects. Evaluation of such angular influences on the downstream products (e.g., vegetation indices) is also under investigation.

Geostationary satellite; Remote Sensing; Atmospher↗

New Development in NASA's Rodent Research Hardware for Conducting Long Duration Biomedical and Basic Research in Space

Animal models, particularly rodents, are the foundation of pre-clinical research to understand human diseases and evaluate new therapeutics, and play a key role in advancing biomedical discoveries both on Earth and in space. The National Research Councils Decadal survey emphasized the importance of expanding NASAs life sciences research to perform long duration, rodent experiments on the International Space Station (ISS). To accomplish this objective, flight hardware, operations, and science capabilities were developed at NASA Ames Research Center (ARC) to enhance science return for both commercial (CASIS) and government-sponsored rodent research. The Rodent Research program at NASA ARC has pioneered a new research capability on the International Space Station and has progressed toward translating research to the ISS utilizing commercial rockets, collaborating with academia and science industry, while training crewmembers to assist in performing research on orbit. Throughout phases of these missions, our practices, hardware and operations have evolved from tested to developed standards, and we are able to modify and customize our procedure and operations for mission specific requirements. The Rodent Research Habitat is capable of providing a living environment for animals on ISS according to standard animal welfare requirements. Using the cameras in the Habitat, the Rodent Research team has the ability to perform daily health checks on animals, and further analyze the collected videos for behavioral studies. A recent development of the Rodent Research hardware is inclusion of enrichment, to provide the animals the ability to rest and huddle. The Enrichment Hut is designed carefully for adult mice (up to 35 week old) within animal welfare, engineering, and operations constraints. The Hut is made out of the same stainless steel mesh as the cage interior, it has an ingress and an egress to allow animals move freely, and a hinge door to allow crewmembers remove the animals easily. The Rodent Research team has also developed Live Animal Return (LAR) capability, which will be implemented during Rodent Research-5 mission for the first time. The animals will be transported from the Habitat to a Transporter, which will return on the Dragon capsule and splashes down in the Pacific Ocean. Once SpaceX retrieves the Dragon, all powered payloads will be transferred to a SeaVan and transferred to the Long Beach pier. The NASA team then receives the transporter and delivers to a PI-designated laboratory within 120 mile radius of Long Beach. This is a significant improvement allowing researchers to examine animals within 72 hrs. of reentry or to conduct recovery experiments. Together, the hardware improvements and experience that the Rodent Research team has gained working with principal investigators and ISS crew to conduct complex experiments on orbit are expanding capabilities for long duration rodent research on the ISS to achieve both basic science and biomedical objectives.

ISS↗

Navigation Algorithms for the SeaWiFS Mission

The navigation algorithms for the Sea-viewing Wide Field-of-view Sensor (SeaWiFS) were designed to meet the requirement of 1-pixel accuracy-a standard deviation (sigma) of 2. The objective has been to extract the best possible accuracy from the spacecraft telemetry and avoid the need for costly manual renavigation or geometric rectification. The requirement is addressed by postprocessing of both the Global Positioning System (GPS) receiver and Attitude Control System (ACS) data in the spacecraft telemetry stream. The navigation algorithms described are separated into four areas: orbit processing, attitude sensor processing, attitude determination, and final navigation processing. There has been substantial modification during the mission of the attitude determination and attitude sensor processing algorithms. For the former, the basic approach was completely changed during the first year of the mission, from a single-frame deterministic method to a Kalman smoother. This was done for several reasons: a) to improve the overall accuracy of the attitude determination, particularly near the sub-solar point; b) to reduce discontinuities; c) to support the single-ACS-string spacecraft operation that was started after the first mission year, which causes gaps in attitude sensor coverage; and d) to handle data quality problems (which became evident after launch) in the direct-broadcast data. The changes to the attitude sensor processing algorithms primarily involved the development of a model for the Earth horizon height, also needed for single-string operation; the incorporation of improved sensor calibration data; and improved data quality checking and smoothing to handle the data quality issues. The attitude sensor alignments have also been revised multiple times, generally in conjunction with the other changes. The orbit and final navigation processing algorithms have remained largely unchanged during the mission, aside from refinements to data quality checking. Although further improvements are certainly possible, future evolution of the algorithms is expected to be limited to refinements of the methods presented here, and no substantial changes are anticipated.

Hooker, Stanford B.↗

Use Computer-Aided Tools to Parallelize Large CFD Applications

Porting applications to high performance parallel computers is always a challenging task. It is time consuming and costly. With rapid progressing in hardware architectures and increasing complexity of real applications in recent years, the problem becomes even more sever. Today, scalability and high performance are mostly involving handwritten parallel programs using message-passing libraries (e.g. MPI). However, this process is very difficult and often error-prone. The recent reemergence of shared memory parallel (SMP) architectures, such as the cache coherent Non-Uniform Memory Access (ccNUMA) architecture used in the SGI Origin 2000, show good prospects for scaling beyond hundreds of processors. Programming on an SMP is simplified by working in a globally accessible address space. The user can supply compiler directives, such as OpenMP, to parallelize the code. As an industry standard for portable implementation of parallel programs for SMPs, OpenMP is a set of compiler directives and callable runtime library routines that extend Fortran, C and C++ to express shared memory parallelism. It promises an incremental path for parallel conversion of existing software, as well as scalability and performance for a complete rewrite or an entirely new development. Perhaps the main disadvantage of programming with directives is that inserted directives may not necessarily enhance performance. In the worst cases, it can create erroneous results. While vendors have provided tools to perform error-checking and profiling, automation in directive insertion is very limited and often failed on large programs, primarily due to the lack of a thorough enough data dependence analysis. To overcome the deficiency, we have developed a toolkit, CAPO, to automatically insert OpenMP directives in Fortran programs and apply certain degrees of optimization. CAPO is aimed at taking advantage of detailed inter-procedural dependence analysis provided by CAPTools, developed by the University of Greenwich, to reduce potential errors made by users. Earlier tests on NAS Benchmarks and ARC3D have demonstrated good success of this tool. In this study, we have applied CAPO to parallelize three large applications in the area of computational fluid dynamics (CFD): OVERFLOW, TLNS3D and INS3D. These codes are widely used for solving Navier-Stokes equations with complicated boundary conditions and turbulence model in multiple zones. Each one comprises of from 50K to 1,00k lines of FORTRAN77. As an example, CAPO took 77 hours to complete the data dependence analysis of OVERFLOW on a workstation (SGI, 175MHz, R10K processor). A fair amount of effort was spent on correcting false dependencies due to lack of necessary knowledge during the analysis. Even so, CAPO provides an easy way for user to interact with the parallelization process. The OpenMP version was generated within a day after the analysis was completed. Due to sequential algorithms involved, code sections in TLNS3D and INS3D need to be restructured by hand to produce more efficient parallel codes. An included figure shows preliminary test results of the generated OVERFLOW with several test cases in single zone. The MPI data points for the small test case were taken from a handcoded MPI version. As we can see, CAPO's version has achieved 18 fold speed up on 32 nodes of the SGI O2K. For the small test case, it outperformed the MPI version. These results are very encouraging, but further work is needed. For example, although CAPO attempts to place directives on the outer- most parallel loops in an interprocedural framework, it does not insert directives based on the best manual strategy. In particular, it lacks the support of parallelization at the multi-zone level. Future work will emphasize on the development of methodology to work in a multi-zone level and with a hybrid approach. Development of tools to perform more complicated code transformation is also needed.

Jin, H.↗

NASA Integrated Network Monitor and Control Software Architecture

The National Aeronautics and Space Administration (NASA) Space Communications and Navigation office (SCaN) has commissioned a series of trade studies to define a new architecture intended to integrate the three existing networks that it operates, the Deep Space Network (DSN), Space Network (SN), and Near Earth Network (NEN), into one integrated network that offers users a set of common, standardized, services and interfaces. The integrated monitor and control architecture utilizes common software and common operator interfaces that can be deployed at all three network elements. This software uses state-of-the-art concepts such as a pool of re-programmable equipment that acts like a configurable software radio, distributed hierarchical control, and centralized management of the whole SCaN integrated network. For this trade space study a model-based approach using SysML was adopted to describe and analyze several possible options for the integrated network monitor and control architecture. This model was used to refine the design and to drive the costing of the four different software options. This trade study modeled the three existing self standing network elements at point of departure, and then described how to integrate them using variations of new and existing monitor and control system components for the different proposed deployments under consideration. This paper will describe the trade space explored, the selected system architecture, the modeling and trade study methods, and some observations on useful approaches to implementing such model based trade space representation and analysis.

Next Generation Uplink↗

Compatibility Assessment Tool

In support of ground system development for the Space Launch System (SLS), engineers are tasked with building immense engineering models of extreme complexity. The various systems require rigorous analysis of pneumatics, hydraulic, cryogenic, and hypergolic systems. There are certain standards that each of these systems must meet, in the form of pressure vessel system (PVS) certification reports. These reports can be hundreds of pages long, and require many hours to compile. Traditionally, each component is analyzed individually, often utilizing hand calculations in the design process. The objective of this opportunity is to perform these analyses in an integrated fashion with the parametric CADCAE environment. This allows for systems to be analyzed on an assembly level in a semi-automated fashion, which greatly improves accuracy and efficiency. To accomplish this, component specific parameters were stored in the Windchill database to individual Creo Parametric models based on spec control drawings. These parameters were then accessed by using the Prime Analysis within Creo Parametric. MathCAD Prime spreadsheets were created that automatically extracted these parameters, performed calculations, and generated reports. The reports described component compatibility based on local conditions such as pressure, temperature, density, and flow rates. The reports also determined component pairing compatibility, such as properly sizing relief valves with regulators. The reports stored the input conditions that were used to determine compatibility to increase traceability of component selection. The desired workflow for using this tool would begin with a Creo Schematics diagram of a PVS system. This schematic would store local conditions and locations of components. The schematic would then populate an assembly within Creo Parametric, using Windchill database parts. These parts would have their attributes already assigned, and the MathCAD spreadsheets could begin running through database parts to determine which components would be suited for specific locations within the assembly. This eliminates a significant amount of time from the design process, and makes initial analysis assessments more accurate. Each component that would be checked for a location within the assembly would generate a report, showing whether the component was compatible. These reports could be used to generate the PVS report without the need to perform the same analysis multiple times. This process also has the potential to be expanded upon to further automate PVS reports. The integration of software codes or macros could be used to automatically check through hundreds of parts for each location on the schematic. If the software could recognize which type of component would be necessary for each location, it is possible that simply starting the macro could completely choose all the components needed for the schematic, and in turn the system. This would save many hours of work initially selecting components, which could end up saving money. Overall, this process helps to automate initial component selections for PVS systems to fit local design specifications. These selections will automatically generate reports showing how the design criteria are met by the specific component that was chosen. These reports will contribute to easier compilation of the PVS certification reports, which currently take a great amount of time and effort to produce.

Egbert, James Allen↗

Cooperative Data Sharing: Simple Support for Clusters of SMP Nodes

Libraries like PVM and MPI send typed messages to allow for heterogeneous cluster computing. Lower-level libraries, such as GAM, provide more efficient access to communication by removing the need to copy messages between the interface and user space in some cases. still lower-level interfaces, such as UNET, get right down to the hardware level to provide maximum performance. However, these are all still interfaces for passing messages from one process to another, and have limited utility in a shared-memory environment, due primarily to the fact that message passing is just another term for copying. This drawback is made more pertinent by today's hybrid architectures (e.g. clusters of SMPs), where it is difficult to know beforehand whether two communicating processes will share memory. As a result, even portable language tools (like HPF compilers) must either map all interprocess communication, into message passing with the accompanying performance degradation in shared memory environments, or they must check each communication at run-time and implement the shared-memory case separately for efficiency. Cooperative Data Sharing (CDS) is a single user-level API which abstracts all communication between processes into the sharing and access coordination of memory regions, in a model which might be described as "distributed shared messages" or "large-grain distributed shared memory". As a result, the user programs to a simple latency-tolerant abstract communication specification which can be mapped efficiently to either a shared-memory or message-passing based run-time system, depending upon the available architecture. Unlike some distributed shared memory interfaces, the user still has complete control over the assignment of data to processors, the forwarding of data to its next likely destination, and the queuing of data until it is needed, so even the relatively high latency present in clusters can be accomodated. CDS does not require special use of an MMU, which can add overhead to some DSM systems, and does not require an SPMD programming model. unlike some message-passing interfaces, CDS allows the user to implement efficient demand-driven applications where processes must "fight" over data, and does not perform copying if processes share memory and do not attempt concurrent writes. CDS also supports heterogeneous computing, dynamic process creation, handlers, and a very simple thread-arbitration mechanism. Additional support for array subsections is currently being considered. The CDS1 API, which forms the kernel of CDS, is built primarily upon only 2 communication primitives, one process initiation primitive, and some data translation (and marshalling) routines, memory allocation routines, and priority control routines. The entire current collection of 28 routines provides enough functionality to implement most (or all) of MPI 1 and 2, which has a much larger interface consisting of hundreds of routines. still, the API is small enough to consider integrating into standard os interfaces for handling inter-process communication in a network-independent way. This approach would also help to solve many of the problems plaguing other higher-level standards such as MPI and PVM which must, in some cases, "play OS" to adequately address progress and process control issues. The CDS2 API, a higher level of interface roughly equivalent in functionality to MPI and to be built entirely upon CDS1, is still being designed. It is intended to add support for the equivalent of communicators, reduction and other collective operations, process topologies, additional support for process creation, and some automatic memory management. CDS2 will not exactly match MPI, because the copy-free semantics of communication from CDS1 will be supported. CDS2 application programs will be free to carefully also use CDS1. CDS1 has been implemented on networks of workstations running unmodified Unix-based operating systems, using UDP/IP and vendor-supplied high- performance locks. Although its inter-node performance is currently unimpressive due to rudimentary implementation technique, it even now outperforms highly-optimized MPI implementation on intra-node communication due to its support for non-copy communication. The similarity of the CDS1 architecture to that of other projects such as UNET and TRAP suggests that the inter-node performance can be increased significantly to surpass MPI or PVM, and it may be possible to migrate some of its functionality to communication controllers.

DiNucci, David C.↗

Influence of Nucleation Mechanisms on the Radiative Properties of Deep Convective Clouds and Subvisible Cirrus in CRYSTAL/FACE

During the past few years we have conducted work on several different topics, as reflected by our publications. As one of the Co-Project scientists for The Cirrus Regional Study of Tropical Anvils and Cirrus Layers - Florida Area Cirrus Experiment (CRYSTAL FACE) we worked to help design the mission and then conduct it in the field. Another major activity during the past two years has been to pull together various groups to formulate plans for follow on missions to CRYSTAL FACE. We organized a workshop at the University of Colorado during the summer of 2003 to assess the best locations for future missions. Working with a group of about 10 scientists from around the country we prepared a science-planning document (Tropical Composition, Cloud and Climate Coupling Experiment (TC(sup 4)) that outlined the rationale, locations, strategy to accomplish the goals, and possible payloads for a set of three tropical missions. We also prepared background materials for various NRAs being prepared at NASA Headquarters for missions in Costa Rica, Darwin and Guam. In conjunction with the group at NASA Ames we have helped build a new numerical model for deep convection and have applied that model to simulate the CRYSTAL data. Our goal in particular has been to better understand how convection distributes water vapor isotopes. CRYSTAL observations of water isotopes are very different from those suggested by previous workers who assumed the isotopes would obey Rayleigh fractionation. The water isotope study has several implications. First it is a check on the realism of the deep convection model. Second, the isotopes are a measure of the precipitation removal in the atmosphere. Hence they provide a constraint on a parameter that is difficult to otherwise measure. Finally it has been suggested that isotopes may be the key to unraveling the water transport into the stratosphere and upper troposphere. Such transport is critical both for the radiation balance and for stratospheric chemistry. Ours is the first model that is able to treat this transport. Our initial results have just been submitted to Geophys. Res. Lett (Smith et al., 2005). Essentially we are able to explain the vertical profiles of isotopes in the tropical tropopause transition layer. We are also able to account for stratospheric humidity and isotope abundances with this model. We have also been heavily involved in trying to improve our understanding of nitric acid condensation on ice. Gao et al (2004) have shown that water supersaturations above ice occur when the atmosphere is supersaturated with respect to nitric acid trihydrate. As one of the co-authors of that work, we suggested the mechanism that may explain why this is occurring. Essentially, ice does not like to grow near unit supersaturation, but does so because the water molecules can find sites on the ice surface to attach themselves to before they fly off the ice surface. This phenomena was well known in the 1960s when it was a source of debate about whether condensation and evaporation coefficients for ice would be the same. Evaporation does not require any molecular orientation, while condensation does, so it was possible that the coefficients would differ. They don't differ because the water molecules rapidly move across the surface and find places to attach. Nitric acid may be occupying these preferred sites and therefore the water molecules can't find a desirable place to attach. We anticipate that this research will be the subject of laboratory work during the coming few years. Another possibility that has been suggested is that cubic ice is forming in clouds. We have measured the vapor pressure of cubic ice, and plan to publish that result in the next few months. We have also been working on additional aspects of the condensation of nitric acid on ice. With Y. Kondo we studied the condensation of NOy on ice using the SOLVE data. Gamblin et al. have continued this work. The CRYSTAL NOy and HNO, groups have shown th their data can be fit using standard Langmuir isotherms as suggested in some, but not all, laboratory studies. We have found in the SOLVE data set that this is not the case. Moreover some laboratory studies show there are important kinetic effects that may be occurring in the atmosphere limiting the transfer of nitric acid to the ice. The SOLVE data seem consistent with these studies. We are currently re-analyzing the CRYSTAL data to look for these kinetic effects. There are a number of implications of these studies. One of the more interesting is that the nitric acid coating on ice can be used as a cloud clock to determine how long the cloud parcel has been in existence. We have also been involved with several laboratory studies. We have worked to improve the database on ice optical constants, which are critical for remote sensing. We have also studied the ways in which ice nucleates on clays. We suspect now that the standard theories used for depositional ice nucleation are completely incorrect. Further work will be needed to develop a new theory.

Toon, Owen B.↗

Simulating the Formation of Lunar Floor-Fracture Craters Using Elastoviscoplastic Relaxation

Lunar floor-fracture craters formed during the height of mare basalt emplacement. Due to a general temporal and spatial relation with the maria, these craters, numbering some 200, may be diagnostic of the thermal structure of the crust during this time. As the name suggests, these craters exhibit brittle failure, generally limited to the central floor region. That, and a shallower depth than fresh lunar craters, has led to two main theories as to their formation: laccolith emplacement under the crater and viscous relaxation. The implications of each model for the state of the Moon's crust during this time are quite different, so the viability of each model must be checked. Laccolith emplacement has been treated elsewhere. However, previous attempts to study the relaxation of the craters have assumed only a uniform, Newtonian viscous response of the near surface to the topographic driving forces, and simply postulated that the fractures resulted from tensile stresses associated with floor uplift. Here, we use a more sophisticated rheological model that includes not only non-Newtonian viscous behavior (i.e., the viscosity is stress-dependent), but also incorporates elastic behavior and a plastic component to the rheology to directly simulate the formation of the floor fractures. The results of our simulations show that while elastoviscoplastic relaxation is potentially viable for larger floor-fracture craters, it is not viable for craters with diameters < or = 60 km, the size of the majority of floor-fracture craters. We employ the finite element method, a numerical technique well suited for boundary-value problems, via the commercially available MARC software package. To test the viability of topographic relaxation, our goal is to prepare the simulations as to maximize the amount of relaxation. We take advantage of the natural axisymmetry of craters, simulating one radial plane. Initial shapes are based on data for fresh craters from Pike. To simplify implementation, a fourth order polynomial is used for the basin, while a third order inverse function is used for the rim. This form closely approximates the long-wavelength behavior of complex craters, while ignoring higher-frequency topography, save the rim. This approximation is appropriate because crater relaxation is strongly controlled by long-wavelength topography. Loading is accomplished assuming a uniform gravity field (1.62 m/s-square) and a uniform density of 2900 kg/cubic m. The initial stress state is set to be hydrostatic, with an additional pressure term to account for any overlying topography. This additional pressure term is tapered exponentially with depth. While the simulations quickly settle on a preferred stress state, and while the final solution is fairly insensitive to the choice of the e-folding depth of the taper, selecting an e-folding depth close to the diameter of the crater sets the initial stress state near the preferred state. We assume a diuranally averaged surface temperature of -20 C, and allow temperature to increase with depth at a rate of 50 K//km. Assuming a thermal conductivity of 2 W/in/K, this gradient translates to a heat flow of 100mW/square m, an extremely high value for the Moon. Temperature, of course, will not increase without bound. To maximize relaxation, we allow our temperature profile to increase linearly until it reaches the solidus (assumed to be 1200C) at a depth of 24.4 km, at which point it is kept constant. The presence of melt will drop the bulk viscosity; however, we have no rheological control for partial melts. Therefore, we make no attempt to simulate this situation. Elastoviscoplastic rheological model. In general, geologic materials can behave in three main ways: elastically, viscously (via solid-state creep), and brittly (plasticity is a continuum approach to simulate this phenomenon). We combine these three deformation mechanisms in an extended Maxwell solid, where the total strain can be broken down into a simple summation of the elastic, creep, and plastic strains. In relaxation phenomena in general, the system takes advantage of any means possible to eliminate deviatoric stresses by relaxing away the topography. Previous analyses have only modeled the viscous response. Comparatively, the elastic response in our model can augment the relaxation, to a point. This effect decreases as the elastic response becomes stiffer; indeed, in the limit of infinite elastic Young's modulus (and with no plasticity), the solution converges on the purely viscous solution. Igneous rocks common to the lunar near-surface have Young's modulii in the range of 10-100 GPa. To maximize relaxation, we use a Young's modulus of 10 GPa. (There is negligible sensitivity to the other elastic modulus, the Poisson's ratio; we use 0.25.) For the viscous response, we use a flow law for steady-state creep in thoroughly dried Columbia diabase, because the high plagioclase (about 70 vol%) and orthopyroxene (about 17 vol%) content is similar to the composition of the lunar highland crust as described by remote sensing and sample studies: noritic anorthosite. This flow law is highly non-Newtonian, i.e., the viscosity is highly stress dependent. That, and the variability with temperature, stands in strong contrast to previous examinations of lunar floor-fracture crater relaxation. To model discrete, brittle faulting, we assume "Byerlee's rule," a standard geodynamical technique. We implement this "rule" with an-angle of internal friction of about 40 deg, and a higher-than-normal cohesion of about 3.2 MPa (to approximate the breaking of unfractured rock). The actual behavior of geologic materials is more complex than in our rheological model, so the uncertainties in the plasticity do not represent the state-of-the-art error. Additional information is contained in the original.

Dombard, A. J.↗