MANUAL

Media and fluid modeling

A fluid model combines a network of transport and storage components with a medium that supplies thermodynamic properties. Keep the medium definition, thermodynamic state, and fluid connections distinct so the same component can work with different property models.

The examples use local definitions to introduce medium data, fluid ports, and transport equations. A complete interactive network then demonstrates path variables as a way to share configuration. The examples require no installation of MediaComponents or FluidComponents.

This page builds on component composition, structural parameters, and the physical connection rules in Connectors and Networks.

Separate the three responsibilities

Part	Contains	Dyad representation
Medium definition	Property constants, composition dimensions, property-model choices	Immutable Julia data passed as a structural parameter with a Native type.
Thermodynamic state	Pressure, temperature, density, enthalpy, composition	Variables and equations in a component.
Fluid interface	Pressure, mass flow, transported enthalpy and composition	A connector with potential, flow, and stream fields.

A medium definition selects the laws and dimensions used to construct a model. The state variables describe the fluid as the simulation evolves. Pass the same medium definition to the components and connectors in one compatible fluid network.

Pass immutable medium data into a component

Put Julia support definitions in the library's dyad/definitions.jl. This constant-property example defines medium data and an enthalpy function:

struct SimpleLiquidData
    cp::Float64
    T_ref::Float64
end

liquid_enthalpy(medium::SimpleLiquidData, T) = medium.cp * (T - medium.T_ref)

Declare the Julia type at the Dyad boundary and pass an instance structurally:

type SimpleLiquidData = Native

component LiquidProperties
  structural parameter medium_data::SimpleLiquidData = SimpleLiquidData(4184.0, 273.15)
  parameter temperature::Real = 300.0
  variable h::Real
relations
  h = liquid_enthalpy(medium_data, temperature)
end

LiquidProperties calculates enthalpy at the fixed temperature parameter; it is a standalone property calculation. Native exposes a Julia type to Dyad. The structural parameter carries the immutable definition into model construction. A function in the same library's definitions.jl is available to the Dyad equations by name.

For this simple liquid, h is specific enthalpy relative to T_ref; use consistent units for temperature and heat capacity. A production medium should also define its validity range and reference conventions. Functions used with state variables must support the symbolic values used during model construction; the arithmetic in this function does.

For a configurable medium, property accessors can supply the number of species and reference composition. Components can use these values to derive final structural parameter values and array dimensions. The medium data then provides one definition of these construction-time choices.

Define a fluid connector

Fluid transport requires a connector in addition to property calculations. This minimal single-substance connector carries pressure, mass flow, and transported enthalpy:

connector LiquidPort
  potential p::Real
  flow m_flow::Real
  stream h_outflow::Real
end

Use one unit convention throughout this connector: pressure in Pa, mass flow in kg/s, and specific enthalpy in J/kg are typical choices. A library can encode these conventions in named scalar types.

Field	Connection meaning
p	Connected potentials are equal.
m_flow	Connected flows satisfy conservation, with the connector's orientation determining signs.
h_outflow	The specific enthalpy that this component would supply if fluid flowed out through this port.

h_outflow describes a hypothetical outflow even when the actual flow points into the component. instream(port.h_outflow) obtains the incoming mixture's enthalpy from the connection. Equating all stream fields would erase the transport and mixing behavior that the stream connector represents.

See Connectors and connections for the general connection rules and signal interfaces.

Transport fluid through a reusable component

A two-port transport component combines mass conservation with an enthalpy transport rule. This simple resistance stores no mass or energy:

component LiquidResistance
  a = LiquidPort()
  b = LiquidPort()
  parameter R::Real = 1.0
relations
  a.m_flow + b.m_flow = 0
  a.p - b.p = R * a.m_flow
  a.h_outflow = instream(b.h_outflow)
  b.h_outflow = instream(a.h_outflow)
end

Positive a.m_flow enters at a and leaves at b. The two enthalpy equations supply outflow values for either flow direction. The pressure law is a simple linear constitutive relation; choose R with units compatible with pressure and mass flow. Boundary components must supply the network's pressure and inflow thermodynamic conditions before this element forms a simulation model.

A storage component adds mass and energy balances and a thermodynamic state. Its outflow values follow from that internal state. Keep a component's pressure law, transport equations, and stored energy explicit so each can be reviewed against the intended physics.

Do MediaComponents and FluidComponents use path variables?

MediaComponents and FluidComponents are not yet published. Their current development sources use explicit structural-parameter forwarding: FluidComponents ports declare medium_data as MediaComponents.Interfaces.AbstractMediumData, and components pass medium_data = medium_data to child ports and medium-state models. MediaComponents supplies the native data types and property accessors. Neither library currently uses path variables or continuity to propagate medium data. Follow this explicit interface when extending their components.

Explicit forwarding follows the component hierarchy. The path-variable example below demonstrates sharing configuration through connections instead.

Share configuration along a path

A path variable carries construction-time data across a connected network. The following example shares the scalar heat capacity cp through connections, independently of the earlier SimpleLiquidData example. Declare it with path in a connector, then give the connected path one consistent definition. Components can read that value through their ports. A path variable can represent a medium choice, a property constant, or other configuration shared by the whole flow path.

connect(a, b) joins matching path fields on connected ports. Inside a two-port component, continuity(a.cp, b.cp) carries the same configuration from one port to the other. The component's equations define its pressure drop and transport.

The diagram shows two boundaries joined through a resistance. Follow these steps in the code pane, or open Code on narrower screens:

1. PathLiquidNetwork defines cp once and binds it to the inlet port.

2. Connections carry cp between components; the resistance's continuity relation carries it between its ports.

3. Both boundaries use port.cp to calculate their outflow enthalpy.

Select a component in the diagram to inspect its parameters. Download as a Dyad projectFluidPathGuide.zipOpen in Dyad Studio›

The network defines cp once, in J/(kg·K). The network's continuity relation binds it to the inlet port. Connections carry that definition to the resistance, whose internal continuity carries it through to the outlet. Both boundaries read port.cp when computing the enthalpy they supply to the network. The pressure difference gives a mass flow of 1 kg/s through the resistance.

The path value remains fixed as the simulation evolves. Temperature belongs in state variables or boundary parameters, and transported enthalpy belongs in a stream field. Sharing cp does not force the inlet and outlet temperatures to match.

Keep explicit continuity relations at the top level of relations. The current compiler joins top-level continuity declarations. Arrays share one path identity for the whole array, so use separately declared components when their path configurations must differ.

Scale the pattern to mixtures and configurable models

A mixture interface adds composition to the single-substance pattern. Accessors can derive composition and trace-substance dimensions from medium data; additional stream arrays transport independent mass fractions and extra properties alongside enthalpy.

When designing such an interface:

• Choose the medium once in the containing model and forward it explicitly to each child that needs it.

• Derive species counts and other dependent dimensions as final structural parameters.

• Use structural conditions for optional equations, diagnostic variables, and composition branches whose presence depends on the medium.

• Give each port an outflow state and use incoming stream values when computing properties of fluid entering the component.

• Separate reusable partial interfaces from the concrete equations that close a pressure-flow, heat-transfer, or storage model.

When extending a library, follow its complete convention for absent composition and trace substances. Array dimensions and any placeholder constraints work together; changing only an array size can change the connection equations.

These are ordinary component, connector, structural-parameter, and Julia interoperability patterns. The component guide covers composition and inheritance, and Parameters, Variables, and Equations covers the declarations and equations used to express them.