Skip to content

ThermofluidStream.FlowControl.SpecificValveType parametrization #381

Description

@RaphaelGebhart

ThermofluidStream.FlowControl.SpecificValveType currently allows the user by default to specify a valve via a combination of Kvs and zeta (or alternatively Cvs_US/m_flow_ref_set and zeta). This formulation effectively lets the user define the valve diameter indirectly via:

d = (zeta * c2 * Kv^2)^(1/4)
c2 = 6.22e-10

which is in my opinion very impractical and not common in data sheets.

Quick derivation

Using SI units and the defining relations

V_flow = Av * sqrt(dp / rho)
Av = c1 * Kv,  c1 = 27.7e-6

(see Modelica.Fluid.Valves.BaseClasses.PartialValve and Modelica.Fluid.UsersGuide.ComponentDefinition.ValveCharacteristics), together with

dp = 1/2 * zeta * rho * v^2
v = V_flow / A
A = pi/4 * d^2

one obtains

zeta = d^4 / (c2 * Kv^2)
c2 = c1^2 * 8 / pi^2 = 6.22e-10

(Note: some sources, e.g. https://www.schweizer-fn.de/zeta/armaturen/armaturen.php, report c2 = 626.3, which is (except for rounding errors) equivalent when the diameter is expressed in millimeters.)

Resonable parametrization

The model currently also allows the user (as last option) to explicitly provide d_valve and zeta. Combining the equations in ThermofluidStream.FlowControl.Internal.PartialValve (line 40) and ThermofluidStream.FlowControl.SpecificValveType (lines 36, 83, 92, with line 94 simplified to k_u = k_u_zeta) yields the physically consistent relation

dp = 1/2 * zeta * rho * v^2

which is in my opinion the only practical version of SpecificValveType.

Proposed changes (if we want to keep the model)

  • Deprecate all alternative parameterizations (Kvs, Cvs, etc.) in favor of d_valve.
  • Reorder parameters so that d_valve is listed first.
  • Raise an error if Kvs, Cvs, or similar parameters are used.

Alternative solution

Create a new model where the user can define Kv, Cv, or zeta+d as a function of valve opening. The model could support linear or logarithmic interpolation.

I would prefer creating a new model, because the current one offers too many possibilities for incorrect usage.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions