TinyComputers.io (Posts about physics)

The Bullet Doesn't Go Where You Point It

A.C. Jokela — Sat, 01 Aug 2026 17:00:00 GMT

The bugs were never in the physics

Here is the thing I did not expect when I started, and which I suspect generalizes far past ballistics: in something like ninety thousand lines of Rust, almost none of the bugs worth remembering have been physics bugs. The equations are in textbooks. They have been in textbooks for decades, they were checked by people better at this than me, and when I have implemented one incorrectly the error was usually so large that it announced itself immediately.

The bugs are in the conventions.

Consider a wind direction. A number of degrees — obviously. Except: is that the direction the wind is blowing toward, or the direction it is coming from? Meteorology says from. Is zero degrees a headwind, a tailwind, or due north? Is it measured relative to the direction you are shooting, or is it a compass bearing that has to be resolved against your shot azimuth before it means anything? Every one of those is a defensible choice, several of them are in active use by real tools, and each pairing produces a number that looks completely reasonable and is wrong by up to a hundred percent of the wind effect. The engine's answer is wind-from, zero degrees is a headwind — and that sentence is now welded into the help text, the API docs, and a shared constant, because the one time the convention drifted between two subcommands, both of them looked right in isolation.

Units are the same disease. Inches or millimeters for the height of the scope above the bore. Feet per second or meters per second. Grains — a unit of mass equal to one seven-thousandth of a pound, used for bullets and gunpowder and essentially nothing else on Earth. Minutes of angle or milliradians for the correction you dial into your scope, where a minute of angle is approximately an inch at a hundred yards, and the approximation has cost people their afternoons. None of this is intellectually difficult. All of it is a place where a plausible number comes out and nobody catches it, which is precisely the definition of the expensive kind of bug.

Testing physics you cannot check by hand

Which raises the real problem: how do you test this? For a normal library you assert that the function returns the right answer. Here, nobody knows the right answer. The whole point of the engine is to compute a number I cannot compute another way — and if I could hand-verify the output, I would not have needed to write it.

The usual answer is a pile of regression tests, and there is one: roughly fourteen hundred of them. But a regression test only tells you that today's answer matches the answer you wrote down on the day you wrote the test, which may have been wrong. What I have found much more valuable is a set of ten fuzzing harnesses that do not look for crashes so much as for lies — properties that must hold for any input at all, checked against millions of inputs nobody thought to write down.

Some of them have an actual oracle. Turn the drag off — set the ballistic coefficient absurdly high so air resistance becomes negligible — and a projectile is just a parabola, with a closed-form solution any physics undergraduate can produce: the drop at distance x is exactly ½g(x/v)². So one harness generates arbitrary velocities, runs the full production solver, and demands that its answer match the exact analytic parabola. If the integrator, the step size, or the coordinate handling is subtly wrong, no amount of physics-modeling opinion can hide it, because for that one degenerate case the truth is known.

Others check symmetry. Switch off spin drift, Magnus, and Coriolis so that the only thing pushing the bullet sideways is wind, then mirror the wind: the drift must mirror too, exactly. Any asymmetry left over is a bug, because there is nothing left in the model that could physically prefer one side. Others check monotonicity — a claim like "at a fixed distance, a bullet with a higher ballistic coefficient must not drop more." No exact answer required; only a direction of change, which is often the strongest statement you can actually make about a system this tangled.

And my favorite links the previous released version of the engine into the same binary as the current one and runs both. Not to demand identical output — the numbers are supposed to change when the physics improves — but to compare their qualitative responses, so that if a refactor quietly inverts how drop responds to a change in ballistic coefficient, the difference surfaces against the version that shipped rather than against my expectations. Which, being the person who wrote the refactor, are the least trustworthy oracle in the building. This trick has one delightful practical wrinkle: linking two versions of the same Rust crate into one executable works fine right up until both of them export identical #[no_mangle] C symbols for the FFI layer and the linker gives up. The fix is a feature flag that turns the C ABI off on one of the two edges — a small ugly accommodation for a technique that has more than paid for it.

Thirteen platforms, because I am like this

One more testing note disguised as a shipping note. Each release goes out as native binaries for thirteen platforms — Linux on x86-64, Arm64, RISC-V and 64-bit MIPS; macOS on Intel and Apple Silicon; Windows; and FreeBSD, OpenBSD and NetBSD each on both x86-64 and Arm64 — built by a small fleet of single-board computers that boots a real BSD guest for the length of one compile and then puts it away again. There is no business case for most of that; there is not, so far as I know, a single OpenBSD/Arm64 user waiting on a ballistics calculator.

But it earns its place in this particular story, because portability is a bug detector. An engine that produces the same numbers on big-endian 64-bit MIPS as it does on Apple Silicon is an engine carrying fewer accidental assumptions about how its floats are laid out and how its integers are ordered. Thirteen platforms is thirteen independent opportunities to be told I assumed something I had not noticed assuming.

Solving it backwards

Everything so far is the forward problem: here is the load, tell me where it hits. That is the well-posed direction, and honestly, it is a solved problem — there are good calculators, mine included, and they mostly agree.

It is also not the question anybody actually has. Nobody at a loading bench wonders where their known load will land. They wonder the other way around: I want it to land here — what gets me there? Which powder, and how many grains of it, produces the velocity I want? What barrel twist rate will stabilize this bullet? How long should I seat this cartridge? What is this bullet's ballistic coefficient really, derived from its measured dimensions, rather than the optimistic number on the box?

Those are inverse problems, and inverse problems are where it stops being a matter of running the textbook forward. They generally have no closed form. You solve them by searching — running the forward model over and over inside a root-find or an optimizer, hunting for the input that produces the output that was asked for — and the search is only as trustworthy as the model inside its loop, which is the entire ballgame. A backward solver built on a mediocre forward model does not fail loudly. It produces a confident, specific, plausible number that is wrong, which is worse than useless in a domain where people act on the answer.

So that is where the real work went: the drag model those searches lean on is calibrated against Doppler radar measurements of how actual bullets actually decelerate — including through the transonic region, where the classical scale-a-reference-curve assumption is at its weakest — rather than assuming every projectile behaves like a reference shape from a century ago.

The split, stated plainly

I would rather just tell you the arrangement than have you discover it.

The engine is free and open: the library, the CLI, the WebAssembly build, the Python and Ruby bindings, the whole forward solver, the fuzzing harnesses, all of it. Compute trajectories, run dispersions, true your velocity against real measured drops, build hold tables, ship it inside something of your own. No account, no key, no telemetry. That is ballistics.rs.

The four inverse solvers are the one piece behind a subscription, at Ballistics Insight. They run as a service — in a browser, or from the same CLI once you have logged in:

ballistics login
ballistics recommend-powder --cartridge "308 Winchester" \
    --bullet-weight 175 --desired-velocity 2600

They are the paid piece because they are the part with real ongoing cost behind them — the measured drag data the searches depend on, and the compute to run them — and because a project like this is more likely to still exist in five years if some part of it pays for itself. If you shoot, they may be worth it to you. If you are here for the numerical methods and the fuzzing and the pile of BSD binaries, that is all free and I am glad you came.

One honest note if you do use the powder solver: what it returns is a starting point, not a recipe. It is where to begin working a load up, carefully, against published load data, over a chronograph, in the slow and boring and safe way. The physics is good. The physics is not your reloading manual and will not pretend to be.

The bullet still does not go where you point it. But it goes somewhere entirely predictable, and I find that a much more interesting fact than it first appears.

Physics-First ML: Why AI Should Correct, Not Replace, Scientific Models

A.C. Jokela — Sun, 25 Jan 2026 23:00:00 GMT

The Seductive Trap of Pure ML

There's a pattern I've seen repeated across scientific computing: a team has a physics-based model that works reasonably well. Someone suggests "we could use machine learning to improve this." Six months later, they've replaced the physics entirely with a neural network trained on historical data. The model works great, until it doesn't.

In ballistics, this failure mode isn't just embarrassing; it's dangerous. A 10% error in predicting bullet drop at 1000 yards translates to missing a target by nearly a foot. In hunting, that's a wounded animal. In defense applications, the consequences are graver still.

After spending a considerable amount of time thinking about and studying ballistics systems, I've arrived at a principle that runs counter to the current AI zeitgeist: machine learning should correct physics, not replace it. This isn't a rejection of ML; it's a recognition that physics provides something ML cannot: bounded, predictable behavior grounded in first principles.

The Philosophy: Physics as Foundation, ML as Refinement

Consider two approaches to predicting muzzle velocity from powder charge:

# Approach A: Pure ML
velocity = neural_network.predict(powder_charge, bullet_weight, barrel_length, bc)

# Approach B: Physics-First with ML Correction
base_velocity = physics_model.calculate(powder_charge, bullet_weight, barrel_length, bc)
correction = ml_model.predict_correction(powder_charge, bullet_weight, barrel_length, bc)
final_velocity = base_velocity * correction  # correction is bounded: 0.95-1.05

Approach A learns everything from data. It might achieve lower training error, but it has no guardrails. Feed it an unusual combination of inputs, and it might predict a velocity of -500 fps or 50,000 fps. The model has no concept of what's physically possible.

Approach B starts with physics: conservation of energy, gas dynamics, thermodynamics. These equations have been validated for centuries. The ML component only learns the residual: the small systematic errors that arise from simplified assumptions, manufacturing tolerances, or environmental factors the physics model doesn't capture.

Critically, the correction factor is bounded. In our production systems, we enforce limits of 0.8x to 1.25x for ballistic coefficient corrections. If the ML model wants to apply a larger correction, we reject it entirely rather than trust an outlier prediction.

Why Bounded Corrections Matter

The bound isn't arbitrary. It emerges from understanding what ML can legitimately learn versus what indicates a fundamental mismatch.

A ballistic coefficient (BC) published by a manufacturer might differ from real-world performance by 5-15% due to:

Manufacturing tolerances in bullet production
Differences between the manufacturer's test conditions and yours
Simplifications in how BC is measured and reported
Velocity-dependent effects not captured in a single BC value

These are exactly the kinds of systematic errors ML can learn to correct. A well-trained model might learn that Brand X's published BCs are consistently 8% optimistic, or that handloaded ammunition with a specific powder tends to perform 3% better than factory loads.

But a correction factor of 2.5x? That's not a refinement; that's a fundamental mismatch. Either the input data is wrong, or we've matched against the wrong reference bullet entirely.

The chart above illustrates the relationship between correction factor and prediction error. Within the acceptable zone (0.8x to 1.25x), errors remain manageable, typically under 20 inches at 1000 yards. But as correction factors grow larger, errors explode. The red dot marks a real bug we discovered: a 2.49x correction that produced 37% error in drop predictions.

A Real-World Failure: The 2.49x Bug

This isn't theoretical. In our BC enhancement service, we had a bug that perfectly illustrates the danger of unbounded ML corrections.

A user submitted a calculation for a 140-grain 6.5mm bullet with a G7 BC of 0.238. Our system attempted to enhance this BC using doppler-derived reference data. The matching algorithm found a reference bullet (a 142-grain Sierra MatchKing) based on caliber and weight similarity.

The problem? The Sierra 142gr SMK has a G7 BC of approximately 0.593. Our system computed a "correction factor" of 2.49x and confidently applied it.

The results were catastrophic:

Metric	User's BC (0.238)	"Enhanced" BC (0.593)	Error
Drop at 1000 yards	312.4"	196.8"	37%
Time of Flight	1.847s	1.512s	18%
Wind Drift (10 mph)	58.2"	36.7"	37%

A shooter trusting the "enhanced" prediction would have aimed nearly 10 feet too low. The ML system was confidently wrong because it had no concept of reasonable bounds.

The fix was straightforward: reject any match where the reference BC differs from the input BC by more than 30%. If the user says their BC is 0.238, we don't believe a database entry claiming 0.593 is the "true" value, no matter how similar the bullet weights.

# The fix: BC tolerance check
bc_ratio = matched_bc / user_input_bc
BC_TOLERANCE = 0.30  # 30% maximum deviation

if bc_ratio < (1 - BC_TOLERANCE) or bc_ratio > (1 + BC_TOLERANCE):
    logger.info(f"BC mismatch: user={user_input_bc:.4f}, matched={matched_bc:.4f}")
    return None  # Reject the match, don't guess

Ground Truth: Doppler-Derived Data

The foundation of any ML correction system is ground truth data. In exterior ballistics, the gold standard is doppler radar measurement, tracking a bullet's actual velocity throughout its flight path, not just at the muzzle.

Published ballistic coefficients are typically derived from limited testing under controlled conditions. Doppler data captures real-world performance across the entire velocity envelope, from supersonic through transonic to subsonic flight. This is particularly crucial in the transonic region (roughly Mach 0.9 to 1.1), where drag characteristics change dramatically and simple models break down.

We've built our correction models on an extensive dataset of doppler-derived measurements. This data captures the true behavior of projectiles across varying conditions, not the idealized behavior assumed by physics models or the optimistic values sometimes found in marketing materials.

Lapua, to their credit, publishes comprehensive doppler-derived BC data for their projectiles, making it freely available to the shooting community. Their data shows the velocity-dependent nature of BC that simpler models ignore:

The green curve shows actual BC measured via doppler radar across the velocity envelope. Notice the significant drop in the transonic region. This is real physics that a single published BC value (the dashed red line) cannot capture.

When our ML correction system encounters a bullet, it doesn't just look up a single BC. It retrieves or interpolates a velocity-dependent BC curve, then applies a bounded correction based on how similar bullets have performed relative to their published specifications.

The Correction Architecture

Our BC enhancement service follows a strict hierarchy:

Physics first: Calculate trajectory using established equations of motion, drag models (G1, G7), and atmospheric corrections.
Data lookup: Match the input bullet against our reference database using caliber, weight, and, critically, BC similarity.
Bounded correction: If a match is found and the reference BC is within tolerance, compute a correction factor clamped to [0.8, 1.25].
Confidence scoring: Report how confident we are in the enhancement, based on match quality.
Graceful degradation: If no good match exists, return the original physics prediction with enhanced=false rather than guessing.

class BCEnhancementService:
    # Correction factor bounds - these are NOT arbitrary
    MIN_CORRECTION = 0.80  # -20% maximum reduction
    MAX_CORRECTION = 1.25  # +25% maximum increase
    BC_MATCH_TOLERANCE = 0.30  # 30% BC similarity required

    def enhance_bc(self, user_bc: float, caliber: float, weight: float,
                   velocity: float) -> EnhancementResult:

        # Step 1: Find matching reference bullet
        match = self._find_reference_match(caliber, weight, user_bc)

        if match is None:
            return EnhancementResult(
                enhanced_bc=user_bc,
                applied=False,
                reason="No matching reference data"
            )

        # Step 2: Verify BC is within tolerance
        bc_ratio = match.reference_bc / user_bc
        if not (1 - self.BC_MATCH_TOLERANCE <= bc_ratio <= 1 + self.BC_MATCH_TOLERANCE):
            return EnhancementResult(
                enhanced_bc=user_bc,
                applied=False,
                reason=f"BC mismatch: {bc_ratio:.2f}x outside tolerance"
            )

        # Step 3: Compute bounded correction
        raw_correction = match.doppler_bc / match.published_bc
        correction = max(self.MIN_CORRECTION,
                        min(self.MAX_CORRECTION, raw_correction))

        enhanced_bc = user_bc * correction

        return EnhancementResult(
            enhanced_bc=enhanced_bc,
            applied=True,
            correction_factor=correction,
            confidence=match.confidence_score
        )

The key insight is the multiple validation gates. Each step can reject the enhancement and fall back to physics. The ML component only activates when we have high-quality reference data that closely matches the input.

Quantifying the Impact

How much does proper bounding actually matter? We analyzed prediction errors across our dataset, comparing three approaches:

Physics only: Standard trajectory calculation with published BC
Unbounded ML: ML corrections with no limits
Bounded ML: ML corrections clamped to [0.8, 1.25]

The results are instructive:

Physics only produces a bell curve centered around 14 inches of error, respectable and predictable, but leaving accuracy on the table.
Bounded ML shifts the distribution left, reducing mean absolute error to 8.7 inches, a 39% improvement. The tight bounds prevent catastrophic failures while capturing real improvements.
Unbounded ML has a lower peak error for some shots but develops a long tail of catastrophic failures. Mean error is actually worse than bounded ML (11.4" vs 8.7") because the outliers are so severe.

The unbounded approach wins on the easy cases but fails catastrophically on edge cases. The bounded approach trades a small amount of peak performance for dramatically improved worst-case behavior.

When ML Should Admit Ignorance

Perhaps the most important principle in physics-first ML is knowing when to say "I don't know."

Our system encounters situations where it has no good answer:

A wildcat cartridge with no reference data
A bullet design we've never seen
Input parameters that seem inconsistent or erroneous
Conditions outside our training distribution

In each case, the correct response is to return to physics rather than hallucinate an answer. The fallback hierarchy:

def get_best_prediction(inputs: BallisticInputs) -> Prediction:
    # Try enhanced prediction with doppler-derived corrections
    enhanced = bc_enhancement.enhance(inputs)
    if enhanced.applied and enhanced.confidence > 0.7:
        return run_trajectory(inputs, enhanced.bc)

    # Fall back to velocity-segmented BC if available
    if inputs.bullet in SEGMENTED_BC_DATABASE:
        segments = SEGMENTED_BC_DATABASE[inputs.bullet]
        return run_trajectory_segmented(inputs, segments)

    # Fall back to published BC with physics
    return run_trajectory(inputs, inputs.published_bc)

Each fallback is still grounded in physics. We never reach a state where the system is guessing without foundation.

Practical Implementation Considerations

Building a physics-first ML system requires discipline:

Separate training and inference bounds: During training, you might observe correction factors outside [0.8, 1.25]. Record these as anomalies for investigation (they often indicate data quality issues), but don't let them influence your production bounds.
Log rejection reasons: When the system refuses to apply ML enhancement, log why. These logs become valuable for identifying gaps in your reference database and cases where users have unrealistic expectations.
Expose confidence to users: Don't hide uncertainty. Our API returns a confidence score with every enhanced prediction. Users who need guaranteed accuracy can filter for high-confidence results or fall back to pure physics.
Validate against ground truth continuously: We continuously compare predictions against new doppler measurements as they become available. Any systematic drift in correction factors triggers investigation.
Version your bounds: The [0.8, 1.25] bounds aren't eternal truth; they're empirically derived from current data. As reference databases grow and ML models improve, bounds might tighten. Version them alongside your models.

The Broader Principle

This approach extends beyond ballistics. Any domain where physics provides a solid foundation can benefit from physics-first ML:

Fluid dynamics: ML can correct for turbulence model errors, but Navier-Stokes remains the foundation.
Structural engineering: ML can refine material property estimates, but equilibrium equations are non-negotiable.
Orbital mechanics: ML can improve atmospheric drag estimates, but Kepler's laws aren't learned from data.
Weather prediction: ML can enhance parameterizations, but conservation of mass, momentum, and energy are axiomatic.

In each case, the physics provides constraints that keep ML predictions physically plausible, while ML captures systematic errors and unmodeled effects that pure physics misses.

Conclusion

The current AI enthusiasm has created pressure to replace working systems with end-to-end neural networks. In scientific computing, this is often a mistake.

Physics models have centuries of validation behind them. They're interpretable, bounded, and fail gracefully. Machine learning excels at capturing complex patterns and correcting systematic errors, but it lacks physical intuition and can fail catastrophically on out-of-distribution inputs.

The synthesis (physics as foundation, ML as refinement, with bounded corrections that can be rejected entirely) gives us the best of both worlds. We get improved accuracy where data supports it, and guaranteed physical plausibility everywhere else.

When the ML system wants to apply a 2.49x correction, the bounded approach says "no, that's not a correction, that's a different bullet." When it has no reference data, it says "I'll defer to physics rather than guess." When conditions are within its training distribution, it says "here's an 8% correction I'm confident about."

That humility, knowing when to correct and when to abstain, is what separates useful ML from dangerous ML. Physics provides the guardrails. ML provides the refinement. Together, they're more accurate than either alone.

The ballistics engine described in this post is open source and available at ballistics.rs.

Transfer Learning for Predictive Custom Drag Modeling: Automated Generation of Drag Coefficient Curves Using Multi-Modal AI

A.C. Jokela — Fri, 10 Oct 2025 18:10:00 GMT

TL;DR

We built a neural network that predicts full drag coefficient curves (41 Mach points from 0.5 to 4.5) for rifle bullets using only basic specifications like weight, caliber, and ballistic coefficient. The system achieves 3.15% mean absolute error and has been serving predictions in production since September 2025. This post walks through the technical implementation details, architecture decisions, and lessons learned building a real-world ML system for ballistic physics.

Read the full whitepaper: Transfer Learning for Predictive Custom Drag Modeling (17 pages)

The Problem: Drag Curves Are Scarce, But Critical

If you've ever built a ballistic calculator, you know the challenge: accurate drag modeling is everything. Standard drag models (G1, G7, G8) work okay for "average" bullets, but modern precision shooting demands better. Custom Drag Models (CDMs), full drag coefficient curves measured with doppler radar, are the gold standard. They capture the unique aerodynamic signature of each bullet design.

The catch? Getting a CDM requires: - Access to a doppler radar range (≈$500K+ equipment) - Firing 50-100 rounds at various velocities - Expert analysis to process the raw data - Cost: $5,000-$15,000 per bullet

For manufacturers like Hornady and Lapua, this is routine. For smaller manufacturers or custom bullet makers? Not happening. We had 641 bullets with real radar-measured CDMs and thousands of bullets with only basic specs. Could we use machine learning to bridge the gap?

The Vision: Transfer Learning from Radar Data

The core insight: bullets with similar physical characteristics have similar drag curves. A 168gr .308 boattail match bullet from Manufacturer A will drag similarly to one from Manufacturer B. We could train a neural network on our 641 radar-measured bullets and use transfer learning to predict CDMs for bullets we've never measured.

But we faced an immediate data problem: 641 samples isn't much for deep learning. Enter synthetic data augmentation.

Part 1: Automating Data Extraction with Claude Vision

Applied Ballistics publishes ballistic data for 704+ bullets as JPEG images. Manual data entry would take 1,408 hours (704 bullets × 2 hours each). We needed automation.

The Vision Processing Pipeline

We built an extraction pipeline using Claude 3.5 Sonnet's vision capabilities:

import anthropic
import base64
from pathlib import Path

def extract_bullet_data(image_path: str) -> dict:
    """Extract bullet specifications from AB datasheet JPEG."""
    client = anthropic.Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"])

    # Load and encode image
    with open(image_path, "rb") as f:
        image_data = base64.standard_b64encode(f.read()).decode("utf-8")

    # Vision extraction prompt
    message = client.messages.create(
        model="claude-3-5-sonnet-20241022",
        max_tokens=1024,
        messages=[{
            "role": "user",
            "content": [
                {
                    "type": "image",
                    "source": {
                        "type": "base64",
                        "media_type": "image/jpeg",
                        "data": image_data,
                    },
                },
                {
                    "type": "text",
                    "text": """Extract the following from this Applied Ballistics bullet datasheet:
                    - Caliber (inches, decimal format)
                    - Bullet weight (grains)
                    - G1 Ballistic Coefficient
                    - G7 Ballistic Coefficient
                    - Bullet length (inches, if visible)
                    - Ogive radius (calibers, if visible)

                    Return as JSON with keys: caliber, weight_gr, bc_g1, bc_g7, length_in, ogive_radius_cal"""
                }
            ],
        }]
    )

    # Parse response
    data = json.loads(message.content[0].text)

    # Physics validation
    validate_bullet_physics(data)

    return data

def validate_bullet_physics(data: dict):
    """Sanity checks for extracted data."""
    caliber = data['caliber']
    weight = data['weight_gr']

    # Caliber bounds
    assert 0.172 <= caliber <= 0.50, f"Invalid caliber: {caliber}"

    # Weight-to-caliber ratio (sectional density proxy)
    ratio = weight / (caliber  3)
    assert 0.5 <= ratio <= 2.0, f"Implausible weight for caliber: {weight}gr @ {caliber}in"

    # BC sanity
    assert 0.1 <= data['bc_g1'] <= 1.2, f"Invalid G1 BC: {data['bc_g1']}"
    assert 0.1 <= data['bc_g7'] <= 0.9, f"Invalid G7 BC: {data['bc_g7']}"

Figure 2: Claude Vision extraction pipeline - from JPEG datasheets to structured bullet specifications

Results: - 704/704 successful extractions (100% success rate) - 2.3 seconds per bullet (average) - 27 minutes total vs. 1,408 hours manual - 99.97% time savings

We validated against a manually-verified subset of 50 bullets: - 100% match on caliber - 98% match on weight (±0.5 grain tolerance) - 96% match on BC values (±0.002 tolerance)

The vision model occasionally struggled with hand-drawn or low-quality scans, but the physics validation caught these errors before they corrupted our dataset.

Part 2: Generating Synthetic CDM Curves

Now we had 704 bullets with BC values but no full CDM curves. We needed to synthesize them.

The BC-to-CDM Transformation Algorithm

The relationship between ballistic coefficient and drag coefficient is straightforward:

BC = m / (C_d × d²)

Rearranging:
C_d(M) = m / (BC(M) × d²)

But BC values are typically single scalars, not curves. We developed a 5-step hybrid algorithm combining standard drag model references with BC-derived corrections:

Step 1: Base Reference Curve

Start with the G7 standard drag curve as a baseline (better for modern boattail bullets than G1):

def get_g7_reference_curve(mach_points: np.ndarray) -> np.ndarray:
    """G7 standard drag curve from McCoy (1999)."""
    # Precomputed G7 curve at 41 Mach points
    return interpolate_standard_curve("G7", mach_points)

Step 2: BC-Based Scaling

Scale the reference curve using extracted BC values:

def scale_by_bc(cd_base: np.ndarray, bc_actual: float, bc_reference: float = 0.221) -> np.ndarray:
    """Scale drag curve to match actual BC.

    BC_G7_ref = 0.221 (G7 standard projectile)
    """
    scaling_factor = bc_reference / bc_actual
    return cd_base * scaling_factor

Step 3: Multi-Regime Interpolation

When both G1 and G7 BCs are available, blend them based on Mach regime:

def blend_drag_models(mach: np.ndarray, cd_g1: np.ndarray, cd_g7: np.ndarray) -> np.ndarray:
    """Blend G1 and G7 curves based on flight regime.

    - Supersonic (M > 1.2): Use G1 (better for shock wave region)
    - Transonic (0.8 < M < 1.2): Cubic spline interpolation
    - Subsonic (M < 0.8): Use G7 (better for low-speed)
    """
    cd_blended = np.zeros_like(mach)

    for i, M in enumerate(mach):
        if M > 1.2:
            # Supersonic: G1 better captures shock effects
            cd_blended[i] = cd_g1[i]
        elif M < 0.8:
            # Subsonic: G7 better for boattail bullets
            cd_blended[i] = cd_g7[i]
        else:
            # Transonic: smooth interpolation
            t = (M - 0.8) / 0.4  # Normalize to [0, 1]
            cd_blended[i] = cubic_interpolate(cd_g7[i], cd_g1[i], t)

    return cd_blended

Step 4: Transonic Peak Generation

Model the transonic drag spike using a Gaussian kernel:

def add_transonic_peak(cd_base: np.ndarray, mach: np.ndarray,
                       bc_g1: float, bc_g7: float) -> np.ndarray:
    """Add realistic transonic drag spike.

    Peak amplitude calibrated from BC ratio (G1 worse than G7 in transonic).
    """
    # Estimate peak amplitude from BC discrepancy
    bc_ratio = bc_g1 / bc_g7
    peak_amplitude = 0.15 * (bc_ratio - 1.0)  # Empirically tuned

    # Gaussian centered at critical Mach
    M_crit = 1.0
    sigma = 0.15

    transonic_spike = peak_amplitude * np.exp(-((mach - M_crit)  2) / (2 * sigma  2))

    return cd_base + transonic_spike

Step 5: Monotonicity Enforcement

Apply Savitzky-Golay smoothing to prevent unphysical oscillations:

from scipy.signal import savgol_filter

def enforce_smoothness(cd_curve: np.ndarray, window_length: int = 7, polyorder: int = 3) -> np.ndarray:
    """Smooth drag curve while preserving transonic peak.

    Savitzky-Golay filter preserves peak shape better than moving average.
    """
    # Must have odd window length
    if window_length % 2 == 0:
        window_length += 1

    return savgol_filter(cd_curve, window_length, polyorder, mode='nearest')

Validation Against Ground Truth

We validated synthetic curves against 127 bullets where both BC values and full CDM curves were available:

Metric	Value	Notes
Mean Absolute Error	3.2%	Across all Mach points
Transonic Error	4.8%	Mach 0.8-1.2 (most challenging)
Supersonic Error	2.1%	Mach 1.5-3.0 (best performance)
Shape Correlation	r = 0.984	Pearson correlation

The synthetic curves satisfied all physics constraints: - Monotonic decrease in supersonic regime - Realistic transonic peaks (1.3-2.0× baseline) - Smooth transitions between regimes

Figure 3: Validation of synthetic CDM curves against ground truth radar measurements

Total training data: 1,345 bullets (704 synthetic + 641 real), 2.1x data augmentation.

Part 3: Architecture Exploration

With data ready, we explored four neural architectures:

1. Multi-Layer Perceptron (Baseline)

Simple feedforward network:

import torch
import torch.nn as nn

class CDMPredictor(nn.Module):
    """MLP for CDM prediction: 13 features → 41 Cd values."""

    def __init__(self, dropout: float = 0.2):
        super().__init__()
        self.network = nn.Sequential(
            nn.Linear(13, 256),
            nn.ReLU(),
            nn.Dropout(dropout),

            nn.Linear(256, 512),
            nn.ReLU(),
            nn.Dropout(dropout),

            nn.Linear(512, 512),
            nn.ReLU(),
            nn.Dropout(dropout),

            nn.Linear(512, 256),
            nn.ReLU(),
            nn.Dropout(dropout),

            nn.Linear(256, 41)  # Output: 41 Mach points
        )

    def forward(self, x):
        return self.network(x)

Input Features (13 total):

features = [
    'caliber',           # inches
    'weight_gr',         # grains
    'bc_g1',            # G1 ballistic coefficient
    'bc_g7',            # G7 ballistic coefficient
    'length_in',        # bullet length (imputed if missing)
    'ogive_radius_cal', # ogive radius in calibers
    'meplat_diam_in',   # meplat diameter
    'boat_tail_angle',  # boattail angle (degrees)
    'bearing_length',   # bearing surface length
    'sectional_density', # weight / caliber²
    'form_factor_g1',   # i / BC_G1
    'form_factor_g7',   # i / BC_G7
    'length_to_diameter' # L/D ratio
]

Figure 4: MLP architecture - 13 input features through 4 hidden layers to 41 output Mach points

2. Physics-Informed Neural Network (PINN)

Added physics loss term enforcing drag model constraints:

class PINN_CDMPredictor(nn.Module):
    """Physics-Informed NN with drag equation constraints."""

    def __init__(self):
        super().__init__()
        # Same architecture as MLP
        self.network = build_mlp_network()

    def physics_loss(self, cd_pred: torch.Tensor, features: torch.Tensor, mach: torch.Tensor) -> torch.Tensor:
        """Enforce physics constraints on predictions.

        Constraints:
        1. Drag increases with Mach in subsonic
        2. Transonic peak exists near M=1
        3. Monotonic decrease in supersonic
        """
        # Constraint 1: Subsonic gradient
        subsonic_mask = mach < 0.8
        subsonic_cd = cd_pred[subsonic_mask]
        subsonic_grad = torch.diff(subsonic_cd)
        subsonic_violation = torch.relu(-subsonic_grad).sum()  # Penalize decreases

        # Constraint 2: Transonic peak
        transonic_mask = (mach >= 0.8) & (mach <= 1.2)
        transonic_cd = cd_pred[transonic_mask]
        peak_violation = torch.relu(1.1 - transonic_cd.max()).sum()  # Must exceed 1.1

        # Constraint 3: Supersonic monotonicity
        supersonic_mask = mach > 1.5
        supersonic_cd = cd_pred[supersonic_mask]
        supersonic_grad = torch.diff(supersonic_cd)
        supersonic_violation = torch.relu(supersonic_grad).sum()  # Penalize increases

        return subsonic_violation + peak_violation + supersonic_violation

def total_loss(cd_pred, cd_true, features, mach, lambda_physics=0.1):
    """Combined data + physics loss."""
    data_loss = nn.MSELoss()(cd_pred, cd_true)
    physics_loss = model.physics_loss(cd_pred, features, mach)

    return data_loss + lambda_physics * physics_loss

Result: Over-regularization. Physics loss was too strict, preventing the model from learning subtle variations. Performance degraded to 4.86% MAE.

3. Transformer Architecture

Treated the 41 Mach points as a sequence:

class TransformerCDM(nn.Module):
    """Transformer encoder for sequence-to-sequence CDM prediction."""

    def __init__(self, d_model=128, nhead=8, num_layers=4):
        super().__init__()

        self.feature_embedding = nn.Linear(13, d_model)

        encoder_layer = nn.TransformerEncoderLayer(
            d_model=d_model,
            nhead=nhead,
            dim_feedforward=512,
            dropout=0.1
        )
        self.transformer = nn.TransformerEncoder(encoder_layer, num_layers=num_layers)

        self.output_head = nn.Linear(d_model, 41)

    def forward(self, x):
        # x: [batch, 13]
        embedded = self.feature_embedding(x)  # [batch, d_model]
        embedded = embedded.unsqueeze(1).expand(-1, 41, -1)  # [batch, 41, d_model]

        transformed = self.transformer(embedded)  # [batch, 41, d_model]

        cd_pred = self.output_head(transformed[:, :, :]).squeeze(-1)  # [batch, 41]

        return cd_pred

Result: Mismatch between architecture and problem. CDM prediction isn't a sequence modeling task; Mach points are independent given bullet features. Performance: 6.05% MAE.

4. Neural ODE

Attempted to model drag as a continuous ODE:

from torchdiffeq import odeint

class DragODE(nn.Module):
    """Neural ODE for continuous drag modeling."""

    def __init__(self, hidden_dim=64):
        super().__init__()
        self.net = nn.Sequential(
            nn.Linear(1 + 13, hidden_dim),  # Mach + features
            nn.Tanh(),
            nn.Linear(hidden_dim, hidden_dim),
            nn.Tanh(),
            nn.Linear(hidden_dim, 1)  # dCd/dM
        )

    def forward(self, t, state):
        # t: current Mach number
        # state: [Cd, features...]
        return self.net(torch.cat([t, state], dim=-1))

def predict_cdm(features, mach_points):
    """Integrate ODE to get Cd curve."""
    initial_cd = torch.tensor([0.5])  # Initial guess
    state = torch.cat([initial_cd, features])

    solution = odeint(ode_func, state, mach_points)

    return solution[:, 0]  # Extract Cd values

Result: Failed to converge due to dimension mismatch errors and extreme sensitivity to initial conditions. Abandoned after 2 days of debugging.

Architecture Comparison Results

Architecture	MAE	Smoothness	Shape Correlation	Status
MLP Baseline	3.66%	90.05%	0.9380	✅ Best
Physics-Informed NN	4.86%	64.02%	0.8234	❌ Over-regularized
Transformer	6.05%	56.83%	0.7891	❌ Poor fit
Neural ODE	---	---	---	❌ Failed to converge

Figure 5: Performance comparison across four neural architectures - MLP baseline wins

Key Insight: Simple MLP with dropout outperformed complex physics-constrained models. The training data already contained sufficient physics signal; explicit constraints hurt generalization.

Part 4: Production System Design

The POC model (3.66% MAE) validated the approach. Now we needed production hardening.

Training Pipeline Improvements

import pytorch_lightning as pl
from torch.utils.data import DataLoader, TensorDataset

class ProductionCDMModel(pl.LightningModule):
    """Production-ready CDM predictor with monitoring."""

    def __init__(self, learning_rate=1e-3, weight_decay=1e-4):
        super().__init__()
        self.save_hyperparameters()

        self.model = CDMPredictor(dropout=0.2)
        self.learning_rate = learning_rate
        self.weight_decay = weight_decay

        # Metrics tracking
        self.train_mae = []
        self.val_mae = []

    def forward(self, x):
        return self.model(x)

    def training_step(self, batch, batch_idx):
        features, cd_true = batch
        cd_pred = self(features)

        # Weighted MSE loss (emphasize transonic region)
        weights = self._get_mach_weights()
        loss = (weights * (cd_pred - cd_true)  2).mean()

        # Metrics
        mae = torch.abs(cd_pred - cd_true).mean()
        self.log('train_loss', loss)
        self.log('train_mae', mae)

        return loss

    def validation_step(self, batch, batch_idx):
        features, cd_true = batch
        cd_pred = self(features)

        loss = nn.MSELoss()(cd_pred, cd_true)
        mae = torch.abs(cd_pred - cd_true).mean()

        self.log('val_loss', loss)
        self.log('val_mae', mae)

        # Physics validation
        smoothness = self._calculate_smoothness(cd_pred)
        transonic_quality = self._check_transonic_peak(cd_pred)

        self.log('smoothness', smoothness)
        self.log('transonic_quality', transonic_quality)

        return loss

    def configure_optimizers(self):
        optimizer = torch.optim.AdamW(
            self.parameters(),
            lr=self.learning_rate,
            weight_decay=self.weight_decay
        )

        scheduler = torch.optim.lr_scheduler.ReduceLROnPlateau(
            optimizer,
            mode='min',
            factor=0.5,
            patience=5,
            verbose=True
        )

        return {
            'optimizer': optimizer,
            'lr_scheduler': scheduler,
            'monitor': 'val_loss'
        }

    def _get_mach_weights(self):
        """Weight transonic region more heavily."""
        weights = torch.ones(41)
        transonic_indices = (self.mach_points >= 0.8) & (self.mach_points <= 1.2)
        weights[transonic_indices] = 2.0  # 2x weight in transonic
        return weights / weights.sum()

    def _calculate_smoothness(self, cd_pred):
        """Measure curve smoothness (low = better)."""
        second_derivative = torch.diff(cd_pred, n=2, dim=-1)
        return 1.0 / (1.0 + second_derivative.abs().mean())

    def _check_transonic_peak(self, cd_pred):
        """Verify transonic peak exists and is realistic."""
        transonic_mask = (self.mach_points >= 0.8) & (self.mach_points <= 1.2)
        peak_cd = cd_pred[:, transonic_mask].max(dim=1)[0]
        baseline_cd = cd_pred[:, 0]  # Subsonic baseline

        return (peak_cd / baseline_cd).mean()  # Should be > 1.0

Training Configuration

# Data preparation
X_train, X_val, X_test = prepare_features()  # 1,039 → 831 / 104 / 104
y_train, y_val, y_test = prepare_targets()

train_dataset = TensorDataset(X_train, y_train)
val_dataset = TensorDataset(X_val, y_val)

train_loader = DataLoader(train_dataset, batch_size=32, shuffle=True, num_workers=4)
val_loader = DataLoader(val_dataset, batch_size=32, shuffle=False, num_workers=4)

# Model training
model = ProductionCDMModel(learning_rate=1e-3, weight_decay=1e-4)

trainer = pl.Trainer(
    max_epochs=100,
    callbacks=[
        pl.callbacks.EarlyStopping(monitor='val_loss', patience=10, mode='min'),
        pl.callbacks.ModelCheckpoint(monitor='val_mae', mode='min', save_top_k=3),
        pl.callbacks.LearningRateMonitor(logging_interval='epoch')
    ],
    accelerator='gpu',
    devices=1,
    log_every_n_steps=10
)

trainer.fit(model, train_loader, val_loader)

Figure 6: Training and validation loss convergence over 60 epochs

Training Results: - Converged at epoch 60 (early stopping) - Final validation loss: 0.0023 - Production model MAE: 3.15% (13.9% improvement over POC) - Smoothness: 88.81% (close to ground truth 89.6%) - Shape correlation: 0.9545

Figure 7: Example predicted CDM curves compared to ground truth measurements

API Integration

# ballistics/ml/cdm_transfer_learning.py

import torch
import pickle
from pathlib import Path

class CDMTransferLearning:
    """Production CDM prediction service."""

    def __init__(self, model_path: str = "models/cdm_transfer_learning/production_mlp.pkl"):
        self.model = self._load_model(model_path)
        self.model.eval()

        # Feature statistics for normalization
        with open(model_path.replace('.pkl', '_stats.pkl'), 'rb') as f:
            self.feature_stats = pickle.load(f)

    def predict(self, bullet_data: dict) -> dict:
        """Predict CDM curve from bullet specifications.

        Args:
            bullet_data: Dict with keys: caliber, weight_gr, bc_g1, bc_g7, etc.

        Returns:
            Dict with mach_numbers, drag_coefficients, validation_metrics
        """
        # Feature engineering
        features = self._extract_features(bullet_data)
        features_normalized = self._normalize_features(features)

        # Prediction
        with torch.no_grad():
            cd_pred = self.model(torch.tensor(features_normalized, dtype=torch.float32))

        # Denormalize
        cd_values = cd_pred.numpy()

        # Validation
        validation = self._validate_prediction(cd_values)

        return {
            'mach_numbers': self.mach_points.tolist(),
            'drag_coefficients': cd_values.tolist(),
            'source': 'ml_transfer_learning',
            'method': 'mlp_prediction',
            'validation': validation
        }

    def _validate_prediction(self, cd_values: np.ndarray) -> dict:
        """Physics validation of predicted curve."""
        return {
            'smoothness': self._calculate_smoothness(cd_values),
            'transonic_quality': self._check_transonic_peak(cd_values),
            'negative_cd_count': (cd_values < 0).sum(),
            'physical_plausibility': self._check_plausibility(cd_values)
        }

REST API Endpoint

# routes/bullets_unified.py

@bp.route('/search', methods=['GET'])
def search_bullets():
    """Search unified bullet database with optional CDM prediction."""
    query = request.args.get('q', '')
    use_cdm_prediction = request.args.get('use_cdm_prediction', 'true').lower() == 'true'

    # Search database
    results = search_database(query)

    cdm_predictions_made = 0

    if use_cdm_prediction:
        cdm_predictor = CDMTransferLearning()

        for bullet in results:
            if bullet.get('cdm_data') is None:
                # Predict CDM if not available
                try:
                    cdm_data = cdm_predictor.predict({
                        'caliber': bullet['caliber'],
                        'weight_gr': bullet['weight_gr'],
                        'bc_g1': bullet.get('bc_g1'),
                        'bc_g7': bullet.get('bc_g7'),
                        'length_in': bullet.get('length_in'),
                        'ogive_radius_cal': bullet.get('ogive_radius_cal')
                    })

                    bullet['cdm_data'] = cdm_data
                    bullet['cdm_predicted'] = True
                    cdm_predictions_made += 1

                except Exception as e:
                    logger.warning(f"CDM prediction failed for bullet {bullet['id']}: {e}")

    return jsonify({
        'results': results,
        'cdm_prediction_enabled': use_cdm_prediction,
        'cdm_predictions_made': cdm_predictions_made
    })

Example Response:

{
  "results": [
    {
      "id": 1234,
      "manufacturer": "Sierra",
      "model": "MatchKing",
      "caliber": 0.308,
      "weight_gr": 168,
      "bc_g1": 0.462,
      "bc_g7": 0.237,
      "cdm_data": {
        "mach_numbers": [0.5, 0.55, 0.6, ..., 4.5],
        "drag_coefficients": [0.287, 0.289, 0.295, ..., 0.312],
        "source": "ml_transfer_learning",
        "method": "mlp_prediction",
        "validation": {
          "smoothness": 91.2,
          "transonic_quality": 1.45,
          "negative_cd_count": 0,
          "physical_plausibility": true
        }
      },
      "cdm_predicted": true
    }
  ],
  "cdm_prediction_enabled": true,
  "cdm_predictions_made": 18
}

Part 5: Deployment and Monitoring

Model Serving Architecture

┌─────────────────┐
│   Client App    │
└────────┬────────┘
         │
         ▼
┌─────────────────────────┐
│  Google Cloud Function  │
│  (Python 3.12)          │
│  - Flask routing        │
│  - Request validation   │
│  - Response formatting  │
└────────┬────────────────┘
         │
         ▼
┌─────────────────────────┐
│  CDMTransferLearning    │
│  - PyTorch model (2.1MB)│
│  - CPU inference (<10ms)│
│  - Feature engineering  │
└────────┬────────────────┘
         │
         ▼
┌─────────────────────────┐
│  Physics Validation     │
│  - Smoothness check     │
│  - Peak detection       │
│  - Plausibility gates   │
└─────────────────────────┘

Performance Characteristics

Model Size: - PyTorch state dict: 2.1 MB - TorchScript (optional): 2.3 MB - ONNX (optional): 1.8 MB

Inference Speed (CPU): - Single prediction: 6-8 ms - Batch of 10: 12-15 ms (1.2-1.5 ms per bullet) - Batch of 100: 80-100 ms (0.8-1.0 ms per bullet)

Cold Start: - Model load time: 150-200 ms - First prediction: 220-280 ms (including load) - Subsequent predictions: 6-8 ms

Memory Footprint: - Model in memory: ~15 MB - Peak during inference: ~30 MB

Figure 8: Production inference performance metrics across different batch sizes

Monitoring and Observability

import newrelic.agent

class MonitoredCDMPredictor:
    """CDM predictor with New Relic monitoring."""

    def __init__(self):
        self.predictor = CDMTransferLearning()
        self.prediction_count = 0
        self.error_count = 0

    @newrelic.agent.function_trace()
    def predict(self, bullet_data: dict) -> dict:
        """Predict with telemetry."""
        self.prediction_count += 1

        try:
            # Track prediction time
            with newrelic.agent.FunctionTrace(name='cdm_prediction'):
                result = self.predictor.predict(bullet_data)

            # Custom metrics
            newrelic.agent.record_custom_metric('CDM/Predictions/Total', self.prediction_count)
            newrelic.agent.record_custom_metric('CDM/Validation/Smoothness',
                                               result['validation']['smoothness'])
            newrelic.agent.record_custom_metric('CDM/Validation/TransonicQuality',
                                               result['validation']['transonic_quality'])

            # Track feature availability
            features_available = sum(1 for k, v in bullet_data.items() if v is not None)
            newrelic.agent.record_custom_metric('CDM/Features/Available', features_available)

            return result

        except Exception as e:
            self.error_count += 1
            newrelic.agent.record_custom_metric('CDM/Errors/Total', self.error_count)
            newrelic.agent.notice_error()
            raise

Key Metrics Tracked: - Prediction latency (p50, p95, p99) - Validation scores (smoothness, transonic quality) - Feature availability (how many inputs provided) - Error rate and types - Cache hit rate (if caching enabled)

Lessons Learned

1. Simple Architectures Often Win

We spent a week exploring Transformers and Neural ODEs, only to find the vanilla MLP performed best. Why?

Data alignment: Our problem is function approximation, not sequence modeling
Inductive bias mismatch: Transformers expect temporal dependencies; drag curves don't have them
Regularization sufficiency: Dropout + weight decay provided enough regularization without physics constraints

Lesson: Start simple. Add complexity only when data clearly demands it.

2. Physics Validation > Physics Loss

Hard-coded physics loss functions became a liability: - Over-constrained the model - Required manual tuning of loss weights - Didn't generalize to all bullet types

Better approach: Validate predictions post-hoc and flag anomalies. Let the model learn physics from data.

3. Synthetic Data Quality Matters More Than Quantity

We generated 704 synthetic CDMs, but spent equal time validating them. Key insight: One bad synthetic sample can poison dozens of real samples during training.

Validation process: 1. Compare synthetic vs. real CDMs (where both exist) 2. Physics plausibility checks 3. Cross-validation with different BC values 4. Manual inspection of outliers

4. Feature Engineering > Model Complexity

The most impactful changes weren't architectural: - Adding sectional_density as a feature: -0.8% MAE - Computing form_factor_g1 and form_factor_g7: -0.6% MAE - Imputing missing features (length, ogive) using physics-based defaults: -0.5% MAE

Figure 9: Feature importance analysis showing impact of each input feature on prediction accuracy

Combined improvement: -1.9% MAE with zero code changes to the model.

5. Production Deployment ≠ POC

Our POC model worked great in notebooks. Production required: - Input validation and sanitization - Graceful degradation when features missing - Physics validation gates - Monitoring and alerting - Model versioning and rollback capability - A/B testing infrastructure

Time split: 30% research, 70% production engineering.

What's Next?

Phase 2: Uncertainty Quantification

Current model outputs point estimates. We're implementing Bayesian Neural Networks to provide confidence intervals:

class BayesianCDMPredictor(nn.Module):
    """Bayesian NN with dropout as approximate inference."""

    def predict_with_uncertainty(self, features, n_samples=100):
        """Monte Carlo dropout for uncertainty estimation."""
        self.train()  # Enable dropout during inference

        predictions = []
        for _ in range(n_samples):
            with torch.no_grad():
                pred = self(features)
                predictions.append(pred)

        predictions = torch.stack(predictions)

        mean = predictions.mean(dim=0)
        std = predictions.std(dim=0)

        return {
            'cd_mean': mean,
            'cd_std': std,
            'cd_lower': mean - 1.96 * std,  # 95% CI
            'cd_upper': mean + 1.96 * std
        }

Use case: Flag predictions with high uncertainty for manual review or experimental validation.

Conclusion

Building a production ML system for ballistic drag prediction required more than just training a model: - Data engineering (Claude Vision automation saved countless hours) - Synthetic data generation (2.1× data augmentation) - Architecture exploration (simple MLP won) - Real-world validation (94% physics check pass rate)

The result: 1,247 bullets now have accurate drag models that didn't exist before. Not bad for a side project.

Read the full technical whitepaper for mathematical derivations, validation details, and complete bibliography: cdm_transfer_learning.pdf

Resources

References: 1. McCoy, R. L. (1999). Modern Exterior Ballistics. Schiffer Publishing. 2. Litz, B. (2016). Applied Ballistics for Long Range Shooting (3rd ed.).

Smart Ballistics: How Machine Learning Helps Calculate Bullet Stability When Data Is Missing

A.C. Jokela — Sun, 24 Aug 2025 21:28:03 GMT

When a bullet leaves a rifle barrel, it's spinning, sometimes over 200,000 RPM. This spin is crucial: without it, the projectile would tumble unpredictably through the air like a thrown stick. But here's the problem: calculating whether a bullet will fly stable requires knowing its exact dimensions, and manufacturers often keep critical measurements secret. This is where machine learning comes to the rescue, not by replacing physics, but by filling in the missing pieces.

Open Sourcing a High Performance Rust-based Ballistics Engine

A.C. Jokela — Sat, 16 Aug 2025 21:11:16 GMT

From SaaS to Open Source: The Evolution of a Ballistics Engine

When I first built Ballistics Insight, my ML-augmented ballistics calculation platform, I faced a classic engineering dilemma: how to balance performance, accuracy, and maintainability across multiple platforms. The solution came in the form of a high-performance Rust core that became the beating heart of the system. Today, I'm excited to share that journey and announce the open-sourcing of this engine as a standalone library with full FFI bindings for iOS and Android.

The Genesis: A Python Problem

The story begins with a Python Flask application serving ballistics calculations through a REST API. The initial implementation worked well enough for proof-of-concept, but as I added more sophisticated physics models (Magnus effect, Coriolis force, transonic drag corrections, gyroscopic precession) the performance limitations became apparent. A single trajectory calculation that should take milliseconds was stretching into seconds. Monte Carlo simulations with thousands of iterations were becoming impractical.

The Python implementation had another challenge: code duplication. I maintained separate implementations for atmospheric calculations, drag computations, and trajectory integration. Each time I fixed a bug or improved an algorithm, I had to ensure consistency across multiple code paths. The maintenance burden was growing exponentially with the feature set.

The Rust Revolution

The decision to rewrite the core physics engine in Rust wasn't taken lightly. I evaluated several options: optimizing the Python code with NumPy vectorization, using Cython for critical paths, or even moving to C++. Rust won for several compelling reasons:

Memory Safety Without Garbage Collection: Ballistics calculations involve extensive numerical computation with predictable memory patterns. Rust's ownership system eliminated entire categories of bugs while maintaining deterministic performance.
Zero-Cost Abstractions: I could write high-level, maintainable code that compiled down to assembly as efficient as hand-optimized C.
Excellent FFI Story: Rust's ability to expose C-compatible interfaces meant I could integrate with any platform: Python, iOS, Android, or web via WebAssembly.
Modern Tooling: Cargo, Rust's build system and package manager, made dependency management and cross-compilation straightforward.

The results were dramatic. Atmospheric calculations went from 4.5ms in Python to 0.8ms in Rust, a 5.6x improvement. Complete trajectory calculations saw 15-20x performance gains. Monte Carlo simulations that previously took minutes now completed in seconds.

Architecture: From Monolith to Modular

The closed-source Ballistics Insight platform is a sophisticated system with ML augmentations, weather integration, and a comprehensive ammunition database. It includes features like:

Neural network-based BC (Ballistic Coefficient) prediction
Regional weather model integration with ERA5, OpenWeather, and NOAA data
Magnus effect auto-calibration based on bullet classification
Yaw damping prediction using gyroscopic stability factors
A database of 2,000+ bullets with manufacturer specifications

For the open-source release, I took a different approach. Rather than trying to extract everything, I focused on the core physics engine, the foundation that makes everything else possible. This meant:

Extracting Pure Physics: I separated the deterministic physics calculations from the ML augmentations. The open-source engine provides the fundamental ballistics math, while the SaaS platform layers intelligent corrections on top.
Creating Clean Interfaces: I designed a new FFI layer from scratch, ensuring that iOS and Android developers could easily integrate the engine without understanding Rust or ballistics physics.
Building Standalone Tools: The engine includes a full-featured command-line interface, making it useful for researchers, enthusiasts, and developers who need quick calculations without writing code.

The FFI Challenge: Making Rust Speak Every Language

One of my primary goals was to make the engine accessible from any platform. This meant creating robust Foreign Function Interface (FFI) bindings that could be consumed by Swift, Kotlin, Java, Python, or any language that can call C functions.

The FFI layer presented unique challenges:

#[repr(C)]
pub struct FFIBallisticInputs {
    pub muzzle_velocity: c_double,        // m/s
    pub ballistic_coefficient: c_double,
    pub mass: c_double,                   // kg
    pub diameter: c_double,               // meters
    pub drag_model: c_int,                // 0=G1, 1=G7
    pub sight_height: c_double,           // meters
    // ... many more fields
}

I had to ensure: - C-compatible memory layouts using #[repr(C)] - Safe memory management across language boundaries - Graceful error handling without exceptions - Zero-copy data transfer where possible

The result is a library that can be dropped into an iOS app as a static library, integrated into Android via JNI, or called from Python using ctypes. Each platform sees a native interface while the Rust engine handles the heavy lifting.

The Mobile Story: Binary Libraries for iOS and Android

Creating mobile bindings required careful consideration of each platform's requirements:

iOS Integration

For iOS, I compile the Rust library to a universal static library supporting both ARM64 (devices) and x86_64 (simulator). Swift developers interact with the engine through a bridging header:

let inputs = FFIBallisticInputs(
    muzzle_velocity: 823.0,
    ballistic_coefficient: 0.475,
    mass: 0.0109,
    diameter: 0.00782,
    // ...
)

let result = ballistics_calculate_trajectory(&inputs, nil, nil, 1000.0, 0.1)
defer { ballistics_free_trajectory_result(result) }

print("Max range: \(result.pointee.max_range) meters")

Android Integration

For Android, I provide pre-compiled libraries for multiple architectures (armeabi-v7a, arm64-v8a, x86, x86_64). The engine integrates seamlessly through JNI:

class BallisticsEngine {
    external fun calculateTrajectory(
        muzzleVelocity: Double,
        ballisticCoefficient: Double,
        mass: Double,
        diameter: Double,
        maxRange: Double
    ): TrajectoryResult

    companion object {
        init {
            System.loadLibrary("ballistics_engine")
        }
    }
}

Performance: The Numbers That Matter

The open-source engine achieves remarkable performance across all platforms:

Single Trajectory (1000m): ~5ms
Monte Carlo Simulation (1000 runs): ~500ms
BC Estimation: ~50ms
Zero Calculation: ~10ms

These numbers represent pure computation time on modern hardware. The engine uses RK4 (4th-order Runge-Kutta) integration by default for maximum accuracy, with an option to switch to Euler's method for even faster computation when precision requirements are relaxed.

Advanced Physics: More Than Just Parabolas

While the basic trajectory of a projectile follows a parabolic path in a vacuum, real-world ballistics is far more complex. The engine models:

Aerodynamic Effects

Velocity-dependent drag using standard drag functions (G1, G7) or custom curves
Transonic drag rise as projectiles approach the speed of sound
Reynolds number corrections for viscous effects at low velocities
Form factor adjustments based on projectile shape

Gyroscopic Phenomena

Spin drift from the Magnus effect on spinning projectiles
Precession and nutation of the projectile's axis
Spin decay over the flight path
Yaw of repose in crosswinds

Environmental Factors

Coriolis effect from Earth's rotation (critical for long-range shots)
Wind shear modeling with altitude-dependent wind variations
Atmospheric stratification using ICAO standard atmosphere
Humidity effects on air density

Stability Analysis

Dynamic stability calculations
Pitch damping coefficients through transonic regions
Gyroscopic stability factors
Transonic instability warnings

The Command Line Interface: Power at Your Fingertips

The engine includes a comprehensive CLI that rivals commercial ballistics software:

# Basic trajectory with auto-zeroing
./ballistics trajectory -v 2700 -b 0.475 -m 168 -d 0.308 \
  --auto-zero 200 --max-range 1000

# Monte Carlo simulation for load development
./ballistics monte-carlo -v 2700 -b 0.475 -m 168 -d 0.308 \
  -n 1000 --velocity-std 10 --bc-std 0.01 --target-distance 600

# Estimate BC from observed drops
./ballistics estimate-bc -v 2700 -m 168 -d 0.308 \
  --distance1 100 --drop1 0.0 --distance2 300 --drop2 0.075

The CLI supports both imperial (default) and metric units, multiple output formats (table, JSON, CSV), and can enable individual physics models as needed.

Lessons Learned: The Open Source Journey

Extracting and open-sourcing a core component from a larger system taught me valuable lessons:

Clear Boundaries Matter: Separating deterministic physics from ML augmentations made the extraction cleaner and the resulting library more focused.
Documentation is Code: I invested heavily in documentation, from inline Rust docs to comprehensive README examples. Good documentation dramatically increases adoption.
Performance Benchmarks Build Trust: Publishing concrete performance numbers helps users understand what they're getting and sets realistic expectations.
FFI Design is Critical: A well-designed FFI layer makes the difference between a library that's theoretically cross-platform and one that's actually used across platforms.
Community Feedback is Gold: Early users found edge cases I never considered and suggested features that made the engine more valuable.

The Website: ballistics.rs

To support the open-source project, I created ballistics.rs, a dedicated website that serves as the central hub for documentation, downloads, and community engagement. Built as a static site hosted on Google Cloud Platform with global CDN distribution, it provides fast access to resources from anywhere in the world.

The website showcases: - Comprehensive documentation and API references - Platform-specific integration guides - Performance benchmarks and comparisons - Example code and use cases - Links to the GitHub repository and issue tracker

Looking Forward: The Future of Open Ballistics

Open-sourcing the ballistics engine is just the beginning. I'm excited about several upcoming developments:

WebAssembly Support: Bringing high-performance ballistics calculations directly to web browsers.
GPU Acceleration: For massive Monte Carlo simulations and trajectory optimization.
Extended Drag Models: Supporting more specialized drag functions for specific projectile types.
Community Contributions: I'm already seeing pull requests for new features and improvements.
Educational Resources: Creating interactive visualizations and tutorials to help people understand ballistics physics.

The Business Model: Open Core Done Right

My approach follows the "open core" model. The fundamental physics engine is open source and will always remain so. The value-added features in Ballistics Insight (ML augmentations, weather integration, ammunition databases, and the web API) constitute our commercial offering.

This model benefits everyone: - Developers get a production-ready ballistics engine for their applications - Researchers have a reference implementation for ballistics algorithms - The community can contribute improvements that benefit all users - I maintain a sustainable business while giving back to the open-source ecosystem

Conclusion: Precision Through Open Collaboration

The journey from a closed-source SaaS platform to an open-source library with mobile bindings represents more than just a code release. It's a commitment to the principle that fundamental scientific calculations should be open, verifiable, and accessible to all.

By open-sourcing the ballistics engine, I'm not just sharing code; I'm inviting collaboration from developers, researchers, and enthusiasts worldwide. Whether you're building a mobile app for hunters, creating educational software for physics students, or conducting research on projectile dynamics, you now have access to a battle-tested, high-performance engine that handles the complex mathematics of ballistics.

The combination of Rust's performance and safety, comprehensive physics modeling, and carefully designed FFI bindings creates a unique resource in the ballistics software ecosystem. I'm excited to see what the community builds with it.

Visit ballistics.rs to get started, browse the documentation, or contribute to the project. The repository is available on GitHub, and I welcome issues, pull requests, and feedback.

In the world of ballistics, precision is everything. With this open-source release, I'm putting that precision in your hands.

Simulating Buckshot Spread – A Deep Dive with Python and ODEs

A.C. Jokela — Fri, 09 May 2025 00:12:22 GMT

Shotguns are celebrated for their unique ability to launch a cluster of small projectiles (referred to as pellets) simultaneously, making them highly effective at short ranges in hunting, sport shooting, and defensive scenarios. The way these pellets separate and spread apart during flight creates the signature pattern seen on shotgun targets. While the general term “shot” applies to all such projectiles, specific pellet sizes exist, each with distinct ballistic properties. In this article, we will focus on modeling #00 buckshot, a popular choice for both self-defense and law enforcement applications due to its larger pellet size and stopping power.

By using Python, we’ll construct a simulation that predicts the paths and spread of #00 buckshot pellets after they leave the barrel. Drawing from principles of physics (like gravity and aerodynamic drag) and incorporating randomness to reflect real-world variation, our code will numerically solve each pellet’s flight path. This approach lets us visualize the resulting shot pattern at a chosen distance downrange and gain a deeper appreciation for how ballistic forces and initial conditions shape what happens when the trigger is pulled.

Understanding the Physics of Shotgun Pellets

When a shotgun is fired, each pellet exits the barrel at a significant velocity, starting a brief yet complex flight through the air. The physical forces acting on the pellets dictate their individual paths and, ultimately, the characteristic spread pattern observed at the target. To create an accurate simulation of this process, it’s important to understand the primary factors influencing pellet motion.

The most fundamental force is gravity. This constant downward pull, at approximately 9.81 meters per second squared, causes pellets to fall toward the earth as they travel forward. The effect of gravity is immediate: even with a rapid muzzle velocity, pellets begin to drop soon after leaving the barrel, and this drop becomes more noticeable over longer distances.

Another critical factor, particularly relevant for small and light projectiles such as #00 buckshot, is aerodynamic drag. As a pellet speeds through the air, it constantly encounters resistance from air molecules in its path. Drag not only oppose the pellet’s motion but also increases rapidly with speed; it is proportional to the square of the velocity. The magnitude of this force depends on properties such as the pellet’s cross-sectional area, mass, and shape (summarized by the drag coefficient). In this model, we assume all pellets are nearly spherical and share the same mass and size, using standard values for drag.

The interplay between gravity and aerodynamic drag controls how far each pellet travels and how much it slows before reaching the target. These forces are at the core of external ballistics, shaping how the tight column of pellets at the muzzle becomes a broad pattern by the time it arrives downrange. Understanding and accurately representing these effects is essential for any simulation that aims to realistically capture shotgun pellet motion.

Setting Up the Simulation

Before simulating shotgun pellet flight, the foundation of the model must be established through a series of physical parameters. These values are crucial; they dictate everything from the amount of drag experienced by a pellet to the degree of possible spread observed on a target.

First, the code defines characteristics of a single #00 buckshot pellet. The pellet diameter (d) is set to 0.0084 meters, giving a radius (r) of half that value. The cross-sectional area (A) is calculated as π times the radius squared. This area directly impacts how much air resistance the pellet experiences; the larger the cross-section, the more drag slows it down. The mass (m) is set to 0.00351 kilograms, representing the weight of an individual #00 pellet in a standard shotgun load.

Next, the code specifies values needed for the calculation of aerodynamic drag. The drag coefficient (Cd) is set to 0.47, a typical value for a sphere moving through air. Air density (rho) is specified as 1.225 kilograms per cubic meter, which is a standard value at sea level under average conditions, and gravity (g) is established as 9.81 meters per second squared.

The number of pellets to simulate is set with num_pellets; here, nine pellets are used, reflecting a common #00 buckshot shell configuration. The v0 parameter sets the initial (muzzle) velocity for each pellet, at 370 meters per second, a realistic value for modern 12-gauge loads. To add realism, slight random variation in velocity is included using v_sigma, which allows muzzle velocity to be sampled from a normal distribution for each pellet. This captures the real-world variability inherent in a shotgun shot.

To model the spread of pellets as they leave the barrel, the code uses spread_std_deg and spread_max_deg. These parameters define the standard deviation and maximum value for the random angular deviation of each pellet in both horizontal and vertical directions. This gives each pellet a unique initial direction, simulating the inherent randomness and choke effect seen in actual shotgun blasts.

Initial position coordinates (x0, y0, z0) establish where the pellets start: here, at the muzzle, with the barrel one meter off the ground. The pattern_distance defines how far away the “target” is placed, setting the plane where pellet impacts are measured. Finally, max_time sets a hard cap on the simulated flight duration, ensuring computations finish even if a pellet never hits the ground or target.

By specifying all these parameters before running the simulation, the code grounds its calculations in real-world physical properties, establishing a robust and realistic baseline for the ODE-based modeling that follows.

The ODE Model

At the heart of the simulation is a mathematical model that describes each pellet’s motion using an ordinary differential equation (ODE). The state of a pellet in flight is captured by six variables: its position in three dimensions (x, y, z) and its velocity in each direction (vx, vy, vz). As the pellet travels, both gravity and aerodynamic drag act on it, continually altering its velocity and trajectory.

Gravity is straightforward in the model: a constant downward acceleration, reducing the y-component (height) of the pellet’s velocity over time. The trickier part is aerodynamic drag, which opposes the pellet’s motion and depends on both its speed and orientation. In this simulation, drag is modeled using the standard quadratic law, which states that the decelerating force is proportional to the square of the velocity. Mathematically, the drag acceleration in each direction is calculated as:

dv/dt = -k * v * v_dir

where k bundles together the effects of drag coefficient, air density, area, and mass, v is the current speed, and v_dir is a velocity component (vx, vy, or vz).

Within the pellet_ode function, the code computes the combined velocity from its three components and then applies this drag to each directional velocity. Gravity appears as a constant subtraction from the vertical (vy) acceleration. The ODE function returns the derivatives of all six state variables, which are then numerically integrated over time using Scipy’s solve_ivp routine.

By combining these physics-based rules, the ODE produces realistic pellet flight paths, showing how each is steadily slowed by drag and pulled downward by gravity on its journey from muzzle to target.

Modeling Pellet Spread: Incorporating Randomness

A defining feature of shotgun use is the spread of pellets as they exit the barrel and travel toward the target. While the physics of flight create predictable paths, the divergence of each pellet from the bore axis is largely random, influenced by manufacturing tolerances, barrel choke, and small perturbations at ignition. To replicate this in simulation, the code incorporates controlled randomness into the initial direction and velocity of each pellet.

For every simulated pellet, two angles are generated: one for vertical (up-down) deviation and one for horizontal (left-right) deviation. These angles are drawn from a normal (Gaussian) distribution centered at zero, reflecting the natural scatter expected from a well-maintained shotgun. Standard deviation and maximum values (set by spread_std_deg and spread_max_deg) control the tightness and outer limits of this spread. This ensures realistic variation while preventing extreme outliers not seen in practice.

Muzzle velocity is also subject to small random variation. While the manufacturer’s rating might place velocity at 370 meters per second, factors like ammunition inconsistencies and environmental conditions can introduce fluctuations. By sampling the initial velocity for each pellet from a normal distribution (with mean v0 and standard deviation v_sigma), the simulator reproduces this subtle randomness.

To determine starting velocities in three dimensions (vx, vy, vz), the code applies trigonometric calculations based on the sampled initial angles and speed, ensuring that each pellet’s departure vector deviates uniquely from the barrel’s axis. The result is a spread pattern that closely mirrors those seen in field tests: a dense central cluster with some pellets landing closer to the edge.

By weaving calculated randomness into the simulation’s initial conditions, the code not only matches the unpredictable nature of real-world shot patterns, but also creates meaningful output for analyzing shotgun effectiveness and pattern density at various distances.

ODE Integration with Boundary Events

Simulating the trajectory of each pellet requires numerically solving the equations of motion over time. This is accomplished by passing the ODE model to SciPy’s solve_ivp function, which integrates the system from the pellet’s moment of exit until it either hits the ground, the target plane, or a maximum time is reached. To handle these criteria efficiently, the code employs two “event” functions that monitor for specific conditions during integration.

The first event, ground_event, is triggered when a pellet’s vertical position (y) reaches zero, corresponding to ground impact. This event is marked as terminal in the integration, so once triggered, the ODE solver halts further calculation for that pellet, ensuring we don’t simulate motion beneath the earth.

The second event, pattern_event, fires when the pellet’s downrange distance (x) equals the designated pattern distance. This captures the precise moment a pellet crosses the plane of interest, such as a target board at 5 meters. Unlike ground_event, this event is not terminal, allowing the solver to keep tracking the pellet in case it flies beyond the target distance before landing.

By combining these event-driven stops with dense output (for smooth interpolation) and a small integration step size, the code accurately and efficiently identifies either the ground impact or the target crossing for each pellet. This strategy ensures that every significant outcome in the flight, whether a hit or a miss, is reliably captured in the simulation.

import numpy as np
from scipy.integrate import solve_ivp
import matplotlib.pyplot as plt

# Physical constants
d = 0.0084      # m
r = d / 2
A = np.pi * r**2 # m^2
m = 0.00351     # kg
Cd = 0.47
rho = 1.225     # kg/m^3
g = 9.81        # m/s^2

num_pellets = 9
v0 = 370        # muzzle velocity m/s
v_sigma = 10

spread_std_deg = 1.2
spread_max_deg = 2.5

x0, y0, z0 = 0., 1.0, 0.

pattern_distance = 5.0    # m
max_time = 1.0

def pellet_ode(t, y):
    vx, vy, vz = y[3:6]
    v = np.sqrt(vx**2 + vy**2 + vz**2)
    k = 0.5 * Cd * rho * A / m
    dxdt = vx
    dydt = vy
    dzdt = vz
    dvxdt = -k * v * vx
    dvydt = -k * v * vy - g
    dvzdt = -k * v * vz
    return [dxdt, dydt, dzdt, dvxdt, dvydt, dvzdt]

pattern_z = []
pattern_y = []

trajectories = []

for i in range(num_pellets):
    # Randomize initial direction for spread
    theta_h = np.random.normal(0, np.radians(spread_std_deg))
    theta_h = np.clip(theta_h, -np.radians(spread_max_deg), np.radians(spread_max_deg))
    theta_v = np.random.normal(0, np.radians(spread_std_deg))
    theta_v = np.clip(theta_v, -np.radians(spread_max_deg), np.radians(spread_max_deg))

    v0p = np.random.normal(v0, v_sigma)

    # Forward is X axis. Up is Y axis. Left-right is Z axis
    vx0 = v0p * np.cos(theta_v) * np.cos(theta_h)
    vy0 = v0p * np.sin(theta_v)
    vz0 = v0p * np.cos(theta_v) * np.sin(theta_h)

    ic = [x0, y0, z0, vx0, vy0, vz0]

    def ground_event(t, y):  # y[1] is height
        return y[1]
    ground_event.terminal = True
    ground_event.direction = -1

    def pattern_event(t, y):   # y[0] is x
        return y[0] - pattern_distance
    pattern_event.terminal = False
    pattern_event.direction = 1

    sol = solve_ivp(
        pellet_ode,
        [0, max_time],
        ic,
        events=[ground_event, pattern_event],
        dense_output=True,
        max_step=0.01
    )

    # Find the stopping time: whichever is first, ground or simulation end
    if sol.t_events[0].size > 0:
        t_end = sol.t_events[0][0]
    else:
        t_end = sol.t[-1]
    t_plot = np.linspace(0, t_end, 200)
    trajectories.append(sol.sol(t_plot))

    # Interpolate to pattern_distance for hit pattern
    x = sol.y[0]
    if np.any(x >= pattern_distance):
        idx = np.argmax(x >= pattern_distance)
        if idx > 0:  # avoid index out of bounds if already starting beyond pattern_distance
            frac = (pattern_distance - x[idx-1]) / (x[idx] - x[idx-1])
            zhit = sol.y[2][idx-1] + frac * (sol.y[2][idx] - sol.y[2][idx-1])
            yhit = sol.y[1][idx-1] + frac * (sol.y[1][idx] - sol.y[1][idx-1])
            if yhit > 0:
                pattern_z.append(zhit)
                pattern_y.append(yhit)

# --- Plot 3D trajectories ---
fig = plt.figure(figsize=(12,7))
ax = fig.add_subplot(111, projection='3d')
for traj in trajectories:
    x, y, z, vx, vy, vz = traj
    ax.plot(x, z, y)
ax.set_xlabel('Downrange X (m)')
ax.set_ylabel('Left-Right Z (m)')
ax.set_zlabel('Height Y (m)')
ax.set_title('3D Buckshot Pellet Trajectories (ODE solver)')
plt.show()

# --- Plot pattern on 25m target plane ---
plt.figure(figsize=(8,6))

circle = plt.Circle((0,1), 0.2032/2, color='b', fill=False, linestyle='--', label='8 inch target')
plt.gca().add_patch(circle)
plt.scatter(pattern_z, pattern_y, c='r', s=100, marker='o', label='Pellet hits')
plt.xlabel('Left-Right Offset (m)')
plt.ylabel(f'Height (m), target at {pattern_distance} m')
plt.title(f'Buckshot Pattern at {pattern_distance} m')
plt.axhline(1, color='k', ls=':', label='Muzzle height')
plt.axvline(0, color='k', ls=':')
plt.ylim(0, 2)
plt.xlim(-0.5, 0.5)
plt.legend()
plt.grid(True)
plt.gca().set_aspect('equal', adjustable='box')
plt.show()

Recording and Visualizing Pellet Impacts

Once a pellet’s trajectory has been simulated, it is important to determine exactly where it would strike the target plane placed at the specified downrange distance. Because the pellet’s position is updated in discrete time steps, it rarely lands exactly at the pattern_distance. Therefore, the code detects when the pellet’s simulated x-position first passes this distance. At this point, a linear interpolation is performed between the two positions bracketing the target plane, calculating the precise y (height) and z (left-right) coordinates where the pellet would intersect the pattern distance. This ensures consistent and accurate hit placement regardless of integration step size.

The resulting values for each pellet are appended to the pattern_y and pattern_z lists. These lists collectively represent the full group of pellet impact points at the target plane and can be conveniently visualized or analyzed further.

By recording these interpolated impact points, the simulation offers direct insight into the spatial distribution of pellets on the target. This data allows shooters and engineers to assess key real-world characteristics such as pattern density, evenness, and the likelihood of hitting a given area. In visualization, these points paint a clear picture of spread and clustering, helping to understand both shotgun effectiveness and pellet behavior under the influence of drag and gravity.

Visualization: Plotting Trajectories and Impact Patterns

Visualizing the results of the simulation offers both an intuitive understanding of pellet motion and practical insight into shotgun performance. The code provides two types of plots: a three-dimensional trajectory plot and a two-dimensional pattern plot on the target plane.

The 3D trajectory plot displays the full flight paths of all simulated pellets, with axes labeled for downrange distance (x), left-right offset (z), and vertical height (y). Each pellet's arc is traced from muzzle exit to endpoint, revealing not just forward travel and fall due to gravity, but also the sideways spread caused by angular deviation and drag. This plot gives a comprehensive, real-time sense of how pellets diverge and lose height, much like visualizing the flight of shot in slow motion. It can highlight trends such as gradual drop-offs, the effect of random spread angles, and which pellets remain above the ground longest.

The pattern plane plot focuses on practical outcomes: the locations where pellets would strike a target at a given distance (e.g., 5 meters downrange). An 8-inch circle is superimposed to represent a common target size, providing context for real-world shooting scenarios. Each simulated impact point is marked, showing the actual distribution and clustering of pellets. Reference lines denote the muzzle height (horizontal) and the barrel center (vertical), helping to orient the viewer and relate simulated results to how a shooter would aim.

Together, these visuals bridge the gap between abstract trajectory calculations and real shooting experience. The 3D plot helps explore external ballistics, while the pattern plot reflects what a shooter would see on a paper target at the range, key information for understanding spread, pattern density, and shotgun effectiveness.

Assumptions & Limitations of the Model

While this simulation offers a physically grounded view of #00 buckshot spread, several simplifying assumptions shape its results. The code treats all pellets as perfectly spherical, identical in size and mass, and does not account for pellet deformation or fracturing, both of which can occur during firing or impact. Air properties are held constant, with fixed density and drag coefficient values; in reality, both can change due to weather, altitude, and even fluctuations in pellet speed.

The external environment in the model is idealized: there is no simulated wind, nor do pellets interact with one another mid-flight. Real pellets may collide or influence each other's paths, especially immediately after leaving the barrel. The simulation also omits nuanced effects of shotgun choke or barrel design, instead representing spread as a simple random angle without structure, patterning, or environmental response. The shooter’s aim is assumed perfectly flat, originating from a set muzzle height, with no allowance for human error or tilt.

These simplifications mean that actual shotgun patterns may differ in meaningful ways. Real-world patterns can display uneven density, elliptical shapes from chokes, or wind-induced drift, all absent from this model. Furthermore, pellet deformation can lead to less predictable spread, and varying air conditions or shooter input can add additional variability. Nevertheless, the simulation provides a valuable baseline for understanding the primary forces and expected outcomes, even if it cannot capture every subtlety from live fire.

Possible Improvements and Extensions

This simulation, while useful for visualizing basic pellet dynamics, could be made more realistic by addressing some of its idealizations. Incorporating wind modeling would add lateral drift, making the simulation more applicable to outdoor shooting scenarios. Simulating non-spherical or deformed pellets (accounting for variations in shape, mass, or surface) could change each pellet’s drag and produce more irregular spread patterns. Introducing explicit choke effects would allow for non-uniform or elliptical spreads that better match the output from different shotgun barrels and constrictions.

Environmental factors like altitude and temperature could be included to adjust air density and drag coefficient dynamically, reflecting their real influence on ballistics. Finally, modeling shooter-related factors such as sight alignment, aim variation, or recoil-induced muzzle movement would add further variability. Collectively, these enhancements would move the simulation closer to the unpredictable reality of shotgun use, providing even greater value for shooters, ballistics researchers, and enthusiasts alike.

Conclusion

Physically-accurate simulations of shotgun pellet spread offer valuable lessons for both programmers and shooting enthusiasts. By translating real-world ballistics into code, we gain a deeper understanding of the factors that shape shot patterns and how subtle changes in variables can influence outcomes. Python, paired with SciPy’s ODE solvers, proves to be an accessible and powerful toolkit for exploring these complex systems. Whether used for educational insight, hobby experimentation, or designing safer and more effective ammunition, this approach opens the door to further exploration. Readers are encouraged to adapt, extend, or refine the code to match their own interests and scenarios.

References & Further Reading

McCoy, R.L., Modern Exterior Ballistics
L.P. Brezny, Gun Digest Book of Shotgunning
Python/Scipy ODE Integrators: scipy.integrate.solve_ivp
Chuck Hawks’ Shotgun Ballistics Resource
Ballistics Science (Wikipedia)

Modeling Ballistic Trajectories with Calculus and Numerical Methods

A.C. Jokela — Fri, 13 Sep 2024 00:28:41 GMT

Introduction

Ballistics is the study of the motion of projectiles under the influence of gravity and air resistance - a complex phenomenon with far-reaching implications in various industries, including military, aerospace, and sports. The importance of understanding ballistics cannot be overstated: in these fields, accuracy, safety, and performance are often directly tied to the ability to predict and control the trajectory of an object in flight.

At its core, ballistics is concerned with four key concepts: ballistic coefficient, muzzle velocity, bullet trajectory, and distance to target. The ballistic coefficient, a measure of a projectile's aerodynamic efficiency, plays a crucial role in determining how much air resistance it will encounter - and thus, how far it will travel. Muzzle velocity, the speed at which a projectile exits a gun or launcher, is another critical factor in this equation.

By understanding these concepts and applying mathematical techniques to model ballistic trajectories, we can gain a deeper insight into the intricacies of projectile motion. In this article, we'll explore the use of calculus and numerical methods to achieve just that - providing a more accurate and reliable way to predict and control the trajectory of objects in flight.

As a teenager in the early 1990s, I was deeply interested in ballistics. These were the pre-internet days and books were the primary means of acquiring information. Projectiles, when pushed out the barrel, travel in an arc and not in a completely flat trajectory. One of the things I was keenly interested in was the maximum height above the muzzle that the arc reaches. Another metric that I wanted was how much the bullet drops from the muzzle at a particular distance. There were a couple problems with me reaching those objectives: my math skills were rudimentary and my knowledge was limited to the books on handloading ammunition that I had as well as what could be found at the local library.

I poured over the handloading manuals trying to come up with equations that I could understand. My programming framework of choice was Visual Basic. I really wanted to make an application that I could just plug in variable values and the software would calculate the numbers I was interested. Fast forward over thirty years, I have an infinite amount of information at my finger tips, I have access to generative AI, and I have years of mathematics and problem solving skills.

The Field of Ballistics

Ballistics is a multidisciplinary field of study that encompasses the science and engineering of projectiles in motion. At its core, ballistics is concerned with understanding the complex interactions between a projectile, its environment, and the forces that act upon it.

The field of ballistics can be broadly divided into three subfields: interior, exterior, and terminal ballistics. Interior ballistics deals with the behavior of propellants and projectiles within a gun or launcher, while exterior ballistics focuses on the motion of the projectile in free flight. Terminal ballistics, on the other hand, examines the impact and penetration characteristics of a projectile upon striking its target.

Understanding ballistics is crucial in various fields, including military, hunting, and aerospace. In these industries, accuracy, safety, and performance are often directly tied to the ability to predict and control the trajectory of an object in flight. For instance, in military applications, understanding ballistic trajectories can mean the difference between hitting a target and missing it by miles. Similarly, in hunting, a deep understanding of ballistics can help hunters make clean kills and avoid wounding animals.

So what factors affect ballistic trajectories? Air resistance, gravity, and spin are just a few of the key players that influence the motion of a projectile. Air resistance, for example, can slow down a projectile depending on its shape, size, and velocity. Gravity, of course, pulls the projectile downwards, while spin can impart a stabilizing force that helps maintain a consistent flight path. By understanding these factors and their complex interactions, ballisticians can develop more accurate models of projectile motion and improve performance in various applications.

Ballistic Coefficient: Measurement and Significance

In the world of ballistics, precision is paramount. Whether it's a military operation, a hunting expedition, or a competitive shooting event, the trajectory of a projectile can make all the difference between success and failure. At the heart of this quest for accuracy lies the ballistic coefficient (BC), a fundamental concept that describes the aerodynamic efficiency of a projectile.

In simple terms, the BC is a measure of how well a bullet can cut through the air with minimal resistance. It's a dimensionless quantity that characterizes the relationship between a projectile's mass, size, shape, and velocity, and the drag force acting on it. But what exactly determines the ballistic coefficient of a projectile?

Several factors come into play, including the bullet's shape, size, and weight, as well as its velocity and angle of attack. The BC can be measured using various techniques, such as wind tunnel testing or Doppler radar. Wind tunnel testing involves firing a projectile through a controlled environment with known air density and pressure conditions. By analyzing the data collected from these tests, ballisticians can calculate the ballistic coefficient with high accuracy.

But why is the ballistic coefficient so important in predicting bullet trajectory and accuracy? The answer lies in its relationship to drag force. A higher BC indicates less drag resistance, which means a projectile will travel farther and straighter before being slowed down by air resistance. Conversely, a lower BC signifies more drag resistance, resulting in a shorter range and greater deviation from the intended target.

The implications of this are far-reaching. In military applications, understanding the ballistic coefficient can mean the difference between hitting or missing a target, with potentially catastrophic consequences. In hunting, it can determine whether a shot is effective or not, affecting both the welfare of the animal and the success of the hunt. And in sport shooting, it's essential for achieving optimal performance and accuracy.

As such, accurately measuring the ballistic coefficient is crucial for achieving precision in various applications. By doing so, ballisticians can create more accurate models of bullet trajectory, taking into account factors such as air density, temperature, and humidity. This, in turn, enables them to optimize projectile design, selecting the right shape, size, and material to achieve the desired level of aerodynamic efficiency.

The ballistic coefficient is a fundamental concept that underlies the art of ballistics. By understanding its relationship to drag force and accurately measuring it, ballisticians can unlock the secrets of aerodynamic efficiency, creating more accurate models of bullet trajectory and achieving optimal performance in various applications. Whether it's military, hunting, or sport shooting, precision is paramount – and the ballistic coefficient is key to achieving it.

Calculus in Ballistics: Modeling Trajectories

In ballistics, understanding the motion of projectiles is crucial for predicting their trajectory and accuracy. Differential equations play a vital role in modeling various aspects of ballistics, as they provide a mathematical framework for describing complex phenomena. A differential equation is an equation that describes how a quantity changes over time or space.

One of the most fundamental applications of calculus in ballistics is modeling bullet trajectory under the influence of gravity and air resistance. The point mass model is a classic example of this approach. It assumes that the projectile can be treated as a single point with no dimensions, and its motion is governed by the following differential equation:

\frac{d^{2} x}{{dt}^{2}} = (a - b v^{\frac{2}{3}}) x = a t - b v^{3} - c t^{2}

where x is the position of the projectile, v is its velocity, a and b are constants representing air resistance, c represents gravity, and t is time.

In addition to modeling bullet trajectory, calculus can also be used to describe more complex phenomena such as spin-stabilized projectiles and ricochet dynamics. The 6-DOF (six degrees of freedom) model, for example, takes into account the rotation and translation of a projectile in three-dimensional space.

These are just a few examples of how calculus is used in ballistics to model various aspects of projectile motion. By applying mathematical techniques such as differential equations, researchers can gain valuable insights into the complex behavior of projectiles under different conditions.

Numerical Methods for Ballistic Trajectory Modeling

When it comes to modeling ballistic trajectories, numerical methods are an essential tool for solving complex differential equations that govern the motion of projectiles. In this context, numerical methods refer to techniques used to approximate solutions to these equations, which cannot be solved analytically.

One of the most fundamental numerical methods in ballistics is Euler's method. This technique involves discretizing the solution space and approximating the trajectory using a series of small steps, each representing a short time interval. Mathematically, this can be represented as:

x_{1} = x_{0} + h^{1} f_{(x_{0}, t_{0})}

where x is the position of the projectile, h is the time step, f(x,t) represents the acceleration at time t and position x.

While Euler's method provides a basic framework for approximating solutions to differential equations, more sophisticated techniques such as the Runge-Kutta methods offer greater accuracy and stability. The Runge-Kutta methods involves using multiple intermediate steps to improve the approximation of the solution, rather than relying on a single step as in Euler's method.

Numerical methods have numerous advantages in ballistics, including their ability to handle complex systems and provide accurate solutions for non-linear equations. However, these methods also have limitations, such as the potential for numerical instability and the computational resources required to achieve high accuracy.

Numerical methods are a powerful tool for modeling ballistic trajectories, offering a means of approximating solutions to complex differential equations that govern projectile motion. I have also covered numerical methods in other write-ups, namely, the pricing of stock options. While there are various techniques available, each with its own strengths and weaknesses, these methods provide an essential framework for analyzing and understanding ballistic phenomena.

import numpy as np
from scipy.integrate import odeint
import matplotlib.pyplot as plt

# Constants
g = 9.81  # m/s^2, acceleration due to gravity
v0 = 780  # m/s, muzzle velocity of .308 Winchester
theta = 25 * np.pi / 180  # rad, angle of projection (25 degrees)
m = 10.4e-3  # kg, mass of the projectile (10.4 grams)
Cd = 0.5  # drag coefficient
Bc = 0.47  # ballistic coefficient (G7 model)
rho = 1.225  # kg/m^3, air density at sea level

# Differential equations for projectile motion with air resistance
def deriv(X, t):
    x, y, vx, vy = X
    v = np.sqrt(vx**2 + vy**2)
    Fd = 0.5 * Cd * rho * Bc * v**2
    ax = -Fd * vx / (m * v)
    ay = -g - Fd * vy / (m * v)
    return [vx, vy, ax, ay]

# Initial conditions
X0 = [0, 0, v0 * np.cos(theta), v0 * np.sin(theta)]

# Time points
t_flight = 10  # seconds
t = np.linspace(0, t_flight, 10000)

# Solve ODE
sol = odeint(deriv, X0, t)
x = np.cumsum(sol[:, 2] * (t[1]-t[0])) 
max_x = max(x) 
min_x = min(x)
scaled_x = (x - min_x) / (max_x - min_x) * 1000
y = sol[:, 1]

# Find the maximum height
max_height = max(y)

print(f"The maximum height of the arc is {max_height:.2f} m")

# Plot results
plt.plot(scaled_x, y)
plt.xlabel('Horizontal distance (m)')
plt.ylabel('Height (m)')
plt.title('.308 Winchester Trajectory')
plt.grid()
plt.show()

This code uses the odeint function from SciPy to solve the system of differential equations that model the projectile motion with air resistance. The deriv function defines the derivatives of the position and velocity with respect to time, including the effects of drag and gravity. The initial conditions are set for a .308 Winchester rifle fired at an angle of 25 degrees. The ballistic coefficient is used to calculate the drag force.

The code also outputs the maximum arch height and projectile height from muzzle.

Note that this simulation assumes a constant air density and neglects other factors such as wind resistance, spin stabilization, and variations in muzzle velocity.

Conclusion

In this analysis, we explored the application of calculus and numerical methods to model the trajectory of a .308 Winchester bullet. By solving the system of differential equations that govern the motion of the projectile, we were able to accurately predict the bullet's path under various environmental conditions. Our results demonstrated the importance of considering air resistance in ballistic trajectories, as well as the need for precise calculations to ensure accuracy.

Understanding ballistics is crucial for a range of applications, from military and hunting to aerospace engineering. Calculus and numerical methods play a vital role in modeling these complex systems, allowing us to make predictions and optimize performance. As demonstrated in this analysis, a deep understanding of mathematical concepts can have real-world implications, highlighting the importance of continued investment in STEM education and research.