Hi, trying to model a more complex family house I wonder why solar gains are not shown when rooms have an Airwall?
With normal Walls everything is displayed.
Does this mean they are not calculated at all, or are they just not displayed?
When air boundaries are used between two rooms, EnergyPlus calculates the solar radiation in the two rooms as one room and renames it “Solar Enclosure 1” which prevents honeybee from reading the solar results properly.
Since it is an EnergyPlus feature, I’m not sure if there is a way for Honeybee to split the solar load back into two rooms…
Here is a discussion on UnmetHours talking about air boundaries and solar calculations:
3 Likes
Very interesting, I didn’t catch this back when they introduced the improved air wall. But what exactly is the problem with splitting the solar load back into two rooms? Is the problem that there’s no way to identify the original two rooms when it’s renamed? Also where is this beviour described in the documentation? I can’t seem to find any reference to this renaming behaviour in the EP I/O for the air wall[1]
[1] Group – Surface Construction Elements: Input Output Reference — EnergyPlus 9.5
@kentakahas is correct and it says it here, @SaeranVasanthakumar :
The two zones separated by this air boundary will be grouped together into a combined enclosure for solar distribution, daylighting, and radiant exchange (including distribution of radiant internal gains). If a given zone has an air boundary with more than one zone, then all of the connected zones will be grouped together.
If you check the raw output from the Honeybee result-parsing component, you will see that E+ will actually give you the solar gain for the entire “Solar Enclosure” that contains all of the connected rooms. It’s just that the “HB Color Rooms” component doesn’t know how to match the solar enclosure back to the rooms since the two of them have different IDs.
Does EnergyPlus not report what room IDs are assigned to each solar enclosure ID?
If there is some way to trace that information back, it would be nice for the “HB Color Rooms” component to color all the rooms with the same value.
I would add: if they aren’t reporting the original room IDs, this seems like a conceptual error from the EP team that can be easily fixed on their end.
Unless there’s some additional complexity or nuance I’m missing here. The only problem I can think of is that the output would represent a non-uniform distribution of solar energy between multiple rooms as misleadingly uniform distribution when averaged together.
In my opinion, the EnergyPlus developers made the right choice of reporting the data at the level of the enclosure because there’s no way to know how the solar energy is distributed across all of the rooms that make up the enclosure when you have free radiant exchange over the whole enclosure.
This said, I’m not against someone putting in a “best guess” if they want to make some type of assumption in honeybee like “all of the solar energy of the enclosure is evenly distributed across the rooms.” It will be a bit misleading in some cases like Saeran says but looking at data on the room level is already pretty coarse. Still, because it’s a little misleading, this just isn’t that high of a priority for me, especially when I still have many more energy features to be added.
You can always do some post-processing of the solar enclosure results with native Grasshopper components if you want to add them to your visualization. You can also hack the “HB Color Rooms” component to do this. Both the .eio file and the .sql file should contain the information about which enclosures contain which rooms/zones but you can also probably figure it out by analyzing the adjacencies of the input rooms, knowing that EnergyPlus numbers the enclosures according to the order that they are discovered in the model.
If anyone wanted to implement a solution like this or edit the core honeybee-energy ColorRoom class, I would be happy to review a PR and merge it into the code base.
I’ll also just say: if you only need this for visualization purposes of solar gain, you can always just run the simulation using a paper thin opaque wall instead of an AirBoundary. The total incoming solar energy will still be the same whether you use the AirBoundary or an opaque wall. It’s just not going to distribute the solar beyond the paper thin opaque construction so some of the other load balance terms output from the simulation won’t be as accurate. But you can just run another simulation with AirBoundaries for that case.
Thanks, it’s good to get confirmation that’s the underlying problem, and the fact that the enclosure to room data is in the .eio and .sql files means it’s a solvable issue.
Personally, I would prefer having access to the averaged solar data per enclosure, versus having it omitted. It’s definitely somewhat of a novel situation that requires some care or warning in reporting it as a value, but out of anyone, I trust energy modelers will know how to correctly interpret averaging at different spatial scopes.
@SaeranVasanthakumar and @Martin6 ,
I think you will both be happy to know that I made a tweak to the “HB Color Rooms” component to split the solar data of enclosures into individual Honeybee Rooms before we color the geometry:
The only requirement that you need to follow in order to see solar results for rooms with air boundaries is that you must connect the whole model to the _rooms_model input and you can’t just connect a list of individual rooms.
The best criteria that could think of in order to split the total solar energy between the rooms was the area of exterior apertures on each room. Using exterior aperture area should be a little less misleading than evenly subdividing the solar across all rooms in the enclosure or using the floor area to do so.
And, most importantly, it gets around the unexpectedness that you experienced here and while remaining faithful to the total solar energy that EnergyPlus reports over each enclosure.
4 Likes
Thank you @chris I think that’s a good compromise.
There is one question that comes to my mind. How to deal with connected rooms without apertures?
Shouln’d they get some kind of minimum “radiance share”?
@chris great and thank you! My need for more data is satisfied.
The use of exterior aperture area as a way to split the solar energy is a much better way to split the solar energy then using floor area like I suggested. I think it’s a good balance of something quick to calculate while still providing a meaningful result for most zoning conditions. It would lead to inaccuracy only in certain edge cases (documented here mainly for my own understanding):
-
Radically different window SHGC factors. Solution here would be to weight by an additional SHGC factor would provide a small improvement.
-
One room that has a higher window exposure from other room windows. A solution here may be a cheap numerical view factor approach (\frac{1}{N} \frac{A_{win}}{\pi r^2} \sum cos(\theta_{floor}) cos(\theta_{win})) summed over all apertures, but starts being a costly operation.
-
Radically different solar radiation values from the window based on orientation. Don’t think there’s a great solution for this one that doesn’t start reproducing the EP solar calculations.
Thanks for implementing it.
1 Like