AirFlowNetwork:Surface fails when assigned to a Surface with Construction:AirBoundary with GroupedZones

[chriswmackey]

Issue overview

I am 99% sure that this is a bug in EnergyPlus that results from a missing check for the new Construction:AirBoundary object. Specifically, if I create a Construction:AirBoundary that uses the GroupedZones option for Radiant Exchange Method, then I assign that construction to a Surface, I am then unable to include that Surface in an Airflow Network. Trying to assign that Building Surface an AirflowNetwork:MultiZone:Surface object results in EnergyPlus throwing the following Fatal error and terminating the simulation:

   ** Severe  ** GetAirflowNetworkInput: AirflowNetwork:MultiZone:Surface object
   **   ~~~   ** ..The surface specified must be a heat transfer surface. Invalid Surface Name = 9722CF1B-18C4-4A41-8873-1101BE9C5D3F_1
   **  Fatal  ** GetAirflowNetworkInput: Errors found getting inputs. Previous error(s) cause program termination.

Here is an IDF that recreates this issue: https://drive.google.com/file/d/1khOh5rGzdTZqIgkkaco90G2yYBrJ5RGc/view?usp=sharing

Interestingly enough, when I change the Construction:AirBoundary to use IRTSurface instead of GroupedZones, the error goes away and I can include the Surface in the Airflow Network as I normally would. So this is what makes me think it is a bug related to the Construction:AirBoundary and the new GroupedZones feature.

Details

Some additional details for this issue:

• Windows 10
• EnergyPlus 9.3

[chriswmackey]

@mjwitte and @Myoldmopar , I know that you two were the ones who added the Construction:AirBoundary and I thank you immensely for this feature. We've made it a standard part of the Ladybug Tools package such that there will now be thousands of people making use of it. Is there any chance that either of you could confirm that this interaction of the Construction:AirBoundary with the AirflowNetwork is a bug?

Thanks again!

[mjwitte]

@chriswmackey Hmm, the way Construction:AirBoundary is implemented, when using the grouped option for both solar and radiant exchange, the surface is not tagged as a heat transfer surface and is essentially removed from the simulation. So there is no surface to attach AFN objects to. When using the IRTSurface or InteriorWindow options, the surface remains in the model with modified heat transfer characteristics, but that limits the whole purpose of removing the wall and letting the adjacent zones act as a single enclosure.

With the current approach, the error message above should certainly be modified to be a warning for an air boundary surface and then ignore those inputs (or stay fatal because it could cascade into problems with related AFN objects and add language to explain why this surface doesn't exist anymore) - and some documentation changes to clarify all of this.

It may be possible to allow AFN to reference that type of surface. I'll have to look at the interactions to see what information AFN needs from the surface.

[chriswmackey]

Thanks, @mjwitte . Your explanation confirms what I thought was going on.

Having the AirflowNetwork ignore the Surface with the Construction:AirBoundary is definitely a solution that allows the simulation to continue since I have been able to run the IDF I attached after removing the AirflowNewtwork:MultiZone:Surface that is tied to the BuildingSurface:Detailed that is using the Construction:AirBoundary with GroupedZones. However, this seems to imply that there is no air exchange in the AirflowNetwork across the AirBoundary Surface, which I am sure most users are not expecting.

I sense that the ideal solution would be to allow users to add surfaces using Construction:AirBoundary into the AFN as AirflowNetwork:SimpleOpening as @saeranv suggests in that issue that you referenced. There are certainly other ways that it could be resolved but modeling AirBoundary Surfaces as AFN Openings seems to be a solution that is still true to the fluid dynamics that the AFN is trying to model and it doesn't seem to require a huge refactor of the AFN as it exists right now. Still, I realize that it might not be trivial to pass the properties of the AirBoundary surface to the AFN when it doesn't exist in the simulation as a heat transfer surface.

In any case, I am anxious to know what you find and I'm happy to generate more samples, test or help in any way that I can.

[mjwitte]

@chriswmackey This raises the question of how flexible we should allow this to be. I have a working version that allows AirflowNetwork:MultiZone:Surface to reference an air boundary surface. It also allows any type of opening or crack to be attached to an air boundary surface (even if the air boundary surface is not a fenestration surface). It runs and produces AFN Zone Mixing Volume values. I'll work on getting a test version available so you can see if it's generating meaningful results.

Next question for @jasondegraw @lgu1234 @chriswmackey : How restrictive should this be? Technically speaking, venting controls should not apply to an air boundary surface. Likewise, a crack should not apply. Allow these anyway without warning? Throw a warning if applied to an air boundary but proceed? Or don't allow it and throw a severe/fatal error?

[chriswmackey]

Thank you, @mjwitte ! That's wonderful to hear that you have a fix ready that allows the assignment of AFN Opening objects to the surface. I am definitely happy to do some QAQC of the results once there's a build available.

I know that my philosophy isn't always the most appropriate but I am a big fan of allowing the simulation proceed but adding Severe warnings if the user input is fishy. This is what I would recommend if people use AirflowNetwork:MultiZone:Surface:Crack with the AirBoundary surface since I am sure that many developers will have a first instinct to use a Crack for AirBoundaries just like all of the other opaque building surfaces. A Severe warning is a good way to let such developers know that they can use AirflowNetwork:MultiZone:Component:SimpleOpening objects and that this is recommended. At the same time, it doesn't totally restrict the user's freedom since there could be some rare cases where an AirBoundary surface is very narrow and the Crack model could actually be appropriate.

Things get a little more complex with the controls because I think that many people using the AFN use the EnergyManagementSystem for controls. This is what I use for all of my simulations with the AFN and it seems to be what a lot of people on Unmethours use. In this case of the EMS, users are already specifying the control logic at a fine enough detail that it will be tough to accidentally set up a simulation where the AirBoundary opening closes (unless this is intentional and the user has some good reason for it).

However, I realize that some of the simpler VentilationControlModes could be prone to this accidental closing of the AirBoundary opening without the user's knowledge. If there is a way to just avoid having the AirBoundary opening close for these simpler control modes, this seems ideal. But, if this is tough to implement, then it would seem appropriate to issue warnings whenever there's an AirBoundary in the AFN and Temperature, Enthalpy, or the Adaptive models has been selected for controls.

[mjwitte]

@chriswmackey Thanks for the feedback. As it stands right now, the code in #8263

1. Allows cracks to be applied to air boundary surfaces without warning.
2. Warns and turns off any venting controls on an air boundary surface (sets to Constant with no schedule).
3. It appears that the EMS actuator for Airflow Network Openings should work for air boundary surfaces - but I need to test to be sure. This should probably throw a warning when the actuator is set up? Please contact me directly to arrange for a test build.

[mjwitte]

@chriswmackey For a test build - Mac, Linux, or Windows?

[chriswmackey]

Hi @mjwitte , All great to hear and thanks again! For testing on my end, Windows would be ideal. By "contact you directly" do you mean via email?

[mjwitte]

@chriswmackey Never mind that. I've tagged a pre-release for you (or anyone) to test. Installers for all platforms should appear within a few hours. Really appreciate your willingness to test. FYI, v9.4.0 code freeze is next week on 9/17 or so. So, this is timely. I can make any needed changes up to about 9/16.

[chriswmackey]

@mjwitte , Wonderful! Thanks for putting together the pre-release and, if I didn't say it earlier, I really appreciate the quick fix here and all that you have done to make the AirBoundary constructions a reality. I'll try to test everything later tonight or tomorrow morning depending on when the Windows installer gets built. And I'll post the results here once I have them. Thanks again!

[chriswmackey]

@mjwitte ,

I tested a bunch of scenarios on my end and some things seem to be working as intended while others not so much.

First, I verified that the previous file with the fatal error could simulate without warnings, which it could, though it was using an AFN Crack for the air boundary and we know that is not the best way to model it. For what it's worth, the air flows across the AirBoundary Surface were in the ranges I expected since I used a very large flow coefficient that was derived from the area of the AirBoundary surface. Here's the hourly flow rate for each direction across the surface: So it seems we at least have some way of including AirBoundaries in the AFN now.

Next, I tried changing the AirFlowNewtork Surface to reference a SimpleOpening object and got a fatal error that makes sense sine the AirBoundary surface in my model is horizontal. The error was ** Severe ** An AirflowNetwork:Multizone:Surface object has an air-flow opening corresponding to window or door, which is within 10 degrees of being horizontal. So everything is good here!

Next, I changed the file to use an AirflowNetwork:MultiZone:Component:HorizontalOpening and everything simulated without warnings. However, the opening appeared to be in a constant state of closure. Here's the flow across the surface when I did this (paying close attention to the legend):

I could change the Air Mass Flow Coefficient When Opening is Closed property on the HorizontalOpening to have a large flow coefficient that was similar to the Crack and I was then able to get similar flow rates to the Crack across the air boundary surface. This seems to confirm that the opening is remaining in a closed state throughout the simulation.

I am wondering if this is because I am using a HorizontalOpening instead of a SimpleOpening and I will try a test with a vertically-oriented air boundary shortly. In the meantime, let me know if you have any thoughts here.

I should also note that there was no EMS actuating on the AirBoundary surface in any of these tests. So we can't blame anything on that for the moment.

[chriswmackey]

I verified that the same thing seems to be happening when I have a vertical Air Boundary surface that is using a SimpleOpening object. Here is the air flow that I get when the Air Mass Flow Coefficient When Opening is Closed is very low:

... and here is what I get when the Air Mass Flow Coefficient When Opening is Closed is high:

So this closed behavior is definitely what is governing the flow rate across the air boundary. I verified that this is still the case even when I set AirflowNetwork:MultiZone:Surface object to have a Constant control mode.

[chriswmackey]

I have one last check that I did: I set the OpenFactor of the SimpleOpening on the AirBoundary surface to be always open using the EMS but this still did not have any effect. It's always the Air Mass Flow Coefficient When Opening is Closed that determines the flow across the air boundary.

This is still a huge improvement from before but it would be really nice if there's some way to have the AirBoundary surface simulate as an actual Opening instead of the current behavior, which is always crack-like.

[mjwitte]

@chriswmackey Thanks for testing. I'll work on figuring out why the openings are always closed.

[mjwitte]

@chriswmackey I think it's fixed now. The openings should be fully open now (at the specified Window/Door Opening Factor) and controllable with EMS. Here's another test release.

[chriswmackey]

Thanks @mjwitte . I will check it out now.

[chriswmackey]

Woohoo! It all seems to be working as intended. I re-ran my initial model with a horizontal AirBoundary and got the following results regardless of what value was set for the Air Mass Flow Coefficient When Opening is Closed.

Admittedly, the results look eerily identical to what I had gotten previously using a Crack object for the Air Boundary but I guess this is just an indication that I picked a really good flow coefficient that was correctly derived from the underlying formulas of the AFN.

Things are at least slightly different for the example I have with a vertical air boundary (though still in the expected ranges):

So I think we are all good to go here. Thanks again @mjwitte !

[mjwitte]

@chriswmackey This has been merged for the v9.4 release at the end of September.