Solvers›Concepts

Cases & Environments

Ferro's project model is deliberately close to Ansys Mechanical's, so if you've used Mechanical before, the mapping is direct.

Case

A Case (FerroCase) is the equivalent of an Ansys Mechanical project. It owns everything that's shared across analyses of the same part or assembly:

  • The mesh
  • A materials catalog
  • Named selections (surfaces, edges, node sets you've grouped for reuse in loads and boundary conditions)
  • One or more Environments

Because the mesh and materials live on the Case, switching between a static run and a modal run doesn't mean re-meshing or re-defining materials — you're just adding another Environment to the same Case.

Environment

An Environment is the equivalent of a "Static Structural" or "Modal" branch inside an Ansys Mechanical project. Each Environment owns:

  • Its own analysis type and settings (see Analysis Types)
  • Its own loads and supports (boundary conditions)
  • A reference back to the Case's shared mesh, materials, and named selections

When you solve an Environment, Ferro resolves it — via FerroCase::request_for — into a fully-specified FerroRequest: the self-contained input that actually gets handed to the solver. The Case/Environment split exists so authoring stays DRY; the FerroRequest is what all three surfaces (Prism, ferro-cli, ferro-py) ultimately produce and consume, whether or not they went through a Case at all.

On Disk

A Case and its Environments are what get packaged into a .ferro/ directory bundle when you save from Prism — see File Formats for exactly what's in that bundle. The Case document itself (case.toml or case.json, chosen by extension) is a plain serializable file, so it's diffable and can be hand-edited or generated by a script.