STAR
Cal STAR — firmware, DAQ server, and engine design
Loading...
Searching...
No Matches
feedtwin.props.state Namespace Reference

Classes

class  Phase
class  PropertySpec
class  ThermoState

Functions

tuple[str, PropertySpec] _spec (str name, str unit, str description)
PropertySpec register_property (str name, str unit, str description)

Variables

dict PROPERTIES

Detailed Description

What a property query returns, and the registry of what can be asked for.

Two things live here, and they are deliberately the same concept seen twice:

* :data:`PROPERTIES` -- the registry of every quantity the layer can produce.
  Adding one is a single entry here plus a line in whichever backends can
  compute it. Nothing else in the codebase enumerates properties.
* :class:`ThermoState` -- an eager, immutable snapshot at one state point.

**Everything is SI.** Pa, K, kg/m3, Pa.s, J/kg, J/(kg.K), W/(m.K), m/s. There is
no unit handling inside the solver; conversion happens once at the schema
boundary (Phase 02). A number that reaches this module is already SI.

Why the snapshot is eager
-------------------------
The obvious cheaper design is lazy: hold the backend and fetch properties on
demand. It is a trap. Backend handles are mutable and reused -- a second query
re-points the same handle -- so a lazily-evaluated state would silently answer
with a *later* state point's numbers. Every field is therefore read before the
snapshot is returned.

That costs about eight backend reads where the solver's hot path needs one, so
the hot path does not use snapshots at all: :meth:`Fluid.get` fetches a single
property. :meth:`Fluid.state` is for reporting, diagnostics and frames.

Function Documentation

◆ _spec()

tuple[str, PropertySpec] feedtwin.props.state._spec ( str name,
str unit,
str description )
protected

Definition at line 75 of file state.py.

◆ register_property()

PropertySpec feedtwin.props.state.register_property ( str name,
str unit,
str description )
Add a property to the registry at runtime.

For quantities a project needs that this package does not ship -- a
surface tension correlation, a user-supplied fouling factor. Backends that
cannot compute it simply do not advertise it, and the fluid's chain falls
through to one that can.

Definition at line 105 of file state.py.

Variable Documentation

◆ PROPERTIES

dict feedtwin.props.state.PROPERTIES
Initial value:
1= dict(
2 [
3 _spec("p", "Pa", "Pressure"),
4 _spec("T", "K", "Temperature"),
5 _spec("rho", "kg/m^3", "Mass density"),
6 _spec("h", "J/kg", "Specific enthalpy"),
7 _spec("s", "J/(kg.K)", "Specific entropy"),
8 _spec("u", "J/kg", "Specific internal energy"),
9 _spec("cp", "J/(kg.K)", "Specific heat at constant pressure"),
10 _spec("cv", "J/(kg.K)", "Specific heat at constant volume"),
11 _spec("mu", "Pa.s", "Dynamic viscosity"),
12 _spec("k", "W/(m.K)", "Thermal conductivity"),
13 _spec("a", "m/s", "Speed of sound"),
14 _spec("Z", "-", "Compressibility factor, p/(rho.R_specific.T)"),
15 _spec("gamma", "-", "Heat capacity ratio cp/cv"),
16 _spec("molar_mass", "kg/mol", "Molar mass"),
17 ]
18)

Definition at line 85 of file state.py.