Search NASA⌕ Search

SEARCH · Search NASA

Results for “start up files”

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 91 records · Page 5
All sourcesNASA NTRSDOE OSTI
NASA NTRSDate not supplied

MISR Level 2 Aerosol parameters (MIL2ASAE_V2)

The Aerosol data contain aerosol optical depth, aerosol physical model, ancillary meteorological data, and related parameters. The aerosol data include tropospheric aerosol optical depth, Angstrom exponent and single scattering albedo on 17.6 km centers, aerosol mixture identifier and retrieval residuals, and ancillary data including assumed ozone optical depth and retrieval flags. For complete information about the aerosol mixtures, the user will need to order the MISR Aerosol Climatology Product (MIANACP) to obtain Aerosol Physical and Optical Properties (APOP) and the Mixture files. The Mixture files list up to 3 component models used in each mixture, with their relative compositional fractions, and includes ancillary information such as single scattering albedo. The APOP gives detailed information for the component particle models. [Location=GLOBAL] [Temporal_Coverage: Start_Date=2000-02-24; Stop_Date=] [Spatial_Coverage: Southernmost_Latitude=-90; Northernmost_Latitude=90; Westernmost_Longitude=-180; Easternmost_Longitude=180] [Data_Resolution: Latitude_Resolution=1.1 km - 17.6 km; Longitude_Resolution=1.1 km - 17.6 km; Horizontal_Resolution_Range=1 km - < 10 km or approximately .01 degree - < .09 degree; Temporal_Resolution=about 15 orbits/day; Temporal_Resolution_Range=Daily - < Weekly, Daily - < Weekly].

EOSDIS↗
NASA NTRS2001

Java Application Shell: A Framework for Piecing Together Java Applications

This session describes the architecture of Java Application Shell (JAS), a Swing-based framework for developing interactive Java applications. Java Application Shell is being developed by Commerce One, Inc. for NASA Goddard Space Flight Center Code 588. The purpose of JAS is to provide a framework for the development of Java applications, providing features that enable the development process to be more efficient, consistent and flexible. Fundamentally, JAS is based upon an architecture where an application is considered a collection of 'plugins'. In turn, a plug-in is a collection of Swing actions defined using XML and packaged in a jar file. Plug-ins may be local to the host platform or remotely-accessible through HTTP. Local and remote plugins are automatically discovered by JAS upon application startup; plugins may also be loaded dynamically without having to re-start the application. Using Extensible Markup Language (XML) to define actions, as opposed to hardcoding them in application logic, allows easier customization of application-specific operations by separating application logic from presentation. Through XML, a developer defines an action that may appear on any number of menus, toolbars, and buttons. Actions maintain and propagate enable/disable states and specify icons, tool-tips, titles, etc. Furthermore, JAS allows actions to be implemented using various scripting languages through the use of IBM's Bean Scripting Framework. Scripted action implementation is seamless to the end-user. In addition to action implementation, scripts may be used for application and unit-level testing. In the case of application-level testing, JAS has hooks to assist a script in simulating end-user input. JAS also provides property and user preference management, JavaHelp, Undo/Redo, Multi-Document Interface, Single-Document Interface, printing, and logging. Finally, Jini technology has also been included into the framework by means of a Jini services browser and the ability to associate services with actions. Several Java technologies have been incorporated into JAS, including Swing, Internal Frames, Java Beans, XML, JavaScript, JavaHelp, and Jini. Additional information is contained in the original extended abstract.

Miller, Philip↗
NASA NTRS2012

Particle Filtering for Model-Based Anomaly Detection in Sensor Networks

A novel technique has been developed for anomaly detection of rocket engine test stand (RETS) data. The objective was to develop a system that postprocesses a csv file containing the sensor readings and activities (time-series) from a rocket engine test, and detects any anomalies that might have occurred during the test. The output consists of the names of the sensors that show anomalous behavior, and the start and end time of each anomaly. In order to reduce the involvement of domain experts significantly, several data-driven approaches have been proposed where models are automatically acquired from the data, thus bypassing the cost and effort of building system models. Many supervised learning methods can efficiently learn operational and fault models, given large amounts of both nominal and fault data. However, for domains such as RETS data, the amount of anomalous data that is actually available is relatively small, making most supervised learning methods rather ineffective, and in general met with limited success in anomaly detection. The fundamental problem with existing approaches is that they assume that the data are iid, i.e., independent and identically distributed, which is violated in typical RETS data. None of these techniques naturally exploit the temporal information inherent in time series data from the sensor networks. There are correlations among the sensor readings, not only at the same time, but also across time. However, these approaches have not explicitly identified and exploited such correlations. Given these limitations of model-free methods, there has been renewed interest in model-based methods, specifically graphical methods that explicitly reason temporally. The Gaussian Mixture Model (GMM) in a Linear Dynamic System approach assumes that the multi-dimensional test data is a mixture of multi-variate Gaussians, and fits a given number of Gaussian clusters with the help of the wellknown Expectation Maximization (EM) algorithm. The parameters thus learned are used for calculating the joint distribution of the observations. However, this GMM assumption is essentially an approximation and signals the potential viability of non-parametric density estimators. This is the key idea underlying the new approach.

Solano, Wanda↗
NASA NTRS1981

Timeline Resource Analysis Program (TRAP): User's manual and program document

The Timeline Resource Analysis Program (TRAP), developed for scheduling and timelining problems, is described. Given an activity network, TRAP generates timeline plots, resource histograms, and tabular summaries of the network, schedules, and resource levels. It is written in ANSI FORTRAN for the Honeywell SIGMA 5 computer and operates in the interactive mode using the TEKTRONIX 4014-1 graphics terminal. The input network file may be a standard SIGMA 5 file or one generated using the Interactive Graphics Design System. The timeline plots can be displayed in two orderings: according to the sequence in which the tasks were read on input, and a waterfall sequence in which the tasks are ordered by start time. The input order is especially meaningful when the network consists of several interacting subnetworks. The waterfall sequence is helpful in assessing the project status at any point in time.

Sessler, J. G.↗
NASA NTRS1986

The CAIS 2 Project

The Common APSE Interface Set (CAIS) is a proposed MIL-STD intended to promote the portability of Ada Programming Support Environment (APSE) tools written in Ada. The standardized interfaces define a virtual operating system, from which portable tools derive their basic services, e.g., file management, input/output, communications, and process control. In the Ada world, such a virtual operating system is called a Kernel Ada Programming Support Environment (KAPSE). The CAIS is a standardized interface between KAPSEs and tools. The CAIS has been proposed as a starting point for standard interfaces to be used in the NASA Software Support Environment (SSE) for the Space Station Program. The status of the CAIS standardization effort and plans for further development are described.

Legrand, Sue↗
NASA NTRS1993

Generating Finite-Element Models Of Composite Materials

Program starts at micromechanical level, from simple inputs supplied by user. COMGEN, COmposite Model GENerator, is interactive FORTRAN program used to create wide variety of finite-element models of continuous-fiber composite materials at micromechanical level. Quickly generates batch or "session files" to be submitted to finite-element preprocessor and postprocessor program, PATRAN. COMGEN requires PATRAN to complete model.

Melis, M. E.↗
NASA NTRS2014

SCCS System SW Development

The original project to be completed, GenSim, was a Generic Simulator for Application Control Language scripts. This would mock the systems on which the scripts were meant to be run on so that you could run tests without access to the machine. Soon after the project was started, a different project took priority. Unit testing the Application Services Framework code became the focus of the team because of approaching deadlines. Communication was very important to ensure that code wasn't being duplicated and to keep the team up to date with what mock files are available to them. Because of this, daily meetings were conducted until the testing was complete.

computer programming↗
NASA NTRS2018

More Efficient Precipitation Rate Data Acquisition with the STORM Swath-Based Analysis Tool

A multitude of locations exist for acquiring satellite-derived precipitation rate data. Because the volume of data exceeds what can reasonably be analyzed manually, online tools have been developed to help researchers make more informed data acquisition decisions. Some interfaces provide sample images generated from prioritized variables to enable efficient visual inspection, while others include the ability to subset geographically to reduce the volume of the data to the area of interest. Building upon such value-added services is the STORM (the NASA Precipitation Processing System (PPS) data product ordering system) Swath-Based Analysis Tool (https://storm.pps.eosdis.nasa.gov/storm/Analysis.jsp). With it, users can compare overflights of multiple precipitation satellites simultaneously and from this make determinations about which swaths will best serve their research. They can preview these overflights with two distinct visualization tools. Finally, they can then download geographically subset swaths that have precipitation rate characteristics matching their research needs. A user starts by making up to six selections. They then select their date range of interest going back to 1997. Finally, they select a geographical region either by inputting latitude-longitude corners of a rectangle or drawing that rectangle on an interactive map. The system processes each file, determining aggregate statistics about the precipitation rates within the selected region as observed by each instrument. These statistical values are added to a time series graph as a "time remaining" counter is continuously updated. The chart is fully interactive, with detailed values displayed upon mouseover, and numerous options available upon clicking each point. Since the user is likely to need the relevant files for their own research, they can generate an order from their request. All files are geographically subset to the region of interest, and the user can use the statistical values to limit which files are added to the order. This flexibility helps to ensure researchers are only downloading the files they need for their work, making for a more efficient process both from a time-consumption and a storage perspective. This paper will introduce the Swath-Based Analysis Tool and explore its numerous features. It will discuss several use cases for precipitation scientists.

remote sensing↗
NASA NTRS2017

Electronics and Software Engineer for Robotics Project Intern

I was assigned to mentor high school students for the 2017 First Robotics Competition. Using a team based approach, I worked with the students to program the robot and applied my electrical background to build the robot from start to finish. I worked with students who had an interest in electrical engineering to teach them about voltage, current, pulse width modulation, solenoids, electromagnets, relays, DC motors, DC motor controllers, crimping and soldering electrical components, Java programming, and robotic simulation. For the simulation, we worked together to generate graphics files, write simulator description format code, operate Linux, and operate SOLIDWORKS. Upon completion of the FRC season, I transitioned over to providing full time support for the LCS hardware team. During this phase of my internship I helped my co-intern write test steps for two networking hardware DVTs , as well as run cables and update cable running lists.

Teijeiro, Antonio↗
NASA NTRS2007

Overview of TRMM Data Products and Services

November 27, 2007 marks the l0th anniversary of the launch of the Tropical Rainfall Measuring Mission (TRMM) satellite. In anticipation of this anniversary, this paper will present an overview of the various TRMM data products currently available including the standard products, near real-time products, special products, and prototype products. It also will present an easy way to obtain these data. TRMM standard products have been publicly available since a few months after launch in November 1997. TRMM is currently on version 6 of the data product. Version 3 was the "at launch" version. The approval for each of these versions came through the Joint TRMM Science Team. Standard products are divided into 3 categories: single TRMM instrument, Visible Infrared Scanner (VIRS), TRMM Microwave Imager (TMI), and Precipitation Radar (PR); combined TRMM products (PR and TMI); finally TRMM and other satellites (combined, TMI, SSMI, AMSRE, AMSU). The single TRMM instrument products are processed through 4 levels: Level lA, science data packets processed into orbital files; Level 1B and lC, geolocated data at the instrument field of view; Level 2, geolocated, geophysical parameters at the instrument field of view; Level 3, time aggregated, gridded geophysical parameters. These products are available with 24 hours of production through an anonymous ftp account on trmmopen.gsfc.nasa.gov. The TRMM data system started to produce near real-time products at the end of 1999. They are currently available only through a controlled user account. However, approval to get access to this account can be obtained by sending a note to Erich.F.Stoclter@nasa.gov providing the reason for access and contact information including a valid email. TRMM is not restricting access but needs the information to determine the usefulness of near-real time data to the general science community including applications agencies. TRMM near real-time products are swath products up to Level 2 of processing. The oldest data in the swath is generally no older than 120 minutes when it becomes available to the community. The real-time products including a VIRS level lB, a TMI parameter reduced 1B, a TMI level 2 parameter reduced rain product, a PR level 2 surface rain product, and a PR level 2 rain product with 25 vertical levels. Currently, TRMM also produces a gridded 3 hour global merged product from several radiometers including AMSU and from radiometercalibrated IR data. The paper also describes several simple-format gridded text products available fiom the trmmopen.gsfc.nasa.gov anonymous fip server denoted as 3668 products. These products were produced to provide rain estimates from the three TRMM instruments in a universal format (ASCII) that requires very little data format knowledge. The paper goes on to describe prototype L1 radiometer products that apply an early intercalibration approach that provides a starting point to be used for Global Precipitation Measurement mission radiometer products. The paper also provides a brief overview of a precipitation features data product being produced using TRMM products including the Lighting Imaging Sensor (LIS) using an algorithm developed at the University of Utah and distributed by that organization. The paper concludes with some possible changes to products that are planned for the next reprocessing cycle and special services such as geographical subsetting available to the science community.

Stocker, Erich Franz↗
NASA NTRS2009

Graphical User Interface for Simulink Integrated Performance Analysis Model

The J-2X Engine (built by Pratt & Whitney Rocketdyne,) in the Upper Stage of the Ares I Crew Launch Vehicle, will only start within a certain range of temperature and pressure for Liquid Hydrogen and Liquid Oxygen propellants. The purpose of the Simulink Integrated Performance Analysis Model is to verify that in all reasonable conditions the temperature and pressure of the propellants are within the required J-2X engine start boxes. In order to run the simulation, test variables must be entered at all reasonable values of parameters such as heat leak and mass flow rate. To make this testing process as efficient as possible in order to save the maximum amount of time and money, and to show that the J-2X engine will start when it is required to do so, a graphical user interface (GUI) was created to allow the input of values to be used as parameters in the Simulink Model, without opening or altering the contents of the model. The GUI must allow for test data to come from Microsoft Excel files, allow those values to be edited before testing, place those values into the Simulink Model, and get the output from the Simulink Model. The GUI was built using MATLAB, and will run the Simulink simulation when the Simulate option is activated. After running the simulation, the GUI will construct a new Microsoft Excel file, as well as a MATLAB matrix file, using the output values for each test of the simulation so that they may graphed and compared to other values.

Durham, R. Caitlyn↗
NASA NTRS1998

A Geometry Based Infra-Structure for Computational Analysis and Design

The computational steps traditionally taken for most engineering analysis suites (computational fluid dynamics (CFD), structural analysis, heat transfer and etc.) are: (1) Surface Generation -- usually by employing a Computer Assisted Design (CAD) system; (2) Grid Generation -- preparing the volume for the simulation; (3) Flow Solver -- producing the results at the specified operational point; (4) Post-processing Visualization -- interactively attempting to understand the results. For structural analysis, integrated systems can be obtained from a number of commercial vendors. These vendors couple directly to a number of CAD systems and are executed from within the CAD Graphical User Interface (GUI). It should be noted that the structural analysis problem is more tractable than CFD; there are fewer mesh topologies used and the grids are not as fine (this problem space does not have the length scaling issues of fluids). For CFD, these steps have worked well in the past for simple steady-state simulations at the expense of much user interaction. The data was transmitted between phases via files. In most cases, the output from a CAD system could go to Initial Graphics Exchange Specification (IGES) or Standard Exchange Program (STEP) files. The output from Grid Generators and Solvers do not really have standards though there are a couple of file formats that can be used for a subset of the gridding (i.e. PLOT3D data formats). The user would have to patch up the data or translate from one format to another to move to the next step. Sometimes this could take days. Specifically the problems with this procedure are:(1) File based -- Information flows from one step to the next via data files with formats specified for that procedure. File standards, when they exist, are wholly inadequate. For example, geometry from CAD systems (transmitted via IGES files) is defined as disjoint surfaces and curves (as well as masses of other information of no interest for the Grid Generator). This is particularly onerous for modern CAD systems based on solid modeling. The part was a proper solid and in the translation to IGES has lost this important characteristic. STEP is another standard for CAD data that exists and supports the concept of a solid. The problem with STEP is that a solid modeling geometry kernel is required to query and manipulate the data within this type of file. (2) 'Good' Geometry. A bottleneck in getting results from a solver is the construction of proper geometry to be fed to the grid generator. With 'good' geometry a grid can be constructed in tens of minutes (even with a complex configuration) using unstructured techniques. Adroit multi-block methods are not far behind. This means that a million node steady-state solution can be computed on the order of hours (using current high performance computers) starting from this 'good' geometry. Unfortunately, the geometry usually transmitted from the CAD system is not 'good' in the grid generator sense. The grid generator needs smooth closed solid geometry. It can take a week (or more) of interaction with the CAD output (sometimes by hand) before the process can begin. One way Communication. (3) One-way Communication -- All information travels on from one phase to the next. This makes procedures like node adaptation difficult when attempting to add or move nodes that sit on bounding surfaces (when the actual surface data has been lost after the grid generation phase). Until this process can be automated, more complex problems such as multi-disciplinary analysis or using the above procedure for design becomes prohibitive. There is also no way to easily deal with this system in a modular manner. One can only replace the grid generator, for example, if the software reads and writes the same files. Instead of the serial approach to analysis as described above, CAPRI takes a geometry centric approach. This makes the actual geometry (not a discretized version) accessible to all phases of the analysis. The connection to the geometry is made through an Application Programming Interface (API) and NOT a file system. This API isolates the top-level applications (grid generators, solvers and visualization components) from the geometry engine. Also this allows the replacement of one geometry kernel with another, without effecting these top-level applications. For example, if UniGraphics is used as the CAD package then Parasolid (UG's own geometry engine) can be used for all geometric queries so that no solid geometry information is lost in a translation. This is much better than STEP because when the data is queried, the same software is executed as used in the CAD system. Therefore, one analyzes the exact part that is in the CAD system. CAPRI uses the same idea as the commercial structural analysis codes but does not specify control. Software components of the CAD system are used, but the analysis suite, not the CAD operator, specifies the control of the software session. This also means that the license issues (may be) minimized and individuals need not have to know how to operate a CAD system in order to run the suite.

Haimes, Robert↗
NASA NTRS2012

Revamping Spacecraft Operational Intelligence with Splunk

So what is Splunk? Instead of giving the technical details, which you can find online, I'll tell you what it did for me. Splunk slapped everything into one place, with one uniform format, and gave me the ability to forget about all these annoying details of where it is, how to parse it, and all that. Instead, I only need to interact with Splunk to find the data I need. This sounds simple and obvious, but it's surprising what you can do once you all of your data is indexed in one place. By having your data organized, querying becomes much easier. Let's say that I want to search telemetry for a sensor_name gtemp_1 h and to return all data that is at most five minutes old. And because Splunk can hook into a real ]time stream, this data will always be up-to-date. Extending the previous example, I can now aggregate all types of data into one view based in time. In this picture, I've got transaction logs, telemetry, and downlinked files all in one page, organized by time. Even though the raw data looks completely than this, I've defined interfaces that transform it into this uniform format. This gives me a more complete picture for the question what was the spacecraft doing at this particular time? And because querying data is simple, I can start with a big block of data and whiddle it down to what I need, rather than hunting around for the individual pieces of data that I need. When we have all the data we need, we can begin widdling down the data with Splunk's Unix-like search syntax. These three examples highlights my trial-and-error attempts to find large temperature changes. I begin by showing the first 5 temperatures, only to find that they're sorted chronologically, rather than from highest temperatures to lowest temperatures. The next line shows sorting temperatures by their values, but I find that that fs not really what I want either. I want to know the delta temperatures between readings. Looking through Splunk's user manual, I find the delta function, which lets me dynamically generate new information to use in my query. With that extra piece of information, I can now return only the telemetry readings where the temperature changed by at least 10. One other useful feature I'll mention is that all of these queries can be run through Splunk's API. So any scripting language you can think of can plug right in and make these queries. This gives us the ability to build a lot of new tools.

operational intelligence↗
NASA NTRS1994

SEQ-REVIEW: A tool for reviewing and checking spacecraft sequences

A key component of JPL's strategy to make space missions faster, better and cheaper is the Advanced Multi-Mission Operations System (AMMOS), a ground software intensive system currently in use and in further development. AMMOS intends to eliminate the cost of re-engineering a ground system for each new JPL mission. This paper discusses SEQ-REVIEW, a component of AMMOS that was designed to facilitate and automate the task of reviewing and checking spacecraft sequences. SEQ-REVIEW is a smart browser for inspecting files created by other sequence generation tools in the AMMOS system. It can parse sequence-related files according to a computer-readable version of a 'Software Interface Specification' (SIS), which is a standard document for defining file formats. It lets users display one or several linked files and check simple constraints using a Basic-like 'Little Language'. SEQ-REVIEW represents the first application of the Quality Function Development (QFD) method to sequence software development at JPL. The paper will show how the requirements for SEQ-REVIEW were defined and converted into a design based on object-oriented principles. The process starts with interviews of potential users, a small but diverse group that spans multiple disciplines and 'cultures'. It continues with the development of QFD matrices that related product functions and characteristics to user-demanded qualities. These matrices are then turned into a formal Software Requirements Document (SRD). The process concludes with the design phase, in which the CRC (Class, Responsibility, Collaboration) approach was used to convert requirements into a blueprint for the final product.

Maldague, Pierre F.↗
NASA NTRS2016

Next Generation Flight Displays Using HTML5

The Human Integrated Vehicles and Environments (HIVE) lab at Johnson Space Center (JSC) is focused on bringing together inter-disciplinary talent to design and integrate innovative human interface technologies for next generation manned spacecraft. As part of this objective, my summer internship project centered on an ongoing investigation in to building flight displays using the HTML5 standard. Specifically, the goals of my project were to build and demo "flight-like" crew and wearable displays as well as create a webserver for live systems being developed by the Advanced Exploration Systems (AES) program. In parallel to my project, a LabVIEW application, called a display server, was created by the HIVE that uses an XTCE (XML (Extensible Markup Language) Telemetry and Command Exchange) parser and CCSDS (Consultative Committee for Space Data System) space packet decoder to translate telemetry items sent by the CFS (Core Flight Software) over User Datagram Protocol (UDP). It was the webserver's job to receive these UDP messages and send them to the displays. To accomplish this functionality, I utilized Node.js and the accompanying Express framework. On the display side, I was responsible for creating the power system (AMPS) displays. I did this by using HTML5, CSS and JavaScript to create web pages that could update and change dynamically based on the data they received from the webserver. At this point, I have not started on the commanding, being able to send back to the CFS, portion of the displays but hope to have this functionality working by the completion of my internship. I also created a way to test the webserver's functionality without the display server by making a JavaScript application that read in a comma-separate values (CSV) file and converted it to XML which was then sent over UDP. One of the major requirements of my project was to build everything using as little preexisting code as possible, which I accomplished by only using a handful of JavaScript libraries. As a side project, I created a model of the HIVE lab and Building 29 using SketchUp. I obtained the floorplans of the building from the JSC Geographic Information Systems (GIS), which were computer-aided design (CAD) files, and imported them into SketchUp. I then took those floorplans and created a 3D model of the building from them. Working in conjunction with the Hybrid Reality lab in Building 32, the SketchUp model was imported into Unreal Engine for use with the HTC Vive. Using the Vive, I was able to interact with the model I created in virtual reality (VR). The purpose of this side project was to be able to visualize potential lab layouts and mockup designs as they are in development in order to finalize design decisions. Pending approval, the model that I created will be used in the Build-As-You-Test: Can Hybrid Reality Improve the SE/HSI Design Process project in the fall. Getting the opportunity to work at NASA has been one of the most memorable experiences of my life. Over the course of my internship, I improved my programming and web development abilities substantially. I will take all the skills and experiences I have had while at NASA back to school with me in the fall and hope to pursue a career in the aerospace industry after graduating in the spring.

Greenwood, Brian↗
NASA NTRS2006

Various Ambiguities in Re-constructing Laser Pulse Parameters

We think that mode lock laser pulses are generated by the summation process that take place between the monochromatic EM filed frequencies as if they interact with each other as shown in equation 1. In reality, the pulse generation is a collaborative interaction process between EM fields and various material medium. When we carry out the actual mode lock analysis, we do take into account of interpaly between all the temporal dynamics of the cavity gain medium, cavity round trip time and the response time of the intra cavity element (saturable absorber, Kerr medium, etc.). that really enforces the locking of the phase of the cavity spontaneous emissions. On a conceptual level, this simplistic representation of the mode locking by Eq.1 ignores all these critical physical processes. When we try to analyze a pulsed field, again we start by representing it very much like this equation, even though we can only detect the square modulus of this complex field and loose a lot of phase related information to the detectors quantum whims and their time constants. The key parameters for a light pulse are as follows. Foremost is the (i) carrier frequency, which cannot be described or imagined without its state of undulation expressed as its (ii) phase. Next is our imagined time finite (iii) carrier envelope that provides the temporal boundary of the field amplitude strength of the undulating E-field. The final parameter is the (iv) state of polarization or the unique plane along which the strength of the E-field gradient undulates. None of these filed characteristics are made self-evident to us by the fields themselves. We do not see light. Light does not see light. Light beams pass through each other without altering each others energy distribution unless there are interacting material molecules (dipoles) within the physical volume of superposition of the beams. In contrast, we can sense the material particles. Material particles sense each other and they cannot pass through each other without interacting with (scattering from) each other. Thus the interpretation of the superposition phenomenon of multiple fields on detectors should not be lumped under the mysterious "wave-particle duality" philosophy. The phenomenon of superposition can be understood better when we focus on the actual process experienced by the detecting dipoles when allowed by QM rules, they respond to and sum all the induced stimulations due to all the superposed fields followed by the proportionate energy absorption giving rise to the fringes we observe. We will present various experimental results to illustrate our arguments. Our position is that such detector behavior driven interpretations rather than the generally implied field-field interaction driven explanations, will help us better understand the ultimate nature of light and hence invent better and newer devices and instruments.

Roychoudhuri, Chandrasekhar↗
NASA NTRS1995

Exchange, interpretation, and database-search of ion mobility spectra supported by data format JCAMP-DX

To assist peak assignment in ion mobility spectrometry it is important to have quality reference data. The reference collection should be stored in a database system which is capable of being searched using spectral or substance information. We propose to build such a database customized for ion mobility spectra. To start off with it is important to quickly reach a critical mass of data in the collection. We wish to obtain as many spectra combined with their IMS parameters as possible. Spectra suppliers will be rewarded for their participation with access to the database. To make the data exchange between users and system administration possible, it is important to define a file format specially made for the requirements of ion mobility spectra. The format should be computer readable and flexible enough for extensive comments to be included. In this document we propose a data exchange format, and we would like you to give comments on it. For the international data exchange it is important, to have a standard data exchange format. We propose to base the definition of this format on the JCAMP-DX protocol, which was developed for the exchange of infrared spectra. This standard made by the Joint Committee on Atomic and Molecular Physical Data is of a flexible design. The aim of this paper is to adopt JCAMP-DX to the special requirements of ion mobility spectra.

Baumback, J. I.↗
NASA NTRS1999

Energy Minimization of Molecular Features Observed on the (110) Face of Lysozyme Crystals

Molecular dynamics and energy minimization have been carried out using the program XPLOR to check the plausibility of a model lysozyme crystal surface. The molecular features of the (110) face of lysozyme were observed using atomic force microscopy (AFM). A model of the crystal surface was constructed using the PDB file 193L, and was used to simulate an AFM image. Molecule translations, van der Waals radii, and assumed AFM tip shape were adjusted to maximize the correlation coefficient between the experimental and simulated images. The highest degree of 0 correlation (0.92) was obtained with the molecules displaced over 6 A from their positions within the bulk of the crystal. The quality of this starting model, the extent of energy minimization, and the correlation coefficient between the final model and the experimental data will be discussed.

Perozzo, Mary A.↗