Revision history [back]

Well when I originally put the one fan limit in place in OpenStudio I thought it was an EnergyPlus restriction, so I figured it was better for OS to reject multiple fans as opposed to finding out downstream when you try to run a simulation. (This is generally the pattern in OS with respect to dropping things on nodes, we try to prevent bad things early) Along the way people pointed out valid workflows where at least two fans make sense and in fact despite what I thought, E+ allows them. The two typical situations being return fans (upstream of oa mixer) and relief fans (oa relief stream). So the rules are now relaxed in OS, allowing up to two. Here is the change that actually relaxed the rules. It looks like it come in in v1.3.3 so the current behavior has been there for a little while. It was actually a more recent commit that supported relief fans.

Recently I've been thinking that the whole numeric limit is overly draconian altogether. For instance when swapping components, say constant speed fan for variable speed, I generally recommend that people add the new component THEN remove the old component. This is the preferred method because removing a component will also remove at least one neighboring node, and that node might be the exact one that you are about to add the new thing to. If you add, then remove, the whole complication is avoided. But of course this means you might momentarily have three fans, which OpenStudio is going to raise a fuss about. I welcome conversation about these behaviors from this community, and will make adjustments according to what people thing makes sense.

In general I think the fans will operate as you expect according to the availability manager, but there might be some caveats depending on how the fan schedules are setup, so I'd say proceed with caution or hope that someone with more knowledge than me chimes in.

Well when I originally put the one fan limit in place in OpenStudio I thought it was an EnergyPlus restriction, so I figured it was better for OS to reject multiple fans as opposed to finding out downstream when you try to run a simulation. (This is generally the pattern in OS with respect to dropping things on nodes, we try to prevent bad things early) Along the way people pointed out valid workflows where at least two fans make sense and in fact despite what I thought, E+ allows them. The two typical situations being return fans (upstream of oa mixer) and relief fans (oa relief stream). So the rules are now relaxed in OS, allowing up to two. Here is the change that actually relaxed the rules. It looks like it come in in v1.3.3 so the current behavior has been there for a little while. It was actually a more recent commit that supported relief fans.

Recently I've been thinking that the whole numeric limit is overly draconian altogether. For instance when swapping components, say constant speed fan for variable speed, I generally recommend that people add the new component THEN remove the old component. This is the preferred method because removing a component will also remove at least one neighboring node, and that node might be the exact one that you are about to add the new thing to. If you add, then remove, the whole complication is avoided. But of course this means you might momentarily have three fans, which OpenStudio is going to raise a fuss about. I welcome conversation about these behaviors from this community, and will make adjustments according to what people thing makes sense.

In general I think the fans will operate as you expect according to the availability manager, but there might be some caveats depending on how the fan schedules are setup, so I'd say proceed with caution and verify by looking at the output data, or hope that someone with more definitive knowledge than me chimes in.

Well when I originally put the one fan limit in place in OpenStudio I thought it was an EnergyPlus restriction, so I figured it was better for OS to reject multiple fans as opposed to finding out downstream when you try to run a simulation. (This is generally the pattern in OS with respect to dropping things on nodes, we try to prevent bad things early) Along the way people pointed out valid workflows where at least two fans make sense and in fact despite what I thought, E+ allows them. The two typical situations being return fans (upstream of oa mixer) and relief fans (oa relief stream). So the rules are now relaxed in OS, allowing up to two. Here is the change that actually relaxed the rules. It looks like it come in in v1.3.3 so the current behavior has been there for a little while. It was actually a more recent commit that supported relief fans.

Notice if you are writing measures there are methods to conveniently retrieve the different types of fans from the AirLoopHVAC object. supplyFan, returnFan, and reliefFan

Recently I've been thinking that the whole numeric limit is overly draconian altogether. For instance when swapping components, say constant speed fan for variable speed, I generally recommend that people add the new component THEN remove the old component. This is the preferred method because removing a component will also remove at least one neighboring node, and that node might be the exact one that you are about to add the new thing to. If you add, then remove, the whole complication is avoided. But of course this means you might momentarily have three fans, which OpenStudio is going to raise a fuss about. I welcome conversation about these behaviors from this community, and will make adjustments according to what people thing makes sense.

In general I think the fans will operate as you expect according to the availability manager, but there might be some caveats depending on how the fan schedules are setup, so I'd say proceed with caution and verify by looking at the output data, or hope that someone with more definitive knowledge than me chimes in.