Workflow
Every Ferro solve follows the same physics regardless of which surface you drive
it from: assemble the global stiffness matrix, apply boundary conditions, solve
K·u = f, then recover stress and strain from the displacement field. What
differs is how you get there.
Via Qubis
Opening a .ferro/ directory bundle in Qubis loads it into a dedicated view with:
- A 3D viewport for the mesh and results
- A JSON editor for the underlying analysis configuration
- Results overlays (stress, displacement, etc.) once a solve completes
This is the fastest path for interactive work — building up a Case, adding Environments, and iterating on loads/supports visually.
Via ferro-cli
Build the CLI from the physics/ workspace:
cd physics
cargo build -p ferro-cli --releaseIts subcommands:
| Subcommand | Purpose |
|---|---|
run | Solve a request JSON on a mesh and write the result to a .fres file |
validate | Check a request JSON is well-formed, optionally against a mesh to validate named sets |
mesh-summary | Print a summary of a mesh file |
schema | Print the JSON schema for a FerroRequest |
This is the path for scripting solves in CI or batch-processing a sweep of configurations without opening Qubis.
Both surfaces converge on the same ferro-config::FerroRequest
type. A request written by hand for the CLI and one exported from a Qubis Case
will solve identically — there's no behavioral difference between the
interactive and scripted paths.
Next
See File Formats for what each of these commands actually reads and writes.