Build, verify and debug
constitutive models.

From constitutive equation
to verified implementation.

A constitutive model lives in fragments: equations in a paper, a derivation, a parameter table, Fortran, an input deck, a single-element test, and a solver log. Engineers move between them by hand. ddsdde is built to own that path from end to end.

Separately these look like utilities. Together they close a loop: a paper becomes a structured model, the model becomes code, the code is tested, failures are diagnosed, and the evidence is packaged into a report. Stages 04 and 06 are marked because that is where the product is defensible. Generated code is cheap. Evidence that it is right is not.

Every new feature must make implementation faster, verification stronger, or debugging more reliable. If it does none of those, it does not belong in the first product. The rule this roadmap is held to

The manual answers this
in twenty minutes.

ddsdde answers it in zero. Put the cursor on an argument and the panel on the right fills in.

Hold Shift and click any argument to open its full reference — type, ordering, sign convention and the mistakes people make with it.

Three panels. Nothing else.

A file tree, an editor, and the inspector. The top bar carries one control. Everything else lives on a keyboard shortcut, the way you already work.

These figures are drawn from the interface source rather than photographed, so they stay sharp on any display and follow your system light or dark setting.

Give the model
a place to live.

Open Workspace in the editor toolbar to organize the material model: its equations, parameter ordering, state variables, generated code, checks and report. Follow a number back to its source and keep the assumptions beside the implementation.

Workspace follows the structured model. To test an existing UMAT already open in the editor, use Verify. Model generation and Workspace checks depend on the supported model family.

Your UMAT.
Put it to the test.

Click Verify in the editor toolbar to check the active UMAT, including unsaved edits. Design tests around the physics in that file, watch the prescribed deformation, and inspect the computed stress and state history. No Fortran compiler installation required for supported source.

1. Inspect the source

   A local compatibility check identifies unsupported Fortran syntax before execution. The snapshot includes the code currently in your editor.

2. Design relevant checks

   Explicitly send the source and your context to Anthropic using your key. AI proposes loading paths, source evidence and expected behavior. Review extracted inputs and supply any missing material values.

3. Run and see the response

   The built-in interpreter executes supported source locally. Play through the recorded increments, inspect the block’s displacement constraints, and compare stress–strain curves or state values with references.

4. Keep the evidence

   Read pass, fail or inconclusive results with their measurements and tolerances. Export the source fingerprint, reviewed plan, recorded histories and results.

What the visual test represents: a homogeneous unit block with prescribed affine displacement, labelled boundary conditions and adjustable display magnification. Current support is a bounded Fortran subset for self-contained 3D small-strain UMATs. Resolved fiber–matrix geometry, contact and friction require additional solver support. A passing test covers its selected cases; it is not component certification.

Read the paper.
Check every claim.

Point ddsdde at a paper and it proposes a model: equations, parameters, state variables and assumptions. Nothing it proposes enters your model. Every claim carries a quote, and every quote is checked against the paper before you see it.

An accepted field records that the paper said it, with the page. A field you corrected records that you said it. Six months later that is the difference between what a paper states and what somebody typed.

What this does not do: judge whether the model read the right table, attributed the right symbol, or understood the physics. It reduces the reading you must do from the whole extraction to the parts that failed a mechanical check. A paper gives equations, not an algorithm — the order they are evaluated in stays your decision, and ddsdde says so rather than inventing one.

Write the equations.
Check the answer.

ddsdde keeps the model as structure, not as text. From that structure it writes the subroutine. Then it grades what it wrote. The material Jacobian is checked against a numerical reference. The physics is checked against results that do not depend on the code being tested.

The two halves are separate on purpose. A Jacobian can be a perfect derivative of a stress update that is wrong. A stress update can be correct while the Jacobian costs the solver ten iterations an increment. The last four rows above pass every Jacobian check.

What these checks prove: the algorithm is correct, and the Jacobian matches the stress update. What they do not prove: that your compiler built what you read. ddsdde writes a single-element input deck with the expected results, so that last step takes one run.

The reference behind
every claim on this page.

Each of these answers one question completely — the conventions, the failure modes, and the numbers. They are worth reading whether or not you ever run ddsdde.

Every argument. Every type.

All 346 arguments carry a description, a unit and an access direction. UMAT has the most depth, because UMAT is the primary target of this release.

COMPLETE means every argument carries a description, a unit and an access direction. It does not mean the data is free of errors. Report an incorrect entry and it gets corrected.

From first UMAT
to research grade.

Nineteen model topics, ordered so each one prepares you for the next. The linked worked guides explain the physics, implementation details, a verification procedure, and the mistakes that cost people weeks.

Browse the worked example guides →
Each example cites the papers and repositories to read. ddsdde summarises them; it does not redistribute their code.

Fortran, done right.

Built on Monaco — the editor inside Visual Studio Code. If you come from VS Code, your key bindings already work.

• Fixed form and free form The editor reads the extension. .f and .for files get rulers at column 6 and column 72, where Fortran 77 actually breaks.
• Split panes Split right or down, drag the divider, and the inspector follows the pane you are typing in — not the one you started in.
• 14 templates Start from a working subroutine. Six are UMAT: elastic, J2 plasticity, Drucker-Prager, neo-Hookean, GTN damage, viscoelastic.
• 21 themes Dark and light, switched from the command palette. The reference window follows whichever you pick.
• Optional AI completion Add an Anthropic API key for inline completions. Everything else works without one, and works offline.
• Almost no chrome One button in the top bar. Press Ctrl+Shift+P for every command, or Ctrl+P to jump between files.

Material behavior.
Engineering consequences.

Before a new part flies, generates power, or leaves a factory, engineers need to understand how its material responds. DDSDDE helps turn those material rules into code they can inspect and check.

1. 01 / Understand

   Measure how the material stretches, yields, or changes.

2. 02 / Implement

   Write those rules as material code. This is part of DDSDDE’s focus.

3. 03 / Check

   Compare the implementation against reference behavior.

4. 04 / Apply

   Use validated models in component simulations and physical test programs.

The opportunity is more understandable, reproducible material implementations. Code verification does not replace experimental validation, full-system analysis, or certification. Industry background: NASA computational materials · DOE materials aging. These sources describe the field, not endorsements of DDSDDE.