Search NASA⌕ Search

SEARCH · Search NASA

Results for “Multimission”

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 325 records · Page 18
All sourcesNASA NTRSDOE OSTI
NASA NTRS2010

Assessment of Current Estimates of Global and Regional Mean Sea Level from the TOPEX/Poseidon, Jason-1, and OSTM 17-Year Record

The science value of satellite altimeter observations has grown dramatically over time as enabling models and technologies have increased the value of data acquired on both past and present missions. With the prospect of an observational time series extending into several decades from TOPEX/Poseidon through Jason-1 and the Ocean Surface Topography Mission (OSTM), and further in time with a future set of operational altimeters, researchers are pushing the bounds of current technology and modeling capability in order to monitor global sea level rate at an accuracy of a few tenths of a mm/yr. The measurement of mean sea-level change from satellite altimetry requires an extreme stability of the altimeter measurement system since the signal being measured is at the level of a few mm/yr. This means that the orbit and reference frame within which the altimeter measurements are situated, and the associated altimeter corrections, must be stable and accurate enough to permit a robust MSL estimate. Foremost, orbit quality and consistency are critical to satellite altimeter measurement accuracy. The orbit defines the altimeter reference frame, and orbit error directly affects the altimeter measurement. Orbit error remains a major component in the error budget of all past and present altimeter missions. For example, inconsistencies in the International Terrestrial Reference Frame (ITRF) used to produce the precision orbits at different times cause systematic inconsistencies to appear in the multimission time-frame between TOPEX and Jason-1, and can affect the intermission calibration of these data. In an effort to adhere to cross mission consistency, we have generated the full time series of orbits for TOPEX/Poseidon (TP), Jason-1, and OSTM based on recent improvements in the satellite force models, reference systems, and modeling strategies. The recent release of the entire revised Jason-1 Geophysical Data Records, and recalibration of the microwave radiometer correction also require the further re-examination of inter-mission consistency issues. Here we present an assessment of these recent improvements to the accuracy of the 17 -year sea surface height time series, and evaluate the subsequent impact on global and regional mean sea level estimates.

Beckley, Brian D.↗
NASA NTRS2006

Cassini Archive Tracking System

The Cassini Archive Tracking System (CATS) is a computer program that enables tracking of scientific data transfers from originators to the Planetary Data System (PDS) archives. Without CATS, there is no systematic means of locating products in the archive process or ensuring their completeness. By keeping a database of transfer communications and status, CATS enables the Cassini Project and the PDS to efficiently and accurately report on archive status. More importantly, problem areas are easily identified through customized reports that can be generated on the fly from any Web-enabled computer. A Web-browser interface and clearly defined authorization scheme provide safe distributed access to the system, where users can perform functions such as create customized reports, record a transfer, and respond to a transfer. CATS ensures that Cassini provides complete science archives to the PDS on schedule and that those archives are available to the science community by the PDS. The three-tier architecture is loosely coupled and designed for simple adaptation to multimission use. Written in the Java programming language, it is portable and can be run on any Java-enabled Web server.

Conner, Diane↗
NASA NTRS2005

Simulator of Space Communication Networks

Multimission Advanced Communications Hybrid Environment for Test and Evaluation (MACHETE) is a suite of software tools that simulates the behaviors of communication networks to be used in space exploration, and predict the performance of established and emerging space communication protocols and services. MACHETE consists of four general software systems: (1) a system for kinematic modeling of planetary and spacecraft motions; (2) a system for characterizing the engineering impact on the bandwidth and reliability of deep-space and in-situ communication links; (3) a system for generating traffic loads and modeling of protocol behaviors and state machines; and (4) a system of user-interface for performance metric visualizations. The kinematic-modeling system makes it possible to characterize space link connectivity effects, including occultations and signal losses arising from dynamic slant-range changes and antenna radiation patterns. The link-engineering system also accounts for antenna radiation patterns and other phenomena, including modulations, data rates, coding, noise, and multipath fading. The protocol system utilizes information from the kinematic-modeling and link-engineering systems to simulate operational scenarios of space missions and evaluate overall network performance. In addition, a Communications Effect Server (CES) interface for MACHETE has been developed to facilitate hybrid simulation of space communication networks with actual flight/ground software/hardware embedded in the overall system.

Clare, Loren↗
NASA NTRS2011

CCSDS Advanced Orbiting Systems Virtual Channel Access Service for QoS MACHETE Model

To support various communications requirements imposed by different missions, interplanetary communication protocols need to be designed, validated, and evaluated carefully. Multimission Advanced Communications Hybrid Environment for Test and Evaluation (MACHETE), described in "Simulator of Space Communication Networks" (NPO-41373), NASA Tech Briefs, Vol. 29, No. 8 (August 2005), p. 44, combines various tools for simulation and performance analysis of space networks. The MACHETE environment supports orbital analysis, link budget analysis, communications network simulations, and hardware-in-the-loop testing. By building abstract behavioral models of network protocols, one can validate performance after identifying the appropriate metrics of interest. The innovators have extended the MACHETE model library to include a generic link-layer Virtual Channel (VC) model supporting quality-of-service (QoS) controls based on IP streams. The main purpose of this generic Virtual Channel model addition was to interface fine-grain flow-based QoS (quality of service) between the network and MAC layers of the QualNet simulator, a commercial component of MACHETE. This software model adds the capability of mapping IP streams, based on header fields, to virtual channel numbers, allowing extended QoS handling at link layer. This feature further refines the QoS v existing at the network layer. QoS at the network layer (e.g. diffserv) supports few QoS classes, so data from one class will be aggregated together; differentiating between flows internal to a class/priority is not supported. By adding QoS classification capability between network and MAC layers through VC, one maps multiple VCs onto the same physical link. Users then specify different VC weights, and different queuing and scheduling policies at the link layer. This VC model supports system performance analysis of various virtual channel link-layer QoS queuing schemes independent of the network-layer QoS systems.

Jennings, Esther H.↗
NASA NTRS2011

MaROS: Information Management Service

This software is provided by the Mars Relay Operations Service (MaROS) task to a variety of Mars projects for the purpose of coordinating communications sessions between landed spacecraft assets and orbiting spacecraft assets at Mars. The Information Management Service centralizes a set of functions previously distributed across multiple spacecraft operations teams, and as such, greatly improves visibility into the end-to-end strategic coordination process. Most of the process revolves around the scheduling of communications sessions between the spacecraft during periods of time when a landed asset on Mars is geometrically visible by an orbiting spacecraft. These relay sessions are used to transfer data both to and from the landed asset via the orbiting asset on behalf of Earth-based spacecraft operators. This software component is an application process running as a Java virtual machine. The component provides all service interfaces via a Representational State Transfer (REST) protocol over https to external clients. There are two general interaction modes with the service: upload and download of data. For data upload, the service must execute logic specific to the upload data type and trigger any applicable calculations including pass delivery latencies and overflight conflicts. For data download, the software must retrieve and correlate requested information and deliver to the requesting client. The provision of this service enables several key advancements over legacy processes and systems. For one, this service represents the first time that end-to-end relay information is correlated into a single shared repository. The software also provides the first multimission latency calculator; previous latency calculations had been performed on a mission-by-mission basis.

Allard, Daniel A.↗
NASA NTRS2011

In Situ Surface Characterization

Operation of in situ space assets, such as rovers and landers, requires operators to acquire a thorough understanding of the environment surrounding the spacecraft. The following programs help with that understanding by providing higher-level information characterizing the surface, which is not immediately obvious by just looking at the XYZ terrain data. This software suite covers three primary programs: marsuvw, marsrough, and marsslope, and two secondary programs, which together use XYZ data derived from in situ stereo imagery to characterize the surface by determining surface normal, surface roughness, and various aspects of local slope, respectively. These programs all use the Planetary Image Geometry (PIG) library to read mission-specific data files. The programs themselves are completely multimission; all mission dependencies are handled by PIG. The input data consists of images containing XYZ locations as derived by, e.g., marsxyz. The marsuvw program determines surface normals from XYZ data by gathering XYZ points from an area around each pixel and fitting a plane to those points. Outliers are rejected, and various consistency checks are applied. The result shows the orientation of the local surface at each point as a unit vector. The program can be run in two modes: standard, which is typically used for in situ arm work, and slope, which is typically used for rover mobility. The difference is primarily due to optimizations necessary for the larger patch sizes in the slope case. The marsrough program determines surface roughness in a small area around each pixel, which is defined as the maximum peak-to-peak deviation from the plane perpendicular to the surface normal at that pixel. The marsslope program takes a surface normal file as input and derives one of several slope-like outputs from it. The outputs include slope, slope rover direction (a measure of slope radially away from the rover), slope heading, slope magnitude, northerly tilt, and solar energy (compares the slope with the Sun s location at local noon). The marsuvwproj program projects a surface normal onto an arbitrary plane in space, resulting in a normalized 3D vector, which is constrained to lie in the plane. The marsuvwrot program rotates the vectors in a surface normal file, generating a new surface normal file. It also can change coordinate systems for an existing surface normal file. While the algorithms behind this suite are not particularly unique, what makes the programs useful is their integration into the larger in situ image processing system via the PIG library. They work directly with space in situ data, understanding the appropriate image metadata fields and updating them properly. The secondary programs (marsuvwproj, marsuvwrot) were originally developed to deal with anomalous situations on Opportunity and Spirit, respectively, but may have more general applicability.

Deen, Robert G.↗
NASA NTRS2012

Quality and Consistency of the NASA Ocean Color Data Record

The NASA Ocean Biology Processing Group (OBPG) recently reprocessed the multimission ocean color time-series from SeaWiFS, MODIS-Aqua, and MODIS-Terra using common algorithms and improved instrument calibration knowledge. Here we present an analysis of the quality and consistency of the resulting ocean color retrievals, including spectral water-leaving reflectance, chlorophyll a concentration, and diffuse attenuation. Statistical analysis of satellite retrievals relative to in situ measurements will be presented for each sensor, as well as an assessment of consistency in the global time-series for the overlapping periods of the missions. Results will show that the satellite retrievals are in good agreement with in situ measurements, and that the sensor ocean color data records are highly consistent over the common mission lifespan for the global deep oceans, but with degraded agreement in higher productivity, higher complexity coastal regions.

Franz, Bryan A.↗
NASA NTRS2013

Support Routines for In Situ Image Processing

This software consists of a set of application programs that support ground-based image processing for in situ missions. These programs represent a collection of utility routines that perform miscellaneous functions in the context of the ground data system. Each one fulfills some specific need as determined via operational experience. The most unique aspect to these programs is that they are integrated into the large, in situ image processing system via the PIG (Planetary Image Geometry) library. They work directly with space in situ data, understanding the appropriate image meta-data fields and updating them properly. The programs themselves are completely multimission; all mission dependencies are handled by PIG. This suite of programs consists of: (1)marscahv: Generates a linearized, epi-polar aligned image given a stereo pair of images. These images are optimized for 1-D stereo correlations, (2) marscheckcm: Compares the camera model in an image label with one derived via kinematics modeling on the ground, (3) marschkovl: Checks the overlaps between a list of images in order to determine which might be stereo pairs. This is useful for non-traditional stereo images like long-baseline or those from an articulating arm camera, (4) marscoordtrans: Translates mosaic coordinates from one form into another, (5) marsdispcompare: Checks a Left Right stereo disparity image against a Right Left disparity image to ensure they are consistent with each other, (6) marsdispwarp: Takes one image of a stereo pair and warps it through a disparity map to create a synthetic opposite- eye image. For example, a right eye image could be transformed to look like it was taken from the left eye via this program, (7) marsfidfinder: Finds fiducial markers in an image by projecting their approximate location and then using correlation to locate the markers to subpixel accuracy. These fiducial markets are small targets attached to the spacecraft surface. This helps verify, or improve, the pointing of in situ cameras, (8) marsinvrange: Inverse of marsrange . given a range file, re-computes an XYZ file that closely matches the original. . marsproj: Projects an XYZ coordinate through the camera model, and reports the line/sample coordinates of the point in the image, (9) marsprojfid: Given the output of marsfidfinder, projects the XYZ locations and compares them to the found locations, creating a report showing the fiducial errors in each image. marsrad: Radiometrically corrects an image, (10) marsrelabel: Updates coordinate system or camera model labels in an image, (11) marstiexyz: Given a stereo pair, allows the user to interactively pick a point in each image and reports the XYZ value corresponding to that pair of locations. marsunmosaic: Extracts a single frame from a mosaic, which will be created such that it could have been an input to the original mosaic. Useful for creating simulated input frames using different camera models than the original mosaic used, and (12) merinverter: Uses an inverse lookup table to convert 8-bit telemetered data to its 12-bit original form. Can be used in other missions despite the name.

Deen, Robert G.↗
NASA NTRS2014

Cost Analysis In A Multi-Mission Operations Environment

Spacecraft control centers have evolved from dedicated, single-mission or single missiontype support to multi-mission, service-oriented support for operating a variety of mission types. At the same time, available money for projects is shrinking and competition for new missions is increasing. These factors drive the need for an accurate and flexible model to support estimating service costs for new or extended missions; the cost model in turn drives the need for an accurate and efficient approach to service cost analysis. The National Aeronautics and Space Administration (NASA) Huntsville Operations Support Center (HOSC) at Marshall Space Flight Center (MSFC) provides operations services to a variety of customers around the world. HOSC customers range from launch vehicle test flights; to International Space Station (ISS) payloads; to small, short duration missions; and has included long duration flagship missions. The HOSC recently completed a detailed analysis of service costs as part of the development of a complete service cost model. The cost analysis process required the team to address a number of issues. One of the primary issues involves the difficulty of reverse engineering individual mission costs in a highly efficient multimission environment, along with a related issue of the value of detailed metrics or data to the cost model versus the cost of obtaining accurate data. Another concern is the difficulty of balancing costs between missions of different types and size and extrapolating costs to different mission types. The cost analysis also had to address issues relating to providing shared, cloud-like services in a government environment, and then assigning an uncertainty or risk factor to cost estimates that are based on current technology, but will be executed using future technology. Finally the cost analysis needed to consider how to validate the resulting cost models taking into account the non-homogeneous nature of the available cost data and the decreasing flight rate. This paper presents the issues encountered during the HOSC cost analysis process, and the associated lessons learned. These lessons can be used when planning for a new multi-mission operations center or in the transformation from a dedicated control center to multi-center operations, as an aid in defining processes that support future cost analysis and estimation. The lessons can also be used by mature serviceoriented, multi-mission control centers to streamline or refine their cost analysis process.

Newhouse, M.↗
NASA NTRS2013

The Gravity Recovery and Interior Laboratory Mission

The Gravity Recovery and Interior Laboratory (GRAIL) mission, launched in September 2011, successfully completed its Primary Science Mission in June 2012 and is currently in Extended Mission operations. Competitively selected under a NASA Announcement of Opportunity in December 2007, GRAIL is a Discovery Program mission subject to a mandatory project cost cap. The purpose of the mission is to precisely map the gravitational field of the Moon to reveal its internal structure from crust to core, determine its thermal evolution, and extend this knowledge to other planets. The mission uses twin spacecraft flying in tandem to provide the gravity map. The GRAIL Flight System, consisting of the spacecraft and payload, was developed based on significant heritage from previous missions such an experimental U.S. Air Force satellite, the Mars Reconnaissance Orbiter (MRO) mission, and the Gravity Recovery and Climate Experiment (GRACE) mission. The Mission Operations System (MOS) was based on high-heritage multimission operations developed by NASA's Jet Propulsion Laboratory and Lockheed Martin. Both the Flight System and MOS were adapted to meet the unique challenges posed by the GRAIL mission design. This paper summarizes the implementation challenges and accomplishments of getting GRAIL ready for launch. It also discusses the in-flight challenges and experiences of operating two spacecraft, and mission results.

GRAIL↗
NASA NTRS2012

Relay Support for the Mars Science Laboratory and the Coming Decade of Mars Relay Network Evolution

In the past decade, an evolving network of Mars relay orbiters has provided telecommunication relay services to the Mars Exploration Rovers, Spirit and Opportunity, and to the Mars Phoenix Lander, enabling high-bandwidth, energy-efficient data transfer and greatly increasing the volume of science data that can be returned from the Martian surface, compared to conventional direct-to-Earth links. The current relay network, consisting of NASA's Odyssey and Mars Reconnaissance Orbiter and augmented by ESA's Mars Express Orbiter, stands ready to support the Mars Science Laboratory, scheduled to arrive at Mars on Aug 6, 2012, with new capabilities enabled by the Electra and Electra-Lite transceivers carried by MRO and MSL, respectively. The MAVEN orbiter, planned for launch in 2013, and the ExoMars/Trace Gas Orbiter, planned for launch in 2016, will replenish the on-orbit relay network as the current orbiter approach their end of life. Currently planned support scenarios for this future relay network include an ESA EDL Demonstrator Module deployed by the 2016 ExoMars/TGO orbiter, and the 2018 NASA/ESA Joint Rover, representing the first step in a multimission Mars Sample Return campaign.

MAVEN↗
NASA NTRS2014

Mars Relay Operations Service (MaROS): A Present Service Preparing for the Future

The Mars Relay Operations Service (MaROS) has been deployed by NASA's Mars Program Office and the Multimission Ground Systems and Services (MGSS) Project into mission operations to aid in the coordination of relay activities at Mars. This live system presents standardized interfaces and a centralized infrastructure to current and future participants in the Mars Relay Network for the purpose of reliably and securely exchanging and storing all relay-related planning and operations data. The initial development of this system leveraged over eight years of experience performing relay operations between the various spacecraft at Mars. Now, four years after its initial deployment, MaROS continues to undergo further refinement to better meet the needs of the Mars Relay Network. The most substantial, recent update was focused on providing capabilities needed by the Mars Science Laboratory project, which landed on Mars in August of 2012. This paper will describe the nature of that update and describe additional features being added to the system to better serve the needs of current and future Mars missions.

Gladden, Roy E.↗
NASA NTRS2014

Securing Ground Data System Applications for Space Operations

The increasing prevalence and sophistication of cyber attacks has prompted the Multimission Ground Systems and Services (MGSS) Program Office at Jet Propulsion Laboratory (JPL) to initiate the Common Access Manager (CAM) effort to protect software applications used in Ground Data Systems (GDSs) at JPL and other NASA Centers. The CAM software provides centralized services and software components used by GDS subsystems to meet access control requirements and ensure data integrity, confidentiality, and availability. In this paper we describe the CAM software; examples of its integration with spacecraft commanding software applications and an information management service; and measurements of its performance and reliability.

Security↗
NASA NTRS2015

An Updated Process for Automated Deepspace Conjunction Assessment

There is currently a high level of interest in the areas of conjunction assessment and collision avoidance from organizations conducting space operations. Current conjunction assessment activity is mainly focused on spacecraft and debris in the Earth orbital environment [1]. However, collisions are possible in other orbital environments as well [2]. This paper will focus on the current operations of and recent updates to the Multimission Automated Deep Space Conjunction Assessment Process (MADCAP) used at the Jet Propulsion Laboratory for NASA to perform conjunction assessment at Mars and the Moon. Various space agencies have satellites in orbit at Mars and the Moon with additional future missions planned. The consequences of collisions are catastrophically high. Intuitive notions predict low probability of collisions in these sparsely populated environments, but may be inaccurate due to several factors. Orbits of scientific interest often tend to have similar characteristics as do the orbits of spacecraft that provide a communications relay for surface missions. The MADCAP process is controlled by an automated scheduler which initializes analysis based on a set timetable or the appearance of new ephemeris files either locally or on the Deep Space Network (DSN) Portal. The process then generates and communicates reports which are used to facilitate collision avoidance decisions. The paper also describes the operational experience and utilization of the automated tool during periods of high activity and interest such as: the close approaches of NASA's Lunar Atmosphere & Dust Environment Explorer (LADEE) and Lunar Reconnaissance Orbiter (LRO) during the LADEE mission. In addition, special consideration was required for the treatment of missions with rapidly varying orbits and less reliable long term downtrack estimates; in particular this was necessitated by perturbations to MAVEN's orbit induced by the Martian atmosphere. The application of special techniques to non-operational spacecraft with large uncertainties is also studied. Areas for future work are also described. Although the applications discussed in this paper are in the Martian and Lunar environments, the techniques are not unique to these bodies and could be applied to other orbital environments.

collision↗
NASA NTRS2017

A New Architecture for Visualization: Open Mission Control Technologies

Open Mission Control Technologies (MCT) is a new architecture for visualisation of mission data. Driven by requirements for new mission capabilities, including distributed mission operations, access to data anywhere, customization by users, synthesis of multiple data sources, and flexibility for multi-mission adaptation, Open MCT provides users with an integrated customizable environment. Developed at NASAs Ames Research Center (ARC), in collaboration with NASAs Advanced Multimission Operations System (AMMOS) and NASAs Jet Propulsion Laboratory (JPL), Open MCT is getting its first mission use on the Jason 3 Mission, and is also available in the testbed for the Mars 2020 Rover and for development use for NASAs Resource Prospector Lunar Rover. The open source nature of the project provides for use outside of space missions, including open source contributions from a community of users. The defining features of Open MCT for mission users are data integration, end user composition and multiple views. Data integration provides access to mission data across domains in one place, making data such as activities, timelines, telemetry, imagery, event timers and procedures available in one place, without application switching. End user composition provides users with layouts, which act as a canvas to assemble visualisations. Multiple views provide the capability to view the same data in different ways, with live switching of data views in place. Open MCT is browser based, and works on the desktop as well as tablets and phones, providing access to data anywhere. An early use case for mobile data access took place on the Resource Prospector (RP) Mission Distributed Operations Test, in which rover engineers in the field were able to view telemetry on their phones. We envision this capability providing decision support to on console operators from off duty personnel. The plug-in architecture also allows for adaptation for different mission capabilities. Different data types and capabilities may be added or removed using plugins. An API provides a means to write new capabilities and to create data adaptors. Data plugins exist for mission data sources for NASA missions. Adaptors have been written by international and commercial users. Open MCT is open source. Open source enables collaborative development across organizations and also makes the product available outside of the space community, providing a potential source of usage and ideas to drive product design and development. The combination of open source with an Apache 2 license, and distribution on GitHub, has enabled an active community of users and contributors. The spectrum of users for Open MCT is, to our knowledge, unprecedented for mission software. In addition to our NASA users, we have, through open source, had users and inquires on projects ranging from Internet of Things, to radio hobbyists, to farming projects. We have an active community of contributors, enabling a flow of ideas inside and outside of the space community.

Trimble, Jay↗
NASA NTRS2017

Unusual Black Hole Binary LMC X-3: A Transient High-Mass X-Ray Binary That Is Almost Always On?

We have analyzed a rich, multimission, multiwavelength data set from the black hole X-ray binary (BHXB) LMC X-3, covering a new anomalous low state (ALS), during which the source flux falls to an unprecedentedly low and barely detectable level, and a more normal low state. Simultaneous X-ray and UV/optical monitoring data from Swift are combined with pointed observations from the Rossi X-ray Timing Explorer (RXTE) and X-ray Multi- Mirror Mission (XMM-Newton) and light curves from the Monitor of All-Sky X-ray Image (MAXI) instrument to compare the source characteristics during the ALS with those seen during the normal low state. An XMM-Newton spectrum obtained during the ALS can be modeled using an absorbed power law with Gamma = 1.41‚+/- 0.65 and a luminosity of 7.97 x 10(exp 33) erg/s (0.6-5 keV). The Swift X-ray and UV light curves indicate an X-ray lag of approx. 8 days as LMC X-3 abruptly exits the ALS, suggesting that changes in the mass accretion rate from the donor drive the X-ray lag. The normal low state displays an asymmetric profile in which the exit occurs more quickly than the entry, with minimum X-ray flux a factor of approx. 4300 brighter than during the ALS. The UV brightness of LMC X-3 in the ALS is also fainter and less variable than during normal low states. The existence of repeated ALSs in LMC X-3, as well as a comparison with other BHXBs, implies that it is very close to the transient/persistent X-ray source dividing line. We conclude that LMC X-3 is a transient source that is almost always "on."

Simultaneous X-ray and UV/optical monitoring dat↗
NASA NTRS2018

Heasim and Skyback Simulation Tools and Their Application to the Hitomi Mission

We present an introduction to the heasim multimission observation and skyback background, high-energy pseudo Monte Carlo astrophysical simulation tools. Heasim may be used to accurately and efficiently construct flexible image transport system (FITS) event files for simple or composite sources with a wide range of standard and user-defined spatial, spectral, and temporal characteristics. Skyback is designed to enable users to assess the impact of background discrete and diffuse emission on prospective observations, and skyback output may be directly input into heasim. We present a brief overview of heasim and skyback input, algorithms, usage, and output. We also introduce the sxsbranch tool that computes Hitomi soft X-ray spectrometer resolution grade branching ratios, emphasizing its application to simulations. We include several examples of particular relevance to the Hitomi mission.

Loewenstein, Michael↗