Engineering PapersSearch

SEARCH · Engineering Papers

Results for “input file”

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 73 records · Page 4

Knowledge Graph for End-to-End Traceability of an Integrated Human-Earth System Model

Integrated human-Earth system models inform energy-water-land system dynamics and policies, yet their results are difficult to trace through input-data, model structure, scenario configurations, and solved outputs. Because this information is siloed across disconnected artifacts, process-based IAMs have historically lacked a unified, queryable representation. Such lack of traceability prevents researchers from systematically isolating the multi-sector drivers of complex outcomes (such as tracing water-scarcity results back to distant energy-system dynamics) or conducting holistic uncertainty attribution across hundreds of interacting parameters. To address this concern, our work documents the software engineering process of a knowledge graph that unifies these four layers for the Global Change Analysis Model (GCAM-USA_Reference scenario, GCAM v9.1). The graph was built as a relational property graph in DuckDB from the run’s own artifacts: the input-preparation dependency map (gcamdata chunk map), the model’s XML input files, the run configuration, and the results database (BaseX), successfully mapping the model’s declared structure. The resulting graph comprises 204,321 nodes and 1,687,814 edges across 16 node types and 15 edge types, with approximately 16.3 million time-series values stored separately to maintain structural efficiency. To ensure representation fidelity, every edge carries an epistemic-status annotation recording the warrant for the relationship (structural, provenance, dependency, or model-derived), and a machine-readable provenance ledger classifying the origin of every schema element. Evaluation against a fixed five-benchmark suite with locked baselines reports zero structural orphans, zero dangling edge endpoints, and 100% of output-producing technologies traceable to raw input files. Two interactive interfaces present the graph, including a serverless browser application built on DuckDB-Wasm. By establishing the first end-to-end provenance framework for an IAM, this work enables researchers and scientists to systematically audit complex policy scenarios, debug model structures, and trace policy-relevant outputs to their data origins in real time.

Artifical Intelligence

Tolerance and UQ4SIM: Nimble Uncertainty Documentation and Analysis Software

Ultimately, scientific numerical models need quantified output uncertainties so that modeling can evolve to better match reality. Documenting model input uncertainties and variabilities is a necessary first step toward that goal. Without known input parameter uncertainties, model sensitivities are all one can determine, and without code verification, output uncertainties are simply not reliable. The basic premise of uncertainty markup is to craft a tolerance and tagging mini-language that offers a natural, unobtrusive presentation and does not depend on parsing each type of input file format. Each file is marked up with tolerances and optionally, associated tags that serve to label the parameters and their uncertainties. The evolution of such a language, often called a Domain Specific Language or DSL, is given in [1], but in final form it parallels tolerances specified on an engineering drawing, e.g., 1 +/- 0.5, 5 +/- 10%, 2 +/- 10 where % signifies percent and o signifies order of magnitude. Tags, necessary for error propagation, can be added by placing a quotation-mark-delimited tag after the tolerance, e.g., 0.7 +/- 20% 'T_effective'. In addition, tolerances might have different underlying distributions, e.g., Uniform, Normal, or Triangular, or the tolerances may merely be intervals due to lack of knowledge (uncertainty). Finally, to address pragmatic considerations such as older models that require specific number-field formats, C-style format specifiers can be appended to the tolerance like so, 1.35 +/- 10U_3.2f. As an example of use, consider figure 1, where a chemical reaction input file is has been marked up to include tolerances and tags per table 1. Not only does the technique provide a natural method of specifying tolerances, but it also servers as in situ documentation of model uncertainties. This tolerance language comes with a utility to strip the tolerances (and tags), to provide a path to the nominal model parameter file. And, as shown in [1], having the ability to quickly mark and identify model parameter uncertainties facilitates error propagation, which in turn yield output uncertainties.

Kleb, Bil

Sierra/SD – User’s Guide for NasGen – 5.20

NasGen provides a path for migration of structural models from Nastran bulk data format (BDF) into both an Exodus mesh file and an ASCII input file for Sierra Structural Dynamics (Salinas) and Solid Mechanics (Adagio). Many tools at Sandia National Labs (SNL) use the Exodus format. This document describes capabilities and limitations of the NasGen translation software.

97 MATHEMATICS AND COMPUTING

Sierra/SD – User’s Guide for NasGen – 5.22

NasGen provides a path for migration of structural models from Nastran bulk data format (BDF) into both an Exodus mesh file and an ASCII input file for Sierra Structural Dynamics (Salinas) and Solid Mechanics (Adagio). Many tools at Sandia National Labs (SNL) use the Exodus format. This document describes capabilities and limitations of the NasGen translation software.

97 MATHEMATICS AND COMPUTING

Sierra/SD – User’s Guide for NasGen (V.5.24)

NasGen provides a path for migration of structural models from Nastran bulk data format (BDF) into both an Exodus mesh file and an ASCII input file for Sierra Structural Dynamics (Salinas) and Solid Mechanics (Adagio). Many tools at Sandia National Labs (SNL) use the Exodus format. This document describes capabilities and limitations of the NasGen translation software.

97 MATHEMATICS AND COMPUTING

Sierra/SD – User’s Guide for NasGen – 5.28

NasGen provides a path for migration of structural models from Nastran bulk data format (BDF) into both an Exodus mesh file and an ASCII input file for Sierra Structural Dynamics (Salinas) and Solid Mechanics (Adagio). Many tools at Sandia National Labs (SNL) use the Exodus format. This document describes capabilities and limitations of the NasGen translation software.

97 MATHEMATICS AND COMPUTING

Sierra/SD– User’s Guide for NasGen - 5.30

NasGen provides a path for migration of structural models from NASTRAN bulk data format (BDF) into both an Exodus mesh file and an ASCII input file for Sierra Structural Dynamics (Salinas) and Solid Mechanics (Presto). Many tools at Sandia National Labs use the Exodus format. NasGen was written specifically for Salinas and Presto but should be usable with a number of these packages.

97 MATHEMATICS AND COMPUTING

The Design and Usage of the New Data Management Features in NASTRAN

Two new data management features are installed in the April 1984 release of NASTRAN. These two features are the Rigid Format Data Base and the READFILE capability. The Rigid Format Data Base is stored on external files in card image format and can be easily maintained and expanded by the use of standard text editors. This data base provides the user and the NASTRAN maintenance contractor with an easy means for making changes to a Rigid Format or for generating new Rigid Formats without unnecessary compilations and link editing of NASTRAN. Each Rigid Format entry in the data base contains the Direct Matrix Abstraction Program (DMAP), along with the associated restart, DMAP sequence subset and substructure control flags. The READFILE capability allows an user to reference an external secondary file from the NASTRAN primary input file and to read data from this secondary file. There is no limit to the number of external secondary files that may be referenced and read.

Pamidi, P. R.

Automation of POST Cases via External Optimizer and "Artificial p2" Calculation

During early conceptual design of complex systems, speed and accuracy are often at odds with one another. While many characteristics of the design are fluctuating rapidly during this phase there is nonetheless a need to acquire accurate data from which to down-select designs as these decisions will have a large impact upon program life-cycle cost. Therefore enabling the conceptual designer to produce accurate data in a timely manner is tantamount to program viability. For conceptual design of launch vehicles, trajectory analysis and optimization is a large hurdle. Tools such as the industry standard Program to Optimize Simulated Trajectories (POST) have traditionally required an expert in the loop for setting up inputs, running the program, and analyzing the output. The solution space for trajectory analysis is in general non-linear and multi-modal requiring an experienced analyst to weed out sub-optimal designs in pursuit of the global optimum. While an experienced analyst presented with a vehicle similar to one which they have already worked on can likely produce optimal performance figures in a timely manner, as soon as the "experienced" or "similar" adjectives are invalid the process can become lengthy. In addition, an experienced analyst working on a similar vehicle may go into the analysis with preconceived ideas about what the vehicle's trajectory should look like which can result in sub-optimal performance being recorded. Thus, in any case but the ideal either time or accuracy can be sacrificed. In the authors' previous work a tool called multiPOST was created which captures the heuristics of a human analyst over the process of executing trajectory analysis with POST. However without the instincts of a human in the loop, this method relied upon Monte Carlo simulation to find successful trajectories. Overall the method has mixed results, and in the context of optimizing multiple vehicles it is inefficient in comparison to the method presented POST's internal optimizer functions like any other gradient-based optimizer. It has a specified variable to optimize whose value is represented as optval, a set of dependent constraints to meet with associated forms and tolerances whose value is represented as p2, and a set of independent variables known as the u-vector to modify in pursuit of optimality. Each of these quantities are calculated or manipulated at a certain phase within the trajectory. The optimizer is further constrained by the requirement that the input u-vector must result in a trajectory which proceeds through each of the prescribed events in the input file. For example, if the input u-vector causes the vehicle to crash before it can achieve the orbital parameters required for a parking orbit, then the run will fail without engaging the optimizer, and a p2 value of exactly zero is returned. This poses a problem, as this "non-connecting" region of the u-vector space is far larger than the "connecting" region which returns a non-zero value of p2 and can be worked on by the internal optimizer. Finding this connecting region and more specifically the global optimum within this region has traditionally required the use of an expert analyst.

Dees, Patrick D.

Inputs to GCAM-USA: IM3 Phase 2 Experiments

Overview This dataset contains XML input files for the IM3 Phase 2 version of GCAM-USA. The files are organized into two categories: Scenario-specific inputs represent hydroclimate and socioeconomic effects on water availability, heating and cooling degree-hours, and agricultural productivity. They support eight IM3 canonical scenarios: rcp45cooler_ssp3 rcp45cooler_ssp5 rcp45hotter_ssp3 rcp45hotter_ssp5 rcp85cooler_ssp3 rcp85cooler_ssp5 rcp85hotter_ssp3 rcp85hotter_ssp5 Model-improvement inputs extend GCAM-USA v5.3 with updated representations of coal and nuclear power plant retirements, electricity trade among U.S. interconnections, offshore carbon storage costs, and groundwater depletion constraints. Data structure Scenario-specific inputs rcp45_runoff/ and rcp85_runoff/XML files describing water availability by HUC2 basin under the RCP 4.5 and RCP 8.5 scenarios. rcp45_hdcd/ and rcp85_hdcd/XML files containing monthly-day and monthly-night heating and cooling degree-hours at the U.S. state level for different RCP-SSP combinations. rcp45_agyields/ and rcp85_agyields/XML files describing changes in agricultural productivity at the intersection of GCAM regions and HUC2 water basins for different RCP-SSP combinations. rcp45_emissions_pathway/The emissions-constraint XML file used to represent the RCP 4.5 pathway. Model-improvement inputs core_retire/Updates coal-fired power plant retirement schedules based on New England ISO. GCAMUSA_IM3_elec_trade_interconnect.xmlRestricts electricity trade to occur within the ERCOT, WECC, and IE interconnections. nuclear_USA.xmlUpdates the retirement schedules of the Diablo Canyon and Palisades nuclear power plants. high_cost_offshore_carbon.xmlUpdates the assumed cost of offshore carbon storage. water_supply_constrained_gleeson_5pct.xmlReplaces WaterGAP historical groundwater-depletion estimates with data from the Gleeson dataset and limits groundwater extraction to 5% of the available groundwater in each Superwell grid cell. How to use the data This dataset is designed for use with the IM3 version of GCAM-USA. Download or clone GCAM-USA from the IM3 GCAM GitHub repository at https://github.com/IMMM-SFA/gcam-core and check out the gcam-usa-im3 branch. Place the downloaded folder im3scenarios in the gcam-core/input directory while preserving the provided folder structure.

Energy

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

An analytically linearized helicopter model with improved modeling accuracy

An analytically linearized model for helicopter flight response including rotor blade dynamics and dynamic inflow, that was recently developed, was studied with the objective of increasing the understanding, the ease of use, and the accuracy of the model. The mathematical model is described along with a description of the UH-60A Black Hawk helicopter and flight test used to validate the model. To aid in utilization of the model for sensitivity analysis, a new, faster, and more efficient implementation of the model was developed. It is shown that several errors in the mathematical modeling of the system caused a reduction in accuracy. These errors in rotor force resolution, trim force and moment calculation, and rotor inertia terms were corrected along with improvements to the programming style and documentation. Use of a trim input file to drive the model is examined. Trim file errors in blade twist, control input phase angle, coning and lag angles, main and tail rotor pitch, and uniform induced velocity, were corrected. Finally, through direct comparison of the original and corrected model responses to flight test data, the effect of the corrections on overall model output is shown.

Jensen, Patrick T.

Software Aids In Graphical Depiction Of Flow Data

Interactive Data Display System (IDDS) computer program is graphical-display program designed to assist in visualization of three-dimensional flow in turbomachinery. Grid and simulation data files in PLOT3D format required for input. Able to unwrap volumetric data cone associated with centrifugal compressor and display results in easy-to-understand two- or three-dimensional plots. IDDS provides majority of visualization and analysis capability for Integrated Computational Fluid Dynamics and Experiment (ICE) system. IDDS invoked from any subsystem, or used as stand-alone package of display software. Generates contour, vector, shaded, x-y, and carpet plots. Written in C language. Input file format used by IDDS is that of PLOT3D (COSMIC item ARC-12782).

Stegeman, J. D.

Mars Reconnaissance Orbiter Wrapper Script

The MRO OLVM wrapper script software allows Mars Reconnaissance Orbiter (MRO) sequence and spacecraft engineers to rapidly simulate a spacecraft command product through a tool that simulates the onboard sequence management software (OLVM). This script parses sequence files to determine the appropriate time boundaries for the sequence, and constructs the script file to be executed by OLVM to span the entirety of the designated sequence. It then constructs script files to be executed by OLVM, constructs the appropriate file directories, populates these directories with needed input files, initiates OLVM to simulate the actual command product that will be sent to the spacecraft, and captures the results of the simulation run to an external file for later review. Additionally, the tool allows a user to manually construct the script, if desired, and then execute the script with a simple command line.

Gladden, Roy

Automatic Command Sequence Generation

Automatic Sequence Generator (Autogen) Version 3.0 software automatically generates command sequences for the Mars Reconnaissance Orbiter (MRO) and several other JPL spacecraft operated by the multi-mission support team. Autogen uses standard JPL sequencing tools like APGEN, ASP, SEQGEN, and the DOM database to automate the generation of uplink command products, Spacecraft Command Message Format (SCMF) files, and the corresponding ground command products, DSN Keywords Files (DKF). Autogen supports all the major multi-mission mission phases including the cruise, aerobraking, mapping/science, and relay mission phases. Autogen is a Perl script, which functions within the mission operations UNIX environment. It consists of two parts: a set of model files and the autogen Perl script. Autogen encodes the behaviors of the system into a model and encodes algorithms for context sensitive customizations of the modeled behaviors. The model includes knowledge of different mission phases and how the resultant command products must differ for these phases. The executable software portion of Autogen, automates the setup and use of APGEN for constructing a spacecraft activity sequence file (SASF). The setup includes file retrieval through the DOM (Distributed Object Manager), an object database used to store project files. This step retrieves all the needed input files for generating the command products. Depending on the mission phase, Autogen also uses the ASP (Automated Sequence Processor) and SEQGEN to generate the command product sent to the spacecraft. Autogen also provides the means for customizing sequences through the use of configuration files. By automating the majority of the sequencing generation process, Autogen eliminates many sequence generation errors commonly introduced by manually constructing spacecraft command sequences. Through the layering of commands into the sequence by a series of scheduling algorithms, users are able to rapidly and reliably construct the desired uplink command products. With the aid of Autogen, sequences may be produced in a matter of hours instead of weeks, with a significant reduction in the number of people on the sequence team. As a result, the uplink product generation process is significantly streamlined and mission risk is significantly reduced. Autogen is used for operations of MRO, Mars Global Surveyor (MGS), Mars Exploration Rover (MER), Mars Odyssey, and will be used for operations of Phoenix. Autogen Version 3.0 is the operational version of Autogen including the MRO adaptation for the cruise mission phase, and was also used for development of the aerobraking and mapping mission phases for MRO.

Fisher, Forest

Integrating Characteristic Arctic Vegetation in a Land Surface Model Improves Representation of Carbon Dynamics Across a Tundra Landscape: Modeling Archive

This modeling archive is in support of the Next-Generation Ecosystem Experiments in the Arctic (NGEE Arctic) publication "Integrating Characteristic Arctic Vegetation in a Land Surface Model Improves Representation of Carbon Dynamics Across a Tundra Landscape", by Murphy et al. (2025). This archive contains model input files and outputs from landscape-scale simulations conducted using ELM, the land model component of the Department of Energy’s Energy Exascale Earth System Model (E3SM), at the Council NGEE Arctic field site (Council Road mile marker 71) on Alaska’s Seward Peninsula. Input data and model output from two sets of ELM simulations are provided. The first set of simulations were conducted with the two default ELM Arctic plant functional types (PFTs; broadleaf deciduous boreal shrub and a C3 grass) and the second set of simulations were conducted with a set of nine Arctic-specific PFTs including nonvascular mosses and lichens, graminoids, forbs, evergreen dwarf shrubs, three height classes of deciduous shrubs (dwarf, low, and low to tall), and deciduous alder shrubs (Sulman et al., 2021). Parameter names and major parameter changes in the Arctic-specific PFT configuration are described in Sulman et al. (2021) and archived in the Sulman et al. (2021) dataset (see below). Simulations were spatially explicit, covering an approximately 6.4X3.3 km domain at the Council site with a spatial resolution of 100 m for a total of 2,112 simulated grid cells under each ELM PFT configuration. The modeling archive contains meteorological forcing (seven *.nc files and one *.txt file), a domain definition file (one *.nc files), land surface configuration files (two *.nc files), parameter files (two *.nc files), annual ELM output files spanning 1980-2014 (68 *.nc files), and a User’s Guide (*pdf file). Additional information on the provided files is in the “Modeling Archive Contents” section of the User’s Guide. Model outputs are aggregated to the column scale (i.e. PFT-specific outputs are not provided here).

Murphy, Bailey [ORNL] (ORCID:0000000203995221)

PUFFIn Software Modeling for Quality Management

PUFFIn (PENELOPE User Friendly Fast Interface) was designed as a fast and simple Monte Carlo simulation tool for the transport of photons and electrons, with a primary purpose as a learning and education tool for a broad range of static configurations in the radiation processing industry. Development of the PUFFIn software is funded by the Office of Radiological Security (ORS) within the United States National Nuclear Security Administration (NNSA). PUFFIn helps fill the education and knowledge gaps in the industry, as identified in reports by Fermilab (2017) and the IAEA (2020). PUFFIn uses the PENELOPE (NEA-2023) physics engine to perform simulations on static configurations. PUFFIn has support for multiple geometry types from simple, single material simulations to full 3D configurations created from CAD input files or images from X-Ray Tomography scans. PUFFin was designed to be easy for the novice user, it will generate the input and geometry files required by PENLOPE and will display the output plots within the PUFFIn interface. PUFFin is distributed for free but requires a free workshop so users can be adequately trained in its use. Workshops have been presented in the past at Texas A&M university, the Aerial-CRT facility in Strasbourg France and Jakarta Indonesia. PUFFIn simulations have been validated by 10 MeV ebeam experiments done at Aerial-CRT in France (Radiation Physics and Chemistry 222 (2024) 111774). Further user experimental comparisons were made at the medical product hands on workshop at Texas A&M in October 2024.

73 NUCLEAR PHYSICS AND RADIATION PHYSICS

An expert system shell for inferring vegetation characteristics: The learning system (tasks C and D)

This report describes the implementation of a learning system that uses a data base of historical cover type reflectance data taken at different solar zenith angles and wavelengths to learn class descriptions of classes of cover types. It has been integrated with the VEG system and requires that the VEG system be loaded to operate. VEG is the NASA VEGetation workbench - an expert system for inferring vegetation characteristics from reflectance data. The learning system provides three basic options. Using option one, the system learns class descriptions of one or more classes. Using option two, the system learns class descriptions of one or more classes and then uses the learned classes to classify an unknown sample. Using option three, the user can test the system's classification performance. The learning system can also be run in an automatic mode. In this mode, options two and three are executed on each sample from an input file. The system was developed using KEE. It is menu driven and contains a sophisticated window and mouse driven interface which guides the user through various computations. Input and output file management and data formatting facilities are also provided.

Harrison, P. Ann