FAQ

FAQ

What is this, in one sentence?

A Python library and MCP server that reduce strain-controlled fatigue test data, fit the standard strain-life models, and predict life. It is built so an AI agent can run the whole analysis by calling tools.

Do I need an AI agent to use it?

No. The library works like any Python package, and the no-code GUI covers the same core workflow for people who do not program. The MCP server is the primary interface and the reason the project exists, but it is not the only one.

Does my data leave my machine?

No. The MCP server runs locally over stdio, the GUI is a local app in your browser, and the result store is a local directory. The toolkit uploads nothing anywhere. If you drive the tools through a cloud-hosted AI assistant, the numbers you paste into that conversation go to that assistant like any other message. Treat conversation content by your own data rules.

Which AI clients work?

Anything that speaks MCP over stdio. Claude Desktop, Claude Code, Cursor, VS Code in Copilot agent mode, and Google Antigravity are covered in MCP Client Setup.

Which materials does it support?

It is material agnostic. The models are the standard strain-life formulation, Basquin, Coffin-Manson, and Ramberg-Osgood with mean-stress corrections, which apply wherever those models apply. Nothing is tuned to one alloy family.

How much is validated?

The core paths are validated against published values: the SAE 1137 strain-life fit, the ASTM E1049 rainflow example, and the SAE variable-amplitude programs. Some paths are verified against their defining equations but not against independent lab data. Validation lists both sides explicitly, including where predictions run non-conservative.

Can I trust the fitted constants?

The fit is standard least squares on the log-linearized branches, and it reports r squared and standard errors where they apply. It surfaces problems instead of hiding them. The fit reports a Masing departure, and a plastic branch left with fewer than two usable points raises a clear error rather than fitting garbage. Judging whether a fit is good enough for a design decision remains your call, and the statistics layer exists to support that with censored fits and design bounds.

What are the units and conventions?

Stress and modulus in MPa, strain as a dimensionless fraction, life in reversals, and the exponents b and c are negative. All analysis uses true stress and true strain, engineering input is converted at ingestion.

How is this different from pyLife, py-fatigue, fatpack, or reliability?

Those are good libraries and the toolkit is input compatible with the pandas data shapes of pyLife and py-fatigue. The differences: this project reduces raw strain-controlled test data end to end, tracks per-cycle evolution, and exposes everything as MCP tools an agent can drive. None of the others focus on those three things.

How do I cite it?

Use the "Cite this repository" button on the repository page. Or cite the Zenodo concept DOI 10.5281/zenodo.21222820, which always resolves to the latest archived release.

Can I contribute data?

Yes, strain-controlled data with provenance and a redistribution basis, especially with per-cycle evolution. The rules are in docs/CONTRIBUTING-DATA.md, and lcf-validate checks any document against the interchange schemas from the command line.

Is the Windows exe safe? Windows warns about it.

The exe attached to releases is unsigned, so SmartScreen shows a warning on first run. That is a signing-certificate matter, not a verdict on the contents. The build recipe is scripts/build_gui_app.py in the repository, and CI builds the release artifact from the tagged source. Choose "More info", then "Run anyway", or use pip install "lcf-strain-life[gui]" instead.