Open macumber opened 6 years ago
Questions for @DavidGoldwasser @asparke2 @shorowit
Do we want floors with multipliers to be flying in the sky like shown? Is that important to indicate there are multipliers in use?
How should boundary conditions be handled for these floors? You can intersect the non-multiplier floor with the floors above or below it and set adjacencies between a non-multiplier floor and a multiplier floor to adiabatic. For multiplier floors you can intersect with the non-multiplier floors above and below as well as with itself (e.g. intersect the ceiling with it's own floor), change anything that intersects with anything to adiabatic?
Another question is if we want to support multipliers on individual spaces, this is used by some of the reference buildings.
We can get around some of this by creating 3 levels for every multiplier story (for multipliers > 3)
I think we should go with adiabatic for all non-exterior boundary conditions with multipliers
Hmm. Wouldn't we want a story multiplier to be simply translated as thermal zone multipliers?
If a thermal zone has a multiplier, and the story it's in also has a multiplier, then the translated OS zone would have a multiplier that is the product of the two multipliers.
The advantage being that the EnergyPlus simulation will be faster.
@shorowit it gets pretty weird quickly as thermal zones don't correspond 1-to-1 with stories. My thought is to apply the story multiplier to spaces on that story first, then apply the space multipliers to thermal zones (giving a warning if a thermal zone has a mix of spaces with different multipliers).
The biggest issue is how to deal with boundary conditions so you get the correct amount of exterior area after all the multipliers are applied.
But in FloorspaceJS, a thermal zone is a child of a story. It's fine to have multiple thermal zones in a story, while the app prevents a thermal zone from being attached to multiple stories. Right?
You can have thermal zones that span stories, we could add that as a constraint but currently it is not
Don't most of the residential buildings use a single zone for all floors?
Oops, you're right, it's not a constraint. Good point.
Yes, our residential single-family models can use a single zone for multiple stories. And our residential multifamily models use story multipliers. But I don't think we'd ever have a model where we used both. I think it's fine to require a story with multiplier > 1 to not have a thermal zone that spans multiple stories.
This will cover us for 2.5.0 release https://github.com/NREL/floorspace.js/issues/290
My preference is to just model the mid floor floating once with multiplier of 6. Make any floor/ceiling surfaces for the mid floor zones adiabatic, as well as the 'interior' ceilings of the lower story and the 'interior' floors of the story above the mid story.
For non-rectangular buildings you may want to make shading surfaces to represent the missing stories, this isn't for cosmetic reasons but to address self shading.
@DavidGoldwasser for story_multipliers2 (different sized floors) you would make the entire floor and ceiling of the multiplier story adiabatic? This would exclude some exterior area from the top of the multiplied floors.
@macumber Ah, I see your point when the mid floor is bigger than the story above it. In that case, I agree that we should make a single copy of the mid floor with a multiplier of 1 just below the top story, and then changing the multiplier for the mid floor to 5. You could take the same approach at the bottom of the multiplied section if the mid floor is bigger than the bottom floor (like the ESIF). I can see the benefit of always treating the top and bottom this way as you have shown, so you don't need to bother analyzing adjacent stories.
By the time it gets to EnergyPlus, a multiplied zone should not have any exterior/ground floor surfaces at the bottom or exterior roof surfaces at the top (except for different use case like guest room that represents 1 of x rooms on a facade of a single story, used as a horizontal vs. vertical multiplier)
I generally like this proposal for story_multipliers2: "creating 3 levels for every multiplier story (for multipliers > 3)". But I hope it's only going to be done when there are different size stories adjacent to the story with multiplier > 1? As there can be a significant impact on simulation runtime to doing this for, e.g., the story_multipliers case.
We need to have some discussions about the desired output for stories with multipliers. Here are two test cases for discussion
story_multipliers:
story_multipliers2: