|
STAR
Cal STAR — firmware, DAQ server, and engine design
|
Classes | |
| class | Fluid |
Functions | |
| None | _validate (str name, float value) |
Variables | |
| dict | _PAIR_BY_KWARGS |
| dict | _PAIR_BY_ORDERED |
| tuple | _SNAPSHOT_PROPS = ("p", "T", "rho", "h", "s", "u", "cp", "cv", "mu", "k", "a", "Z") |
| dict | _STRICTLY_POSITIVE |
| dict | _UNIT_FRACTION = {"q": "vapour quality [-]"} |
| dict | _FAST_LOW = {name: 0.0 for name in (*_STRICTLY_POSITIVE, "q")} |
| dict | _FAST_HIGH = {"q": 1.0} |
| dict | _FAST_RESOLVE |
| ChainEntry = str | PropertyBackend | |
| int | _MEMO_ENTRIES = 512 |
The caller-facing handle: a fluid you can ask for properties.
``Fluid`` is a thin thing over a *chain* of backends::
n2 = Fluid("nitrogen") # ["bicubic", "heos"]
n2.get("rho", p=3.1e7, T=293.0) # ~0.13 us, from tables
n2.get("rho", p=5.0e9, T=293.0) # tables refuse; the EOS answers
The chain is the whole design. "Fast where possible, exact where necessary,
measured where we have data" is a list, not a branch -- so adding a source means
adding an element, and no call site learns about it.
Threading
---------
Backends wrap mutable cursors: ``update`` moves them, ``value`` reads wherever
they were last moved. Two threads sharing one would interleave into nonsense
that never raises -- each would read the other's state point. Every backend is
therefore **thread-confined**: built per thread, on demand, and never handed
across. A ``Fluid`` is safe to share; the backends underneath it are not, and
never leave.
|
protected |
Definition at line 110 of file fluid.py.
Referenced by feedtwin.props.fluid.Fluid._resolve(), and feedtwin.props.fluid.Fluid.accessor().
|
protected |
|
protected |
|
protected |
|
protected |
|
protected |
|
protected |
|
protected |
| feedtwin.props.fluid.ChainEntry = str | PropertyBackend |