Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “interface problems”

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 1,567 records · Page 87
All sourcesNASA NTRSDOE OSTI
NASA NTRS2016

Investigating the Simulink Auto-Coding Process

Model based program design is the most clear and direct way to develop algorithms and programs for interfacing with hardware. While coding "by hand" results in a more tailored product, the ever-growing size and complexity of modern-day applications can cause the project work load to quickly become unreasonable for one programmer. This has generally been addressed by splitting the product into separate modules to allow multiple developers to work in parallel on the same project, however this introduces new potentials for errors in the process. The fluidity, reliability and robustness of the code relies on the abilities of the programmers to communicate their methods to one another; furthermore, multiple programmers invites multiple potentially differing coding styles into the same product, which can cause a loss of readability or even module incompatibility. Fortunately, Mathworks has implemented an auto-coding feature that allows programmers to design their algorithms through the use of models and diagrams in the graphical programming environment Simulink, allowing the designer to visually determine what the hardware is to do. From here, the auto-coding feature handles converting the project into another programming language. This type of approach allows the designer to clearly see how the software will be directing the hardware without the need to try and interpret large amounts of code. In addition, it speeds up the programming process, minimizing the amount of man-hours spent on a single project, thus reducing the chance of human error as well as project turnover time. One such project that has benefited from the auto-coding procedure is Ramses, a portion of the GNC flight software on-board Orion that has been implemented primarily in Simulink. Currently, however, auto-coding Ramses into C++ requires 5 hours of code generation time. This causes issues if the tool ever needs to be debugged, as this code generation will need to occur with each edit to any part of the program; additionally, this is lost time that could be spent testing and analyzing the code. This is one of the more prominent issues with the auto-coding process, and while much information is available with regard to optimizing Simulink designs to produce efficient and reliable C++ code, not much research has been made public on how to reduce the code generation time. It is of interest to develop some insight as to what causes code generation times to be so significant, and determine if there are architecture guidelines or a desirable auto-coding configuration set to assist in streamlining this step of the design process for particular applications. To address the issue at hand, the Simulink coder was studied at a foundational level. For each different component type made available by the software, the features, auto-code generation time, and the format of the generated code were analyzed and documented. Tools were developed and documented to expedite these studies, particularly in the area of automating sequential builds to ensure accurate data was obtained. Next, the Ramses model was examined in an attempt to determine the composition and the types of technologies used in the model. This enabled the development of a model that uses similar technologies, but takes a fraction of the time to auto-code to reduce the turnaround time for experimentation. Lastly, the model was used to run a wide array of experiments and collect data to obtain knowledge about where to search for bottlenecks in the Ramses model. The resulting contributions of the overall effort consist of an experimental model for further investigation into the subject, as well as several automation tools to assist in analyzing the model, and a reference document offering insight to the auto-coding process, including documentation of the tools used in the model analysis, data illustrating some potential problem areas in the auto-coding process, and recommendations on areas or practices in the current Ramses model that should be further investigated. Several skills were required to be built up over the course of the internship project. First and foremost, my Simulink skills have improved drastically, as much of my experience had been modeling electronic circuits as opposed to software models. Furthermore, I am now comfortable working with the Simulink Auto-coder, a tool I had never used until this summer; this tool also tested my critical thinking and C++ knowledge as I had to interpret the C++ code it was generating and attempt to understand how the Simulink model affected the generated code. I had come into the internship with a solid understanding of Matlab code, but had done very little in using it to automate tasks, particularly Simulink tasks; along the same lines, I had rarely used shell script to automate and interface with programs, which I gained a fair amount of experience with this summer, including how to use regular expression. Lastly, soft-skills are an area everyone can continuously improve on; having never worked with NASA engineers, which to me seem to be a completely different breed than what I am used to (commercial electronic engineers), I learned to utilize the wealth of knowledge present at JSC. I wish I had come into the internship knowing exactly how helpful everyone in my branch would be, as I would have picked up on this sooner. I hope that having gained such a strong foundation in Simulink over this summer will open the opportunity to return to work on this project, or potentially other opportunities within the division. The idea of leaving a project I devoted ten weeks to is a hard one to cope with, so having the chance to pick up where I left off sounds appealing; alternatively, I am interested to see if there are any opening in the future that would allow me to work on a project that is more in-line with my research in estimation algorithms. Regardless, this summer has been a milestone in my professional career, and I hope this has started a long-term relationship between JSC and myself. I really enjoy the thought of building on my experience here over future summers while I work to complete my PhD at Missouri University of Science and Technology.

Gualdoni, Matthew J.↗
NASA NTRS2012

OVERSMART Reporting Tool for Flow Computations Over Large Grid Systems

Structured grid solvers such as NASA's OVERFLOW compressible Navier-Stokes flow solver can generate large data files that contain convergence histories for flow equation residuals, turbulence model equation residuals, component forces and moments, and component relative motion dynamics variables. Most of today's large-scale problems can extend to hundreds of grids, and over 100 million grid points. However, due to the lack of efficient tools, only a small fraction of information contained in these files is analyzed. OVERSMART (OVERFLOW Solution Monitoring And Reporting Tool) provides a comprehensive report of solution convergence of flow computations over large, complex grid systems. It produces a one-page executive summary of the behavior of flow equation residuals, turbulence model equation residuals, and component forces and moments. Under the automatic option, a matrix of commonly viewed plots such as residual histograms, composite residuals, sub-iteration bar graphs, and component forces and moments is automatically generated. Specific plots required by the user can also be prescribed via a command file or a graphical user interface. Output is directed to the user s computer screen and/or to an html file for archival purposes. The current implementation has been targeted for the OVERFLOW flow solver, which is used to obtain a flow solution on structured overset grids. The OVERSMART framework allows easy extension to other flow solvers.

Kao, David L.↗
NASA NTRS2011

NASA's Integrated Instrument Simulator Suite for Atmospheric Remote Sensing from Spaceborne Platforms (ISSARS) and Its Role for the ACE and GPM Missions

Forward simulation is an indispensable tool for evaluation of precipitation retrieval algorithms as well as for studying snow/ice microphysics and their radiative properties. The main challenge of the implementation arises due to the size of the problem domain. To overcome this hurdle, assumptions need to be made to simplify compiles cloud microphysics. It is important that these assumptions are applied consistently throughout the simulation process. ISSARS addresses this issue by providing a computationally efficient and modular framework that can integrate currently existing models and is also capable of expanding for future development. ISSARS is designed to accommodate the simulation needs of the Aerosol/Clouds/Ecosystems (ACE) mission and the Global Precipitation Measurement (GPM) mission: radars, microwave radiometers, and optical instruments such as lidars and polarimeter. ISSARS's computation is performed in three stages: input reconditioning (IRM), electromagnetic properties (scattering/emission/absorption) calculation (SEAM), and instrument simulation (ISM). The computation is implemented as a web service while its configuration can be accessed through a web-based interface.

real-aperture instruments↗
NASA NTRS1996

Interface Configuration Experiments (ICE) Explore the Effects of Microgravity on Fluids

The Interface Configuration Experiment (ICE) is actually a series of experiments that explore the striking behavior of liquid-vapor interfaces (i.e., fluid surfaces) in a low gravity environment under which major shifts in liquid position can arise from small changes in container shape or contact angle. Although these experiments are designed to test current mathematical theory, there are numerous practical applications that could result from these studies. When designing fluid management systems for space-based operations, it is important to be able to predict the locations and configurations that fluids will assume in containers under low-gravity conditions. The increased ability to predict, and hence control, fluid interfaces is vital to systems and/or processes where capillary forces play a significant role both in space and on the Earth. Some of these applications are in general coating processes (paints, pesticides, printing, etc.), fluid transport in porous media (ground water flows, oil recovery, etc.), liquid propellant systems in space (liquid fuel and oxygen), capillary-pumped loops and heat pipes, and space-based life-support systems. In space, almost every fluid system is affected, if not dominated, by capillarity. Knowledge of the liquid-vapor interface behavior, and in particular the interface shape from which any analysis must begin, is required as a foundation to predict how these fluids will react in microgravity and on Earth. With such knowledge, system designs can be optimized, thereby decreasing costs and complexity, while increasing performance and reliability. ICE has increased, and will continue to increase this knowledge, as it probes the specific peculiarities of current theory upon which our current understanding of these effects is based. Several versions of ICE were conducted in NASA Lewis Research Center's drop towers and on the space shuttle during the first and second United States Microgravity Laboratory missions (USML-1 and USML-2). Additional tests are planned for the space shuttle and for the Russian Mir space station. These studies will focus on interfacial problems concerning surface existence, uniqueness, configuration, stability, and flow characteristics.

Source record↗
NASA NTRS2005

Formal Safety Certification of Aerospace Software

In principle, formal methods offer many advantages for aerospace software development: they can help to achieve ultra-high reliability, and they can be used to provide evidence of the reliability claims which can then be subjected to external scrutiny. However, despite years of research and many advances in the underlying formalisms of specification, semantics, and logic, formal methods are not much used in practice. In our opinion this is related to three major shortcomings. First, the application of formal methods is still expensive because they are labor- and knowledge-intensive. Second, they are difficult to scale up to complex systems because they are based on deep mathematical insights about the behavior of the systems (t.e., they rely on the "heroic proof"). Third, the proofs can be difficult to interpret, and typically stand in isolation from the original code. In this paper, we describe a tool for formally demonstrating safety-relevant aspects of aerospace software, which largely circumvents these problems. We focus on safely properties because it has been observed that safety violations such as out-of-bounds memory accesses or use of uninitialized variables constitute the majority of the errors found in the aerospace domain. In our approach, safety means that the program will not violate a set of rules that can range for the simple memory access rules to high-level flight rules. These different safety properties are formalized as different safety policies in Hoare logic, which are then used by a verification condition generator along with the code and logical annotations in order to derive formal safety conditions; these are then proven using an automated theorem prover. Our certification system is currently integrated into a model-based code generation toolset that generates the annotations together with the code. However, this automated formal certification technology is not exclusively constrained to our code generator and could, in principle, also be integrated with other code generators such as RealTime Workshop or even applied to legacy code. Our approach circumvents the historical problems with formal methods by increasing the degree of automation on all levels. The restriction to safety policies (as opposed to arbitrary functional behavior) results in simpler proof problems that can generally be solved by fully automatic theorem proves. An automated linking mechanism between the safety conditions and the code provides some of the traceability mandated by process standards such as DO-178B. An automated explanation mechanism uses semantic markup added by the verification condition generator to produce natural-language explanations of the safety conditions and thus supports their interpretation in relation to the code. It shows an automatically generated certification browser that lets users inspect the (generated) code along with the safety conditions (including textual explanations), and uses hyperlinks to automate tracing between the two levels. Here, the explanations reflect the logical structure of the safety obligation but the mechanism can in principle be customized using different sets of domain concepts. The interface also provides some limited control over the certification process itself. Our long-term goal is a seamless integration of certification, code generation, and manual coding that results in a "certified pipeline" in which specifications are automatically transformed into executable code, together with the supporting artifacts necessary for achieving and demonstrating the high level of assurance needed in the aerospace domain.

Denney, Ewen↗
NASA NTRS2009

Port-O-Sim Object Simulation Application

Port-O-Sim is a software application that supports engineering modeling and simulation of launch-range systems and subsystems, as well as the vehicles that operate on them. It is flexible, distributed, object-oriented, and realtime. A scripting language is used to configure an array of simulation objects and link them together. The script is contained in a text file, but executed and controlled using a graphical user interface. A set of modules is defined, each with input variables, output variables, and settings. These engineering models can be either linked to each other or run as standalone. The settings can be modified during execution. Since 2001, this application has been used for pre-mission failure mode training for many Range Safety Scenarios. It contains range asset link analysis, develops look-angle data, supports sky-screen site selection, drives GPS (Global Positioning System) and IMU (Inertial Measurement Unit) simulators, and can support conceptual design efforts for multiple flight programs with its capacity for rapid six-degrees-of-freedom model development. Due to the assembly of various object types into one application, the application is applicable across a wide variety of launch range problem domains.

Lanzi, Raymond J.↗
NASA NTRSDate not supplied

Demonstration of Rapid Development Through Containerization: OSE-SAT

Modern advancements in spacecraft technology have enabled engineers to develop radically smaller and lighter spacecraft, which has drastically reduced the cost of putting spacecraft into space. Despite these advancements and the shrinking cost to get spacecraft into space, space exploration is still prohibitively expensive. So much so that many space missions prefer to err on the side of caution than take on additional risk by trying newer, unproven technologies. This risk-averse mission design, while very reasonable from a program management point of view, significantly impacts engineers’ ability to solve newer, more complicated problems and limits scientists’ ability to develop more complex experiments that rely on newer technology. Often these new technologies remain stuck at lower technology readiness levels for many years due to the space community's reluctance to take on the additional risks of proving out unproven technology. The Distributed Spacecraft Autonomy (DSA) team at NASA Ames Research Center is developing a containerized solution to enable the rapid development of newer space technologies and accelerate their adoption into space missions. The Opportunistic Software Experiments for Spacecraft Autonomy Testbeds (OSE-SAT) is an on-orbit test bed that aims to reduce the amount of risk associated with newer, unproven space technologies by containerizing each experiment in its own isolated environment and providing a safe, robust, and controlled interface to access spacecraft host resources that is monitored in real time by thoroughly tested Trusted Container developed by DSA. This paper will describe DSA’s implementation of OSE-SAT and discuss the benefits, as well as challenges, of on-orbit containerization.

Aaron J Woodard↗
NASA NTRS1983

Systems and operations - Living with complexity and growth

Since the space station concept currently being developed by NASA calls for system updates and additions over a period of at least ten years following launch, attention must be given to the interfaces between station elements. Efforts have begun to develop generic fault detection, isolation, and correction techniques that could simplify on-orbit operations, maintenance and repair. An integrated hydrogen-oxygen system has been identified as the feature promising the greatest reduction in resupply costs. Scavenging excess fuel from the Space Shuttle's internal and external tanks, and using leftover Shuttle payload for fluid tankage, could supply hydrogen and oxygen for consumption in the form of propellants, fuel cell electricity, and life support gases. Advancements in cryogenic fluid management and storage technology are the keys to the design of this integrated system. Attention is given to the Interactive Design and Evaluation of Advanced Spacecraft computer-aided design and analysis system, which allows system engineers to study the integration problems presented by 40 technical modules.

Hook, W. R.↗
NASA NTRS2005

IVHM Framework for Intelligent Integration for Vehicle Health Management

Integrated Vehicle Health Management (IVHM) systems for aerospace vehicles, is the process of assessing, preserving, and restoring system functionality across flight and techniques with sensor and communication technologies for spacecraft that can generate responses through detection, diagnosis, reasoning, and adapt to system faults in support of Integrated Intelligent Vehicle Management (IIVM). These real-time responses allow the IIVM to modify the affected vehicle subsystem(s) prior to a catastrophic event. Furthermore, this framework integrates technologies which can provide a continuous, intelligent, and adaptive health state of a vehicle and use this information to improve safety and reduce costs of operations. Recent investments in avionics, health management, and controls have been directed towards IIVM. As this concept has matured, it has become clear that IIVM requires the same sensors and processing capabilities as the real-time avionics functions to support diagnosis of subsystem problems. New sensors have been proposed, in addition to augment the avionics sensors to support better system monitoring and diagnostics. As the designs have been considered, a synergy has been realized where the real-time avionics can utilize sensors proposed for diagnostics and prognostics to make better real-time decisions in response to detected failures. IIVM provides for a single system allowing modularity of functions and hardware across the vehicle. The framework that supports IIVM consists of 11 major on-board functions necessary to fully manage a space vehicle maintaining crew safety and mission objectives. These systems include the following: Guidance and Navigation; Communications and Tracking; Vehicle Monitoring; Information Transport and Integration; Vehicle Diagnostics; Vehicle Prognostics; Vehicle Mission Planning, Automated Repair and Replacement; Vehicle Control; Human Computer Interface; and Onboard Verification and Validation. Furthermore, the presented framework provides complete vehicle management which not only allows for increased crew safety and mission success through new intelligence capabilities, but also yields a mechanism for more efficient vehicle operations.

Paris, Deidre↗
NASA NTRS1986

Magnetized thermal conduction fronts

The evolution of planar thermal conduction fronts in the presence of a dynamically weak, but otherwise self-consistent, magnetic field is considered. The field is assumed to be connected and untangled. In the diffusion limit for the thermal conductivity, these fronts exhibit self-similar behavior, even in the presence of a field. The role of the field is restricted to channeling the heat flux along its lines of force, and it enters into the problem as a dimensionless angle variable. 'Combing' (or opening) of insulating field lines by the evaporative flow is explicitly demonstrated. Unless the field is nearly perpendicular to the front normal in the hot gas, insulating effects are not profound. Self-similarity breaks down if the front becomes saturated, and under certain conditions magnetized saturated conduction fronts cannot propagate: the solution characteristics of the wave equation form caustics. The physical resolution is the advent of two-fluid (nonlocal) heating. Such Coulomb-heated fronts are expected to be relatively rare in typical astrophysical systems. The large-scale effects of a magnetic field on cloud evaporation in the interstellar medium are briefly discussed, and it is suggested that these fields preclude the presence of time-independent evaporative solutions. Thermal interfaces may then continue to evolve until radiative cooling halts their development; large tracts of warm 10,000 K gas may result.

Balbus, S. A.↗
NASA NTRS1996

Analytic corrections to CFD heating predictions accounting for changes in surface catalysis

Integral boundary-layer solution techniques applicable to the problem of determining aerodynamic heating rates of hypersonic vehicles in the vicinity of stagnation points and windward centerlines are briefly summarized. A new approach for combining the insight afforded by integral boundary-layer analysis with comprehensive (but time intensive) computational fluid dynamic (CFD) flowfield solutions of the thin-layer Navier-Stokes equations is described. The approach extracts CFD derived quantities at the wall and at the boundary layer edge for inclusion in a post-processing boundary-layer analysis. It allows a designer at a workstation to address two questions, given a single CFD solution. (1) How much does the heating change for a thermal protection system with different catalytic properties than was used in the original CFD solution? (2) How does the heating change at the interface of two different TPS materials with an abrupt change in catalytic efficiency? The answer to the second question is particularly important, because abrupt changes from low to high catalytic efficiency can lead to localized increase in heating which exceeds the usually conservative estimate provided by a fully catalytic wall assumption.

Gnoffo, Peter A.↗
NASA NTRS2003

Switching Oxide Traps

We consider radiation-induced charge trapping in SiO2 dielectric layers, primarily from the point of view of CMOS devices. However, SiO2 insulators are used in many other ways, and the same defects occur in other contexts. The key studies, which determined the nature of the oxide charge traps, were done primarily on gate oxides in CMOS devices, because that was the main radiation problem in CMOS at one time. There are two major reviews of radiation-induced oxide charge trapping already in the literature, which discuss the subject in far greater detail than is possible here. The first of these was by McLean et al. in 1989, and the second, ten years later, was intended as an update, because of additional, new work that had been reported. Basically, the picture that has emerged is that ionizing radiation creates electron-hole pairs in the oxide, and the electrons have much higher mobility than the holes. Therefore, the electrons are swept out of the oxide very rapidly by any field that is present, leaving behind any holes that escape the initial recombination process. These holes then undergo a polaron hopping transport toward the Si/SiO2 interface (under positive bias). Near the interface, some fraction of them fall into deep, relatively stable, long-lived hole traps. The nature and annealing behavior of these hole traps is the main focus of this paper.

Oldham, Timothy R.↗
NASA NTRS1995

Key design issues for user terminals operating with HEO satellites

Coverage of high-latitude areas in the northern hemisphere using geostationary satellites can not be achieved with good elevation angles, and highly inclined elliptical orbits (HEO) present one possible way to overcome this problem. The high elevation angles they achieve and the relative motion of the satellites across the sky, including satellite hand-over, present a specific set of requirements for the design of user terminals, be they for communication or broadcast-reception purposed. This paper reviews key design issues for user terminals operating with satellites in highly inclined elliptical orbits. While all aspects of user terminal design are broadly covered, special emphasis is given to the antenna and RF front-end design. The types of terminals discussed include communications terminals: the hand-held, the notebook, and the vehicle-mounted types, as well as the vehicle-mounted digital audio broadcasting (DAB) receiver terminal. A number of solutions are outlined, based on tradeoffs with respect to the most significant system interface parameters such as G/T and equivalent isotropically radiated power (EIRP). Candidate antenna and front-end configurations were studied, in particular patch and helical antennas with the principal aim of deriving low cost, yet effective solutions. Issues related to achieving best EIRP for the communications terminals are presented, taking into account radiation safety limits. The differences in the design of receive only versus receive/transmit RF front-ends for HEO system terminals are highlighted and solutions for both proposed. This paper summarizes the results of internal ESTEC studies and external ESA-sponsored work concerning major user terminal parameters and design aspects performed for Archimedes -- a HEO satellite constellation for multimedia broadcasting and communications.

Stojkovic, I.↗
NASA NTRS1999

Role of Dynamic Nucleation at Moving Boundaries in Phase and Microstructure Selection

Solidification microstructures that form under steady-state growth conditions (cells, dendrites, regular eutectics, etc.) are reasonably well understood in comparison to other, more complex microstructures, which form under intrinsically non-steady-state growth conditions due to the competition between the nucleation and growth of several phases. Some important practical examples in this latter class include microstructures forming in peritectic systems in highly undercooled droplets, and in strip cast stainless steels. Prediction of phase and microstructure selection in these systems has been traditionally based on (1) heterogeneous nucleation on a static interface, and (2) comparing the relative growth rate of different phase/microstructures under steady-state growth conditions. The formation of new phases, however, occurs via nucleation on, or ahead of, a moving boundary. In addition, the actual selection process is controlled by a complex interaction between the nucleation process and the growth competition between the nuclei and the pre-existing phase under non-steady-state conditions. As a result, it is often difficult to predict which microstructure will form and which phases will be selected under prescribed processing conditions. This research addresses this critical role of nucleation at moving boundaries in the selection of phases and solidification microstructures through quantitative experiments and numerical modeling in peritectic systems. In order to create a well characterized system in which to study this problem, we focus on the directional solidification of hypo- and hyper-peritectic alloys in the two-phase region, imposing a large enough ratio of temperature gradient/growth rate (G/V(sub p)) to suppress the morphological instability of both the parent (alpha) and peritectic (Beta) phases, i.e. each phase alone would grow as a planar front. Our combined experimental and theoretical results show that, already in this simplified case, the growth competition of these two phases leads to a rich variety of microstructures that depend sensitively upon the relative importance of nucleation, diffusion, and convection.

Karma, Alain↗
NASA NTRS2002

Influence of Turbulence on the Restraint of Liquid Jets by Surface Tension in Microgravity Investigated

Microgravity poses many challenges to the designer of spacecraft tanks. Chief among these are the lack of phase separation and the need to supply vapor-free liquid or liquidfree vapor to the spacecraft processes that require fluid. One of the principal problems of phase separation is the creation of liquid jets. A jet can be created by liquid filling, settling of the fluid to one end of the tank, or even closing a valve to stop the liquid flow. Anyone who has seen a fountain knows that jets occur in normal gravity also. However, in normal gravity, the gravity controls and restricts the jet flow. In microgravity, with gravity largely absent, surface tension forces must contain jets. To model this phenomenon, a numerical method that tracks the fluid motion and the surface tension forces is required. Jacqmin has developed a phase model that converts the discrete surface tension force into a barrier function that peaks at the free surface and decays rapidly away. Previous attempts at this formulation were criticized for smearing the interface. This can be overcome by sharpening the phase function, double gridding the fluid function, and using a higher order solution for the fluid function. The solution of this equation can be rewritten as two coupled Poisson equations that also include the velocity. After the code was implemented in axisymmetric form and verified by several test cases at the NASA Glenn Research Center, the drop tower runs of Aydelott were modeled. Work last year with a laminar model was found to overpredict Aydelott's results, except at the lowest Reynolds number conditions of 400. This year, a simple turbulence model was implemented by adding a turbulent viscosity based on the mixing-length hypothesis and empirical measurements of previous works. Predictions made after this change was implemented have been much closer to experimentally observed flow patterns and geyser heights. Two model runs is shown. The first, without any turbulence correction, breaks through the free surface and strikes the far end of the tank. In the second, the turbulence spreads the jet momentum over more of the free surface, enabling the surface tension forces to turn the jet back into the bulk liquid. The model geyser height with the second model is 1.1 cm. This is quite close to the 1.5-cm geyser height measured by Aydelott.

Chato, David J.↗
NASA NTRSDate not supplied

Earth Science Data Processing With Nextflow

Earth science data processing tasks present many challenges. These tasks often process large input datasets and require scores of CPU-hours to generate results. All but the simplest tasks will be decomposed into a series of computational or data manipulation steps, also known as a scientific workflow. In order to reduce the burden of orchestrating and running the dependent processing steps, a workflow execution engine is required. This poster describes the lessons learned by the CLARREO Pathfinder (CPF) team while developing multiple scientific workflows and utilizing the open-source Nextflow engine to execute them in a cloud computing environment. The Nextflow engine is designed with the following stated goals: first, the engine does not dictate how individual steps in the task are implemented (i.e. it is language and interface agnostic); second, the engine supports easy configuration and modularity at the workflow level so that others can easily execute our workflows to reproduce results; lastly, the engine eases development by transparently scaling execution from local to remote environments. Nextflow was developed for the bioinformatics domain but is a good fit for other scientific workflows where the overall task is well-described by a dataflow diagram. The CPF team has developed Nextflow pipelines (i.e. scientific workflows) to simulate CLARREO radiance, generate large look-up tables for inter-calibration algorithms, and generate L4 intercalibration data products. These pipelines consume from single-digits to hundreds of thousands of CPU-hours. In the development and evolution of these pipelines we have discovered many design patterns, pitfalls, and solutions to common problems. Our goal is to demonstrate important aspects of how to design, implement, run, and ultimately share Nextflow pipelines in the domain of Earth science.

Aron D Bartle↗
NASA NTRS2005

The Influence of Dynamic Contact Angle on Wetting Dynamics

When surface tension forces dominate, and regardless of whether the situation is static or dynamic, the contact angle (the angle the interface between two immiscible fluids makes when it contacts a solid) is the key parameter that determines the shape of a fluid-fluid interface. The static contact angle is easy to measure and implement in models predicting static capillary surface shapes and such associated quantities as pressure drops. By contrast, when the interface moves relative to the solid (as in dynamic wetting processes) the dynamic contact angle is not identified unambiguously because it depends on the geometry of the system Consequently, its determination becomes problematic and measurements in one geometry cannot be applied in another for prediction purposes. However, knowing how to measure and use the dynamic contact angle is crucial to determine such dynamics as a microsystem throughput reliably. In this talk we will present experimental and analytical efforts aimed at resolving modeling issues present in dynamic wetting. We will review experiments that show the inadequacy of the usual hydrodynamic model when a fluid-fluid meniscus moves over a solid surface such as the wall of a small tube or duct. We will then present analytical results that show how to parametrize these problems in a predictive manner. We will illustrate these ideas by showing how to implement the method in numerical fluid mechanical calculations.

Rame, Enrique↗
NASA NTRS2012

Pattern Generator for Bench Test of Digital Boards

All efforts to develop electronic equipment reach a stage where they need a board test station for each board. The SMAP digital system consists of three board types that interact with each other using interfaces with critical timing. Each board needs to be tested individually before combining into the integrated digital electronics system. Each board needs critical timing signals from the others to be able to operate. A bench test system was developed to support test of each board. The test system produces all the outputs of the control and timing unit, and is delivered much earlier than the timing unit. Timing signals are treated as data. A large file is generated containing the state of every timing signal at any instant. This file is streamed out to an IO card, which is wired directly to the device-under-test (DUT) input pins. This provides a flexible test environment that can be adapted to any of the boards required to test in a standalone configuration. The problem of generating the critical timing signals is then transferred from a hardware problem to a software problem where it is more easily dealt with.

Berkun, Andrew C.↗