Inelastic collision calculator

You supply the two masses and their initial velocities along a chosen one-dimensional axis; the engine applies conservation of momentum and returns v_f equals open parenthesis m1 times v1 plus m2 times v2 close parenthesis divided by open parenthesis m1 plus m2 close parenthesis.

What a perfectly inelastic collision means and what the response contains

Rearranging that identity gives the closed form v_f equals open parenthesis m1 v1 plus m2 v2 close parenthesis over open parenthesis m1 plus m2 close parenthesis. The response returns the normalized inputs m1, v1, m2, and v2, the total_mass m1 plus m2, the total_momentum m1 v1 plus m2 v2, the final_velocity v_f, the precision used, a method tag perfectly_inelastic_collision, a short formula reminder, and a unit hint m/s when masses are in kilograms and velocities in meters per second. There is no multi-body contact simulation and no coefficient of restitution path: the engine either evaluates the momentum quotient inside the supported numeric range or rejects the input with invalid_input. Rejected cases include missing masses or velocities, non-finite values, magnitudes above the documented ceilings, negative mass, and any case where total mass is zero or numerically zero, because division by zero leaves no defined common final velocity.

How masses and velocities are read and how v_f stays reproducible

Zero mass for one body is allowed when the other mass is positive, which simply reduces to the remaining body keeping its velocity. Both masses zero is rejected because total mass must not be zero. Velocities may be positive, negative, or zero to encode direction on a one-dimensional axis; the tool does not convert unit systems for you, so keep masses consistent with each other and velocities in a matching length-per-time unit. Optional leading plus signs and scientific notation on numeric strings are allowed when they parse as finite decimals; embedded spaces and non-numeric tokens are rejected. The preferred fields are m1 and m2 for the two masses and v1 and v2 for the two initial velocities, but aliases mass1, M1, and mass_1 for m1, mass2, M2, and mass_2 for m2, and velocity1, u1, vel1, V1 for v1 plus velocity2, u2, vel2, V2 for v2 are accepted so spreadsheets, query strings, and typed forms can reuse the same contract. Masses must be finite and non-negative: a negative mass fails with invalid_input and a message that names the field, so a bad cell does not become a silent nonsense result. An optional precision field, with aliases decimals and dp, chooses how many decimal places to expose for the numeric outputs, defaulting to ten and capped at fifteen so JSON goldens stay stable. Pair the free browser run on this page with the priced API when you need the identical mathematical result inside an automated pipeline without re-implementing the inelastic-collision formula yourself.

Where perfectly inelastic collisions fit in study, design, and software

Product and education tools use the endpoint when a learner types two masses and two speeds and the UI must show the combined velocity after a perfectly inelastic crash. On this page the work runs entirely in your browser; through the API each successful lookup costs $0.002, failed validation is not charged, and nothing is stored after the response returns. That split — free interactive exploration and a priced, identical API — matches the rest of the KIT tier-A catalog and lets you move from a classroom demo to an automated pipeline without changing the mathematical result. Pair it with weight-force, friction-force, or average-acceleration helpers when you need related mechanics, and with other math endpoints when you are building a small lab of free, deterministic physics calculators.