This post is a follow on to a conversation started in 797. It has a few parts:

1. Moving the airVolumeAdjustability to be a property on a {fan motor equip}
2. Adding stepped as a choice of the above
3. Adding the concept of Fan Placement as a property of an airHandlingEquip and/or airTerminalUnit. Choices for this are proposed as:
   • blowThrough - airHandlingEquip
   • drawThrough - airHandlingEquip
   • parallel - airTerminalUnit
   • series - airTerminalUnit

Adjustability and Stepped

For stepped, I believe we should also have a required accompanying tag, something like numSteps:N where N is an integer value, so as to know the exact number of fan steps (although typically 2). This would help with templating out expected points.

I didn't find a great definition for stepped, but ASHRAE 90.1-2016 utilizes the concept in Section 6.5.3.2 and in Table 11.5.2-1. So how about this as a first pass: "A stepped motor utilizes discrete control speeds, represented as integer values beginning at 1, 2, etc. This is in contrast to near-continuous speeds of motor control, as is the case of an electronically commutated motor or variable speed drive."

• Do we want to represent a two-stage fan differently than two fans which are staged? If so, how to tackle? Thoughts appreciated.

References: Trane

Fan Placement

Regarding blowThrough and drawThrough:

• I propose this on the airHandlingEquip as it is typically used to describe the configuration of fans in relation to other things, i.e. heating / cooling elements or filters
• Generally thought of as upstream (blowThrough) vs. downstream (drawThrough) of filters or heating / cooling elements. Can somebody with mechanical engineering expertise chime in thoughts.

Reference: Engineering360

Regarding definitions for series and parallel:

• These can either be used on terminal units or for AHUs.
• When applied to terminal units, it is describing the fan in relation to the upstream air being delivered by an AHU and also denotes something about the expected operation of the terminal unit.
• Should this also be applicable to AHUs?, Based on the ACHR article, fans in series can happen? Do fans in parallel also happen?

References: ACHR, Trane

Additional Questions

• In an AHU application, how should we describe:
  • Multiple fans in series?
  • Multiple fans in parallel (what is generally referred to as a fan wall)?

Cory this is a great post that I don't even recall seeing until Brian included the link in his post; I wondered why it didn't catch my attention before then saw the April 2020 date and realized their were a few distractions going on in the world at that time!

I agree with adding stepped as a airVolumeAdjustabilityType. However, I think the definition for this should be simplistic focusing on the control output rather than the means of controlling. Much like the definition for variableAirVolume is "Delivers a variable volume of air flow"; which does not define if that is achieved by a VFD or inlet guide vanes, but simply indicates there is an analog output controlling the air volume and leaves the means to be described elsewhere.

Perhaps something like:

• stepped Utilizes discrete control speeds, represented as integer values beginning at 1, 2, etc.

That leaves defining if it is multi-speed motor, or main and pony motor to be defined separately in the same way the variableAirVolume does.

As far as fan placement, in my experience the terms blowThrough and drawThrough typically relate specifically to the supply fans placement in relation to the cooling coil. Mechanically speaking this is critical for knowing if the condensate drain will need to be trapped or not to drain properly. From an analytics perspective in could indicate were to expect to see a slight rise in air temperature from the fan. The term typically does not have any bearing on the fan placement in relation to the air filters or heating source unless specifically referencing them.

I agree blowThrough and drawThrough should be applied on the airHandlingEquip and definitions might look like:

• blowThrough The discharge fan is located upstream of the cooling coil.
• drawThrough The discharge fan is located downstream of the cooling coil.

Lastly, I feel adding the ability to add series or parallel to ahu fans could be beneficial. In either situation these tags could not only indicate the position of additional fans but also indicate the presence of additional fans in the same position such as:

{discharge, air, fan, parallel, dis:"Supply Fan A"}
{discharge, air, fan, parallel, dis:"Supply Fan B"}

Definitions might look like:

• parallel Indicates flow has multiple paths. When used on a fan equip indicates the presence of multiple fans with the same placement which air that passes through one fan will not pass through another fan with the same placement.
• series Indicates flow has a single path. When used on a fan equip indicates the presence of multiple fans with the same placement which air that passes through one fan will or has passed through another fan with the same placement.

I like the addition of stepped and agree w/ Leroy's definition.

The addition of blowThrough and drawThrough is helpful. I wonder if it would be possible to just model all the contents of an air handler sequentially.. Something like: @AHU1 contains: [@OADamper, @Prefilter, @Postfilter, @SupplyFan1, @CHWCoil1, @HWCoil, @DADamper]. Obviously it becomes tricky when there are converging and diverging sections like a mixed air plenum, but this seems solvable.

Within an AHU, it's pretty unusual for fans to be used in series, but not impossible. I suppose return and supply fans could be thought of as in series with each other: https://cdn2.hubspot.net/hub/416421/file-3234871846-png/blog-files/tabdiagram.png

It is very common to have equipment in parallel and not just fans in an air handler. Lots of equipment like pumps, chillers, cooling towers, heat exchangers as well as fans are designed in parallel for redundancy and turn down. They are often staged and sequenced together to common control points. I think it would be helpful to define something like a parallelEquipGroup to group together same-type equipment that is controlled to a common point.

For fans in parallel within an AHU, this parallel equip group could be an intermediate group between the AHU and fans, sort of like: @AHU contains @fanParallelEquipGroup contains @SupplyFan1 and @SupplyFan2.

Good discussion! I'd like to add an alternative approach for fan placement.

Haystack 4 defines most AHU components as equip types, as well as providing air flow relationships via airRef and equipment containment via equipRef. Brian has stated that filters will Ref tags with list values, which covers one-to-many or many-to-many relationships.

So with all this combined, you could model a parallel-fan pull-through AHU in Haystack 4 right now in the following way (notice the equipRef and airRef tags):

id: @ahu
equip
ahu
---
id: @coil
equip
chilled
coolingCoil
water
equipRef: @ahu
---
id: @fan1
equip
fan
equipRef: @ahu
airRef: @coil
---
id: @fan2
equip
fan
equipRef: @ahu
airRef: @coil

I feel that this approach is more general and extensible than flattening these details onto the AHU itself. However, allowing people to "choose" between this exploded style and a flat AHU style definitely becomes an issue with consistency. Do others have thoughts on this approach?

Re: original post - I like the original suggestions, except I think the fan placement tags should go on the fan equip instead of the parent equip. This leaves room for flexibility for odd ball systems that have bizarre fan arrays to indicate where each individual fan is.

Additionally, I think annie's suggestion points to something like an equipGroup being a tidy way to handle quite a lot of situations. For a fan wall, the group could contain all of the fans, and it would really be up to that implementation if modelling each individual fan is necessary, or if the master speed cmd and run sensor is enough to know what's going on.

@Jay, I like the airRef idea as it makes a lot of energy flow analysis intuitive (yay self-serving), but how would you handle airRef outside of this one ahu?

For instance, say this is the main AHU on the floor of an office building. Return air comes from the RA Plenum on the floor, but Outside Air could likely come from a Base Building DOAS unit. Does the ahu get an airRef to the doas? Does the outside air damper of the ahu get that airRef? The outside air duct equip of the ahu? Multiple choice?

The reason I think that answer matters, is querying the air flow from a 10,000 ft view should work as consistently as at the atomic level. So, some magical filter that follows airRef through the Air System of a Building should work the same way as following airRef within one AHU, just maybe with a different scope to it. Not sure if that makes sense, but curious what your thoughts are.

@Jay I like your way better than mine. Still wrapping my head around the new referencing with airRef so thanks for that providing that example. That was helpful and essentially what I was trying to achieve. If modelled as you proposed it should be possible to query into a flat structure of subequips if needed.

I still think grouping parallel equip together into an intermediate single equip might be useful.

@Mike with regards to your question:

Does the ahu get an airRef to the doas? Does the outside air damper of the ahu get that airRef? The outside air duct equip of the ahu? Multiple choice?

I would think you could model as granularly as desired, either linking the outside air damper or duct to the doas or the ahu itself to the doas. My assumption would be that if, for example the outside air duct was airRefd to the doas, then this relationship would be carried up through the chain of containment to the ahu. Not sure if that's a fair assumption.

@Mike Yeah, my understanding is the same as Annie's:

you could model as granularly as desired, either linking the outside air damper or duct to the doas or the ahu itself to the doas

I don't think there would be any other airRef style tag to connect the AHU to to the DOAS, if that's what you mean - it would be airRefs all the way through the airside system.

@Annie + Jay, I think I'm with you guys now, appreciate the responses. I guess my main concern is that flexibility is good but also leaves room for people to take liberty with interpreting it too loosely. That's probably something more to worry about in validation tools though I guess.