Add quasi steady-state air flow network model into Nandrad

[ghorwin]

Similarly to the hydraulic netwerk model, we need an air flow network model that handles the cross-flow calculation across zones.

Pressure-loss coefficients need to be added parallel to construction properties - so a construction instance will also reference an air leakage object that defines the air leakage model and coefficients.

Boundary conditions for air flow need to handle pre-compute stack pressure coefficients and simplified models.

Interaction with zone thermal model as needed for boyant flow calculations. Shall be decoupled from thermal dynamic balances as much as possible.

[KnutKnudson]

Tasks related:

1.) Boundary conditions for stack pressure (data structure design) 2.) Air leakage object data structure and link to construction 3.) Steady-state solver for solving thermal balance

Air cross-flow calculations are able to consider forced flow between different zones and the outside. The flow is directional (pressure driven). Contrarily, buoyant flow results in air exchange over an opened surface (and is non-directional from the view of a single zone). I fear, we need a seperate model for boyant flow.

[KnutKnudson]

The data structure for air network should re-use hydraulic network data structure. For air networks, zones also can act as network node. Further, openings and cracks should be part of the network. All effects including infiltration, air flow through openings and leakages, air conditioning network should be included in one network. Attached a suggestion for data structure.

ThermoHydraulicAirNetwork.txt

[ghorwin]

In contrast to generic hydraulic network routing, air flow networks are determined by zone topology and should be implicitely deducted from that. Only the air-handling unit part should be modeled in its own subnetwork data structure.

[KnutKnudson]

This convention makes sense, if NANDRAD is used as stand-alone data structure. Anyhow, we only use export tools. Translating a building topology into an air network is a preprocessing step - why should this be done inside the solver?

[KnutKnudson]

Further, air network and air flow must always be integrated inside the same model network - because each zone only can have one pressure node. What will be the case, if we have two separated hydraulic air networks? As soon, as air flow is activated, these two separate networks must be merged - sometimes. Only if they contact the same zones.

For discussion with Dirk:

[KnutKnudson]

Mechanical ventilation (Dirk's wish) is treated in a seperate issue.

[KnutKnudson]

See attached the suggestion for combined mechanical and natural ventilation.

ThermoHydraulicAirFlow.txt

EnergyPlus suggests both models for forced flow as well as mixed forced and buoyant flow (does this make sense?)

EquationEnergyPlus.txt