I have been working on a quiet detailed energy simulation in HB. Every zone has been created from separate HB Surfaces to which I have assigned my own EP Constructions with custom EP Materials. Because for example ceiling/floor between the zones have the layers reversed, I have modelled it twice in order to have the innermost layers always on the internal side (don’t know if this makes sense).
My problem is, that if I use the Solve Adjacencies component to ensure that during the simulation, the SW knows the heat transfer is into another zone, it ignores all my custom EP Constructions and rewrites it with the default ones. If I should specify the adjacencies for each pair of zones separately, it would take a lot of time and I am not sure, how to keep both reversed layer orders.
Is there any way in which I could deal with this?
Is the “flipping” of the construction the right move, actually?
Thanks in advance
As for the Energyplus simulation, you are correct about your construction should be “flipped” between the ceiling of space A and the floor of space B.
For example, let’s say space A is above space B , and they share a surface. Space A’s ceiling will be Space B’s floor. In reality, there is only one surface, but for Energyplus you should have two, one for each space. The construction in real life is an acoustic tile, 8 in. concrete slab, and carpet.
In this case, in Energyplus you should define the ceiling construction of space A with the outside layer being what would be the last layer from Zone A’s perspective. If you are inside space A and look to the ceiling, there is acoustic tile, then concrete, then carpet. The opposite would be true for floor B.
If you don’t flip the surfaces and you match them (you define the outside boundary of Zone’s A ceiling to be Zone B’s floor) then E+ will spit an error.
The reason why the solve adjacencies component overwrites the constructions is precisely to deal with the reversed constructions issue. Most of the time, trying to match the reversed order of materials manually would result in errors, particularly in zone-building workflows that are not surface-by-surface. So we overwrite the interior constructions to make sure that they are properly reversed between adjacent surfaces. Of course, there is often a need to have custom interior constructions and that is why the altConstruction_ input exists on the component:
You can plug in a construction here and the component will automatically make sure that the order of constructions is reversed in the adjacent surface.
We realize that there are a few fringe cases that aren’t easily accommodated by this workflow. Notably, if you have an asymmetrical altConstruction_, the order of how the zones are connected up to the component will determine the direction that the materials of the altConstruction_ are facing in the resulting Honeybee surfaces. So, if the logic of the directions of materials doesn’t follow a zone-level structure, the altConstruction_ won’t be able to help you much. Additionally, if you have two different constructions between the surfaces of two zones, you will be up a creek by only having a single altConstruction_ input.
Is your case here one of these fringe cases? If so, we can add a boolean input to the component that preserves the originally-assigned constructions. I’d imagine that this input is really just for hardcore advanced users since, as I mentioned, you really have to do your homework to get such a model to run without errors.
@chris, yes, my case really is one of the fringe cases you are describing. I think, the boolean sounds like a great idea, mostly because if I am dealing with more zones with different asymetric interzone constructions.
Just a simplified illustration: I have a concrete-based construction between the underground unconditioned garages and the conditioned zone, but a steel-based construction with a lot of thermal insulation between the conditioned zone and the unconditioned “attic”.
In todays workflow, if I understand correctly, I would have to solve adjacencies twice (or with even more zones, for each pair of zones separately) and be careful about the order of the zones I plug into the solve adjacencies component.
As for the work with matching the reverse order of layers, I really did my homework at the beginning of the setup, and I actually wrote a Python interpreter script to create the reverse construction for me (I am really a “self thought” newbie to Python, but I can provide you guys with the script to refine it and eventually include), so that I have both conctructions next to each other and I just assign the ceiling/floor to the zone surface.
In fact, that boolean to maintain the original construction of the surfaces would be very helpful.
In quite a few cases I’ve had to open and remove the part of the code that replaces the constructions. Mostly on the surface-by-surface zone workflows with different constructions, to avoid having a big number of solve adjacencies around the canvas. Definitely, for the mass-to-zones workflow it’s fundamental
You can see an example file that shows the capability in action here: PreserveAdjacentConstructions.gh (552.7 KB)
…and you will also see in that file that the use of this input requires diligence in making sure constructions are reversed but it should allow you to model the previously mentioned fringe cases.
Coming back on this one, I´ve just realised that the check to preserve existing constructions is not applied to interior windows. So the construction of child surfaces is changed to interior windows independently of the _preserveConstr input.
In case anyone needs it, I´ve just added the same check in the code after line 157 and now it seems to work well.
