NEA Close Approaches: Analysis & Simulation 

This section is dedicated to the analysis of Near-Earth Asteroid (NEA) close approaches and to “what-if” physical consequence scenarios. The data is generated by a custom Python script that:

1. retrieves official close-approach geometry and relative velocity from NASA/JPL SSD services, and

2. produces a hypothetical impact/entry consequence estimate (energy partition, breakup/burst altitudes, and crater size where applicable).

Important note: the physical section is a scenario generator (“if the object impacted at the encounter-relative speed”), not an official hazard assessment. Official impact monitoring information is reported from NASA/JPL Sentry when available.

Software Overview 

The software was built with a simple idea in mind: start from official, reproducible geometry of a close approach, and then explore a clearly labeled “what-if” physical scenario, without mixing the two. The workflow begins with data retrieval from NASA/JPL Solar System Dynamics services. The script resolves the target through the SBDB endpoint and collects orbital and physical metadata (including the physical-parameters section when available). For the encounter geometry, it first attempts to use the close-approach list embedded in SBDB; when that list is missing, too sparse, or does not contain a usable record for the selected year, the script falls back to the SBDB Close-Approach Data API (CAD).

The risk section follows an explicit “official-first” rule. If the object appears in the NASA/JPL Sentry risk system, the report includes the official Sentry summary and the Virtual Impactor (VI) table (object-mode output). If Sentry has no entry (or the object is listed as removed), the script can still print a non-official "toy" metric, clearly labeled as such and intended only as a simplified way to visualize how uncertainty and encounter geometry interact, never as an impact probability.

For the physical “what-if” engine, the key drivers are diameter and composition, and the software makes those choices explicit and reproducible. If the user provides an override diameter, that value is adopted; otherwise the script prefers a diameter reported by Sentry when available, and falls back to the standard H albedo estimate derived from SBDB parameters. The report prints both the estimated diameter and the adopted diameter (with its source), so the reader can always trace what actually drove the numbers.

Entry and impact consequences are (hopefully) kept easy readable and stable, and the software adapt the “physics” workflow in two ways: when connectivity allows it (and unless explicitly disabled), the script queries the public Earth Impact Effects calculator (Impact:Earth) and adopts its breakup/burst altitudes, residual velocity and crater outputs as a benchmark reference, consistent with the widely used approximations described by Collins, Melosh & Marcus (2005). These values are tagged as “Impact:Earth” in the report, and a short parsed excerpt is included for traceability. If the calculator is unreachable (or disabled), the script falls back to an internal "toy" parameterization based on a simple stagnation-pressure breakup threshold in an exponential atmosphere, preserving the narrative separation between “breakup begins” and “energy release peaks” without claiming a full fragmentation cascade model.

Consequence branching remains deliberately explicit: smaller bodies are treated as airburst dominated cases, larger ones as ground impacts with crater scaling, and the script keeps a transitional tuning in the regime where discontinuities are most sensitive. For kilometre-class objects (≥ 1 km) the internal "toy" engine switches to a dedicated large impactor branch that neglects atmospheric losses and emits domain warnings once crater sizes enter basin scale territor, where simplified scaling laws are no longer reliable.

Finally, everything is written into a structured text report that preserves a strict separation between (1) official encounter geometry, (2) official hazard monitoring when present via Sentry, and (3) hypothetical physical consequences. That separation is not cosmetic: it is the guardrail that prevents “what-if” numbers from being read as forecasts.