Meteoroid Engineering Model (MEM)
Web Application User Guide

1  Introduction

The Meteoroid Engineering Model (MEM) version 3 is NASA’s most current and accurate model of the meteoroid environment.  MEM 3 supersedes all previous versions of MEM, including MEM Release 2.0 (MEMR2), MEM Release 1.0c (MEMR1c), and previously internally controlled and released versions of MEMCxP v2.0 and LunarMEM v2.0.  Earlier versions of MEM superseded older models of the meteoroid environment such as the Grün model and its derivative, Technical Memo 4527 (LAST, YEAR; hereafter abbreviated as TM 4527).!!tm4527

1.1  History

Prior to the establishment of the NASA Meteoroid Environment Office (MEO), NASA’s meteoroid environment models relied on a simple empirical expression derived from LAST (YEAR),!!ref2 as described in LAST (YEAR)!!ref3 and later in TM 4527.!!tm4527  This expression describes the meteoroid flux incident on a flat plate near 1 au.  TM 4527 assumes an isotropic environment, making the orientation of the plate irrelevant.!!ref4  The flux was combined with scale factors to account for the reduction in flux occurring when the Earth shields the spacecraft from a portion of the meteoroid environment and the enhancement in flux due to the focusing effect of Earth’s gravitational field.  TM 4527 also introduced a crude, piecewise meteoroid speed distribution with an average velocity of 19 km/s for an orbiting spacecraft based on LAST (YEAR).!!ref5  Finally, TM 4527 assumed a three-step density distribution in which dust particles smaller than 10^–⁠6 g have a density of 2 g/cm³, micrometeoroids between 10^–⁠6 g and 0.01 g have a density of 1 g/cm³, and meteoroids larger than 0.01 g have a density of 0.5 g/cm³.  Thus, the meteoroid model presented in TM 4527 was assembled from multiple independent sources.

Although TM 4527 was the first effort to build a comprehensive model of the meteoroid environment, it was never formally peer-reviewed and does not accurately reproduce crater counts on low-Earth-orbiting spacecraft.!!ref6  As a result, TM 4527 underrepresents the risk of meteoroid impacts posed to spacecraft in low Earth orbit.  The subsequent review of NASA’s meteoroid models by several independent boards led to the development of a new model whose flux and speed were consistent with the observations and physics.  This model forms the basis of MEM and is briefly described in section 2.

The MEO was established under the Office of Safety and Mission Assurance (OSMA) in October 2004 at Marshall Space Flight Center.  The MEO is responsible for defining the meteoroid environment and providing support to NASA programs and projects for spacecraft engineering and operations.  To accomplish this task, the MEO funds and conducts research in various areas of meteor science to develop engineering environment models for NASA programs and projects.  The formation of this office is due in large part to several independent study and panel recommendations such as the report of the Columbia Accident Investigation Board.!!ref7  These reports agreed that current meteoroid environment models were inadequate and that a central NASA technical authority should be designated to coordinate the development and review of an agency-wide meteoroid model.  MEM was developed to meet this need.

1.2  Requirements

MEM’s target audience is spacecraft design engineers and analysts, and its intended purpose is to provide a meteoroid environment description suitable for performing risk assessments of particle penetration.  To meet the needs of its target audience, MEM must provide an accurate description of the environment in a useful format and with minimal computation time.  Like all engineering environment models, it must describe the environment in terms that are useful to the design engineer in the particle range considered threatening to spacecraft.

The risk of spacecraft penetration is higher when the number of incident particles is larger; thus, MEM’s key output is meteoroid flux.  However, the response of spacecraft shield materials to a meteoroid impact depends on the particle’s size, density, relative speed, and impact angle.  The smallest particle capable of damaging a spacecraft component is determined by ballistic limit equations (or BLEs), which take all of these properties as inputs; see LAST (YEAR)!!ref8 for example BLEs.  Additionally, determining the directionality of the environment is critical for planning shield placement.  To meet these needs, MEM reports not only the total meteoroid flux but also the flux as a function of speed and direction for a user-determined minimum meteoroid mass.

Note that meteoroid environments are typically described using grams for the unit of mass, whereas orbital debris environment descriptions use size in cm or mm.  This is because the fundamental equations of meteor physics have mass as the primary variable, while orbital debris measurements are based on radar cross-section (size).  However, if needed, users may convert mass to a range of sizes using MEM 3’s bulk density distributions.  The bulk density also factors into most ballistic limit equations and is thus a required output of the model.

1.3  Limitations

Engineering environment models support programs and projects in the design phase of the spacecraft life cycle.  They are not meant to predict the short-term perturbations (such as meteor showers) that may occur during a specific year or month of a mission nor do they capture the long-term changes that take place as the environment evolves over tens of thousands of years.  For the purposes of planning a mission, the meteoroid environment in the year 2020 is no different than the environment in the year 2000; the changes that take place over a 20-year period pale in comparison to the differences in the meteoroid flux relative to two different spacecraft trajectories.  Therefore, MEM describes only the sporadic meteoroid complex, or background meteoroid environment, which is constant from year to year.

It was previously believed that MEM—and other models based on the Grün flux!!ref2—included meteor showers in an average sense.  Recent work!!ref9 indicates that this is not the case; showers pose an additional risk that is not captured by MEM.  However, at MEM’s lower mass limit of 1 μg, showers produce about 1% of the flux, which is well within the uncertainty in the sporadic flux.  Showers contribute a larger fraction of the flux when the limiting mass is larger, but the shower fraction is less than 10% for particles smaller than about half a centimeter in diameter.  The MEO models meteor showers, storms, and outbursts separately; an annual meteor shower forecast for low Earth orbit is made publicly available through the NASA Technical Reports Server (click here for an example) and the MEO produces custom forecasts for programs and projects on request.

MEM also restricts its environment description to particles sizes that are considered to be potentially damaging.  Space shuttle radiators, for instance, were sensitive to impacts from debris particles as small as 100 microns in diameter.!!ref10  MEM takes these findings into account by modeling meteoroids as small as 10^–⁠6 g, which corresponds to 124 microns in diameter for a density of 1 g/cm.!!ref3  Particles smaller than this limit are considered “dust” and are not modeled.  Therefore, MEM is not an appropriate choice for modeling the degradation of sensitive surfaces such as optics or solar arrays by interplanetary dust.

MEM describes the meteoroid environment in the inner solar system between heliocentric distances of 0.2 and 2 au.  It cannot be used to assess meteoroid impact risk outside this region.  Gravitational focusing and shielding effects are computed for the Earth, Moon, Mercury, Venus, and Mars but not the Martian moons, comets, or asteroids.

All versions of MEM up to and including 3.0 are appropriate only for spacecraft that remain near the ecliptic plane.  This is true of all Earth-orbiting spacecraft and most interplanetary spacecraft.  However, MEM 3.0 cannot be used to model the meteoroid environment experienced by the rare spacecraft, such as Ulysses, that travels far from the ecliptic.

1.4  Version history

MEM version 1.0, May 2004: The first version released was valid only for interplanetary spacecraft.  The graphical user interface (GUI) was very simple and required only an input file name and output file name.  The model produced two output files: one described average fluxes and speeds for the surfaces of a basic cube-shaped spacecraft, while the other file provided a composite speed distribution.

MEM version 1.5, September 2004: Version 1.5 was also valid only for interplanetary spacecraft, but offered an updated GUI and help files.  The source code was revised to produce results for additional surfaces and the output file formatting was modified.  The speed distribution output was changed to a normalized distribution.

MEM release 1.0, February 2007: Starting with MEM release 1.0, a single MEM release included two sub-models.  This release contained an interplanetary meteoroid model (IPMEM version 1.6) and a newly developed EarthMEM model (version 1.0) for Earth-orbiting spacecraft.  The output files were updated to include new output values and surface distributions.  A new summary table was added at the end of the main results that described the average environment for all input states.  A gravitational focusing algorithm and planet-centered state vector input coordinate frame option were introduced for EarthMEM.  Users were given a choice of output angular resolution and velocity bin size for output data display.  Errors were fixed in the velocity distribution output file rendering and penetration equation flux calculations.  Memory allocation and array accessing improvements were included.

MEM release 1.0a, December 2007: IPMEM was updated to correct a variable initialization bug in the calculation of the SpdDist.out output file.  The word “Normalized” was removed from the velocity distribution output files in both IPMEM and EarthMEM.  Both models’ help files were updated.  The IPMEM version number was incremented to 1.6a.

MEM release 1.0b, January 2008: The flux averaging technique used to produce the summary table in the main results file for both IPMEM and EarthMEM was changed to use a flux-weighted averaging scheme.  All distributions in the main results file and velocity distribution file reported fractional fluxes rather than normalized fluxes.  All average surface speed values in the summary table were calculated from their respective distributions.  IPMEM received a bug fix to correct the use of a non-normalized unit vector to calculate the \(+z\) surface flux distribution.  The velocity distribution output file calculation method was made consistent with the speed distribution and direction output file.  Both help files were updated.  IPMEM and EarthMEM model numbers were incremented to 2.0.

MEM release 1.0c, January 2008: IPMEM and EarthMEM were updated to fix the sunward and anti-sunward surface speeds in the main results file.  This repaired the problem discussed in the special note sent to users about MEMR1b and removed the need for a user workaround.  Additionally, the “About” dialogs in the GUI and the help files were updated to display the correct version numbering.

MEMCxP v1.0, May 2007: MEMCxP denotes a special version of MEM released to the Constellation Program and its support contractors.  This version was a variation of the EarthMEM model from MEM Release 1.0c.  A random draw routine was developed to randomly sample points from the input state vector file (saving run time for month- or year-long missions).  The random-draw feature enabled the computation of basic statistical quantities such as the average and standard deviation of the flux.  Note that this standard deviation does not represent the uncertainty in the environment; rather, it quantifies the variation in flux experienced along the chosen trajectory.  A new output file was developed to support the use of MEM results with the risk assessment code BUMPER.  This output file reports fluxes within a “threat igloo”; i.e., it reports the flux per speed bin for quasi-equal area igloo bins in azimuth and elevation in the body-centered frame.  User options to select output file resolution for the igloo maps and speed distribution maps were made available in this version.

LunarMEM v1.0, November 2007: This version included several additional enhancements.  A sequential read option was added to allow users to choose between reading states sequentially or randomly selecting points from the input state vector.  Memory allocation was improved, and a bug was fixed in the averaging of distributions for the main output file.

MEMCxP v2.0, January 2008: This version included several additional enhancements.  A sequential read option was added to allow users to choose between reading states sequentially or randomly selecting points from the input state vector.  Memory allocation was improved, and a bug was fixed in the averaging of distributions for the main output file.

LunarMEM v2.0, January 2008: This version fixed a bug in the averaging of distributions in the main output file.

MEMR2.0, October 2013: MEMR2 included three sub-models: EarthMEM, IPMEM, and LunarMEM.  This release repackaged and updated these individual sub-models with new user options for turning off output files, improved random number generation, threat igloo output files, combined output resolution selection, speed distribution plotting, an expanded user’s guide, and a speed distribution correction for EarthMEM that better matches radar meteor observations.  MEMR2 did not include the penetrating flux calculation capability found in MEMR1c.  MEMR2.0 was the first version of MEMR2 and was provided only to a select group of beta testers.

MEMR2.0.1, January 2014: This point release repaired a software bug in which occasional negative fluxes occurred in the Earth sub-model.

MEMR2.0.2, March 2014: This point release included one improvement and one bug fix.  First, it ensured that the main results file was overwritten for each new run, even if the user did not change the file name.  This made it less likely that the user would obtain erroneous fluxes by leaving the results of previous runs in the working directory.  Second, MEMR2.0.1 fixed a GUI bug in which it was impossible to change the sub-model choice after clicking the lunar sub-model option.

MEMR2.0.4, September 2014: This point release fixed two additional user-reported bugs.  First, it fixed a bug in which the software quit without completing post-processing when the random draw feature was used in conjunction with the interplanetary sub-model.  Second, it fixed a bug in which MEM processed only the first 48 TLEs provided by the user.

MEMR2.0.5, July 2015: This point release corrected the calculation of the meteoroid flux onto rotating surfaces.  Prior versions simply reported the average of the flux on four sides of a stationary cube, which can over- or underreport portions of the meteoroid environment by up to 30%.  MEMR2.0.5 reports the flux on the rotating surface correctly (see sec. 4.2.3).  MEMR2.0.5 also corrected a minor bug in which the rotation mode was marked incorrectly in the output file headers, and improved the text alignment in the output files.  The improved random number generation algorithm introduced in MEMR2 for state vector selection was applied throughout the code; users may have seen differences in the output values of approximately 1%.  Finally, the code was changed to make use of double floating point precision for all calculations.

MEM 3.0, May 2019: MEM 3 offers far more than an incremental improvement over previous versions.  The code base was completely refactored and simplified.  The modeling algorithms were corrected and new density distributions were added.  Sub-models were completely eliminated in favor of a more streamlined approach.  A new GUI was designed from scratch and a separate command-line executable was generated.  Section 1.5 of LAST (YEAR)!!ref11 lists the most significant changes between MEM 3 and MEMR2.

MEM 3.0.1, July 2019: This minor point release ensures that no meteoroid flux is encountered at locations inside a planet or Moon.

MEM 3.0.6-beta, March 2022: We have now converted the user interface to a web application; users no longer have to install any software.  Minor changes have also been made to MEM's algorithms; for instance, we have replaced the proprietary random number generator with a native C++ Mersenne Twister 19937 generator.  This version also corrects the velocity bin mid-point labels, which were previously rounded down to the nearest integer.

2  The environment according to MEM 3

NASA programs and projects must consider the meteoroid environment when designing spacecraft.  Risk assessments require descriptions of the meteoroid flux, velocity, density, and directionality to compute the probability of no penetration or impact.  A valid meteoroid model must therefore accurately represent the observations and measurements in these four areas.

This section describes MEM’s underlying environment model and its validation.  As its name indicates, MEM is an engineering model and is intended to be used to characterize meteoroids that are considered a threat to manned and unmanned NASA spacecraft.  We define the threat regime as particles with masses between 10^–⁠6 g and 10 g; particles smaller than 10^–⁠6 g are unlikely to penetrate spacecraft materials and particles larger than 10 g are too rare to pose significant risk.  Furthermore, dust particle measurements are not a useful probe of the properties of potentially hazardous meteoroids because the dynamics of natural particles is a function of particle size.!!ref14^,!!ref15  Thus, observations or measurements of particles outside this mass range (10^–⁠6 – 10 g) are not used as validation datasets.

2.1  Flux

Larger meteoroids are less numerous than smaller meteoroids; thus, when users choose a larger limiting mass they will obtain noticeably smaller fluxes.  MEM 3 models this behavior using the mass scaling specified by the Grün interplanetary flux equation:!!ref2

\begin{equation} g(m) = (c_4 m^{\gamma_4} + c_5)^{\gamma_5} + c_6 (m + c_7 m^{\gamma_6} + c_8 m^{\gamma_7})^{\gamma_8} + c_9 (m + c_{10} m^{\gamma_9})^{\gamma_{10}} \label{eq:grun} \end{equation}

where \(g(m)\) is the flux of particles larger than a limiting mass \(m\); the constants are \(c_4 =\) 2.2 \(\times\) 10³, \(c_5 =\) 15, \(c_6 =\) 1.3 \(\times\) 10^–⁠9, \(c_7 =\) 10^–⁠11, \(c_8 =\) 10²⁷, \(c_9 =\) 1.3 \(\times\) 10^–⁠16, and \(c_{10} =\) 10⁶; and the exponents are \(\gamma_4 =\) 0.306, \(γ_5 =\) −4.38, \(γ_6 =\) 2, \(γ_7 =\) 4, \(γ_8 =\) −0.36, \(γ_9 =\) 2, and \(γ_{10} =\) −0.85.  This equation is applied to MEM’s mass range in figure 1:

The magnitude of the flux is a function of both the heliocentric distance and the distance to the nearest gravitational body and thus may not exactly equal the Grün flux at any particular point.  However, the flux is always proportional to equation A3 of LAST (YEAR)!!ref2 or equation 1 of this guide, and this equation can be used to rescale a given set of MEM outputs to a different limiting mass if desired.

Users sometimes ask how they can scale MEM results to smaller particles.  We discourage this; MEM has a minimum meteoroid mass of 10^–⁠6 g for several reasons.  The first reason is that particles smaller than 10^–⁠6 g are not likely to be dangerous to properly shielded spacecraft components.  Second, MEM is calibrated using meteor observations from the Canadian Meteor Orbit Radar (CMOR), which does not observe meteoroids below this mass limit.  The third reason is that below 10^–⁠6 g, radiative forces such as radiation pressure and Poynting-Robertson drag become significant.  As a result, the directionality and speed distribution are likely different below 10^–⁠6 g!!ref14^,!!ref15 and one cannot model these particles by applying a multiplicative factor to MEM outputs.  This also means it is not possible to validate or invalidate MEM using sub-microgram meteoroid crater data.

If information on the sub-microgram meteoroid environment is needed, there are several models of this population.  One is the European Space Agency’s Interplanetary Meteoroid Model 2 (IMEM2).!!imem2  IMEM2 is a physics-based meteoroid environment model that is tied to zodiacal cloud data instead of meteor survey data and models particles down to 10^–⁠12 g.

2.2  Directionality

The directionality of the sporadic environment has been known to be anisotropic for many decades; mid-twentieth century meteor radar surveys revealed concentrations of sporadic meteor radiants within the ecliptic plane.!!ref16^,!!ref17  These radiant concentrations are separated from the sunward and anti-sunward directions by about 20° and have been termed the “helion” and “antihelion” sporadic sources.  Later surveys uncovered additional concentrations just north and south of the apex direction (i.e., the “north apex” and “south apex” sources).!!ref18  The final two radiant concentrations are the north and south toroidal sources, which lie 60° north and south of the apex direction.!!ref19  In all cases, these sources are named according to their location relative to the Earth’s motion within the ecliptic plane: “apex” refers to the Earth’s ram direction, while “north” and “south” refer specifically to ecliptic north and ecliptic south.  Figure 2 presents the directionality distribution of each of these source populations.

It is clear from these surveys that the meteoroid environment cannot be accurately described using an isotropic model.  Directionality must be taken into account, or meteoroid impact risk on sunward-facing surfaces, such as solar panels, could be substantially underestimated.  Risk assessments therefore require a directional meteoroid model.  Early directional models were constructed in an empirical manner;!!ref20 one major limitation to this approach is that most meteoroid surveys are Earth-based, as the quantity of available meteoroid data outside of near-Earth space is severely limited.  Impact detectors record comparatively few impacts and do not measure meteoroid directionality, and zodiacal light measurements probe a two-dimensional projection of a population of dust particles and meteoroids that are too small to be hazardous.

MEM is based on the meteoroid model of LAST (YEAR),!!ref21 which is a physics-based model calibrated to match Earth-based meteoroid surveys.  This model uses the orbits of known comets to generate a dynamically plausible meteoroid population.  The effects of radiation pressure, Poynting-Robertson drag, and collisions on meteoroid orbits are all taken into account.  The model is constrained using the particle distribution as a function of heliocentric distance derived from zodiacal light and the directionality and particle size distribution observed at Earth by meteor radar surveys.  The resulting sporadic directionality reproduces the directionality observed by both historical meteor surveys and more recent surveys conducted by CMOR.

2.3  Velocity

The meteoroid environment has a distribution of speeds rather than a single representative velocity.  The exact form of this distribution is being frequently revised, with some studies arguing for substantial numbers of slow meteoroids!!ref15 and others for a much faster distribution.!!ref22  The observed velocity distribution requires careful debiasing and is very sensitive at low speeds to small changes in methodology.!!ref23^,!!ref24

MEMR2 contained an adjusted velocity distribution in which faster meteoroids were more heavily weighted to bring it into agreement with LAST (YEAR).!!ref22  This re-weighting was applied to the Earth sub-model only.  We discard this approach in MEM 3, which has a naturally faster speed distribution.  MEM 3’s speed distribution at the top of the atmosphere is shown in figure 3.

The orbits of the meteoroid source populations produce correlations between heliocentric directionality and speed.  Furthermore, meteoroids striking the ram-facing side of a spacecraft will generally have higher relative speeds than those striking the wake-facing side.  MEM 3 fully preserves these correlations, as depicted in figure 4.

2.4  Bulk density

Nearly all meteoroids are thought to be cometary in origin.  At birth, such particles may be either fluffy conglomerates of ice and dust, or they may be compact particles.!!ref25  Over time, exposure to solar radiation is thought to increase the density of these particles.  Thus, meteoroids on short orbits, which frequently pass close to the Sun, are expected to have higher bulk densities than those on long orbits.  This is supported by recent measurements, which find that meteoroids whose orbits resemble those of asteroids or short-period comets are denser than those whose orbits resemble those of long-period comets.!!ref12

MEM 3 divides the meteoroid environment into two density populations based on LAST (YEAR).!!ref12  Helion and anti-helion meteoroids constitute the high-density population, while toroidal and apex meteoroids make up the low-density population.!!ref13  Within each population, density is assumed to be independent of mass, speed, and directionality and follows a log-normal distribution (see fig. 5).

3  Application use

3.1  The web app interface

MEM 3 is now available as a web application; users no longer need to install anything other than a web browser on their personal computers.  When attempting to access the application, users will first be redirected to a login page (see fig. 6).  Users with existing NASA or NASA guest accounts can click the NASA Launchpad button to log in.  Users without existing accounts can request a NASA guest account at guest.nasa.gov.

After login, users will be redirected to the main user interface.  The web interface (see fig. 7) prompts the user for all needed inputs and conducts a few early checks and warnings.  Some input fields may appear inactive or “grayed-out” to ensure correct parameter combinations or selection order; for instance, in figure 7 the “Start run” button is inactive because the user has not yet selected a trajectory file.

In order to submit a run, the user must first upload a spacecraft trajectory file (see sec. 3.2) that is less than 500 MB in size.  The user can then select from a number of run options (see sec. 3.1.1); at minimum, the user should verify that the input origin and axes are compatible with their input file.  Before submitting their run, the user must click the Check options button.  This prompts the application to perform a set of preliminary checks.  If no errors are detected, the Start run button will be activated and the user may proceed with submitting their run.

If the application detects errors in the submission form, error messages will be displayed below the Check options button (see fig. 8).  In some cases, the interface will attempt to resolve incompatible choices and will issue a warning.  For instance, figure 8 warns the user that high-fidelity mode is required for standard deviation outputs, and that this requirement has been enforced.

Once a run has been submitted, the user can view its status and progress in the list of Submitted runs (see fig. 9).  Although there is no “batch” submission available, users can submit additional runs without waiting for the previous run to finish.  Users can view only their own submitted runs, and run results can be retrieved within 3 weeks of submission.

The list of Submitted runs also contains buttons that let the user stop or retrieve results, depending on run status.  For instance, the most recent run shown in figure 9 is in progress, and so the user's only available choices are to let the run complete or to click Abort.  The second run listed in figure 9 has completed, and so the user can choose to Download the run results or Delete the run entirely.

If the user's input file causes a post-submission error, the corresponding run will show up in Submitted runs with a “failed” status (fig. 10).  These runs allow a user to click for Details; doing so opens a log in a separate window (fig. 11).  The contents of the log file should help the user identify the issue.  For instance, in the example shown in figure 11, we see both a warning and an error.  The warning relates to an empty line at the end of the file that does not cause an error in the run.  The error results because we have placed non-numeric characters in one of the state vectors (fig. 12); this error caused the run to fail.  If the application encounters an internal error that is unrelated to the user's input, the user will receive a prompt to contact the developers.

3.1.1  User options

The user has the ability to make a number of choices that influence MEM’s calculations and outputs.  The following subsections describe each of these options in the order that they appear in the user interface (see fig. 7).

input origin

This variable specifies the origin or center of the user’s input trajectory file.  For instance, Earth-centered inertial (ECI) coordinates will have “Earth” as their origin.  Users may also use the Sun, Moon, Mercury, Venus, or Mars as the origin of their spacecraft trajectory coordinate system.

The origin will often be the nearest massive body, but this is not required.  Thus, users can analyze a transfer trajectory in a single run, using any of the possible choices as the origin of their entire trajectory.  MEM will automatically detect whether the spacecraft passes near a massive body and takes any such encounters into account.

input axes

This variable specifies the axis alignment used by the user’s input trajectory file.  Options are “equatorial,” or aligned with the Earth’s equator, and “ecliptic,” or aligned with the ecliptic plane of the Solar System.  For instance, ECI coordinates have “equatorial” axes.

Note that “equatorial” always refers to the Earth’s equator, regardless of the choice of input origin.

vectors used

Users can opt to use a subset of the state vectors listed in their input trajectory file.  They may choose to use all state vectors (“all”), a random selection (“random (n)”), or the first few (“first (n)”).  If the random option is chosen, state vectors are randomly chosen without replacement from the full list; duplicate state vectors are not used.  MEM does not vary the seed for the random number generator.  This allows the user to exactly replicate all runs, even those with random state vector selection.

The original input file will always cover the trajectory more fully than a randomly selected subsample drawn from it.  Therefore, as with all runs, the user should ensure that the input file covers the trajectory well and that a large enough subsample is drawn.  Users are advised to vary the number of random draws; if a large enough sample has been drawn, the results will not vary significantly.  Note, however, that passing this test does not guarantee that the original input file adequately covers the trajectory.

vector count

Users may use this text field to specify the number of state vectors to analyze when using the “random” or “first few” run types.  If this number matches or exceeds the number of state vectors in the input file, a warning may be issued by the GUI.  Users may proceed (or run the code on the command line), but MEM 3 will set the number of state vectors used to the number of state vectors it is able to read from the input file.

limiting mass

The user may specify the base-10 logarithm of the limiting mass in grams.  The user is restricted to choosing a value between -6 and 1, corresponding to 10^–⁠6 and 10 g, respectively.  The field is pre-populated with a default value of -6.  MEM will calculate the meteoroid flux for particles greater than or equal to the chosen limiting mass

high-fidelity mode

If the user chooses to run in high-fidelity mode, four times as many meteoroid orbit realizations are used in the flux calculations.  This reduces noise in the resulting flux values and is required for a standard deviation calculation.  When high-fidelity mode is “off,” the number of orbits is equivalent to MEMR2.  The code runs more slowly in high-fidelity mode (by approximately a factor of 3 to 4, depending on other run parameters).

output origin

This variable specifies the origin the user wishes MEM to use for all output files.  Allowed choices are the Sun, Earth, Moon, Mercury, Venus, or Mars.  In most cases, we expect that users will want to use the same origin for their output files as they do for their spacecraft trajectory, but this is not required.

output axes

This variable specifies the axis alignment the user wishes MEM to use for all output files.  A “body-fixed” option, in which the \(+x\) axis is aligned with the spacecraft’s direction of motion, is available in addition to the “equatorial” and “ecliptic” options.

angular resolution

Users may select an angular resolution of “1°,” “2°,” “3°,” “4°,” or “5°” for their output files.  A coarser angular resolution will reduce run time and file size.

velocity resolution

Users may select a velocity resolution of “1 km/s” or “2 km/s” for their output files.  A coarser resolution will reduce run time and file size, but we recommend the “1 km/s” option in most cases.  The velocity resolution is not tied to the angular resolution.

intermediate files

If users select this option, MEM will output flux files for each spacecraft state vector used.  If this option is not selected, no flux files will be generated until the end of the run.

igloo flux files

If users select this option, MEM will output a “threat igloo” file in which the flux is divided into quasi-equal area angular bins.  If both this option and the intermediate file option are selected, MEM will output an igloo file for each state vector used.

standard deviation files

If users select this option, MEM will output standard deviation files in addition to the average flux files.  If the igloo file option has been chosen, MEM will also output the standard deviation of the flux in igloo file format.  Note that this simply describes the variation along the user-provided spacecraft trajectory and does not describe the uncertainty in the model.

This option requires the use of the high-fidelity mode.

3.1.2  Run time

Depending on the number of state vectors in the input file, MEM run times can vary from minutes to hours.  A faster CPU will reduce the runtime, but MEM has not been parallelized and will not use multiple processors.

A larger number of state vectors will also increase the disk space needed for output files if the user has chosen to “output intermediate files,” which causes the code to generate and save flux files corresponding to each individual state vector.  MEM estimates the total size of the output files at the beginning of a run.  If the output is expected to exceed 20 GB, the run will fail and the reason will be noted in the user log (see sec. 3.1).

3.2  Input trajectory

Because MEM provides trajectory-specific meteoroid environment data, the user must provide an input file containing trajectory information.  This file must contain a series of dates and Cartesian state vectors.  The state vectors in the input file can be sequential or correspond to random points in time.  Each state vector will receive equal weight; we therefore recommend sampling the spacecraft state vector at equal time intervals to avoid underweighting part of the trajectory.

To accommodate trajectory data generated with the popular Systems Tool Kit (STK), MEM assumes that the first six lines of an input file are header.  The contents of this header are irrelevant and may be left empty, but no data will be used prior to line 7 of the input file.  Starting on line 7, the input file lines must consist of a Julian date (in units of days) followed by the Cartesian position and velocity of the spacecraft (in units of km and km/s, respectively).  Individual numbers must be separated by whitespace; the required format is shown in table 1, and an example input file is available here.

1	Header text: no required format other than six line requirement
2
3
4
5
6
7	Julian date #1	\(x_1\)	\(y_1\)	\(z_1\)	\(v_{x,1}\)	\(v_{y,1}\)	\(v_{z,1}\)
8	Julian date #2	\(x_2\)	\(y_2\)	\(z_2\)	\(v_{x,2}\)	\(v_{y,2}\)	\(v_{z,2}\)
...	...	...	...	...	...	...	...
\(N+\)6	Julian date #\(N\)	\(x_N\)	\(y_N\)	\(z_N\)	\(v_{x,N}\)	\(v_{y,N}\)	\(v_{z,N}\)

The input file must also satisfy the following requirements:

• Dates should be in Barycentric Dynamical Time (TDB) or Terrestrial Time (TT) rather than Coordinated Universal Time (UTC).
• State vectors should be in either J2000/ICRF ecliptic or equatorial coordinates, with the origin located at the Sun, Earth, Moon, Mercury, Venus, or Mars.
• Outside of the header, there should not be any commas, brackets, parentheses, or any other non-numeric symbol or character.
• Floating point numbers, integers, and scientific or engineering representation are acceptable number formats.
• While MEM 3 is able to handle trailing empty lines better than previous versions, we recommend keeping extraneous whitespace to a minimum.

Please ensure that the trajectory file does not inadvertently place the spacecraft inside a planet or the Moon.  If this occurs, all meteoroids will be shielded and all flux components will be zero; this will also occur when a spacecraft is inside a planet’s atmosphere.  MEM 3 models the planets and the Moon as spheres with the radii and atmospheric depth specified in table 2.

body	radius + atmosphere
Mercury	2439.7 km
Venus	6172 km
Earth	6471 km
Moon	1737.4 km
Mars	3480 km

The trajectory file can have any alphanumeric name (characters such as dashes and underscores are also permitted) as long as the total number of characters is less than 256.  Input files cannot be larger than 500 MB.

Depending on the number of state vectors in the input file, the run time can vary from seconds to days.  A larger number of state vectors will also increase the size of the output files if the user has chosen to “output intermediate files,” which causes the code to generate and save flux files corresponding to each individual state vector.  Total output sizes larger than 20 GB are not permitted, and users will receive an error if the application anticipates that their run will exceed this limit.

3.3  Output

MEM 3 produces a collection of output files that describe both the aggregate meteoroid environment along the entire provided trajectory and the instantaneous environments corresponding to each input state vector or TLE.  In all cases, the flux and speed information presented in the output files are computed relative to the spacecraft.  The output data include the effects of gravitational focusing and planetary shielding where applicable (i.e., when the spacecraft is near a planet or the Moon).  MEM 3 does not report environment uncertainties; the standard deviation output files report the observed variation in flux along the provided spacecraft trajectory.

Once a run is complete, users can download a zip file of their run output. The zip file expands into a directory containing both run information and meteoroid flux and density files. The flux files are divided into two subdirectories called HiDensity and LoDensity (see fig. 13); these names reflect the two meteoroid populations described by MEM.

3.3.1  Information files

For each run, MEM 3 creates a file named info.txt (fig. 14) that records the start time of the run, point version of MEM, and a brief description of the primary output files.  Users can refer to the information file to refresh their memory of what each file type contains.

MEM also creates a file named options.txt that contains a full record of all user options (fig. 15).  MEM also saves a copy of the user's input trajectory to the output folder.  These two files ensure that the user can exactly replicate any previous run.

A set of MEM run outputs also contains two small files named log.txt and progress.txt. These files do not continue much additional information, but can be checked to confirm successful completion of the run.

3.3.2  Cube files

The “cube” files report meteoroid fluxes and velocities relative to a series of flat surfaces with different orientations. A cube file begins with a nine-line header that first reports the number of rows (line 1) and columns (line 2) of flux data, not including velocity labels.  Next, the file reports the total cross-sectional meteoroid flux summed over all directions and speeds in units of particles per square meter per year (line 4).  This is equivalent to the meteoroid flux on a sphere per square meter of cross-sectional area.  The cube files next provide a table of the average meteoroid speed incident on each face of a cube with the spacecraft’s orientation (line 7).  We warn that the use of average speeds in risk assessments may underestimate vehicle risk and recommend the use of the full meteoroid speed distributions (see sec. 3.3.3).  The total flux incident on each surface is reported next (line 8).

The flux in each speed interval is reported immediately after the header and beginning on line 10.  Speed bins are labeled with the midpoint of the speed range in the first column: 0.5 km/s for meteoroids ranging from 0 to 1 km/s.  The next six columns of data report the corresponding flux component on each side of a cube whose faces are aligned with the user’s chosen coordinate system.  The next three columns report the flux on surfaces facing the Earth, facing the Sun, and facing away from the Sun.  These orientations may be relevant to communications equipment and solar panels, respectively.  Finally, the last three columns report the flux on surfaces rotating about the three axes of the user’s chosen coordinate system.  These fluxes are quoted per unit of average cross-sectional area perpendicular to the axis of rotation.  Part of a sample cube file is shown in figure 16.

All MEM 3 runs produce at least one cube file, cube_avg.txt, which reports each flux component averaged over the spacecraft trajectory.  If users opt to generate standard deviation files, a standard deviation file named cube_std.txt will also be produced.  Finally, if users choose to output intermediate files, a cube flux file will be produced for each state vector used and will be named cube_N.txt, where N is the number of the state vector in the trajectory input file.

3.3.3  Flux files

For each spacecraft state vector, MEM 3 calculates the meteoroid flux within a three-dimensional grid in azimuth, elevation, and velocity; the resolution and orientation of this grid is chosen by the user at the beginning of a run.  The resulting grid of data is written to what we call the “flux files.”

A flux file begins with an eight-line header that first reports the number of rows (line 1) and columns (line 2) of flux data, not including angular labels.  A description of the bin labeling is provided in lines 4-6 of the header.  The last line of the header provides labels for each column of data.

Flux data begins immediately after the header, starting on line 9 of the flux file.  The first column in the file reports the lower elevation limit for a grid cell.  Therefore, the first value will always be -90 and the last value will be 85, 86, or 89, depending on the chosen resolution.  The second column in the file reports the low value for azimuth; the first value will always be 0.  Each of the remaining columns corresponds to a speed bin, and the midpoint of each velocity bin appears as a column label (line 8 of the header).  Part of an example flux file is shown in figure 17.

All MEM 3 runs produce at least one flux file, flux_avg.txt, which reports each flux component averaged over the spacecraft trajectory.  If users opt to generate standard deviation files, a standard deviation file named flux_std.txt will also be produced.  Finally, if users choose to output intermediate files, a flux file will be produced for each state vector used and will be named flux_N.txt, where N is the number of the state vector in the trajectory input file.

For some runs, the first few lines or columns may contain zero flux (for instance, see the example in fig. 17).  This is normal for a spacecraft in low Earth orbit when the body-fixed output coordinate frame is selected.  In this case, the Earth shields the spacecraft from nadir-originating meteoroids.  Low-velocity bins will also typically be empty; meteoroids do not orbit the Earth and thus their speeds necessarily exceed the local escape speed.

Please also note that these files report the meteoroid flux per angular bin.  These bins are not equal in area and cover smaller portions of the sky towards the zenith and nadir directions (see fig. 18).  If the user wishes to generate plots of meteoroid flux as a function of direction, we recommend converting flux per angular bin to flux per square degree, or, alternatively, using the igloo output files (see section 3.3.4).

3.3.4  Igloo files

The flux files described in section 3.3.3 completely describe the meteoroid environment along the given trajectory to the user-specified resolution.  However, the angular bins in the azimuth and elevation grid vary in size.  Therefore, MEM also provides the user with an alternate description of the environment in which flux is divided into an “igloo" of quasi-equal area angular bins.  The azimuthal width of these bins varies such that the solid angle subtended stays roughly constant; for example, the angular area of the 5° igloo bins ranges from 24.35 to 26.17 square degrees.

These igloo files provide a quasi-equal area projection of the meteoroid environment as seen by the spacecraft.  Blocks in the “equator,” or 0° elevation row, span equivalent ranges in elevation and azimuth.  For a 1° resolution choice, these blocks will be approximately one square degree in size.  As elevation increases, the number of blocks in a ring decreases to maintain an angular area similar to that in the 0° ring.  Figure 18 illustrates this threat igloo concept.

Like the flux files, the igloo files begin with an eight-line header that first reports the number of rows (line 1) and columns (line 2) of flux data, not including angular labels.  A description of the bin labeling is provided in lines 4-6 of the header.  The last line of the header provides labels for each column of data.

The first nine columns of an igloo file specify the location of each angular block within the igloo.  The first three columns are block indices: the first column is an element id number, the second column is the elevation “ring” index (\(i\)), and the third column is the block index within that ring (\(j\)).  The next four columns report the lower and upper bounds on elevation angle for the given block followed by the lower and upper bounds on azimuth.

The eighth and ninth columns contain the value of elevation and azimuth that divide the igloo bin into four equal-area quadrants.  The azimuthal angle corresponding to this areal midpoint is simply the average of the two bounding azimuth values.  However, the elevation angle is given by:

\begin{equation} \sin \phi_m = \tfrac{1}{2} (\sin \phi_1 + \sin \phi_2) \label{eq:sinphi} \end{equation}

where \(\phi_1\) and \(\phi_2\) are the two bounding elevation angles of the igloo bin.  For resolutions of 5° or finer, these midpoint angles lie very close, but are not identical, to the centroid of the bin.

Finally, flux values are reported in columns 10 and greater; the number of columns is determined by the chosen speed resolution.  Part of an example igloo file is shown in figure 19.

Igloo files are an optional output.  If the user chooses to output igloo files, MEM 3 runs will produce an average igloo file, igloo_avg.txt, which reports each flux component averaged over the spacecraft trajectory.  If users also opt to generate standard deviation files, a standard deviation file named igloo_std.txt will also be produced.  Finally, if users choose to output both igloo and intermediate files, an igloo file will be produced for each state vector used and will be named igloo_N.txt, where N is the number of the state vector in the trajectory input file.

3.3.5  Density files

MEM 3 produces two density distribution files (hidensity.txt and lodensity.txt) for each run.  The names of these files correspond to the cube and flux files in the directory of the same name.  For instance, hidensity.txt applies to HiDensity\flux_avg.txt.  These files provide the fraction of the flux in each density bin for two meteoroid populations and do not change between runs.  Per population, the density is independent of the speed and directionality.  Users may therefore multiply the cube or flux files by the corresponding density file to add a density dimension to their results.

4  Interpretation

4.1  Coordinate frames

The user can choose to receive output in either a body-fixed or inertial coordinate frame; in this section, we describe each of these reference frames.  When discussing MEM 3 output, it is important to distinguish between (a) a nearby massive body and (b) the origin of the output coordinate system.  Users have the freedom to choose any major body in the inner solar system as the origin of their output coordinate system, regardless of whether it is a sensible choice.  For instance, it is possible, but not recommended, to select the planet Mercury as the output coordinate origin for a spacecraft orbiting Mars.

A spacecraft’s position relative to a nearby massive body will tend to affect the flux.  For instance, spacecraft near a planet or the Moon can experience shielding effects, in which the massive body blocks a portion of the meteoroid environment.  As the spacecraft changes position relative to a nearby massive body, the section of the environment that is blocked will shift, resulting in noticeable changes in meteoroid directionality and flux.

A spacecraft’s position relative to the chosen output origin will not affect the overall flux.  However, it will affect the apparent directionality of the flux—if and only if the user has opted to use a body-fixed output frame.  This is because the body-fixed frame is not an inertial reference frame but is instead defined by the spacecraft’s instantaneous position and velocity relative to the output origin.

4.1.1  Body-fixed coordinate frames

In a body-fixed reference frame, the spacecraft’s velocity vector relative to the central body defines the \(\hat{x}\) direction (see fig. 20).  Thus, \(\hat{x}\) points in the spacecraft’s ram direction, while the wake direction corresponds to \(-\hat{x}\).

If a planet or Moon has been selected as the origin of the output coordinate frame, the spacecraft’s angular momentum vector about that body defines \(\hat{y}\); that is, \(\hat{y} = \hat{h} = \hat{r} \times \hat{x}\).  The \(\hat{z}\) direction is then defined by the cross product of the \(\hat{x}\) and \(\hat{y}\) directions (see fig. 20).  If the spacecraft is in a prograde orbit around the output origin, the \(y\) axis will tend to point in the direction of the output origin’s north pole.  For a retrograde orbit, the reverse is true.  For a perfectly circular orbit, \(\hat{z} = \hat{r}\).

If, instead, the Sun has been selected as the origin of the output coordinate frame, the \(y\) and \(z\) axes are defined differently.  In this case, the \(z\) axis is aligned with the angular momentum vector: \(\hat{z} = \hat{h} = \hat{r} \times \hat{x}\).  Then, \(\hat{y} = \hat{z} \times \hat{x}\) (see the right panel of fig. 20).  This difference in coordinate frame definition tends to align the \(z\) axis with ecliptic north when the spacecraft is near the ecliptic plane and orbiting the Sun in a prograde direction.  For a perfectly circular orbit, \(\hat{y} =\, –\hat{r}\).

Users should note that although \(\vec{r}\) and \(\vec{v}\) are perpendicular for a spacecraft on a circular orbit, this is not the case for eccentric or transfer orbits.  For near-circular orbits, the main output file will show similar if not identical fluxes and speeds for certain surfaces (for example, Earth-facing and nadir surfaces).

The body-fixed frame is often the best choice for a spacecraft that orbits a planet or Moon and maintains a fixed orientation relative to its orbit.  In such a case, the body being orbited should be selected as the origin of the output coordinate system.

4.1.2  Inertial coordinate frames

Two inertial coordinate frames are available in MEM 3: ecliptic and equatorial.  The choice of origin in this case has no effect; meteoroid velocities are always reported relative to the spacecraft.

In both the ecliptic and equatorial reference frames, \(\hat{x}\) points in the direction of the vernal equinox at epoch J2000.  In the ecliptic reference frame, \(\hat{z}\) points toward ecliptic north; both \(\hat{x}\) and \(\hat{y}\) are parallel to the Earth’s orbital plane.  See the left panel of figure 21 for an illustration.

In the equatorial reference frame, \(\hat{z}\) points toward celestial north and is aligned with the Earth’s rotational axis.  The \(\hat{x}\) and \(\hat{y}\) vectors are parallel to the Earth’s equatorial plane.  See the right panel of figure 21 for an illustration.

An inertial output coordinate frame may be more useful for a spacecraft that changes its orientation relative to its direction of motion.

4.1.3  Azimuth and elevation

The flux and igloo output files divide the meteoroid flux into directional bins; each bin spans a range in azimuth (\(\theta\)) and elevation (\(\phi\)).  These angles, \(\theta\) and \(\phi\), are defined relative to the chosen output reference frame.  The azimuth, \(\theta\), measures position within the \(x\)-\(y\) plane, where \(\theta = 0^\circ\) along the \(+x\) axis and \(\theta = 90^\circ\) along the \(+y\) axis.  The elevation angle, \(\phi\), measures displacement from the \(x\)-\(y\) plane: \(\phi = 90^\circ\) along the \(+z\) axis, \(\phi = 0^\circ\) in the \(x\)-\(y\) plane, and \(\phi = -90^\circ\) along the \(−z\) axis.  For the user’s reference, table 3 gives the azimuth and elevation angles for the normal vectors of the cube faces reported for a body-fixed frame.

		\(\theta\)	\(\phi\)
ram	\(\hat{v}\), \(+\hat{x}\)	0°	0°
wake	\(-\hat{x}\)	180°	0°
port	\(+\hat{y}\)	90°	0°
starboard	\(-\hat{y}\)	270°	0°
zenith or “north”	\(+\hat{z}\)	any	+90°
nadir or “south”	\(-\hat{z}\)	any	-90°

4.2  Flux reporting

MEM 3 reports the meteoroid flux to several levels of fidelity; this section discusses the types of meteoroid flux reported, so the user can better determine which suits their needs.

4.2.1  Total cross-sectional flux

The lowest-fidelity flux describing the environment is the “total cross-sectional flux” reported in the cube files.  This quantity is simply the sum of the meteoroid flux over all directions and speeds.  It is equivalent to the total flux incident on a spherical spacecraft and is expressed per square meter of cross-section.

To obtain the flux on one side of a randomly tumbling plate, you can divide the total cross-sectional flux by four.  This factor of four arises from the ratio of the cross-sectional area to surface area of a plate (which is unity) relative to that of a sphere (which is ¼).  This applies if and only if your spacecraft is randomly tumbling.  If your spacecraft’s orientation is known, please use the cube fluxes or calculate their equivalent from the flux or igloo files.

4.2.2  Cube fluxes

The cube files also report the meteoroid flux incident on the sides of a cubic spacecraft.  In a body-fixed frame, these normal vectors are aligned with the ram, wake, port, starboard, zenith, and nadir directions (see sec. 4.1.1).  In an inertial reference frame, they are aligned with the axes of the coordinate system.  In general, the sum of these “cube fluxes” does not and should not equal the “cross-sectional flux” (sec. 4.2.1).  While a sphere presents the same cross-sectional area in all directions, the apparent cross-sectional area of a cube varies with viewing angle (see fig. 22).

In addition to the above surfaces, MEM 3 also calculates the flux on surfaces facing the Earth, facing the Sun, and facing away from the Sun.  Communications equipment and solar panels may have surfaces with these alignments.  For each surface, MEM 3 reports not only the total flux (denoted “total flux”) but also the flux per speed interval, where the size of these intervals is determined by the user’s resolution choice.

Note that these “cube” fluxes are mass-limited, not damage-limited.  While they are useful as a “quick look” at the environment, they are not useful for a full risk analysis.

4.2.3  Flux on rotating surfaces

If a spacecraft rotates as it moves along its trajectory, the cube surfaces discussed in section 4.2.2 may not be meaningful.  Thus, MEM 3 also reports the flux on surfaces that are rotating about each axis of the output coordinate system; these fluxes are given in the last three columns of the cube files.

We caution the user that the flux on the rotating surface is not equivalent to the flux on four sides of a non-rotating cube.  In the case of rotation about the \(z\)-axis, for example, we report the incident flux per square meter of azimuthally-averaged cross-section.  For a unit meter cube, this azimuthally-averaged cross-section is \(4/π\) m² or roughly 1.273 m².  More generally, the azimuthally-averaged cross-section of a non-concave generalized cylinder is \(s l/2 π\), where \(s\) is circumference and \(l\) is length.  Although performing this conversion may seem inconvenient, it is the cross-sectional area that determines how many meteoroids impact the spacecraft, while the ratio of the circumference to cross-section depends on spacecraft shape.

As far as MEM 3 is concerned, these rotation modes are the equivalent of the spacecraft randomly changing its orientation about the rotation axis.  There is no option to specify the rotation rate; the speed of spacecraft surfaces due to rotation is assumed to be negligible compared to the spacecraft’s speed relative to the central body (planet, Moon, or Sun.)  If the orientation of the spacecraft at each point in time is known, the user can perform post-processing to extract more precise fluxes.

4.2.4  Igloo and flux files

For more detailed directional information, users can refer to the igloo and flux files (described in sec. 3.3.3 and sec. 3.3.4); both report the flux per speed interval and per solid angle interval.  The flux files divide the flux into a regular grid in azimuth and elevation and the angular size of the bins is proportional to \(\cos \phi\).  The igloo files, in contrast, divide the flux into azimuth and elevation bins that are approximately equal in angular size (see fig. 18).

The flux files, with their constant number of azimuthal bins, are typically easier to use when generating visualizations.  For instance, the data can be read in, summed across the velocity columns, and then reshaped into a two-dimensional grid for plotting.  However, it is important to remember that the bin size is smaller near the poles and that a correction of \(1/\cos \phi\) must be applied to obtain the flux per square degree (see fig. 23).

The igloo files, with their quasi-equal-area bins, are difficult to render into plots (although this is not impossible; see fig. 23).  However, the smaller number of bins in the igloo files tends to conserve disk space—the igloo files are about 36% smaller than the flux files for any given choice of angular resolution.  As a result, users will also find the igloo files to be faster than the flux files to process for any ballistic limit calculations.

4.2.5  Instantaneous environment information

For those users requiring high fidelity in speed, direction, and time, MEM 3 offers the option of creating a set of output files corresponding to each state vector in the input trajectory file.  If desired, the user can convolve each environment with the spacecraft’s geometry, taking its attitude into account.  Alternatively, the user can feed these environments, along with spacecraft shape and orientation information, into a risk assessment tool such as BUMPER.

4.3  Density distributions

As modeled by MEM 3, all meteoroids belong to either a high-density population or a low-density population.  Within each population, the mass, speed, and angular distributions are independent of density.  Thus, density is not included as a fourth dimension in the flux files; instead, the density distribution is provided separately in two files named hidensity.txt and lodensity.txt.

The third row of each density file does not contain a flux value; instead, it reports the fraction of the flux contained in the given bin.  Thus, any flux component in the cube, flux, or igloo files can be multiplied by the density fraction to obtain the flux value in that density, velocity, and directional bin.

The density files have a fairly fine resolution and users may therefore wish to reduce the number of bins.  One approach is to use only those bins that contain at least a certain fraction of the total (selection of this threshold is up to the user).  If users prefer to take a Monte-Carlo approach, they can draw densities from log-normal distributions, where the probability \(P\) of drawing a particular density value is:

\begin{equation} P(\log_{10} \rho) = \frac{1}{\sqrt{2 \pi \sigma^2}} e^{-(\log_{10} \rho - \mu)^2/2 \sigma^2} \label{eq:prob} \end{equation}

where \(\rho\) is density.  For the low-density population, \( \mu = 2.933\) and \( \sigma = \text{0.127}\); for the high-density population, \( \mu = 3.579 \) and \(\sigma = 0.093\).

4.4  Mass scaling and risk assessment

MEM 3 reports meteoroid flux to a constant limiting mass, chosen by the user.  This means that the reported fluxes include particles of the specified size and larger.  MEM 3 uses the LAST mass scaling relation;!!ref2 this relation can also be used to rescale the results of a MEM run to a different limiting mass (see sec. 2.1).

Most impact effects are not mass-limited.  Instead, the limiting quantity may be penetration depth, kinetic energy, charge produced, or angular momentum imparted.  In order to compute an impact-effect-limited flux, one must first determine the equation that governs the limiting effect and then invert this equation to obtain the limiting mass as a function of speed, impact angle, and meteoroid density.  Let us refer to this mass as \(m_{\text{effect}}(\phi, \theta, v, \rho)\).  Then, the effect-limited-flux is given by:

\begin{equation} \text{flux}_{\text{effect}} = \sum_{i,j,k,n} \text{flux}_{i,j,k} \times \text{fraction}_n \times \frac{g(m_{\text{effect}}(\phi_i, \theta_j, v_k, \rho_n))}{g(m_{\text{run}})} \label{eq:scale} \end{equation}

where \(i\) is used to number the elevation bins, \(j\) is used to number the azimuthal bins, \(k\) is used to number the velocity bins, and \(n\) is used to number the density bins.  Thus, “flux\(_{i,j,k}\)” is the flux in a particular angle and velocity bin in a flux or igloo file and \(\phi_i\), \(\theta_j\), and \(v_k\) are the elevation, azimuth, and velocity corresponding to that bin.  Similarly, “fraction\(_n\)” is the fraction of the flux in a given density bin, where \(\rho_n\) is the corresponding density.  The function \(g\) refers to the Grün flux; see equation 1 of this document.  Finally, \(m_{\text{run}}\) is the mass chosen for the MEM run.

Determination of the correct equation for \(m_{\text{effect}}\) is the responsibility of the user.  Note also that the above equation does not take shadowing effects into account; if the spacecraft has any concavities, one part of the spacecraft’s surface can shield other parts from a portion of the environment.  For assistance with either 3D spacecraft modeling or impact effects, please contact the Hypervelocity Impact Technology team at Johnson Space Center.

5  Uncertainty

The uncertainty in the meteoroid environment is both large and poorly characterized.  The uncertainty near Earth has been estimated as a factor of 2-3!!comp; this is consistent with the level of agreement between MEM and in situ data!!ref11.  We consider this to be an estimate of the uncertainty in impact rate rather than mass-limited meteoroid flux.

Nearly all constraints on the meteoroid flux or impact rate originate from data collected in low Earth orbit or from the observation of meteors in Earth's atmosphere.  The ratio of the meteoroid impact flux at high geocentric altitudes to that at low altitudes depends on the meteoroid speed distribution; as a result, the uncertainty grows with orbital altitude.  If the uncertainty is a factor of three in low Earth orbit, we estimate that it is a factor of four at high altitudes.

Spacecraft on interplanetary trajectories will encounter an even greater level of uncertainty.  LAST (YEAR)!!comp found that early versions of IMEM and MEM predicted meteoroid fluxes at Mercury that differed by two orders of magnitude.  The level of agreement between IMEM2 and MEM 3 has not been assessed, but we estimate the uncertainty to be approximately a factor of 10 at Mars and 1-2 orders of magnitude at Mercury. 

A detailed characterization of the meteoroid impact uncertainty does not exist.  However, for those users who wish to generate a confidence interval, we have constructed a set of simple formulae that are consistent with our estimated uncertainty factors and vary smoothly between distance regimes.  The uncertainty factor, \(s\), can be calculated as a function of distance from Earth as follows:

\begin{equation} s^2(h, r_h) = \left( 3 + \frac{h}{\text{1000 km} + h} \right)^2 + \left( 22 \ln \frac{r_h}{\text{1 au}} \right)^2 \label{eq:s} \end{equation}

Here, \(h\) is orbital altitude above Earth's surface, and \(r_h\) is the distance between the spacecraft and the Sun.  The form of this equation is shown in figure 24.  Notice that units are explicitly included.

We interpret the uncertainty factor \(s\) as the half-width of the 95% confidence interval on the logarithm of the impact rate.  Thus, if a user predicts an impact rate or number of impacts \(N\), the probability distribution function (PDF) for the true number of impacts, \(n\), is:

\begin{align} \text{PDF}(n) &= \frac{1}{\sqrt{2 \pi} \sigma} \frac{1}{n} \exp \left \{ -(\ln n - \ln N)^2 / 2 \sigma^2 \right \} \label{eq:pdf} \\ \sigma &= \frac{1}{2} \ln s \end{align}

Readers may recognize equation 6 as a log-normal distribution.