Best way for passing abstract type data via path variables in Dyad

New to Julia
, ,
1

Hello, I have a question about the proper usage of path variables in MTK and Dyad.

To calculate heat transfer coefficient(HTC) and pressure drop(dP), the specific type and geometry of the heat exchanger(HX) are crucial. My idea was to pass the abstract device object itself through the connector using a path variable.

I started by adding path device::AbstractHX to my fluid connector.

# Connector for fluids
connector FluidPort
    # Potential
    potential p::Pressure
    # Flow
    flow m_flow::MassFlowRate
    # Stream property
    stream h_outflow::SpecificEnthalpy
    # Information shared through the circuit
    path medium::AbstractMedium
    path device::AbstractHX # Passing the device object
end

This would allow me to access the device’s properties within my calculation functions, like so:

HTC(medium::AbstractMedium, hx::AbstractHX, p, h, mdot, Q_heat) = Models.htc(medium, hx, Mediums.State(p=p, h=h), mdot, Q_heat)
dP(medium::AbstractMedium, hx::AbstractHX, p, h, mdot) = Models.dP(medium, hx,  Mediums.State(p=p, h=h), mdot)

However, I realized that a path variable propagates throughout an entire connected circuit. This presents a challenge: when a heat exchanger is connected to a different component type, like a compressor, the single device path variable creates a type conflict. It cannot simultaneously represent a heat exchanger in one part of the circuit and a compressor in another. To resolve this, I’ve considered two potential solutions.

Solution 1: Create a separate DevicePort

# In my library (jl)
abstract type AbstractDevice end
abstract type AbstractHX <: AbstractDevice end
abstract type AbstractComp <: AbstractDevice end

# A connector only for the device (dyad)
connector DevicePort
    path device::AbstractDevice
end

Solution 2: Create a PureFluidPort

# In my library (jl)
abstract type AbstractDevice end
abstract type AbstractHX <: AbstractDevice end
abstract type AbstractComp <: AbstractDevice end

# A connector for fluid and device (dyad)
connector FluidPort
    ...
    path medium::AbstractMedium
    path device::AbstractDevice
end

#  A connector only for fluid
connector PureFluidPort
    ...
    path medium::AbstractMedium
end

Solution 1, using a DevicePort, failed to generate MTK files, likely because a connector with only path variables is invalid.

While Solution 2 is a possible workaround, bundling component-specific data within a FluidPort feels like a design compromise that violates separation of concerns.

What is the recommended design pattern in MTK for making component-specific parameters available to connection-level calculations? Is there a way to make the dedicated connector approach (Solution 1) work correctly?