feedtwin.model.component Namespace Reference

Classes
class	PortState
class	EvalContext
class	Component
class	ComponentInstance

Detailed Description

A configured component, and the shape an evaluable one takes.

Two things here, at different levels of settledness.

:class:`ComponentInstance` is **settled**: one piece of hardware in a network,
with its type, its chosen fidelity model, its validated parameters and what its
ports connect to. It is what a config file deserialises into, what the inspector
edits, and what Phase 03's components are built from. It carries no physics.

:class:`Component` is the protocol those built objects satisfy, and it is
**provisional**. Designing a solver interface before there is a solver is
speculation; it is written down now so Phase 03's components share one shape
rather than three, and it should be expected to move once Phase 04 assembles a
real Jacobian against it. That is said here rather than discovered later.

Why residuals rather than pressure drops
----------------------------------------
The obvious interface is ``dp(mdot) -> float``. It handles a pipe and then
fails, in order, at: a check valve (which has a discrete open/closed state), a
regulator (which has its own poppet dynamics, so its behaviour is an ODE and not
a function), a cavitating venturi (where the relation inverts once choked), and
anything with two flow paths.

Contributing *residuals* to a system -- ``f(port values, flows, states,
derivatives) = 0`` -- covers all of those uniformly, and is the same acausal
formulation Modelica uses for the same reason. The cost is that a component
cannot be evaluated alone, only solved; for a network that was always true.