How Eqiora fits together
Eqiora keeps the mathematical problem separate from the choices needed to solve it. The Get started example shows every step with one decay model.
Model — what must be true?
Section titled “Model — what must be true?”Declare quantities, parameters, initial values and equations. Compilation checks their meaning and produces a Model. A time method, mesh or solver is not an equation. Read Models are not simulations for the distinction, or author a model in Python.
Realization — how will it be solved?
Section titled “Realization — how will it be solved?”Choose the numerical policies admitted for that Model. In the decay example,
eqiora.resolve selects a time method and returns a Plan. Spatial problems also
need the appropriate geometry, mesh and discretization; the
steady-flow investigation shows those
choices on one concrete problem.
Run — perform the work
Section titled “Run — perform the work”Supply the initial state, observation times and other execution inputs required
by the Plan, then call eqiora.run. The
execution guide explains the current source
API’s submitted-run lifecycle and structured diagnostics.
Result — what happened?
Section titled “Result — what happened?”Select an output using the model-bound field handle. For scalar decay, the returned series contains observation times and values. Compare them with a prediction before interpreting a plot. Run and inspect walks through that released path.
A successful run is not proof that the physical assumptions are right. Capabilities and the verification guide explain the supported boundaries and how to find the relevant checks.
Looking inside the implementation?
Section titled “Looking inside the implementation?”The contributor architecture overview describes compiler and execution boundaries. For ordinary modeling, start with the task guides above and the Reference.